FONT SIZE : AAA
Vivado IDE has easy and intuitive ways of debugging. The fifi rst step is to analyze the waveform and/or the log to get to the simulation time, where the bug fifi rst manifests itself. Once that is identififi ed, you should take the simulator to the specififi c simulation time with run (explained in Sect. 11.3.5 ) command. Tracing and HDL code debugging are done further to isolate and identify the bug.
Tracing refers to ability to follow (trace) the flfl ow of simulation on your HDL code. Vivado simulator has two tracing commands: ptrace for process tracing and ltrace for line tracing. Use ptrace on (or, off ) to turn on (or, off) process tracing. An example session with process tracing would look like as below:
Since there can be a lot of information generated by ltrace or ptrace , it might be more effective to use tracing with condition (explained in Sect. 11.4.3 ).
HDL source has executable lines on which breakpoint can be applied. Breakpoint can be set from Vivado GUI or from Tcl Console. In Vivado GUI, the breakable lines have empty circles in front of them, as shown in Fig. 11.3 . Clicking on this circle will add the breakpoint. The breakpoints on the GUI are toggle switch. So clicking them again will remove the breakpoint. The Tcl command to add breakpoint is:
add_bp counter.sv 29
Running the simulator now will automatically stop on hitting this line. The signal values can be observed by hovering the mouse over the signals of interest. Values can also be checked from Tcl shell with get_value or report_value (described in Sect. 11.3.3 ) command. Alternately current values can also be observed in the objects window by selecting the appropriate scope. All the currently active breakpoints can be listed by the command report_bps . The report of active breakpoints will look like:
Condition is a very powerful debugging concept. It permits an action to be associated with a Boolean expression turning true. Whenever the condition is met, the command associated with the condition is executed. You can make use of this capability through add_condition from Tcl command. The command associated with condition can be any valid simulator command. Thus add_condition can be a powerful tool to do white box testing of design without modifying it. For example, to break simulation if a non-zero data is present with reset, use the following command:
add_condition –name ignoredData {reset == 1 && data !=0 } stop
Here stop is the command that gets executed when ( reset==1 && data !=0 )
becomes true. On stopping, the other related signal values can be inspected for
debugging. Once inspected simulation can further continue with run command.
report_conditions reports all the condition objects that are active. remove_condition just like remove_bp can be used to remove one specifi c or all conditions.
Changing Values of Signals
For debugging, you may sometimes want to see the impact of a changed value of signal without changing the design and recompiling it. Vivado simulator provides with two ways to do that from the Vivado Tcl. They are setting and forcing values.
You can use set_value to update a signal or reg immediately. It however permits the value to be changed with future signal update events. Example use:
set_value -radix bin /test/bench_VStatus_pad_0_i[7:0] 1110100101
Forcing is similar to setting value, except it can be done only for signals, and once the value is forced, it cannot be changed till the force is on. You can force a signal to the desired value through add_force . Similarly the force can be removed by the command remove_force .
You can also use GUI to force a signal to a constant value and to remove the force . Right-click on the signal in the object window and select force constant to force a signal to a constant value. Similarly select remove_ force from the menu to remove any force on the signal. You can also force a toggling value to a signal by selecting force clock and fifi lling up the pop-up window with toggle values, start time(offset), duty cycle, and period.
Manufacturer:Xilinx
Product Categories:
Lifecycle:Any -
RoHS: -
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: -
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: -
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS: No RoHS
Support
