Using FPGAs to avoid microprocessor obsolescence

John Swan (Lattice) and Tomek Krzyzak (Digital Core Design) - March 05, 2008


One way that silicon suppliers reduce manufacturing costs is by discontinuing older product portfolios leading to microprocessor obsolescence. Multiple versions of those processor cores and a mix of integrated peripherals complicate the situation, leading to a plethora of silicon incarnations for each particular processor architecture.

By integrating peripherals into a single die with a microprocessor, the supplier could target the microcontroller to a particular application domain with high volume needs. (Throughout this article, the term "microcontroller" refers to the entire component, including the processor core and integrated peripherals.)

As applications and the standards by which they operate evolve over time, the narrower market space of the microcontroller design makes it more vulnerable to obsolescence. This article examines the options that are available to designers facing microprocessor (and microcontroller) obsolescence using FPGAs.

Before considering those options, however, it is helpful first to consider FPGA technology as a means to address the challenge of microprocessor obsolescence. On a LatticeXP2 FPGA, for example, the CPU core of a 68HC11 compatible can be implemented as fully synthesizable code in just 2600 slices. Implementing all the peripherals integrated on this component – as illustrated in the 68HC11 compatible microcontroller shown in Fig 1 – will increase this by a few hundred slices.


1. D68HC11 microcontroller implementation.

In addition to easily fitting onto today's FPGAs, this implementation can run, if desired, up to 5 times faster than the original 8-12 MHz component.

The technology curve
FPGAs let designers take advantage of the technology curve while protecting their designs from microprocessor obsolescence. The peripherals, or some combination of them, may also be in danger of obsolescence.

In addition to handling obsolete microcontrollers, the FPGA technology curve provides options for integrating surrounding functionality onto the FPGA and so reduces the overall system cost and eliminates concern over other components that may be discontinued.

While both SoC-based microcontrollers and FPGAs follow a technology curve as illustrated in Fig 2, with synthesizable RTL and FPGAs designers are protected from future obsolescence, not to mention the huge NREs associated with ASICs.


2. Technology curve adds integration headroom.

The technology curve graph in Fig 2 demonstrates the relative equivalent logic complexity of microprocessors and microcontrollers implemented in silicon versus a soft implementation in an FPGA. As we see, at the time the original microcontroller becomes obsolete, available FPGA logic density is much greater than what is required to implement the microprocessor and its peripherals.

This additional logic, called Peripheral Integration Headroom, will only grow with time as FPGA densities continue to increase. Indeed, the D86HC11 illustrated in Fig 1 includes the DoCD block, which provides real time, non intrusive system debugging; a function not originally integrated into the original microcontroller.

FPGAs offer a range of design trade-offs, so the designer is given choices in implementing a solution. Designers have the following options:

For example, a 68HC11 MCU in production use is discontinued by the vendor. In evaluating possible approaches to this problem, a customer might stipulate that the replacement part has to work identically as the original in terms of functionality and timing, and also that the same binary program has to run without modification.

The customer decides to use a D68HC11 IP Core from Digital Core Design (DCD) in a LatticeXP2 FPGA from Lattice Semiconductor. The on-chip Flash of the LatticeXP2 allows for a simpler design with a lower parts count (Fig 3), because the non-volatile LatticeXP2 does not require an external Flash memory or other circuitry to load the FPGA configuration.


3. Typical implementation for Option 4.

The customer initially might have considered replacing the original 68HC11 hardware with a completely different processor, but this approach would have required replacing the application software. That would have been a daunting task, because the software was written in tight relation to 68HC11 instructions and internal peripherals. Consequently, switching to a new processor would have required considerable effort and time just for the software redesign.

As a result, the most sensible solution would be to replace the discontinued 68HC11 with an FPGA implementation. This option would allow the design team to focus on validation of the D68HC11 IP core inside the FPGA, and avoid changes to any other part of the system (software application, external on-board components) that had worked perfectly for over 15 years.

The most important requirement is to achieve complete software compatibility with the original microprocessor. Not only must the same binary code run on the D68HC11, any change to the binary code is unacceptable. In such cases, the additional restriction is to maintain cycle accuracy of the instructions. This is critical, because the legacy software may use timing delays made with instruction loops. In addition, some of its functionality or peripheral interfaces may rely on exact execution time measured by instructions and clock cycles.

Peripheral compatibility can be difficult to achieve when using this approach. In this case, however, all the digital parts were readily implemented with identical functional and timing behavior. Most of them were off-the-shelf IP core components already designed and verified in the DCD core library.

A related common problem is the replacement of the analog components of the microcontroller, such as Analog-to-Digital converters (ADC), power-up/power-fail reset generators and clock oscillators. The FPGA, being a digital programmable device, can implement any digital interface logic related to these functions, but not the analog circuitry itself.

Replacing the digital functionality of a previously integrated ADC is possible using the FPGA implementation. It is necessary to take an external ADC converter and design a D68HC11 interface to it. Since no currently available ADC has identical conversion accuracy to the original component, one with superior characteristics is selected. The requirement is to have register functionality that is identical to the original ADC interface, including all translation of the control and status signals between the ADC and CPU. The conversion timing must be the same as well. This is the main job of the ADC-interface, implemented inside the FPGA as an additional module of D68HC11.

So, a direct replacement of the legacy part would consist of a small PCB containing the FPGA chip, ADC chip, clock generator and original PLCC socketed for direct connection to the customer's system. No software development or changes to the original board would be necessary.

Most of the IP cores used in this FPGA implementation would come from the DCD library and already be fully verified. Any new peripherals needed would be designed to match the requirements of the legacy 68HC11. These new peripherals would be carefully verified against the original peripherals' timing and functionality. The use of an FPGA would also be ideal for verification, since changes made in the HDL code would be verified on the FPGA almost immediately.

Conclusion
In this article we first highlighted the real problem of microprocessor obsolescence and the challenge it presents. We then presented the FPGA-based options available to designers who must deal with discontinued microcontroller components, and we offered a way to future-proof new designs that require a microcontroller.

We demonstrated how FPGAs offer a solution to the problem of obsolescence as well as offer a range of options that can integrate functionality, reduce board cost and real estate, and increase visibility into the design for debugging.

John Swan is an IP (intellectual property) Product Marketing Manager at Lattice Semiconductor. Before joining Lattice, John was with Motorola Corporate Labs for twenty years in the areas of SoC design and design methodology. His experience also includes marketing and sales as SoC Consulting Manager at Mentor Graphics and at SwanOnChips. John received a BSEE in Computer Engineering, Magna Cum Laude, from the Illinois Institute of Technology and an MBA from Roosevelt University, Chicago.

Tomek Krzyzak is a co-founder and Vice President of Digital Core Design. Krzyzak has more than 10 years of experience in the FPGA and ASIC industries, and holds an MSEE degree from Silesian University of Technology.