Using high integration SoC alternatives for your legacy X86 design

These processors usually have higher power requirements and typically require a different and specific set of companion or support devices in order to create a fully functional system. In many cases the newer devices no longer support some of the legacy interfaces and peripherals needed by OEMs to maintain compatibility with the products they are attempting to keep in production.

Hardware Considerations
Redesigning with newer processors is often easier said than done. There are now fewer available low-end x86 compatible processors and even fewer of the support chips required to use those that remain.

Table 1. Many of the most needed functions necessary to support legacy designs are no longer supported by the newer x86-based architectures.

As shown in Table 1, above, many legacy OEM designs included ISA interfaces to proprietary system functions and although the desktop market wrote ISA's obituary many years ago, it still remains one of the easiest to use and most straightforward interfaces for driving proprietary system functions.

Other features such as the floppy disk controller, IEEE 1284 parallel port and RS232 serial port,  have been supplanted in the desktop by USB but are often still a requirement for embedded applications. As these interfaces and peripherals lose their relevance in the desktop market it becomes harder for OEMs to retain functions that their products had previously.

Additionally, the costs associated with use of the higher-end discarded desktop processors currently being offered as embedded processors often make their use impractical. Issues such as power consumption and heat dissipation requiring heat sinks and fans often eliminate the possibility of their use. Also, their lack of integration and the need for numerous other support components raises the total cost of the bill of materials and overall system cost.

A high integration System-on-a-Chip (SOC) can often be a viable replacement for a design based on a legacy 186, 286, 386 or 486 based design. The need for hardware redesign is not eliminated but it can be much simpler and in many cases can actually result in an overall system cost reduction because of its higher integration and lower power requirements.

In the attached PDF file is a feature comparison showing some of the high integration SOCs currently available and not under EOL notification. Note that it does not include devices from RDC in Taiwan and some other similar devices that use a RISC processor to emulate the x86 functions and are not fully x86 compatible. 

What about Software Compatibility?
Often the most important consideration in choosing a replacement processor is the effect it will have on the software that is already in use. Abandoning debugged, tested and reliable software can be the highest risk component of a system redesign.

The ideal scenario would be to be able to substitute another fully x86 compatible processor and eliminate as much code rewriting as possible. There are still a number of potential issues associated with porting legacy software from the pre-486 era (and even other 486 CPUs) to a more modern highly integrated SOC. In no particular order of importance these are: speed and timing dependencies, CPU features, memory, BIOS dependencies, misuse of standard adapters, and special adapter dependencies.

Speed/timing dependencies
Many SOCs can be slowed to 16MHz, for example, at which point the performance, though still higher than a comparably clocked 386, is similar. Ideally, in the long term, software would be modified to allow for calibration of delays through the real time clocks in the system etc.

For a custom solution the system clocks can be adjusted to provide any level of speed if the SOC selected is a static design. This would literally mean that the speed can be adjusted down to any level for which a clock can be generated.

CPU features
The CPU portion of many of the available x86 compatible SOCs is a proper superset of the features typically seen in the Intel 8086/186/286/386/486 and the non-Intel variants thereof.

With the exception of well documented Intel errata and a small selection of instructions that Intel introduced at the time the 386 came to market that were later removed, the most highly integrated SOCs have all the CPU features present in the Intel devices, and of course many more.

Memory issues
CPUs from the pre-286 era were very limited in the amount of memory a program could address and used a number of memory mapping, paging and other 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 a foot print of less than 640k, even on machines with 16 or more megabytes of DRAM.

The ISA bus on most highly integrated SOCs would allow the attachment of a standard LIMM card, allowing the paging memory extension mechanism to be implemented in hardware, or a better solution is the use of software such as qemm that emulates several of the normal memory extension schemes.

BIOS dependencies
Real-mode software can use BIOS features through both direct and indirect calls to code in the ROM. The typical BIOS used by SOC providers has a high degree of IBM PC/AT BIOS compatibility both in basic functionality and the specific entry points required for legacy software.

For a custom solution needing even more special requirements a custom BIOS can be developed if the OEM is willing to make the investment.

Mis-use of standard adapters
For performance reasons early PC software would address some adapters directly; the video adapter being the most obvious example. Some highly integrated SOCs have an ISA bus and allow for the use of a specific example of a video card/chip if it proves necessary.

However, modern PCI video adapters are much faster than their ISA counterparts, so if at all possible rewriting the software to use the BIOS or DOS system calls will typically give all the performance necessary and a huge increase in cross adapter compatibility.

In a slightly more esoteric hardware dependency, software that accesses hardware I/O ports directly, but assuming a very slow (5MHz) CPU may fail to allow enough time between port accesses when run on a much faster CPU.

This is not a problem on the PCI bus, but only on 8 and 16-bit ISA bus accesses. Assuming the source code is not available additional delays can sometimes be accomplished through patching code, adding wait states etc.

'Special' adapter dependencies
Assuming the adapter can be plugged into any normal PC expansion bus or port, most SOCs can probably accommodate installation and use. They typically 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 BIOS interfaces as well as driver support in Windows 3x, 9x and Linux as well as most x86 compatible RTOS.

Conclusion
Upgrading any design to use a new CPU has its risks. Choosing the CPU is often the first task and deciding whether to retain the x86 architecture or switch to a RISC architecture can have significant impact on software porting and verification.

The software risks associated with upgrading a legacy x86 design can be significantly reduced by staying with the x86 architecture. Hardware risks can also be dramatically reduced by selecting a highly integrated System-on-a-Chip that minimizes the possibility of future redesigns due to processor support chips becoming unavailable.

Finally, by selecting a CPU that is supported by or in some cases comes with fully implemented BIOS, another major stumbling block can be avoided.

David L. Feldman is the President of ZF Micro Solutions, Inc., in Palo Alto, California where he conceived of an x86 compatible embedded System-on-a-Chip that includes patented FailSafe recovery mechanisms. Prior to founding ZF, Mr. Feldman founded Ampro Computers, Inc. where he created the 5¼" EBX form factor for embedded computers and the PC/104 concept for stackable computer and peripheral modules for embedded applications. He has more than 20 years of experience in the embedded systems market. He may be contacted by e-mail at dfeldman@zfmicro.com