April 8th, 2011
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.
Tags: constants, localparam, param, search, Verilog, Verilog IP
Posted in GUI Debugging, Tips | No Comments »
March 21st, 2011
Verilog PLI (Programming Language Interface) applications and SystemC simulations can now be compiled and simulated from the BugHunter graphical interface. It’s also possible to run the resulting SystemC simulations in parallel with a Verilog simulation.
Tags: BugHunter, SystemC, Verilog
Posted in GUI Debugging | No Comments »
February 22nd, 2011
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!
Tags: ActiveHdl, detecting, ModelSim, NcSim, process.ordering, race, simulation.race, VCS, Verilog, VeriLogger
Posted in Tips | No Comments »
July 2nd, 2010
As expected, we didn’t see nearly the performance improvement on Windows that we did on Unix. Average speed improvement was probably 3% or less on our benchmark suite. However, the 64bit simulator is still useful when you’re working on a very large design that won’t compile or run within the memory limits of 32-bit Windows (either 2GB, generally).
Tags: 64bit simulator Windows
Posted in Architecture, Performance | No Comments »
February 13th, 2010
We recently released a 64-bit Linux version of the simulation engine. The main reason for this port was to allow the simulator to handle extremely large designs (32-bit applications are limited to 3GB on Linux and while this is enough for most designs, it’s a definite limitation for some of today’s large designs).
However, we were surprised and pleased to find that the 64bit simulator runtime executes about 30% faster than the 32bit version running on equivalent hardware. We also see a decent speedup during the simulation generation process (e.g. compiling the Verilog code into a simulation). 64bit mode does use a little more memory since pointers are 64bits rather than 32bits in size, and this had been one area of concern to us when starting the port, but in practice we found this had little impact on memory usage by the simulator.
We’ve not had a chance yet to fully explore all the reasons for the speedup, but initial research has turned up several reasons for this. First, in 64bit mode, about twice as many registers are available to the compiler, allowing commonly used varaiables to be kept inside the CPU longer. In addition, since 64bit Linux is less register constrained, it uses a different function calling convention (known as the __fastcall convention)where most function parameters can be passed in registers rather than on the stack, reducing the overhead of function calls. And, finally, 64bit integer operations (such as time value calculations in Verilog) can be done in a single operation, of course.
If you’re like me, you’d like to know more about exactly why we see such a dramatic speedup. Well, it’s on the list for further investigation, but that work is pending right now till we finish our 64bit Windows port. We’ll revisit this subject then, and in the meantime I hope to be able to report on what kind of improvement we see for 64bit Windows. We’re expecting less improvement here, since the 64bit Windows version of the fast-call covention only passes the first four parameters of a function via registers.
Tags: fastcall 32 64 simulation Linux Windows Verilog
Posted in Performance | No Comments »
August 5th, 2009
We’ve made a change in the way we build simulations to eliminate multiple warnings that used to be generated by some firewall software (the most annoying being the built-in firewall that comes with Windows, because it even warns about completely safe local traffic between programs on your system). We no longer create an executable called simxsim.exe each time a simulation is built that needs a new validation by the firewall (for details, see my previous post about firewalls).
Now when you build a simulation, we create a shared library called simxsim.dll (or simxsim.so on Unix), instead. To perform a simulation, an executable program called simxloader.exe is run, and this exe loads and runs the simxsim shared library that represents the actual simulation. Simxloader doesn’t change, so once it’s been validated once by your firewall, it doesn’t have be revalidated again every time you build a new simulation. Peace between VeriLogger and overly picky firewalls has finally been declared!
If you’ve read the previous post on how the various programs communicate in Verilogger, the only change is that where it previously read simxsim.exe, now it should read simxloader.exe (simxloader.exe is installed in the bin subdirectory of the SynaptiCAD installation directory with our other pre-built programs). The Simxsim shared library is built in the current working directory (the directory where your project file is located if you’re building with the BugHunter debugging GUI).
Tags: firewall simxsim simxloader dll shared library Windows
Posted in Architecture | No Comments »
August 5th, 2009
This site was down for a bit during re-hosting, then it was back up, but not accessible internally for me! Needless to say, this made it difficult for us to make new postings. But all’s well now, so let the postings begin…
Posted in Uncategorized | No Comments »
January 30th, 2009
The Verilog 2005 standard introduced a new feature to support protected intellectual property. This feature allows IP vendors to deliver models in encrypted form. Vendors may choose to encrypt entire files, or only encrypt parts of a model. You can choose to encrypt entire files, or only encrypt parts of a model. Xilinx has begun using this method to encrypt it’s latest IP models, since the resulting models simulate faster than object-code model equivalents (e.g. SmartModels).
The simplest way to encrypt your source code is to use VeriLogger’s public key. This will allow any VeriLogger user to compile and use the encrypted model by simply adding the file to their project. VeriLogger will compile and simulate using the encrypted code, but the user will not have access to any of the source code. You can also encrypt a file with a public key of own, then provide this key to consumers of your IP so that they can use the IP with any simulator that supports the encryption standard.
Encryption Steps
Before encrypting your source, test the unencrypted source code with VeriLogger Extreme to ensure that it compiles without errors. Since the end-user of your IP will not have access to the source code, they will be unable to fix any problems, and error messages in encrypted sections of code will be useless.
To create an encrypted file, perform the steps below:
1. Add `pragma protect directives to the source to delimit which sections to encrypt. Anything between a `pragma protect begin line and a `pragma protect end will be encrypted. Anything outside these directives will be copied verbatim to the output file.
2. Run the simulation generator, simxgen, to encrypt a source file called sram.v:
simxgen +protect sram.v
This will generate an encrypted file called sram.vp. The .vp file extension indicates an encrypted verilog file.
For details on how to create and use your own encryption keys or how to encrypt a model with multiple keys, see the section on Verilog Protected Envelopes in the Verilogger online help.
Tags: .vp, encrypted, envelope, models, protected, public key, SmartModels, Verilog 2005, Xilinx
Posted in Uncategorized | No Comments »
December 2nd, 2008
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.
Tags: compiling, error reporting, fuzzy parsing, hdl debugging, preparse
Posted in GUI Debugging | 1 Comment »
September 3rd, 2008
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.
Tags: Waveform dumping, Waveform viewing
Posted in GUI Debugging | No Comments »