Tag Archives: process.ordering

Detecting Races with VeriLogger

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!