Tag Archives: Verilog

Debugging Verilog Parameter errors

Leave a reply

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.

Detecting Races with VeriLogger

Leave a reply

It’s easy to accidentally introduced “races” into Verilog, especially when you’re working with just one simulator. Since the Verilog language purposely doesn’t specify a particular order for execution of parallel process blocks, these races will frequently lead to different simulation results when a design is simulated by simulators from different vendors. VeriLogger has always been pretty useful for detecting simulation races, because our BugHunter GUI allows you to switch back and forth between our simulator (Simx) and 3rd party simulations (e.g. ModelSim, NcSim, ActivHdl, and VCS), making it easier to find such races. But this still required you to have access to other simulators to detect the races.

Over the past few months, while working with some of our customers who were “qualifying” our simulator with their existing designs, several such races have been found in the designs. Each time we encountered a simulation difference between us and a 3rd party simulator they were using, we had to determine whether the problem was a bug in our simulator, a bug in the other simulator, or a race in the design.

To speed this process up, we added several new command-line options to enable our simulator to change our default ordering of process execution and also to handle a few cases where the Verilog Language Reference Manual was vague enough about how a situation should be handled that different 3rd party vendors have chosen different ways to handle those siutations. By default, our simulator most closely models the process ordering used by Cadence’s Ncsim, so we added options to match the ordering used by Mentor’s ModelSim and Aldec ActiveHdl. We also added an option to randomize the ordering which given a few simulation runs should generally detect a problematic race in just about any design. The new options are:

–scd_invert_queue: inverts order in which “same priority” events in the event queue are evaluated.

–scd_randomize_queue: randomizes the order in which “same priority” events are evaluated.

–scd_mtilike_queue: evaluates event queue similar to ModelSim/ActiveHdl.

–scd_immediate_sensitivity: makes event control statements at the beginning of a process immediately sensitive after simulation initialization.

–scd_mtilike_dist_functions: makes $random and $dist functions behave like ModelSim/ActiveHdl instead of like NcSim.

What all this amounts to is, although our original goal was to make it easier to qualify our simulator as being functionally correct, we’ve ended up creating a new way to quickly detect races in your designs, as well. Finding these races can save you a lot of headaches down the road, especially if you sell IP to customers who use different simulators from the ones you normally work with!

VeriLogger Process Communication and Firewalls

Leave a reply

In my last post, I discussed how the VeriLogger GUI can be configured to control different simulators. Today I’ll cover the executable programs used during a typical simulation run and how they communicate with each other.

It’s particularly important to note that these programs communicate via CORBA calls using network sockets, so any firewall software on your system needs to be configured to allow this communication. Please note that this “network communication” is all strictly local to the user’s computer: no internet activity is involved. Unfortunately, most windows-based firewalls do not, in their default configurations, differentiate between inter-process and inter-computer socket communication. Most firewalls will pop-up a warning when you build and run a simulation, and this is the the best time to allow the necessary socket access. However, there are some less commonly used firewalls that are not so friendly about notifying you when it begins blocking communications.

Syncad.exe, the BugHunter debugging GUI, is the program that the user typically interacts with. Syncad.exe launches simwrapd.exe when you first build a project by pressing the yellow “Build” button. Simwrapd.exe is a “simulation wrapper” that translates commands back and forth between the debugger GUI and the simulator, so that the debugger doesn’t need to know details of which simulator is being used. Simwrapd also theoretically allows remote simulations to be run transparently by the user, but this feature is not yet enabled in current versions of BugHunter.

Simwrapd, in turn, starts a simulator executable (vlogcmd.exe or simx.exe, for example). When
simx.exe (the VeriLogger Extreme command line simulator) is run, it then runs another exe called simxgen.exe. Simxgen is the “simulation generator” that compiles these user’s code to an simulation executable file called simxsim.exe. Simxsim.exe is then run to actually compute the results of the simulation.

All the above executables except simxsim.exe are located in the SynaptiCAD/bin directory. Unlike the other exe files, simxsim.exe is not shipped with the product, but is instead created based on the user’s source files, so it is generated into the project directory where the user’s project file (.hpj) is located.
Simxsim.exe is the simulation exe that gets run when you press one of the green “Run” buttons.

The socket communication channels when using VeriLogger Extreme are as follows:
syncad.exe <->simwrapd.exe
simwrapd.exe<->simxsim.exe
syncad.exe<->simxsim.exe

The socket communication channels when using the older vlogcmd simulation are as follow:
syncad.exe <->simwrapd.exe
simwrapd.exe<->vlogcmd.exe
syncad.exe<->vlogcmd.exe

The key difference, however, between simxsim.exe and vlogcmd.exe is that a new simxsim.exe is created with every compile and it is created in the project directory, whereas there’s only one vlogcmd.exe and it’s always located in SynaptiCAD/bin (because it’s an interpreted simulator, not a compiled one).

BugHunter Pro: swapping between different simulators

Leave a reply

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.