SMALL FORM FACTOR FORUM
Software Compatibility with the Flick of a Switch
COLIN MCCRACKER & PAUL ROSENFELD
Page 1 of 1
Ahhh, software. Can’t live with it, can’t live without it. Or so it seems during some projects. In this new world order of limited development budgets, it’s certainly the 800-pound gorilla in the room.
There was a time when hardware could be chosen first, then operating systems and development tools, and application software development occupied the rest of the project. In this highly evolved world of FAA, FDA, FCC, CE, EMI, UL, EN, NEMA, IP, MIL-STD and other regulations, certifications and compliance requirements, developers have a great deal of incentive to reduce and reuse. Just like a municipal recycling program.
Faced with extensive re-certifications, the clear choice is to ensure that new hardware maintains software compatibility at all levels. In some cases, certification filings themselves are drastically simplified if the code remains unchanged. Ever wonder about the 286-class system running the hospital equipment you’re hooked up to? Try implementing a memory hole, an A20 gate, assigning fixed IRQs, or initializing a PS/2 keyboard in the dawn of the UEFI BIOS era on a multicore low-power processor with dual PCI Express x1 lanes…a feast for a firmware king or queen if there ever was one. How about booting a custom OS for which the source code disappeared during the last millennium? Job security for a contractor, or that old software guy that retired a few years ago.
The hardware designer gets to search the world over for that elusive legacy-friendly specification on a component or board datasheet, the proverbial needle in the haystack. For if such electronics cannot execute the 800-pound code properly, it’s back to the hardware drawing board. That code ain’t gonna change.
For those lucky enough to be working with application source code in a high-level language like C with a robust, industry-standard OS interface, life is easier. Not only is the migration from platform to platform less painful, but moving to a completely new CPU architecture and instruction set is within the realm of possibility. At worst, the software engineer rolls up his or her sleeves and plays around with a compiler switch or two–endianness, registers, not a big deal. There are always a few “gotchas,” and verification and field trials can be tall orders, but the application remains fundamentally intact. Compatibility with the “flick” of a compiler switch.
Suddenly, the enticing set of new low-power, small form factor components and boards can lead to stretching that ol’ code for one more generation. The software engineer insists upon four PCI bus masters, but that tiny 5-watt board comes with a “legacy-free” warning label. Tiny IC packages present several space-efficient, speedy PCI Express links instead of the legacy PCI bus. Now the question becomes how to attach those four PCI-style (or worse, ISA-bus) devices.
For designers accustomed to maintaining ancient code along with the processors to which they are shackled, the term “PCI Express” may sound like massive overkill. At 2.5 times the bandwidth of parallel PCI, and duplex capability on separate transmit and receive differential pairs, each of the point-to-point PCI Express lanes has more than enough performance. Best of all, software protocols are preserved going from PCI to the equivalent PCI Express device.
But as a point-to-point bus, each of the four PCI devices would require a separate PCI Express lane. For new chipsets with only one or two PCIe x1 (“by one”) lanes, there is plenty of bandwidth to cover the four bus masters. Commercial PCI Express switches allow the mapping of one lane to multiple lanes, and the switches are smart enough to figure out where the data needs to go. This time, hardware saves the day, and software compatibility is maintained with the flick of an Express switch.
Modern chipsets offer plenty of new alternatives for attaching low-speed peripherals and I/O, although minor code changes are needed to make the connection (otherwise known as the “no free lunch” rule). For example, board-to-board communication over serial ports can be modified to ‘speak’ I2C, LPC bus, or even SPI. Some of these are processor-agnostic, and this type of code change is certainly simpler than converting to heavyweight, driver-intensive USB, Ethernet, or PCI Express communications. Even ISA-bus-dependent code can be preserved with PCI-to-ISA or LPC-to-ISA bridges and ISA cores in FPGAs. New chipsets and programmable devices give hardware designers an “out.” After all, if the software engineer isn’t happy, nobody is happy.
Comments about this topic can be sent to firstname.lastname@example.org.