Tag Archives: simx

Using Symbolic Libraries to Speed Up Verilog Compilation

Leave a reply

Designs often reuse a common set of our Verilog source files. For example, when you’re designing using a particular family of FPGAs or ASICs, you will need to compile the vendor-provided Verilog source files for those parts. Instead of recompiling these files for each new design, you can compile them once into a symbolic library (sometimes referred to as a compiled library), then just reference that symbolic library in your designs. With this approach, you only need to recompile the vendor’s source files when you update your simulator to a newer version.

Cells and Snapshots

A symbolic library contains cells and snapshots. Cells represent the definitions for objects such as modules and User-Defined Primitives (UDPs) that are created when source files are compiled into a library. Snapshots are created during simulation elaboration and represent a fully built “simulation” that can be executed.

Within a library, cell and snapshot names must be unique and any attempt to compile a cell into a library that already contains a cell of that name will cause the original cell to be overwritten. However, cells and snapshots of the same name can exist in different libraries.

Creating Symbolic Libraries

In most Verilog compilers, a symbolic library is given both a logical name (e.g. “work”) and a physical name that indicates it’s storage location (e.g. “c:\myproject\scd_work”). The logical name is used when referring to a symbolic library in the source code or when passing a library name as a command-line option to the verilog compiler, so that the source code and script files don’t have to depend on the library’s location on a particular computer.  The physical name is only used to specify the location of the symbolic library (and typically only when the library is first created). The mapping between these two names is specified using a command-line library tool that can create and manipulate symbolic libraries and the resulting mappings are stored into a “map file”. In simx, for example, this command-line tool is called simxlib. In both Mentor Graphics ModelSim and Aldec Active HDL, the library tool is called vlib.

Work: the Default Symbolic Library

By default, sources files will be compiled into a compiled library with the symbolic name of “work“, unless a different destination library is specified via the --work <destination_library_name> compiler option. Also by default, the work library will be mapped to a subdirectory of the current working directory called scd_work, unless a map file is passed to the compiler that specifies a different physical path name for the library.  This default mapping will be written into a default map file called scd.lib which simx will subsequently load automatically whenever simulations are run from this directory. The above defaults allow simx to be used without having to worry about symbolic libraries, if you don’t plan to take advantage of them to avoid re-compiling shared Verilog code.

By contrast, some compilers require you to create at least one symbolic library using their library tool before you can compile code with these simulators, so if you use BugHunter to compile code with ModelSim or ActiveHDL, you will note that it first launches vlib to create a work library before it launches the actual Verilog or VHDL compilers (aka vlog or vsim) for these simulators.

Example Commands for Creating and Using Symbolic Libraries

To compile test1.v and add it’s contents to the default library called “work”, you can either directly specify the work library with the -work option:

simx --work work test1.v

or let the simulator just use work by default:

simx test1.v

In the above commands, the work library will be automatically created in a subdirectory called scd_work if it doesn’t already exist.

To create a library with the logical name vendor1 located at c:\vendor1 and compile a set of files into this library, use the following commands:

simxlib --create c:\vendor1
simx --work vendor1 test1.v test2.v test3.v

The above commands also create a scd.lib file in the current directory with the following contents:

DEFINE vendor1 c:/vendor1

This line says that the logical library name vendor1 maps to the physical library located at c:\vendor1.

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).