FONT SIZE : AAA
There are ways of achieving some degree of controllability and observability on an FPGA-based emulator, albeit at the cost of performance, logic area, and memory requirements. A general observation is that about 10 ~ 40 % (depending on design specififi cs) of the design overhead on an emulator is attributed to addition of instrumentation for controllability and observability. At each step of the instrumentation addition, exercise care to maintain the equivalence of the design.
Let us assume that the emulator adds an instrumentation port (say Instrumentation JTAG or iJTAG) through which it can carry out the functions of observability and controllability to the design. This instrumentation port provides an interface to the user using a host computer. Figure 18.7 logically explains the two ports needed for an emulator. Modern emulators like Synopsys ZeBu use the PCIe as an instrumentation port.
The emulator start-stop is affected by the clocking. If the clock to the logic blocks does not tick, the emulator is in stop state. The instrumentation needed to achieve the purpose are:
 port connecting host computer and the emulator.png "Instrumentation (iJTAG) port connecting host computer and the emulator.png")
1. Create a set of clock gates in instrumentation through the use of the BUFGCE , BUFGMUX , etc. The BUFGCE is used for Enable . The BUFGMUX is a mux between instrumentation mode and functional mode.
2. Create a set of counters, preferably one per primary clock. It should be possible to start, stop, and free run the counter. A set of count comparators, then could gate the clock to the functional logic blocks. Through the iJTAG one can write into these instrumentation registers which control the counters and clocks.
3. Using similar control instrumentation, you can also have some DUV internal signals trigger or stop the emulator clocks.
The RTL synthesis process for FPGA optimizes out intermediate combinatorial logic signals. This scenario is in contrast with “array of processor”-based emulators, where each node can be maintained within the processor database.
• For the registers, using the iJTAG port, and decoding logic-related instrumentation, it is possible to have full controllability and observability. Figure 18.8 gives a feel of the instrumentation to be added for a register (flfl ip-flfl op).
• For intermediate signals (part of combinatorial logic), a monitor flfl op and control mux can be added to gain controllability and observability. There are multiple methods to enable these instrumentations:
• Modify the RTL to add pragmas known to Xilinx Vivado tool suite.
• Use a netlist editor tool post functional synthesis.
• Use a dedicated vendor tool for instrumentation insertion. Example Synopsys ZeBu tool suite does a seamless instrumentation insertion tailored to the ZeBu FPGA-based emulator.
Often, it is needed to preload internal ROM and SRAMs with the executable code. The C program for the application is compiled, linked, and loaded into internal memories. The intent is to release the CPU reset and expect the CPU to execute the code and data loaded into the respective memories. Instrumentation can be added and accessed using the iJTAG as per the Fig. 18.8 even for memories. Note that the functional ROMs can also be preloaded using the iJTAG after instrumentation insertion.
For memories like dual-port memories, the port which has both write and read ports is chosen for instrumentation. Table 18.5 indicates the typical instrumentation that needs to be inserted for commonly used memories within the DUV.
If the SP/DP RAM has bit- or byte-wise write and read control (functionally strobed lanes), then the instrumentation is suitably adjusted so that all the byte lanes are affected during memory load and dump through iJTAG. The typical sequence for the usage would be:
1. Stop all the clocks to the emulator. This is through iJTAG-based instrumentation register confifi guration.
2. Preload the memories using external iJTAG: (a) Glitch-free selection of the clock to point to iJTAG_TCK. (b) Select the memory to be preloaded. (c) Preload the memory with the (address, value) pairs.
3. Apply reset to the DUV.
4. Start the clocks to the emulator.
5. Release reset to the DUV.
6. Expect the design to run the test (application).
7. Stop all the clocks to the emulator.
8. Read the memory (address, value) pairs, and store it to a fi le on host machine.
Observing waveforms is an important part of the debug process and this feature is integral to any emulator. With regard to waveform, there are a few key concepts that need to be put in place as below:
1. Signal List : List of signals and buses (full hierarchical names) that you want to be added into the debug waveform.
2. Trigger Signals and Trigger Expression : A set of Trigger signals and the Boolean expression which would control the start and stop of the waveform capture.
3. Trace Depth : The maximum number of waveform samples that can be taken using the appropriate sampling clock.
4. Trace Window : The period of time when the waveform samples are captured. You can also have a circular trace buffer, allowing for a % trigger start, i.e., the trace starts x % prior to the actual trigger event and lasts up to (100 − x )% after the trigger event. One can also defifi ne a pre-trigger percent or a post trigger percent based on this as is indicated by Fig. 18.9
Chapter 17 explains various debug cores provided by Xilinx that can be used to capture waveforms. However, often, for deeper level of debug, the ILA is not suffifi cient, and at times the Signal List can span multiple FPGAs. To address this problem, emulators usually have their own external SRAM/DDR memory which can go up to 128 GB to enable deep trace. Intuitively, one can see that the instrumentation needed for this feature is huge. Some basic components are listed in Table 18.6 .
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Résistances
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: Contrôleur logique
Lifecycle:Active Active
RoHS: No RoHS
Support
