A recent white paper about a study exploring issues facing engineers during the design process identified a number of items that are “essential to the design process” but can be difficult to find. At the top of the list were reference designs and application notes. This is in spite of engineers being able to access a wider range of materials across multiple sources via the internet than ever before.
I think part of the reason why these two types of information are identified as essential and difficult to find stems from the growing complexity of contemporary processors. The number and variety of peripherals and special purpose processing engines that are being integrated into today’s newest processors create a steep learning curve for any developer trying to use these devices in their projects. Providing a compiler and debugger does not sufficiently compensate for the amount of effort to master the complexity of today’s processors without negatively impacting the project schedules.
The term reference design can apply to a wide range of materials. An article about reference designs presents a taxonomy for reference materials based on application complexity and design completeness versus broad to application-specific implementation details. If, as the article identifies, reference designs are a sales and marketing tool, why are such material difficult for developers to find?
One possible reason is that developers do not consider reference materials as essential. Another reason is that reference designs, by their nature, apply to a small swath of processors in a huge sea of options, and this makes classifying and getting these reference designs in front of interested developers challenging at best. Attempts by third-party information sources have had limited success at aggregating and connecting the appropriate reference materials with relevant processors. As evidenced by the conclusions of the referenced study, even processor vendors themselves are experiencing limited success getting word out about their own reference materials.
How important are reference materials in choosing and working with processors and other complex components in your designs? Are all types of reference materials equally important or are some types of information more valuable than others? Is aggregating reference material with the appropriate component the best way to connect developers with reference material? What good ways to classify reference material have you seen that help you better find the material you are looking for without having to wade through a bunch of irrelevant reference material?
Tags: Application Notes, Referece Designs, Tracker
A timesaver in either understanding the application context or in providing a canned solution when you have other aspects of the design to worry about.
For new graduates and engineers with few years of experience its important to have good reference designs and/or design guide at least to verify themselves that they are on the right way doing the job.
sometimes its useful in some small details and tricks in the design game that may save you time and efforts, and in case if you are doing a relatively big design that contains many modules or sub-modules, then instead of reinventing the wheel you take some of the modules implemented in the ref. design document and reuse/integrate with your design, however I have to admit that reference designs are not always useful, sometimes they are, sometimes not.
In my experience (I am NOT a new graduate), reference designs can bring you up to speed quickly on new hardware (i.e.: a processor family or communications protocol you have never used before).
Unfortunately, embedded reference designs require software to finish the demo. Whereas I have had little difficulty adapting the schematic of a reference design to my design, the accompanying software is rarely as understandable as the hardware. Often understanding software provided with one of these is so poorly designed it ADDS complexity to the point of nullifying the advantage of the reference design, vis-a-vis starting from scratch.
I have found no correlation between the reputation of the manufacturer as a hardware company, and the quality of the “reference software.” It is also difficult to tell from a web site ad what you are buying.
I try to keep the reference material as just that, reference.
Wholesale copy pasting of reference modules means you have just included a very unknown and often last minute slapped together component into your design.
I prefer to create each required module from scratch and define the interfaces required by the project itself. Then use the reference material as a reference to indicate the necessary steps and operations for each interface.
Thus the code created will always match the coding standard for the project as a whole and code you create yourself will always be clearer in your mind that code you have copied in.
This does take longer than the copy and paste method but not as long as wading through the documentation and creating the module from scratch.
That hopefully give a happy medium between development time and maintainability.
The reference designs provide a snapshot of what the chip designers suggest for the chip/chip family. They are often genericized but contain comments about assumptions made, and alternatives for customizing a design. This goes both for code, and for hardware design.
I tend to use them as Gary suggests, as a hint about how to start with the hardware and software for hw I haven’t used before. In this case they become a great reference material, and sometimes a debugging aid.
Reference designs are particularly important in wireless applications when you don’t have an RF engineer on your staff or team. Antenna design and matching can stump engineers and a reference design gives them something that works and that they can duplicate. As to application notes and similar materials, one glaring problem involves poor organization of information and lack of a taxonomy at the vendor, which makes searching a chore. Several of the big-name MCU vendors have terrible search engines that pull up repeated references to the same information or that miss key information completely. They might have just the application information or note you need, but their search engine can’t find it. By the way, the Gruntware Gopher software lets you do a parametric search for MCUs and then links to vendor information, third-party tools, dev kits, and so on. That sort of approach is valuable. And it’s available for free. –Jon Titus
Several years ago, when the IBM 440 microcontroller was new, I was delighted to see it finally enter the market, having had earlier to resort to various interconnected systems of multiple IBM 405s to get the necessary processing speed and memory bandwidth the firmware group needed on a single datacom blade. With the 440, my hardware design could be drastically simpler for the same throughput, and needed only a single processor with a single memory bank. I designed the prototype by reducing the generic PC-clone reference design to my minimal requirements – but once built, it took way too long to discover why the memory interface was behaving intermittently. In the end, it turned out that the Memory Bank Select pin (described in the user manual only as “selects memory bank”) was required to provide critical timing to the interface of even a single bank of memory. Moral of this drawn-out story (sorry): Lacking adequate written documentation, at least the reference design provided one working configuration. I should have paid more attention to it.
“If…reference designs are a sales and marketing tool, why are such material difficult for developers to find?”
Um, perhaps because the microprocessor vendor declined to create and promote the reference designs? In my opinion, this is a big mistake. As others have alluded, a reference design with working hardware and software provides proof that the chip works in at least one context. This hardware+software context provides a starting point for creating whatever end-system is really needed.
Frankly, creating the end-system is an exercise in risk management. Every new concept that goes into the end-system represents a risk. The more you can borrow from the reference design, the lower your risk. If you get really lucky, you will be able to create an end-system with few hardware and software changes from the reference design. If that is not possible, then at least you can start with the reference design and begin making necessary changes to create the end-system. At least then you have the working reference design to which to fall back.
Anyone can benefit from a reference design, regardless of experience.
Vendor demo/prototype boards have been very valuable because they let us start on our port and development early. We have been able breadboard some of our peripherals for additional benefit. I maintained the BSP for the prototype board in the product base code for years, just in case we wanted to try an upgraded CPU with a new prototype board. The paper reference designs can be a good start or just a sanity check against our own paper design. And, I collect all of the application notes; engineers may collect tips for years before tech pubs does an update. There’s more — I don’t know about other vendors, but Freescale provides a configuration tool for its more complex microcontrollers. This tool helps refine the legal as well as desired desired periperal set, tradeoffs and pinout. It can save weeks studying the documentation, and much head scratching. All of these help us reduce risk and improve time-to-market.
I have used reference designs mainly to clarify points where the documentation is unclear, such as EXACTLY what a particular pin is for, and how it should be used, and to give me confidence that the component will be completely suitable for my purpose. Occasionally I’ve used them as a test configuration for detailed performance testing with samples. Sometimes they’re useful for suggesting auxiliary components. They are always valuable, because, I assume, they have been thoroughly tested and found to work well. I also agree with Franz’s comment.
In my experience reference designs aren’t thorougly tested. They are usually put together in a hurry to provide a sales and marketing platform for a new device and as a consequence are buggy and incomplete. Support is usually sporadic and often stops altogether once the next generation device is launched, even if the vendor is still actively promoting older generations. The software is invariably badly written and poorly commented and documentation (if any) is incomplete, incorrect and out of date.
Functionality is generally restricted to those features that are required for demonstrations and features that aren’t immediately visible to the user, such as power management, are typically not implemented at all or implemented so badly that you have to do them again from scratch to get them to work. Of course some vendors are better than others, but I have yet to find a reference design that does not suffer from at least some of these problems.
On the plus side, a reference design is a far better starting point for your own product than a blank sheet of paper. You know that most of the hardware will work, at least in its default configuraion, even if it isn’t optimal. The software will at least boot up and allow you to interact with the system. So it’s a great deal better than nothing, but still, you gets what you pays for.
ST had a habit of publishing reference designs, then refusing to publish the software that ran the demo. They claimed they could not give it out due to license restrictions.
I agree with A.’s observations. The only stuff that will work on the reference design is the stuff that ALREADY works on the reference design. i.e. the default. At least it can help.
I agree with everyone’s comments. The reference design is valuable as a working starting point and proof for your design. A reference software can be as little as a bunch of test modules to a full set of scalable modules. You need a reference software and hardware to work on while waiting on your prototype board. I’ve never
seen a vendor not offering a reference design.
Sometimes you can extract what you need into your own design. Sometimes the chip is so complex that you need to work from their firmware foundation especially if you don’t want to void their support.
There can be support difficulties even if you do base your hardware and software on their reference design. The moment you make any changes to the reference design they start saying that you should reproduce any problems using their hardware and software before they will investigate. This isn’t always easy to do, especially if you are using features and functions that are not supported by the reference design.
Another nasty surprise they can spring on you is to re-architect their software in update releases. Once you’ve made any significant level of adaptation to the code in a previous release, taking the new release (which is usually necessary if you want bug fixes or enhancements) becomes a significant task. You have to understand the new architecture, how it maps on to the old one and work out how to port your changes to it. All of which leaves you in much the same state that you were in before, but still with a shedload of regression testing to do.
We’ve been on the receiving end of both of these experiences in the past 48 hours so as you might expect I’m feeling a touch aggrieved!
@A. I’ve been there too. You want to be responsible for your own design by knowing every aspect of your modules and not take in 3rd party baggage. That’s what I did in my last project. However, when it comes to more complex chips where much of the firmware resides on the host processor, the vendor’s firmware is part of the total solution. For example a media chip or a LLC chip. You’re at the mercy of the vendor to provide the patches and conformance.
You hope that they are as good as they claimed to be. It sounds like that vendor did a super poor job with their firmware.
Many good points above!
One slight side-issue this made me think of – some vendors (Infineon comes to mind) produce software to “auto-generate” the initialisation code from some set of more user-friendly set-up (e.g. this PWM channel is at 1kHz). Such tools are IN NO WAY a substitute for a properly documented “reference design”. At best they generate truly ugly code that almost does the job and nearly fits into a system not dissimilar from what you’re building. At the end of the day, all you can do with what they produce is try to use it as if it were a reference design, but since it’s so badly structured and undocumented, that’s no easy task.
Good reference designs are valuable to me because microprocessors are not that easy to program or to use as they have been decades ago. Some microprocessors can’t be used without software examples, which are a first step to reference design.
Rockwell did a great job with the AIM 65 and the CO-ED programmer, and then with the RM65 series boards. All aspects of a microprocessor systems, each with it’s own PCB and software, well documented and immediately to be used. I never saw such a sophisticated reference design ever since.
Now I am using Forth for my projects. With Forth I can evaluate a new microprocessor interactively.