Vlogcmd (old VeriLogger Pro) is an interpreted simulator. When vlogcmd starts, it reads the source models, compiles them into internal data structures, and then executes them from these structures. The structures contain enough information that the source can be reproduced from the structures (minus formatting and comments.)

While the model is running, the simulation can be interrupted at any time by pressing <Ctrl>+C. This puts the simulator in an interactive command mode. From here VeriLogger commands and Verilog statements can be entered to debug, modify, or control the course of the simulation.

Command Line Options specific to vlogcmd

•Trace, -t enables a tracing mode that returns a trace history of each line executed into the log file.

simx -t cpu.v memory.v io.v

•Log filename, -l <log filename> changes the name of the log file that contains all output generated during a simulation. By default, the log file is called verilog.log.

simx -l mylog.log -c cpu.v memory.v io.v 

•No log, -l nolog disables the log file.

simx -l nolog -c cpu.v memory.v io.v 

•

•Compile only, -c compiles the source code and exits without performing a simulation.

vlogcmd -c cpu.v memory.v io.v

•Key filename, -k <key filename> changes the name of the key file that contains a log of all keystrokes entered during the simulation run. By default, the key file is called verilog.key.

vlogcmd -k mykey.key -c cpu.v memory.v io.v 

•No Key, -k nokey disables the key file.

vlogcmd -k nokey -c cpu.v memory.v io.v 

•Interactive Command filename, -i <filename.vi> allows the simulator to accept interactive commands from a file. Any legal interactive mode command can be included in the interactive command file. The file is submitted to the simulator before the simulation begins and starts to execute as soon as the simulator enters an interactive simulation mode. Therefore the -i command must be paired with a statement that stops the simulator and enters the interactive mode. There are two ways to do this:

•Use the -s option to stop VeriLogger and enter the interactive mode before execution begins,

•OR, embed the $stop system task into a Verilog source code file and use it with a delay to stop the system at a later time. For example, assume the file cpu.v contains the following code fragment to stop the system 1000 time units after the simulation begins:

         #1000 $stop;

This file is submitted with the following command:

simx -i interactive.vi cpu.v memory.v io.v

Compilation Process

VeriLogger uses a three-phase compilation process:

•Phase 1: The files are read and converted into an internal data structure. Syntax errors and semantic errors regarding undeclared variables or illegal use of variables are reported in this phase.

•Phase 2: In this phase the model hierarchy is built, module ports are connected, and storage for variables is allocated. If any module is instantiated more than once, its structure is copied as many times as needed. Also, module parameters are propagated. Errors reported in this phase deal with missing modules, irregularities of the parameters, and out-of-memory errors during the allocation. The project tree is built during this phase.

•Phase 3: The entire structure is re-parsed during which time-forward references to tasks and functions are resolved, hierarchical names are resolved, and expression sizes are determined. Errors detected in this phase include semantic errors dealing with hierarchical references that could not be detected in Phase 1, illegal references to functions and tasks, port size discrepancies, and illegal expression sizes.

Note: Most memory is allocated in the first two phases of the compilation.

User-Defined Primitives and Memory Usage

User-Defined Primitives (UDPs) are used to define combinatorial primitives and two-state devices. In VeriLogger, UDPs are optimized for performance. This is accomplished by creating a table in memory for each UDP definition. Only one such table is used for each UDP definition; every instance of the definition uses the same table. When there are more than six inputs, the size of the table is very large. For this reason, the maximum number of inputs is ten (nine for state UDPs). The maximum table size is approximately 256K.

Notes on Using Specify Blocks

Specify blocks are used to define pin-to-pin timings and setup-and-hold checks. In VeriLogger, specify blocks function similarly to those described in the Verilog Language Reference Manual. However, there are some differences. In VeriLogger, there is no concept of expanded nets. Nets that are defined as vectors are not split into individual nets and cannot have their own timing information. Therefore, certain combinations of timing specifications will be ignored. Specifically, there are two ways to describe module paths. One is the parallel case (=>), and the other is the full case (*>). In VeriLogger, both cases are treated as if they were defined as the parallel case. This does not pertain to scalar nets. VeriLogger supports all of the defined setup and hold systems tasks.

IEEE-1364 LRM Standardization

Except for the following discrepancies, VeriLogger behaves exactly as specified by the IEEE-1364 LRM and Verilog-XL standards.

Port Collapsing

In certain versions of Verilog, if two nets are connected together via a port, the port is collapsed (combined to form one net). In VeriLogger, module ports are connected using transparent continuous assignments. If a register is connected to a net, then the port propagation does not occur immediately after the port changes. Instead, the port propagation is scheduled for later in the same simulation time. However, when a net is connected to a net, then a collapsed port is emulated by forcing the propagation to occur instantly. The effect of this implementation does not affect the functionality of the model being simulated, but becomes visible during trace.

Port Connections of Different Net Types

VeriLogger does not check the legality of the connections of different net types in the hierarchy. For example, if a parent module instantiates a child module, and the net on the parent’s side of a port is a tri1 while the net on the child’s side of a port is a tri0, an oscillation will result. To use tri1, tri0, triand, and trior as ports effectively in VeriLogger, they should be declared only in the top-most level in the hierarchy. All lower-level connections should be declared as wire or tri.

