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…
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:
simx +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.
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.
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.
If you’re learning Verilog for the first time, you may be interested in several text books that now ship with an included VeriLogger disk and introductory Verilog source files and projects that are “ready to compile”. Here’s a partial listing as of the date of this posting in order of most recently published/updated:
FSM-based Digital Design using Verilog HDL by Peter Minns and Ian Elliott, 2008
Digital Design (4th Edition) by Morris Mano & Michael Ciletti, 2006
Digital Design (3rd Edition) by Morris Mano, 2001
The Verilog Hardware Description Language by Thomas & Moorby, 5th edition (2002)
If you obtain one of the older books, you should probably download the most recent version of the simulator for best performance.
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).
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.