Challenges in Emulation Using FPGAs

The basic challenge is to stitch the hardware, the tool software, and the RTLmapping flfl ow with the evaluation board and components. This section breaks up the challenge into multiple parts and sections. Section 18.4 then explains on how to deal with these challenges.

Design Logic and Memory Size

The engineering choice is to use one FPGA which fifi ts the design. However, sometimes the DUV may be bigger than the largest FPGA available. Even otherwise, sometimes fifi tting the DUV into two smaller FPGAs is cheaper than using the largest FPGA available. If the design is skewed toward huge memory blocks, the FPGA tools can map parts of unmapped logic on the FPGA tile for memory blocks. For an emulator using FPGAs, (since the testbench is embedded into the FPGA) large memories like flfl ash, DDR pose mapping problems. In such scenarios the emulator is fifi tted with large external memories which are then remodeled to behave like flfl ash and DDR. Note that this remodeling is done through custom instrumentation insertion prior to using Vivado P&R tools.

Design Pin Count

The FPGA (or an array of FPGAs) must be able to support the relevant pin count of the device being emulated. In general, for emulation purposes a synthesizable testbench is used, indicating that there are fewer external connections. In certain cases, flfl ash memory can be real components on the board which are then pinned-out to the board.

Clocking

Clocking between FPGAs and ASIC/ASSP is different. In an ASIC/ASSP there could be many hundreds of clock domains with multiple PLLs embedded. Each root clock derived from a PLL can have multiple secondary clock generation logic (say for dividing clocks, test clocking). Furthermore, sets of flfl ip-flfl ops or registers in the design can have clock-gating circuit implemented as part of power-reduction techniques.

FPGAs usually have a limited number of PLLs and a limited number of balanced clock channels incident upon a larger cluster of flfl ip-flfl ops. The challenge is to straighten up the ASIC clocks to map it easily onto the FPGA clocking.

RTL Constructs and Remodeling

Several RTL constructs are not FPGA friendly. These need to be modeled appropriately for FPGA. The remodeling has to be done without modifying the functionality. A module RTL makes it easier and scalable since there is a great usage of common cells in the design.

IO Pads Modeling

IO pads typically have tristate functionality. Usually, these IOs of the DUV are connected to the BFMs in the testbench. Recent FPGAs do not have built-in tristate gates. For FPGA usage, you need to remodel the tristates as shown by the example in Fig. 18.3 . The Xilinx ISE/Vivado toolset automatically transforms internal tristates into logic elements.

ADC Module Modeling

For a module with analog behavior (e.g., ADC/DAC), you need to appropriately model to ensure that its boundary talking to the digital side of the design is clean. For example, an ADC module can easily be modeled with a memory and digital

Remodeling of typical IO connectivity within testbench between DUV and BFM.png

output. The memory can be preloaded with the kind of analog behavior we expect out of the design. Alternatively, an ADC can be placed on the FPGA board and the digital output can be used as an input to the design. If the ADC module is deeply embedded into the DUV, you need to bring out the wires from the embedded hierarchies onto the top level of the testbench.

For Xilinx FPGAs you can use the SYSMON module (explained in Chap. 16 ). However, you still need to take care of:

• Performance of the SYSMON for emulator clocking

• The analog stimulus to be fed to the SYSMON

• The appropriate remodeling of the ADC to instantiate the SYSMON into it

Memory Modeling

Typically the RTL has memories which are either ASIC technology memories or modeled as a memory array. Also, the RTL memory model could have test logic embedded into it. Remodeling memories for FPGA is typically a four-step process.

1. Identify the memories in the design. If the memories belong to the same technology node, then the entity is usually identical except for the address and data width. Sometimes, there might be variants (e.g., byte-wise write).

2. Remodel the memory component with an equivalent FPGA friendly construct. If you are not interested in test logic, they could be tied to their disabled state. This remodeled memory component is then verififi ed to be true using simulation. If the memory needs to have user-defifi ned preloading or dynamic preloading, then explicit instrumentation needs to be added.

3. One level of FPGA synthesis and run is carried out to flfl ush out the flfl ow.

4. Create a scriptware to convert all the flfl avors of data and address widths.

Steps (2), (3), and (4) are true for all types of remodeling done at RTL level, but it deserves a special mention for memories since there are many types.

Standard Cells Modeling

It is best to have synthesizable view of the technology standard cells in the design. Most technology libraries provide the synthesizable view of standard cells.

Inferred Components Modeling

Some RTL descriptions infer multipliers, dividers, special Register Files, FIFOs, etc., during the ASIC synthesis flfl ows. These components use compiled models/ descriptions for simulation. Such components will end up as being unresolved. A way to resolve this problem is to actually do an ASIC synthesis and use the verilog equivalent for the said component. Thus:

FPGA RTL view = synthesized netlist from ASIC tool + the synthesizable RTL view of technology std-cell

FPGA Board Design

The FPGA-based emulation system is very much dependent on the FPGA board design. In particular, the number of FPGAs in the array, the capacity of each FPGA in the array, the external memory connected (for modeling large memories, for dynamic waveform dumping, and for using memory as Look Up Table for large pieces of logic with huge fan-in cones), and the external connectors, switches, GPIOs, and LEDs are provided. Its levels of complexity are higher to move from one FPGA-based emulator to another than it is to move across simulators from different vendors. The basic complexity is due to the use of hardware for emulation and so it is fifi xed. This complexity makes it diffifi cult to make sound design and fifi nancial decisions for the right choice of FPGA-based emulators. FPGA vendors provide a chart with logic gate count estimates, IOs, memory blocks, SERDES blocks, and DSP blocks within the FPGA.

TABLE OF CONTENTS