BROWSE BY TECHNOLOGY










RTC SUPPLEMENTS


SMALL FORM FACTOR FORUM

When did Legacy become a 4-letter word?

COLIN MCCRACKEN & PAUL ROSENFELD

  • Page 1 of 1
    Bookmark and Share

Once upon a time, embedded systems engineers would anxiously scan data sheets for new embedded components and boards looking for those magical words “Backward Compatible” or “Upward Compatible” to provide some level of assurance that the customized hardware and software they had developed over the years would continue to work with the new thing they were considering. Embedded manufacturers, anxious to keep existing customers, realized that product upgrades represented the fastest time to revenue of all potential OEM opportunities, thereby mandating compatibility with prior solutions. At that time, the quickest way to kill a new product was to force the OEM to start development from scratch.

The compatibility king, if you will, was Intel. All the x86 processors developed over the last 30 years continue to run code originally developed for the 64K memory space of the 8008 processor in 1973 (now affectionately known as “real mode”). For all you young'uns out there, that is really a K, as in kryptonite. As the few remaining engineers who may have been forced to sit through a computer architecture class might know, it was possible in those days to construct a complete embedded application in that space by carefully selecting each individual machine instruction. Can anybody under the age of 50 write assembler code today? But we digress.

Sometime in the last ten to fifteen years we got lost. What Intel giveth, Intel taketh away. While real mode lives, the ISA bus that interconnected the processor with virtually all the I/O in original PC systems sadly does not. This first little chink in the compatibility armor sparked two simultaneous and ongoing sets of events. The first event was an industry-wide effort to find some possible way to replicate the bus external to the processor / chipset. This led to a number of bus bridge products that recreate much but not all of the original ISA bus. The second event was a massive engineering effort to start redesigning existing I/O (both hardware and drivers) to utilize new bus technologies.

That sort of opened the floodgates. If Intel could kill off ISA, imagine what else we could dump.  We have USB—who needs RS-232 serial ports? PS/2 keyboard and mouse—who needs ?em?  The PCI bus just wastes a lot of pins. Who needs it? And the parallel printer port—well maybe that one was OK to kill.

In the last ten years, we’ve moved from burying incompatibilities in spec sheets in the hope that no one would notice to shouting from the rooftops—Legacy Free. It’s tantamount to putting a big, bold, boxed warning sticker at the very top of the spec sheet:

Guaranteed not to work with anything you’ve previously developed—hardware or software

What’s next? Now that we have USB 3.0—do we really need to support the previous versions?  And PCI Express Gen 2, let alone Gen 3. How quickly can we dump the previous versions and move on to the next generation? The really clever folks don’t bother to deal with revisions or gens at all—just create a new “type.” As each new type arrives, compatibility with existing types seems not to be a consideration at all. COM Express type 74 is just around the corner!

The good news is that there are signs of resistance. Have you noticed the new PC/104 cards with the Atom processor and the ISA bus? Huh? The Atom chipsets don’t even support ISA. And where’s PCI Express? It doesn’t come off the board. Maybe it’s not required by the many OEMs who just want a new CPU to replace one that is EOL? Blasphemy.

It’s time for suppliers to recognize that there is a lot more demand in the embedded space for “backward compatibility” than for the latest new whizzy bus or interface. I/O vendors reluctantly start new designs for the new bus architectures, looking for a CPU to plug into. CPU vendors look at the paucity of I/O cards that support the new bus architectures and wonder how an OEM can build a system.

We got ourselves into this mess and we need to get ourselves out of it. It’s time for system OEMs to teach suppliers that legacy free means customer free. OEMs can and should adopt new technologies as the benefits from those technologies expand capabilities in their products, but they should insist on doing so only with products that incorporate a smooth, backward compatible migration path from the key technologies of yesterday.