At Speed Debugging Techniques

CHAPTER 18 At Speed Debugging Techniques Throughout the book so far we have discussed a number of techniques for implementing VHDL designs and ways to make sure that the VHDL designs behave as expected. These techniques include simulation, synthesis of the design to an FPGA or ASIC, and gate-level simulation using VITAL libraries. A new technique called At-Speed Debugging is just becoming available that allows much higher performance verification than a typical simulator, yet provides the design visibility necessary to properly debug a design. This technique provides designers with the ability to debug their design in the target system, at target speed, at the VHDL RTL level. Figure 18-1 shows a block diagram of how this works. The VHDL for the device is read into a tool that auto- matically creates and inserts a small debug core into the device that probes internal signals. The debug core is cre- ated based on information from the designer about what 18 signals are to be probed. This debug core communicates through the JTAG port on the device to an HDL debugger executing on a host plat- form. The HDL debugger sends and receives data from the debug core and displays this data in context with the HDL for the design. Wave- forms of the internal device data can also be displayed, providing the ability to trace down problems in the design. This technique works well for any design, but it works especially well for designs where a tremendous amount of data must be processed by the device to determine whether the device is working properly. For instance, devices that process audio or video information require a tremendous amount of data to be processed before it can be determined that the device is working properly. A video processor might need to pro- duce several minutes of high-quality video data to determine whether the encryption decoding algorithm is working properly. Running at or near speed will allow images to be generated quickly and the device function to be analyzed for correctness. The only system as of this writing that performs as described is the Bridges2Silicon debugger from Bridges2Silicon. A block diagram of the system is shown in Figure 18-2. The Bridges2Silicon debugger contains two tools. The Bridges2Silicon instrumentor reads the VHDL description and adds the debug core, called an Intelligent In-Circuit Emulator (IICE) to the design. The Bridges2Silicon debugger communicates with the JTAG port on the target device, reads the database created by the instrumentor, and reads the original source files created by the designer. Chapter Eighteen 400 FPGA or SOC FPGA or SOC IICE JTAG Hardware System HDL Debugger Figure 18-1 At-Speed Debugging Overview. Instrumentor The designer reads the VHDL design into the instrumentor and specifies which signals to probe and which breakpoints to enable. The instrumentor generates a new VHDL description of the design with the IICE core added and connected to the appropriate places in the design. Once the new VHDL description has been created, the designer synthesizes, and place and route the new VHDL description. In an FPGA design environment, the device is programmed with the new device file created by place and route. Debugger Once the board is powered up, and the FPGA device is programmed with the new device file from place and route, the debugger can communicate with the device through the JTAG port. The debugger also reads the data- base file created by the Instrumentor and the original VHDL source files. The instrumentor database relates the real signals on the device to the location of the signals in the original HDL. Debug CPU Design Let’s now look at the process of debugging the CPU design using the Bridges2Silicon Debugger. The first step is to create a project containing all of the HDL files for the design. 401 At Speed Debugging Techniques HDL Sources IICE Implement (Synthesis, P&R) SOC Implement (Synthesis, P&R) Bridges2Silicon Instrumentor Instrumented HDL Sources B2S Project Bridges2Silicon Instrumentor B2S Project Bridges2Silicon Debugger JTAG Bridges2Silicon Debugger JTAG Figure 18-2 Bridges2Silicon Debugger Overview. Create Project To create a project, use the project editor invoked from the File menu or from the toolbar. The Project Editor window is shown in Fig- ure 18-3. To add to the project, use the file navigator in the upper left to nav- igate to the location of files. First select the files and use the right arrow key to add the files to the Design File list on the right of the project editor window as shown in Figure 18-4. Now the design source files need to be re-ordered so that the files are read in the proper order, which is specified by the order of the list. The package cpulib.vhd needs to be read first so that it is available to all the other design files. The easiest way to move cpulib.vhd to the top of the list is to select and drag it to the top of the list. The other file that needs to be moved is the top level of the design, cpu.vhd . File cpu.vhd needs to be moved to the bottom of the list so that it is the last file read. Chapter Eighteen 402 Figure 18-3 Bridges2Silicon Project Editor Window. 403 At Speed Debugging Techniques Specify Top-Level Parameters Once all the files have been specified, the parameters for the top level need to be specified so that the design elements can be properly linked. There are two parameters that need to be specified: the TOP-LEVEL UNIT and TOP-LEVEL LANGUAGE . TOP-LEVEL UNIT specifies which design unit is the top level and will be linked. This value will be specified as CPU. TOP- LEVEL LANGUAGE specifies the default language used to compile the design and to write out the instrumented design. TOP-LEVEL LANGUAGE is specified as VHDL by clicking the VHDL radio button. This is shown in Figure 18-5. Now that we have specified all the needed parameters, click the OK but- ton, which saves the project and also compiles the project. After compila- tion, Figure 18-6 shows the design loaded into the Instrumentor Window. Specify Project Parameters Once all the files have been added to the project, the device parame- ters need to be specified. These parameters determine how the device Figure 18-4 Files added to Project File List. will communicate with the JTAG port and the debugger on the host platform. Use the dialog box shown in Figure 18-7 to set up the device and IICE configuration settings. 1. Device family . We use the Altera Apex technology. 2. JTAG port. The choices are b2s and builtin . We will choose builtin so that we can use JTAG communication with the JTAG tap controller already present in the Altera device. This choice is used predominately and b2s is only used when the board containing the device is not connected to the JTAG chain on the board. 3. Type of RAM . This parameter specifies the type of RAM to be used for the sample buffer that stores internal signal data. The choices are block- ram, logic, and behavioral. This example will use blockram, the most com- mon selection and the most efficient. This selection will build the sample buffer from blockrams available on the FPGA device. If the logic choice is selected, the sample buffer will be built from flip-flops in user logic. This choice is used when there is limited blockram available and is not as effi- cient as blockram. The third choice is behavioral and will generate a behavioral model for the sample buffer. This choice will let the synthesis tool choose the sample buffer implementation based on available resources. 4. Sample clock . This parameter specifies a signal that will be used to clock the data into the sample buffer. This signal can be any signal in the design but must be a clocklike signal. For instance, this signal should be the output of a register so that it does not contain glitches. In this example the signal /clk will be used. 5. Sample depth . This parameter specifies how many samples are gath- ered when a trigger occurs. Depending on how much data are required to find a bug, this value can be any power of 2 that will fit into the Buffer Type specified for the device. In this example, the value 256 will be used. Instrument Signals Now that the design has been compiled and the communication parameters specified, the signals to be instrumented can be selected. For this example we are going to debug the control block. All breakpoints and signals in the control block for the reset sequence will be instrumented for use later dur- ing debugging. The debugger GUI shows only the signals and breakpoints that can be instrumented. Clicking the Radio button next to a signal or breakpoint will instrument that signal or breakpoint. Figure 18-8 shows the Radio buttons for the reset sequence selected for sampling and debugging. Chapter Eighteen 404 Write Instrumented Design Once all the signals and breakpoints have been instrumented, the instru- mented design can be written out. This design will include the original design tree plus the IICE core added for debugging. The IICE core will be connected in such a way as to probe all the instrumented signals in the design. Select the File Save and Instrument menu items to write out the instrumented design. Implement New Design The write instrumented design process will produce a new version of the VHDL files for the CPU design. These files need to be synthesized as described in earlier chapters. The output of the synthesis process is an EDIF netlist. The EDIF netlist is placed and routed with the Altera Quartus tools to produce a file that is programmed into the Altera device 405 At Speed Debugging Techniques Figure 18-5 Top Level Unit and Language Specified. as described earlier. Finally the new programming file is programmed into the Altera device with the Altera programming software. Start Debug Now that the device has been programmed with the new netlist, the device can be debugged with the Bridges2Silicon debugger. The debugger is invoked, and the project created by the Bridges2Silicon instrumentor is loaded into the debugger. This project loads the original source files for the project into the debugger. The debugger now shows only instrumented signals and breakpoints. Enable Breakpoint To enable a breakpoint, click on the radio button next to it. To put a watch expression on a signal, click the signal and specify a signal expression value. Chapter Eighteen 406 Figure 18-6 Compiled Project with Debug Items Shown. A breakpoint is a simple way to specify a complex trigger expression. A breakpoint behaves similar to a breakpoint in a software debugger except that a breakpoint in the debugger does not stop the hardware. A break- point in the debugger represents a trigger condition that causes all instru- mented signal values to be captured and sent to the debugger. Figure 18-9 shows the breakpoint selected at the source line where current_state equals Load12. To activate this trigger, click on the Run button. Clicking the Run button will download this trigger selection to the IICE hardware on the device and arm the trigger to sample data. When signal current_state obtains the value Load12 , the breakpoint triggers and the sample buffer is sent to the debugger through the JTAG port of the device. The actual signal values are displayed on the source code as shown in Figure 18-10. Notice that the value of current_state is Load12 . All the rest of the signals contain values captured when current_state changed to the value Load12 and the trigger condition was met. With this capability a designer can use breakpoints to see the actual behavior of the real hardware to make sure that the design is behaving properly. Figure 18-7 IICE Configuration Dialog. 407 At Speed Debugging Techniques The sample buffer contains as many samples as specified by the sample depth in the instrumentor setup. In this case 256 samples were captured into the sample buffer and sent to the debugger when the trigger occurred. Trigger Position The position of the trigger in the sample buffer data can be controlled so that more history before the trigger is shown, history and future data size are the same, or less history and more future data is shown after the trigger. In this example the history and future data is the same, which corresponds to the middle trigger position. Waveform Display Another way to view the sample buffer data is via a waveform display. In Figure 18-11 the sample buffer data are shown as a waveform. The vertical Chapter Eighteen 408 Figure 18-8 Signals and Break- points Selected for Debug. [...]... after state reset6, the following watchpoints can be specified Place a watchpoint expression of reset6 on signal current_state, and a watchpoint expression of 1 on signal ready When both of these expressions are At Speed Debugging Techniques Figure 18-11 Captured Data Displayed as Waveforms Figure 18-12 Watchpoint Specification Dialog Box 411 412 Chapter Eighteen Figure 18-13 Trigger on progcntrRd Watchpoint... second value to cause a trigger In Figure 18-13, signal current_state must transition from state reset5 to state reset6 to cause a trigger Complex Triggers Watchpoints and breakpoints can be combined to create more complex triggers Complex triggers allow the designer to zoom in on exactly the area of the design to capture data from, or to locate more precisely the cause of a design error For instance, to.. .At Speed Debugging Techniques 409 Figure 18-9 Breakpoint Enabled on Loadl2 cursor shows the position of the trigger Also notice that the first two signals in the waveform display are Sample Clock and Cycle These are added signals used to provide reference points in the waveform The sample clock is used to show the reference edges where sample data was captured The cycle number shows the relative... trigger, indicating that the instruction register is being written with a new value after reset SUMMARY In this chapter we explored a new technique to debug designs using actual hardware implementations The concepts behind instrumenting a design were introduced and techniques for instrumenting a design were shown Next we discussed techniques for setting trigger conditions to find specific design states during... within the sample buffer Cycle number 0 is the trigger point, positive values are after the trigger, and negative values are before the trigger Set Watchpoint Another way to specify trigger conditions is to specify watchpoint expressions on signals A watchpoint expression defines a value or transition that a signal will trigger When the signal value equals the trigger value or transitions from one value... sample buffer to be transferred to the debugger To set a watchpoint expression, click on a signal in the debugger source window The Watchpoint Expression dialog box appears (see Figure 18-12) 410 Chapter Eighteen Figure 18-10 Trigger on Loadi2 and Captured Data Displayed If only the first value is specified, the signal will cause a trigger when that value is reached on the signal When both values are . Captured Data Displayed. Figure 18-11 Captured Data Displayed as Waveforms. Figure 18-12 Watchpoint Specification Dialog Box. 411 At Speed Debugging Techniques. real hardware to make sure that the design is behaving properly. Figure 18-7 IICE Configuration Dialog. 407 At Speed Debugging Techniques The sample buffer