Working Around Pullup/Pulldown Gates

When modeling an open-collector bus, a common technique is to have a pullup or pulldown gate drive a wire net and have drivers pull the bus in the opposite direction with a greater strength when asserting a signal. In VeriLogger, drive strengths are not implemented. Therefore, this technique will generate an unknown value (X) when a driver attempts to drive a signal in the opposite direction as the pull. The preferred method for modeling open-collector buses is to use the triand nets for pullup buses, and the trior nets for pulldown buses. This net type should only appear in the highest level of the hierarchy in which the bus exists.

Using Trace Implementation

Trace is an indispensable tool for debugging Verilog programs. It displays each statement as it is executed, as well as any results returned from the statement. There are three ways to enable a trace:

1) Specify the -t option at the command line.

2) Execute the system task $settrace from either the program or the interactive command line.

3) Execute and trace a single statement by entering a comma (,) at the interactive command line. Enter multiple commas to execute the respective number of statements.

If a model uses continuous assignments or ports, VeriLogger displays the activation of these as part of the trace as soon as the activation occurs. For example, given the continuous assignment assign test = bar; when bar changes, the continuous assignment is executed immediately and displayed in the trace. The continuous assignment represents one of possibly many drivers to the net test; the net itself is scheduled for updating for sometime later in the current simulation time unit.

Because port connections are implemented as continuous assignments it may take several steps for a signal to propagate from an output port to an input port, especially in cases where there are several ports connected to a net. Trace shows part of this propagation. A signal emanating from an output port travels upward to its parent module; it then travels back down to other connected ports. Each time a signal reaches a new port, the net connected to that port is evaluated and the results are displayed in the trace.

Predefined Macro __VERIWELL__

The macro __VERIWELL__ is predefined so that statements such as:

‘ifdef __VERIWELL__

are used for VeriLogger-specific code, such as for waveform display.

Simulation Statistics

The non-standard system task, $showstats, displays statistics about the current simulation, including the amount of memory used and available. Some of the information is provided for diagnostic purposes only.

Displaying the Location of the Last Value Edited

The $showvars system task optionally displays the current location in the module and the simulation time at which the module variables were last changed. This information is updated even if the value did not change (that is the new data is the same as the old data). Tracking this update information may affect the performance of the simulation slightly. If this is a problem, this feature can be disabled with the +noshow_var_change command line option.

User Interrupt

Pressing <Ctrl>+C, COMMAND+C, or <Ctrl>+BREAK (in MS-DOS) during simulation will put the command line version of VeriLogger into interactive mode. Pressing any of these during compilation will halt the process and exit to the operating system.

Implementation Differences from XL

This section describes the differences between the way VeriLogger works and the way Verilog-XL works. Note that these differences are subtle and will not affect the execution of well-written Verilog models.

Event Ordering

The order of event scheduling and execution is consistent with Verilog-XL in every extent possible. The reason for doing this is not so that models are guaranteed to work under both VeriLogger and Verilog- XL but rather because VeriLogger was designed so that users can trace models in both VeriLogger and in Verilog- XL with little noticeable difference. However, it should be noted that models that depend on the order of execution are considered to be unwisely written because they reflect race conditions and may perform unpredictably in other vendors’ Verilog, or even in future releases of VeriLogger (or Verilog- XL). In some cases, the order of net scheduling may be different. This is because Verilog- XL schedules nets differently depending on the type of net, whether it is sourced by a continuous assignment, a net assignment, or a port, and whether a port is collapsed. In most cases, net scheduling will track that of Verilog- XL.

Module Ports and Port Collapsing

Port connections are implemented as continuous assignments in VeriLogger. Rules for port connections are similar to those of Verilog-XL, but there are some differences. In Verilog-XL, under certain circumstances, ports are collapsed, that is, if each side is a net, then one of the nets disappears and only one is used. This is a performance enhancement. VeriLogger emulates port collapsing by immediately propagating values across ports that have been collapsed. This is unlike Verilog-XL, which actually combines nets that have been collapsed. Verilog-XL will expand vector nets into arrays of scalar nets if a port connects two different sized nets, or if one or both sides are concatenations or part selects. VeriLogger does not implement expansion of nets, so it could not handle these cases by building continuous assignments. VeriLogger will collapse a port if both sides of a port are scalar nets or if both sides are vector nets. Therefore, there are some cases when VeriLogger will not collapse a port, but where Verilog-XL will. This may cause a disparity in the way nets are scheduled in the two simulators.

Control Expressions are Limited to 32 Bits

Expressions used by VeriLogger for control are limited to 32 bits. This includes repeat counts, delay values, part- and bit-select and array index expressions, and shift counts. A compile-time error will result if the expression attempts to evaluate a number greater than 32 bits.

The $monitor System Task

Unlike Verilog-XL, the $monitor system task will be triggered if any variable in the argument list changes. In Verilog-XL, $monitor changes only when an argument expression changes. For example, in Verilog-XL the following statement will not be triggered if both a and b changes, and the sum stays the same. In VeriLogger, the statement will be triggered if both a and b change in this case.

$monitor (a + b);