During the past several years End-of-Life (EOL) notices formost legacy x86 processors have increased dramatically leaving manyOEMs producing products for the embedded market with few choices otherthan significant system redesign. Often these OEMs are offered higherperformance processors that are no longer viable in the desktop market.
These processors usually have higher power requirements andtypicallyrequire a different and specific set of companion or support devices inorder to create a fully functional system. In many cases the newerdevices no longer support some of the legacy interfaces and peripheralsneeded by OEMs to maintain compatibility with the products they areattempting to keep in production.
Redesigning with newer processors is often easier said than done. Thereare now fewer available low-end x86 compatible processors andeven fewer of the support chips required to use those that remain.
|Table1. Many of the most needed functions necessary to support legacydesigns are no longer supported by the newer x86-based architectures.|
As shown in Table 1 ,above, many legacy OEM designs included ISA interfaces to proprietarysystem functions and although the desktop market wrote ISA's obituarymany years ago, it still remains one of the easiest to use and moststraightforward interfaces for driving proprietary system functions.
Other features such as the floppy disk controller, IEEE 1284 parallel port and RS232 serial port, havebeensupplanted in the desktop by USB but are oftenstill a requirement for embedded applications. As these interfaces andperipherals lose their relevance in the desktop market it becomesharder for OEMs to retain functions that their products had previously.
Additionally, the costs associated with use of the higher-enddiscarded desktop processors currently being offered as embeddedprocessors often make their use impractical. Issues such as powerconsumption and heat dissipation requiring heat sinks and fans ofteneliminate the possibility of their use. Also, their lack of integrationand the need for numerous other support components raises the totalcost of the bill of materials and overall system cost.
A high integration System-on-a-Chip (SOC) can often be a viablereplacement for a design based on a legacy 186, 286, 386 or 486 baseddesign . The need for hardwareredesign is not eliminated but it can be much simpler and in many casescan actually result in an overall system cost reduction because of itshigher integration and lower power requirements.
In the attached PDF file isa feature comparison showing some of the high integration SOCscurrently available and not under EOL notification. Note that it doesnot include devices from RDC in Taiwan and some other similar devicesthat use a RISC processor to emulate the x86 functions and are notfully x86 compatible.
What about Software Compatibility?
Often the most important consideration in choosing a replacementprocessor is the effect it will have on the software that is already inuse. Abandoning debugged, tested and reliable software can be thehighest risk component of a system redesign.
The ideal scenario would be to be able to substitute another fullyx86 compatible processor and eliminate as much code rewriting aspossible.There are still a number of potential issues associated with portinglegacy software from the pre-486 era (and even other 486 CPUs) to amore modern highly integrated SOC. In no particular order of importancethese are: speed and timing dependencies, CPU features, memory, BIOSdependencies, misuse of standard adapters, and special adapterdependencies.
Many SOCs can be slowed to 16MHz, for example, at which point theperformance, though still higher than a comparably clocked 386, issimilar. Ideally, in the long term, software would be modified to allowfor calibration of delays through the real time clocks in the systemetc.
For a custom solution the system clocks can be adjusted to provideany level of speed if the SOC selected is a static design. This wouldliterally mean that the speed can be adjusted down to any level forwhich a clock can be generated.
The CPU portion of many of the available x86 compatible SOCs is aproper superset of the features typically seen in the Intel8086/186/286/386/486 and the non-Intel variants thereof.
With the exception of well documented Intel errata and a smallselection of instructions that Intel introduced at the time the 386came to market that were later removed, the most highly integrated SOCshave all the CPU features present in the Intel devices, and of coursemany more.
CPUs from the pre-286 era were very limited in the amount of memory aprogram could address and used a number of memory mapping, paging andother extension schemes to try and circumvent this problem.
Even with the advent of the 286 (16-Mbytes maximum) and the 386(4-Gbytes maximum) DOS itself limited the “normal” running program to afoot print of less than 640k, even on machines with 16 or moremegabytes of DRAM.
The ISA bus on most highly integrated SOCs would allow theattachment of a standard LIMM card, allowing the paging memoryextension mechanism to be implemented in hardware, or a better solutionis the use of software such as qemm that emulates several ofthe normal memory extension schemes.
Real-mode software can use BIOS features through both direct andindirect calls to code in the ROM. The typical BIOS used by SOCproviders has a high degree of IBM PC/AT BIOS compatibility both inbasic functionality and the specific entry points required for legacysoftware.
For a custom solution needing even more special requirements acustom BIOS can be developed if the OEM is willing to make theinvestment.
Mis-use of standard adapters
For performance reasons early PC software would address some adaptersdirectly; the video adapter being the most obvious example. Some highlyintegrated SOCs have an ISA bus and allow for the use of a specificexample of a video card/chip if it proves necessary.
However, modern PCI video adapters are much faster than their ISAcounterparts, so if at all possible rewriting the software to use theBIOS or DOS system calls will typically give all the performancenecessary and a huge increase in cross adapter compatibility.
In a slightly more esoteric hardware dependency, software thataccesses hardware I/O ports directly, but assuming a very slow (5MHz)CPU may fail to allow enough time between port accesses when run on amuch faster CPU.
This is not a problem on the PCI bus, but only on 8 and 16-bit ISAbus accesses. Assuming the source code is not available additionaldelays can sometimes be accomplished through patching code, adding waitstates etc.
'Special' adapter dependencies
Assuming the adapter can be plugged into any normal PC expansion bus orport, most SOCs can probably accommodate installation and use. Theytypically support 8 and 16-bit ISA bus, 32-bit PCI bus, 2 serial ports,a multi mode parallel port(SPP, EPP and ECP) all with normal BIOSinterfaces as well as driver support in Windows 3x, 9x and Linux aswell as most x86 compatible RTOS.
Upgrading any design to use a new CPU has its risks. Choosing the CPUis often the first task and deciding whether to retain the x86architecture or switch to a RISC architecture can have significantimpact on software porting and verification.
The software risks associated with upgrading a legacy x86 design canbe significantly reduced by staying with the x86 architecture. Hardwarerisks can also be dramatically reduced by selecting a highly integratedSystem-on-a-Chip that minimizes the possibility of future redesigns dueto processor support chips becoming unavailable.
Finally, by selecting a CPU that is supported by or in some casescomes with fully implemented BIOS, another major stumbling block can beavoided.
David L. Feldman is the Presidentof ZF Micro Solutions, Inc., inPalo Alto, California where he conceived of an x86 compatible embeddedSystem-on-a-Chip that includes patented FailSafe recovery mechanisms.Prior to founding ZF, Mr. Feldman founded Ampro Computers, Inc. wherehe created the 5¼” EBX form factor for embedded computers andthe PC/104 concept for stackable computer and peripheral modules forembedded applications. He has more than 20 years of experience in theembedded systems market. He may be contacted by e-mail at firstname.lastname@example.org