Category Archives: GUI Debugging

Posts about BugHunter, the GUI debugger for VeriLogger

Debugging Verilog Parameter errors

Whenever you’re working with a large Verilog design, there’s likely to be a significant use of params (and localparams), especially when you’re stitching together IP blocks from one or more third party vendors. Params are often defined as mathematical expressions and a param’s final compiled value can often be quite difficult to figure out just by looking at the Verilog code because the expressions are scattered throughout the design hierarchy.

A parameter with an undesired value can lead to both very obvious errors (mismatch in size of a wire to a port) or to very subtle errors (e.g. a parameter used to count a number of clock cycles before reporting an error is set too large to ever get triggered). For this reason, it’s a good idea to verify the values of parameters at the interfaces between code you write and any third party IP you’re using prior to running simulations.

The quickest way to verify the parameter values is to compile (build) the design, then navigate through the resulting graphical design hierarchy tree which shows the computed values of the parameters for each IP instance. You can search for all instances of a module in a tree by entering the name of the module prefixed by a “.” (e.g. “.foo” where foo is the name of the module) in the quick search box. Under each instance node in the tree is a sub-folder called Constants that lists all the top-level parameters for that instance and their compile-computed values. You can quickly scan this list to look for any parameter values that appear to be out of whack.

One final note: scanning through the computed values for internal params in a 3rd party IP is also useful in gaining better insight into how the IP works as key design details are often abstracted into param values. This can help you avoid trying to use the IP in a way that it wasn’t coded to work properly.

BugHunter Preparses before Simulator Builds

When you build a design with BugHunter, it first preparses the HDL source code before it sends it to a simulator for full parsing and compilation. BugHunter’s preparser builds a hierarchical database of the design modules and their contents (e.g. registers, wires, parameters, etc). The preparser performs a “fuzzy” parse, allowing it construct this database even when the parsed HDL code contains minor syntax and grammar errors. One useful benefit of this is that you can navigate IP source code from a third party even before you’ve got a project set up that can correctly compile the IP.

After the preparse is complete and the project window has been populated with the design hierarchy, BugHunter launches the selected simulator which does a full parse of the HDL code to allow the code to be simulated. The errors reported by the simulator are fed back to BugHunter which extracts the information that allows you to click on errors in the error tab to jump to the error location in the source code. Therefore, the exact error messages reported depend on the simulator being used. This means that if you’re not able to understand the error message of a given simulator, you can easily switch to a different simulator and get a different explanation for the error.

Faster Simulations under GUI

If you’re running simulations with the BugHunter GUI and dumping a lot of waveform data to the timing diagram window, you should probably update to the latest version of BugHunter. The new version has significantly speeded up drawing large quantities of waveform data, and this also translates to faster simulations. This enhancement is particularly useful if you want to scroll and zoom around to examine the waveform data while the simulation is still running.

BugHunter Pro: swapping between different simulators

In this blog, I’ll be discussing the evolving architecture of VeriLogger, as well as sharing tips on how to get the most out of the environment. Today I’ll be discussing ways to change what simulator is used by the Verilogger environment to simulate a design.

VeriLogger actually consists of two separate programs: BugHunter Pro , a graphical debugger/testbench generator (executable filename is syncad.exe) and a Verilog simulator. The default Verilog simulator used by BugHunter is SynaptiCAD’s Sim Extreme, a compiled-code Verilog 2001 simulator (executable filename is simx.exe).

BugHunter supports debugging with all the major Verilog and VHDL simulators and it can be easily configured via the GUI to swap out which simulator it uses for performing simulations. In Verilog, it’s fairly easy to accidentally introduce race conditions into your code that will cause simulation output to be different across different simulators, so it’s not a bad idea when you have access to multiple simulators to run your design through multiple simulators and compare the output. This is particularly important when you’re creating IP that is going to customers who may use a different simulator than you used to design your IP.

The first way to set the simulator used by BugHunter is via the command line when BugHunter is started. For example:

syncad -p bhp -S verilogger_extreme

launches the product BugHunter (-p bhp) with the verilog_extreme simulator as the default simulator for new projects.

To override the above default setting for new projects using the GUI, select the menu option Project>Default Project Simulation Properties, click the Settings Template radio button, select the Verilog tab, then set the Simulator Type to the desired simulator.

To change the simulator used for an existing project, select the menu option Project>Project Simulation Properties, click the Verilog tab, and pick the desired simulator from the Simulator Type control.

Debugging information such as breakpoints and which signals to watch in the waveform window are stored in a simulator-independent format inside your project, so this information is portable across simulators. Common compilation options such as include and library paths are also stored in a portable format.

Project files can store multiple configurations, with each configuration storing a list of settings on how to compile the project (what compiler to use and what compilation options). Configurations make it easy to switch between simulators or to simply switch between a “debug simulation” where you build a slower simulation that is fully debuggable versus a “fast simulation” that runs quickly but doesn’t make as much debug info accessible. To create a configuration, use the Project Simulation Properties to set the desired simulator and compilation options, then press the Add button to create the new configuration and give it a name.