Clock Stimulus
Clock signal may be separated from the main stimulus definition, this should simplify the stimulus definition considerably.
The following construct defines a clock with a period of 1000 time units:
always
begin
clock = 0;
#250
clock = 1;
#500
clock = 0;
#250
clock = 0;
end
You can create a default clock stimulus automatically when you run "ext2svmod" using the "-clock <signal>" option. Thus the command "ext2svmod -clock Clock Counter" will create SystemVerilog simulation files for the magic cell "Counter.mag" including a default clock stimulus for the signal "Clock".
Note that no SystemVerilog simulation of a magic design is "time accurate" (the time delays observed arise from the nominal one time unit delay assigned to each transistor in the .vnet netlist file). In order to avoid false timing problems it is best to maintain a high ratio between the clock period and the nominal delay for a single transistor. Thus if you need to reduce the clock period below the default specified here, you should also reduce the "timeunit" setting for the <cellname>.sv file.
Gray Code Stimulus
For simple combinational gates such as AND, OR, NAND, NOR, XOR a Gray code stimulus is appropriate (with this stimulus all combinations of inputs are tested sequentially with no two inputs changing at the same time).
An example of a Gray code stimulus for 4 inputs is shown below:
You can create a Gray code stimulus automatically when you run "ext2svmod" using the "-gray" option.
To create the Gray code stimulus shown above for the magic cell "Nand4.mag", the command is:
ext2svmod -gray "D C B A" Nand4
Bidirectional Ports
For simple gates, "ext2svmod" will automatically detect inputs and outputs based on the presence of appropriate labels in the magic cell and taking into account the transistor wiring in the extracted version (N.B. if "ext2svmod" thinks that one of your inputs is an output or vice versa, you have miswired your circuit).
"ext2svmod" cannot detect bidirectional ports. It will assume that they are outputs. If you have any bidirectional ports in your design, you should use the "-inout" option to declare them when you run "ext2svmod". e.g.
ext2svmod -inout "DataBus" datapath
tells "ext2svmod" that the "DataBus" should be treated as bidirectional when creating default SystemVerilog files.
Probing Internal Signals
"ext2svmod" assumes that any point labels in the magic cell are internal signals of interest to the designer. The names of these signals are included in a list named "wave_signal_list" found in the "<cellname>.tcl" SimVision script file.
If you want to probe additional signals in the toplevel cell, you can add further point labels to your design, delete "<cellname>.sv" and "<cellname>.tcl" then re-run "ext2svmod" and "xmverilog".
Probing Signals within Sub-cells
It is also possible to probe signal which are internal to sub-cells by editting the "<cellname>.tcl" file directly.
If you want to probe a signal "XYZ" within a subcell "subcell_0" the name of the signal in the extracted netlist will be "\subcell_0/XYZ ". Note that the trailing space is part of the name of the signal.
In order to include this signal in the "wave_signal_list" the name used by XM-Verilog includes the name of top level module in the simulation (which will be "<cellname>_stim") and the name of the module instance for the module under test (which is always "instance1").
The full name used in the "<cellname>.tcl" file will be:
{<cellname>_stim.instance1.\subcell_0/XYZ }
The brackets "{}" are used to ensure that the trailing
space is not lost.
The following is an example of a "wave_signal_list" definition that includes both an internal signal "mid" and a signal "nQ" within a sub-cell "dtype_0":
# List of signals to monitor defined here
#
set wave_signal_list {
test_stim.Clock
test_stim.nReset
test_stim.OUT
test_stim.instance1.mid
{test_stim.instance1.\dtype_0/nQ }
}
Probing Multi-Bit Bus Signals within Sub-cells
The "ext2svmod" script understands multi-bit buses in the top level magic cell. Thus if it finds labels A[0], A[1] and A[2] it will identify them as part of a bus A[2:0] and will arrange for the bus to be included in the waveform window.
Probing of multi-bit buses within sub-cells is more complex since it requires the editing of the "<cellname>.sv".
The following example shows the observation of a 8-bit bus signal named A where the different parts of the bus are in different subcells. This is a situation commonly found in bitslice designs.
// structural model of datapath extracted from datapath.mag
module datapath(
output ..... ,
input ..... ,
);
timeunit 1ns;
timeprecision 10ps;
// include netlist information from datapath.vnet
`include "datapath.vnet"
wire [7:0]A;
assign A = { \bitslice_7/A ,
\bitslice_6/A ,
\bitslice_5/A ,
\bitslice_4/A ,
\bitslice_3/A ,
\bitslice_2/A ,
\bitslice_1/A ,
\bitslice_0/A };
endmodule
Points to note:
"\bitslice_5/A " is the name of the signal A within instance 5 of the sub-cell bitslice (make sure you check which which sub-cell has which name in your top level cell).
The space at the end of "\bitslice_5/A " is part of the name - this explains the gap before the comma in "\bitslice_5/A ,"
During extraction, each circuit node is assigned a unique name. Hierarchical names such as "\bitslice_7/A " will be masked if a signal is named in the top level of the hierarchy. Check the <cellname>.vnet file to see which names exist for observation.
The assign statement must come after the `include "<cellname>.vnet" statement.
"wire [7:0]A;" declares the bus signal as a wire - since it is an internal signal it should not be declared as an output.
Probing is now the same for this bus signal as it would be for any other internal signal. In the case of the example above we might add datapath_stim.instance1.A to the list of signals to be monitored within datapath.tcl so that the newly declared bus signal would automatically be shown in the waveform window.