Programmable Logic

FPGA Design Practices That Help Ensure Good Migration

Migrating a design between an ASIC and an FPGA requires special considerations for some design issues.

by Ron Modo

FPGAs, because of their flexibility, have become a way of life for many system designers. FPGA reprogrammability saves many ASIC mask turns, and therefore, product market windows. In addition, FPGA field reprogrammability provides the ability to enhance systems or fix bugs without modifying the hardware.

The biggest advantage, however, is that a designer can obtain an FPGA from a distributor, go through map, place, and route, and then program the device in the board for a test drive.

When systems manufacturers seek ways to reduce product costs, they usually look to the individual boards. If a board contains one or more FPGAs, migrating them to mask-programmed devices and removing the supporting silicon can be attractive because of the price difference between an FPGA and a mask-programmed device. To maximize savings, the migrated device usually must be a "drop-in-replacement." That is, it must be pin-for-pin compatible and require no firmware or software changes.

When designers decide to explore migration, they often find that the very things they avoided in pursuing a quick, easy approach to circuit design cause much aggravation during the migration process. Considering migration issues before designing the FPGA is best. Generally, these issues center on using an ASIC-like design methodology because the device will ultimately be an ASIC (gate array, standard cell, hardwire, etc.).

You can get an FPGA design to operate without using good digital-design practices. Even a trial and error method will get the FPGA to function on the board. However, this may introduce unresolvable race conditions, glitch-prone clocks, and improper initialization in the migrated hard-mask device that must work across all process variations.

Another important issue is understanding the FPGA power-up and configuration timing in the system environment. Unspecified timing may allow a board to boot up using the FPGA, but this could cause a problem when an ASIC replaces the FPGA.

Design the FPGA with migration in mind When migrating a design from FPGA to ASIC, a large amount of time and energy will be saved if FPGA engineers design with migration in mind (see Figure 1). This is important because when migration efforts begin, the original FPGA designer may be unavailable for consultation.

Planning for a migration will eliminate the time and effort required to relearn the circuit and uncover the potential concerns from an ASIC design point of view. Good documentation and functional vectors will also help minimize the ASIC design schedule and migration effort.

Use good digital design techniques Asynchronous circuits are one of the biggest challenges in digital designs. While successful FPGA development may include asynchronous circuitry, this circuitry could make an ASIC untestable or cause it to have low yield or unstable performance. In most cases, following tips should result in a cleaner, more predictable design with good performance and high yield:

Figure 1. The design flow from FPGA to ASIC requires a significant engineering effort to achieve a working ASIC.

• Make the design completely synchronous. A single-clock, synchronous design eliminates asynchronous interfaces between clock domains. Circuit analysis, vector generation, and testing are easier, and the device is more reliable.

• Don't divide clocks or gate them with other signals for use as clock or data inputs to registers or latches.

• Use synchronous circuits instead of asynchronous loops or ripple counters.

• Synchronize asynchronous primary inputs to the chip's main clock.

• Don't insert analog delays in a path to ensure timing for a circuit. Using long routing wires to implement a delay will be lost when the FPGA netlist is translated. This can cause timing problems in the ASIC. If delays are needed, use digital circuits, such as inverter strings. Document this clearly because the delay elements will be optimized away during resynthesis.

• Don't implement circuits that will create spikes because the spike width may vary in the ASIC and cause undesirable behavior. Use enable signals to eliminate spikes.

• Ensure that internal buses are actively driven at all times.

• Provide for initialization of flip-flops to minimize vector count and increase testability.

Design the FPGA for ASIC testability The FPGA to be migrated should be designed with ASIC testability in mind. An ASIC must have high fault coverage. Testability can be added later, but this could add pins, making a pin-for-pin compatible migration difficult.

A design is completely testable when every node in the circuit can be controlled and observed from package pins with a minimum number of vectors. Some circuits can be made untestable if not properly recognized and addressed up front. Also, designing for testability means making the circuit nodes more controllable and observable from primary I/O. The following enhance testability:

• Use un-assigned package pins to control or observe deeply imbedded nodes.

• Breaking up long counter chains into smaller pieces that won't require as many vectors to exercise.

• Initialize every flip-flop with a global set/reset signal. Every ASIC must start from a known state when testing it in the factory. Initializing all flip-flops accomplishes this with a minimum number of vectors.

• Multiplex input and output pins to increase the internal nodes' controllability and observability.

Migration caveats In addition to designing for testability, remember these two migration caveats:

• Some understanding is required of how configuration pins (done pins, etc.) are used in the system.

• Read-back of internal configuration RAM contents cannot be supported in the ASIC.

