At Speed Debugging Techniques

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 communica

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

FPGA or SOC

FPGA or SOC

IICE

JTAG Hardware System

HDL Debugger

Figure 18-1

At-Speed Debugging

Overview.

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

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.vhdneeds to be moved to the bottom of the list so that it is the last file read

Figure 18-3

Bridges2Silicon Project

Editor Window.

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 UNITspecifies which design unit is the top level and will be linked This value will be specified as CPU. TOP-LEVEL LANGUAGEspecifies the default language used to compile the design and to write out the instrumented design.TOP-LEVEL LANGUAGEis 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 parameparame-ters 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 b2sand 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 b2sis 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 blockblock-ram, 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 /clkwill 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 debuggdur-ing 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

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 Saveand Instrumentmenu 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

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

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_stateobtains 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_statechanged to the value

Load12and 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.

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

Figure 18-8

Signals and

Break-points Selected for

Debug.

cursor shows the position of the trigger Also notice that the first two signals in the waveform display are Sample Clockand 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 position 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 ex-pressions on signals A watchpoint expression defines a value or transi-tion that a signal will trigger When the signal value equals the trigger value or transitions from one value to another, the IICE will trigger and cause the sample buffer to be transferred to the debugger To set a watch-point expression, click on a signal in the debugger source window The Watchpoint Expression dialog box appears (see Figure 18-12)

Figure 18-9

Breakpoint Enabled

on Loadl2.

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 specified, the signal must transition from the first value to the second value to cause a trigger In Figure 18-13, signal current_statemust transition from state

reset5to state reset6to 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 specify exactly the case when the instruction is written from the memory bus to the instruction register after state reset6, the following watchpoints can be specified Place a watchpoint expression of reset6on signal current_state, and a watch-point expression of 1on signal ready When both of these expressions are

Figure 18-10

Trigger on Loadi2

and Captured Data

Displayed.

Figure 18-11

Captured Data

Displayed as

Waveforms.

Figure 18-12

Watchpoint

Specification Dialog

Box.

true, the IICE will trigger, indicating that the instruction register is be-ing written with a new value after reset

SUMMARY

In this chapter we explored a new technique to debug designs using ac-tual hardware implementations The concepts behind instrumenting a de-sign were introduced and techniques for instrumenting a dede-sign were shown Next we discussed techniques for setting trigger conditions to find specific design states during debug Finally we discussed how to specify complex triggers to precisely define trigger behavior

Figure 18-13

Trigger on progcntrRd

Watchpoint.