FONT SIZE : AAA
Creating and debugging FPGA designs using an iterative design flfl ow leverages one of the key advantages that FPGA devices have over ASICs and ASSPs: FPGAs are reprogrammable. Adding, modifying, and removing debug instrumentation are an integral part of the FPGA design cycle, as shown in Fig. 17.1 . Due to their fifi xed nature, it is not possible to add, change, or remove debug instrumentation in ASIC/ASSP designs after fabrication.
While you can add debug instrumentation to ASIC/ASSP designs before tape out, it is typically only done at the block interface level or in key control sections of the design. It can be diffifi cult to predict where bugs will pop up in a design, which
means you might not be monitoring the appropriate part of the ASIC/ASSP design. In FPGA designs, you can add just the right amount of debug instrumentation to the appropriate part of the design to fifi nd the bugs and then remove the instrumentation when it is no longer needed.
Simulation vs. Debugging in Hardware
FPGAs are similar to ASICs/ASSPs in that simulation-based verififi cation can be used to ensure the design meets the specififi cation. The main advantage that simulation has over debugging in hardware is that simulation allows for full visibility of any node in the design. However, when debugging in hardware, the number of nodes that can be debugged in any given design iteration is limited to the amount of resources available to the debug instrumentation.
An example of debug instrumentation that is used to trigger on hardware events and capture data of interest is called the Integrated Logic Analyzer ( ILA ) debug core. The ILA IP core uses FPGA fabric resources to implement the trigger functions and it uses block RAM to store the captured data samples. Table 17.1 shows a chart of how many block RAM Tiles in the FPGA device are used for various levels of design debug visibility. The amount of slice logic used by the ILA core ranges from 0.81 to 2.61 % of a Kintex-7 XC7K480T device.
While simulation provides for increased debug node visibility and deeper capture trace, debugging in hardware has two distinct advantages over simulation:
• Faster test run times, typically at the speed of the system under test
• Testing in a real system environment rather than a simulation testbench
Simulation and hardware debugging are not mutually exclusive. In fact, it is often benefifi cial to use simulation to verify the functionality of a design before testing it out in hardware. This is especially true if the design consists of signififi cantly new content that has not been previously verififi ed. After verifying the design using simulation, you can debug in hardware to fifi nd issues that result from design integration or other system-level considerations, under the environment of real-world traffifi c patterns.
In some cases, it can be advantageous to skip simulation altogether and verify the design entirely in hardware. For example, in cases where designs that have been previously verififi ed in simulation are undergoing small modififi cations or are being ported from one FPGA device family to another, you may go directly to hardware.
Before debugging in hardware, make sure the design meets all timing constraint requirements. Debugging a design that does not meet timing is typically not a worthwhile endeavor since any misbehavior could easily be attributed to the failure to meet timing.
In addition to ensuring the design on its own meets timing, also ensure that the design including the debug instrumentation IP (such as the ILA core) meets timing as well. The ILA core uses FPGA device resources and can exhibit unexpected behavior if design does not meet timing.
The ILA core has a clock input that is used to synchronize the measurements to the design-under-test; therefore all design constraints related to that clock domain also apply to the ILA core. The ILA core also has its own design constraints that time the portions of the ILA core not related to the design clock domain. Once all timing constraints are applied correctly and are met, it is quite likely that any misbehaviors that are encountered are due to real functional issues as opposed to timing- related anomalies.
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
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: No RoHS
Support