The need for functional timing vectors While designers have certain responsibilities to ensure a smooth migration path, vendors also have a role. For example, at Lucent Technologies Inc. (Allentown, PA) our objective is to maximize the first-time success rate of customer boards (see Figure 2). One way we do this is by supplying ASICs that pass silicon manufacturing tests with vectors that functionally mimic the system's interaction with the chip being designed. These vectors, called functional vectors, should stress all critical paths, asynchronous interfaces, and I/O specifications while being run at system clock speeds. Because of this, someone with a detailed understanding of the intended chip operation, generally the FPGA logic designer, should write these vectors.

The silicon vendor does not have this functional knowledge and can only write fault-coverage vectors that will toggle nodes in the chip to detect stuck-at faults introduced in manufacturing. These vendor supplied vectors are not written to exercise the chip functionally, but to toggle each net in the circuit and to observe the result at the chip's output pins. To achieve a high level of fault coverage, vendors normally use a scan methodology. This introduces extra logic into the chip that will marginally reduce the device's maximum operating speed.

Figure 2. An important part of the design flow is the design and test documentation.

Historically, an FPGA development cycle involves specifying the circuit, either through schematic capture or a high-level language specification. A netlist is then extracted and layout is implemented. The resulting part is plugged into the target board and lab tested to verify proper device operation and implementation. If the device doesn't work on the board, the cycle is repeated until the desired operation is achieved. This imprecise method of design is viable only because a look-up-table-based FPGA can be reprogrammed as often as necessary when the circuit being developed is small. By analyzing the board's behavior, the designer can get a good idea of which part of the circuit has not been implemented correctly. However, as FPGA complexity increases, this method of design becomes decreasingly successful. A more traditional ASIC approach, using simulation of functional, at-speed vectors to determine the circuit's correct implementation, is necessary.

Although writing and simulating functional at-speed vectors is not necessary in some FPGA design cycles, it is desirable for designs that will be migrated. Of course, a design can be migrated by using fault-coverage vectors for manufacturing screening. However, this does not ensure that the translated design will work logically or meet timing specifications. In this methodology, the fault-coverage vectors will only screen out manufacturing defects but may pass initial models that fail on the board. Worse, initial models may work, but production-process variation may cause chips being delivered to fail in the system. Consequently, board production will stop and engineering efforts will be needed to extinguish this "fire."

Vendor-generated fault-coverage vectors can't specifically check (1) the timing at interfaces between multiple clock domains, (2) critical timing paths between flip-flops, (3) I/O timing specifications, (4) the paths that rely (intentionally or unintentionally) on excessive layout parasitics to ensure that timing is met in the FPGA, (5) delays added by using digital elements such as inverter/buffer strings or NAND/NOR gates with control inputs tied to Vdd/Vss, (6) that races haven't been introduced into the ASIC design, and (7) mistakes in the FPGA that would otherwise be propagated.

Without a good set of functional test vectors with which to design and test the ASIC, the chip will not be tested as thoroughly as possible. The resulting device may not be manufacturable over the full process variation of the silicon- or board-manufacturing lines. To avoid this, develop set(s) of functional vectors when the FPGA is designed. Otherwise, later on, when the FPGA is being migrated, the original designer who has all of the intimate details of the chip may not be available.

Write test-set compatible vectors For functional vectors to be useful in silicon testing, they must be compatible with the vendor's test-set restrictions; this is easier if written this way initially. Vendors may have different requirements for their test sets. Some typical stipulations are:

• Vectors must be periodic.

• Vectors must be synchronous and deterministic.

• Vectors should be organized into self-initializing sets.

• Every input should be driven in every vector set.

• Do not change an input's timing within a given vector set.

• Minimum pulse widths.

• Maximum number of different input timings per vector set.

Understanding the vendor's restrictions and writing vectors according to these guidelines will make it easier to use these vectors for the migrated device.

Proper handling of configuration pins Dedicated pins in the FPGA that are used for programming the chip are of special concern when migrating to a hard-masked device. It is usually desirable to have the migrated device be a pin-for-pin compatible, drop-in replacement. To accomplish this, an FPGA's dedicated pins must be handled carefully in the migrated part.

There may be unspecified timing that allows the FPGA to boot up properly in the system--for example, the timing for the signal PGRMN is low to any pad pulled high. This condition will occur when PGRMN is active, but the timing is not defined. An imprecise design approach may allow a designer to ignore this timing and get an FPGA to work on a board. However, when migrated to an ASIC, this timing will be different and could cause problems for unwary designers.

To avoid this and other problems, make sure you understand the configuration-pin-related timing issues from power-up through configuration.

FPGA vendors can help you understand the timing associated with each programming or special-purpose pin. This information must then be communicated to the migration-device vendor.

Summary Migrating an FPGA into a hard-masked device can be attractive from a cost-savings perspective. However, many issues can cause delays in the schedule or prevent a successful migration if not addressed early in the FPGA design cycle. These issues involve typical ASIC design concerns and configuration-pin timing. Addressing such concerns early is prudent to ensure a successful design flow.

Ron Modo is a member of the technical staff at Lucent Technologies (Allentown, PA).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@isdmag.com.

integrated system design   May1997