Ernest's 'Edicts'

Sticking with standards

By: eg  

In the past, many of the most important specifications and standards in
embedded computing were directly related to the underlying bus structures and PCB form factors of embedded systems. When designing a new system back then, one of the first design choices was the selection of a bus standard. This choice would then dictate many of the overall specifications of the end systems, including the price point, as well as determining the set of vendors who would make up the pool of potential hardware suppliers. So much for history. 

Over time, as the footprint and price point of useful compute engines shrank, the need for an open bus has diminished. Today, the footprint has shrunk to the point where in many instances a “standard” form-factor expansion bus is not needed or required because the entire system can be implemented on a single (albeit proprietary) card. Nevertheless, open standards remain critically important to the embedded computing market. It’s just that many of the important standards today don’t have anything to do with a backplane bus or a board form factor. 

If you don’t want to be on the bleeding edge of technology and your end application has more than enough market risk and you don’t want to make the situation worse by piling on additional technical risk, you may want to stick with open specifications and standards.  

Here’s a short list of some of the important (and most prevalent) open standards in common use in the embedded computing marketplace today. Stick with these and you will be assured of having ready acceptance in the world market, a choice of multiple vendors for key system components, a performance upgrade path in the future, and perhaps at least some chance of minimizing technical risk in the product development. 

o DisplayPort and/or DVI (Digital Video Interface) for a video interface

o DDR3 SDRAM  (JESD79-3) for computer memory modules

o GDDR3 (SDRAM3_11_05_07) for graphics controller memory

o SATA/eSATA for a disk drive interface

o USB  and/or FireWire/1394 for peripheral attachment

o 10/100/1000 Ethernet (IEEE 802.3) for LAN connectivity, and

o PCI/PCIe/PCI-X for a card expansion bus. 

As you look over this list, you might think: “This is a PC list. Why don’t I just use a PC?” This, of course, is a very good question because PCs now come in all manner of sizes and configurations, with a variety of price points. And if your end system can indeed be implemented on a PC, then you might want to think long and hard about why you’re considering proprietary hardware. 

But even if the compute engine portion of your embedded systems can be implemented with a garden- variety PC, oftentimes the differential advantage of the entire system is wrapped up in the application software and some “special” I/O hardware–that last little bit of hardware that is critical to the entire system. In the past, it would have been implemented on a full custom I/O card, but today it can be handled with a single FPGA. Not only does the FPGA supply the custom hardware needed for the current application, but the “programmable” part can also support future functionality and future product differentiation. 

But how can you implement an FPGA based system today, with the I/O connectors that the system will need in the future? Fortunately there’s an open specification that can help here as well: the FPGA Mezzanine Card (FMC) specification, aka VITA 57.  It’s been around for a couple of years, so companies are now starting to deliver FMC-compliant hardware, and VITA recently established the FMC Marketing Alliance. The FMA already has ten member companies, so there’s a good chance that your proprietary I/O needs can be satisfied with standard hardware that conforms to the open FMC specification.