Debugging methods for FPGAs

Simulation There are three main simulation methods: * RTL (Register Transfer Level) simulation * Gate level simulation * Back annotated Timing simulation. RTL simulation is used to verify the functional behaviour of a design written in VHDL, Verilog, systemVerilog or C. In Europe it has become very common to use a mixed language Verilog and VHDL simulation. The Verilog part consists primarily of IP cores, which are not available in both languages. Therefore, it is very useful to have an RTL simulator that can handle both languages at the same time. FPGA vendors typically provide OEM simulators from Mentor or Aldec as an add on or bundled with their design software. For small to midrange designs these simulators are very useful. For larger designs or designs which require complex test benches, faster and more powerful simulators are often required. Suitable simulators can be obtained commercially from EDA software companies such as Aldec, Mentor, Synopsys or Cadence. Such simulators typically cost several thousand dollars but will boost simulation performance by a factor of three to five. Building an advanced test bench that generates adequate coverage for the whole design is a time consuming task, but this effort is well spent. Time spent on simulation will be recovered easily over the project development cycle as a whole, because locating an error when the fpga is on the pcb board is generally much more difficult, expensive and time consuming. In some cases, designers simulate lower level design blocks in a module test bench and then connect these blocks together in the fpga top level. This can save some simulation time, but it should not be overlooked that this still leaves areas in the design that are uncovered. In particular, the interfaces between the individual modules are one of the most critical areas, where problems can easily occur. Simple logic level mismatches (active high vs. active low) are one of the most common problems in a design. Figure 1: System Simulation vs. Module Simulation Differences between a system simulation and a module simulation Gate level simulation can be used to check the behaviour of the design after it has been mapped to the fpga technology. In reality, however, it provides nothing more than a check of the output from the synthesis tool for correct results. Today's synthesis tools already implement formal verification methods that make certain the synthesis result will match the RTL level description. Therefore, a gate level simulation is necessary only if there are different functional results in the timing simulation. If the gate level simulation passes, but the timing simulation fails, then this is a sure indication that the mismatch occurs from the timing and not from the netlist. Back annotated timing simulation is a gate level simulation with timing information. For this simulation the fpga vendor tool generates either a VITAL (VHDL gate level) netlist or a Verilog netlist. In addition, the tool outputs an SDF (Standard Delay Format) file that contains the timing information for each internal cell and routed net. The timing information is provided as best, typical and worst case, according to the design parameters chosen. The worst case parameter can be set in the design tool by choosing appropriate values for operating voltage and temperature. The disadvantage of back annotated timing simulation is that only the paths that are stimulated will be checked (i.e. coverage is dependent on the test vectors). Also, the simulation time is considerably longer compared to the RTL simulation, which is a strong motivation for the designer to move to a faster simulator. To be able to simulate the design with all three methods, Lattice offers the ispLEVER Design environment, which includes a mixed language (VHDL, VERILOG) simulator for RTL, gate level and back annotated timing simulation. If higher performance is required, Aldec offers an upgrade from the OEM simulator provided with ispLever to their commercial product. Static Timing Analysis As described above, an RTL simulation is the primary method for verifying the behaviour of the design. The next step is static timing verification. This involves calculating the timing for each cell and net without stimulating the inputs of the design. This has the benefit of providing a complete and comprehensive timing check. The designer only has to specify appropriate constraints for the design, such as operating frequency, setup time and hold time at inputs and outputs. To speed up the analysis, false paths can be specified. These typically are paths with relaxed requirements or combinational paths that are physically present but not functionally relevant. The designer should not forget to specify multi-cycle paths as well if the design has parts that do not run at full speed (e. g. an accumulator). The output of an accumulator that accumulates 256 numbers is not read in each cycle; therefore it is desirable to assign a multi-cycle path of 256 to such an accumulator output. This method has its limits in designs that contain combinational loops. Combinational loops cannot be calculated, but the point or points at which to break the loop can be specified, and timing of the individual sections then can be calculated. For fully synchronous designs it is not necessary to perform a back-annotated gate level simulation. The combination of RTL simulation and static timing analysis are sufficient to guarantee complete coverage of the design. Lattice offers a static timing verifier as part of the ispLEVER Software. The designer can enter constraints and observe the results in a graphical or ASCII output format. Figure 2 illustrates the output of the static timing verifier using the graphical method in the Performance Analyst. Figure 2: Performance Analyst This output format displays the source and destination name as well as the intermediate cell names, providing a quick and easy way to check the timing in the design. An alternative method is to check the summary report generated by the static timing verifier, whereby the performance of the design is checked against the constraints set by the user. This report file always contains a concise summary indicating whether or not the design requirements have been achieved. An example of a timing report summary file is shown in Figure 3. Figure 3: Static Timing HTML Report Hardware Debugging If the design simulates successfully but problems still arise when the fpga is integrated on the board, there are a number of methods available for performing hardware debugging. The first method described will explain how internal signals can be manually routed to external pins. The ispLever design environment provides a tool called EPIC. EPIC is a design editor that displays the exact implementation of the design in hardware and which also can be used interactively to make smaller modifications to the design after synthesis. Typical modifications include changing selected I/O Standards, adding debugging probes or inverting signals. It is not an efficient approach to create the entire design using EPIC. The benefit of using EPIC for debugging the design is that the original design will not be changed. The desired internal nets are routed via free available routing resources to external pins. The availability of unused routing resources and free external pins is the only prerequisite for making internal nodes externally observable. In addition of course measurement equipment such as a logic analyser is required to capture the test signals at the external pins or test connector. Figure 4: EPIC debugging method with external Logic Analyzer Figure 4 illustrates the concept of hardware debugging using the EPIC method. The internal signals are simply routed to external pins by hand. After adding the debugging probes to the design or rerouting the test signals to the test connector port, the selected internal nodes can be measured in real time. Figure 5: adding probes with EPIC Figure 5 shows the EPIC tool with the signal probing configuration window being used to connect internal signals to external pins. The log window displays the timing information of the routed nets. The disadvantage of this method is that an external logic analyser is required. Furthermore, the probes which are manually added to the design cannot be back annotated to the project files. This means that if the design is changed, all probes are lost. The changes made in EPIC can however be exported to a file (pin, net name) and re-imported into the new design. The changes made in EPIC can alternatively be saved to a script file. This will of course only work as long as the internal signal names do not change. The second hardware debugging method described, involves the assertion of a soft analyser into the synthesised design. For this method, Lattice has implemented a tool called Reveal which is included in the ispLEVER software environment. With Reveal no external logic analyser or free pins on the fpga are required. The software in the system logic analyser captures signal activity and stores the information in internal RAM Blocks. This means the only precondition is that at least one internal RAM block must be free to store the signal information and not used by the functional logic. The stored information is passed via the JTAG interface to the software analyser running on the PC. The trigger conditions can be changed on the fly without changing the design. Figure 6: Reveal debugging method Figure 6 illustrates the Reveal concept. The Soft IP is implemented in the fpga and the Board is connected via the Lattice JTAG cable (USB or parallel) to the PC. If a trigger is detected, the specified signal values are stored in the fpga and transferred via the Lattice JTAG cable to the PC. On the PC the captured signals are displayed in a wave window very similar to the waveform window used in software simulators. Figure 7: Reveal Inserter Figure 7 shows the Reveal inserter in use. The user can drag and drop internal signals from the design browser into the Trace and Trigger signal setup area. On the Trigger setup page trigger Units and trigger Expressions can be specified. The Trigger expressions are built from the trigger units. Different units can be combined together in the trigger expression, such as TU1 | TU2 (TU1 or TU2), to build complex trigger functions. The designer can use the logical operators AND, OR, XOR, NOT as well as the THEN function or alternatively the designer can specify that the Trigger unit should be captured 3 times (TU1 #3), for example. It is also possible to add multiple Analyser cores to a single design, depending on the clock domains which are used. For example, if the design uses a 10 and 100MHz clock domain, it would be useful to add two analyser cores to the design, one being driven by the 10MHz and the other being driven by the 100MHz clock domain. If the analyser recognises a trigger condition, the signal information is displayed in the Reveal Analyser Waveform window. Figure 8: Reveal Analyser Waveform and Trigger Window The waveform window has the same look and feel as a software simulator. The FSM shown in figure 8 can be observed in the defined states (idle, state1, state3). Signals can be combined to busses or busses can be expanded to individual signals. In the Trigger Signal Setup window the designer can change the Trigger values and combinations as well as the interval of capture, depending on whether the pre-trigger, centre-trigger or post-trigger display contains the area of interest. The disadvantage of the Reveal method is that additional functionality is inserted into the original design which in turn will change the routing and placement of the original design. Conclusion The developer has a number of possibilities for effectively debugging an fpga at each stage of the design flow. It is very important to verify and debug a design at as early a stage as possible in order to minimise the probability of problems remaining undetected until the fpga is integrated in the hardware. Reveal and EPIC are powerful tools which can assist the designer in efficiently debugging the hardware, but they are not a replacement for functional simulation and static timing analysis.