-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathREADME
146 lines (109 loc) · 6.26 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
TBGEN(1) General Commands Manual TBGEN(1)
NAME
tbgen - generate testbench from verilog module
SYNOPSIS
tbgen [-c clock] [-d duration] [-f vcdfile] [-I include] [-l dumplevel]
[-m module] [-n tbname] [-r reset] [-s step] [-t timescale]
[inputspec...]
DESCRIPTION
tbgen is a testbench generator. tbgen reads a verilog module, called
“device under test” (or DUT, for short) from its standard input and
generates a testbench for it on the standard output.
By default, tbgen sets random values for each input of the DUT. The
value of an input can however be defined explicitly by calling tbgen
with an argument of the form "INPUTNAME:VALUES[:STEPS]".
INPUTNAME is the name of the input. VALUES is the input's initial
value (such as "4b'1010"); several inputs can be separated with a
comma; the input can also be the letter "i" for the input to be
incremented at each time step or "d" for the input to be decremented at
each time step. An optional STEP is the number of steps after which
the input must be changed. See the EXAMPLES section below for
examples.
The inputs "clk" and "rst" are special and are not set randomly by
default. The input for "clk" is alternated from 1 to 0 and back again
at each step. The input for "rst" begins 1 and is set to 0 after the
first step. Both "clk" and "rst" inputs do not need to be declared as
arguments. The name of those inputs can be changed with the -c and -r
options.
By default, tbgen does not dump memory. A memory can be dump at the
end of the simulation by calling tbgen with an argument of the form
"dump:MEMORY:FILE".
MEMORY is the name of the memory prefixed with the module path
separated by periods. FILE is the name of the file that will contain
the memory dump. See the EXAMPLES section below for illustration.
After the simulation, a "simulation.vcd" file describing the waveform
of the simulation will be created and can be checked with gtkwave(1).
The options are as follows:
-c clock
Name of the clock input (default: clk).
-d duration
Duration of the simulation in multiples of timescale (default:
100).
-f vcdfile
Name of the vcd file to be created (default: simulation.vcd).
-I include
Directory used to search for included files.
-l dumplevel
If set to 0, dump all variables in all level modules. If set to
1, dump all variables in the top-level module (the testbench).
If set to 2, dump all variables in the top-level module and the
modules instantiated by it. If set to 3, dump all variables in
the top-level modudule, the modules instantiated by it, and the
modules instantiated by the modules instantiated by it. And so
on. (default: 1).
-m module
Name of the module (default based on the input).
-n tbname
Name of the testbench module to generate (default: testbench).
-r reset
Name of the reset input (default: rst).
-s step
Duration of each step in multiples of timescale (default: 1).
-t timescale
Time scale and time unit (default: 1ns).
EXAMPLES
After generating the testbench with tbgen, compile it and the module of
the device under test with iverilog(1) to generate the vvp file; then
run the compiled vvp file with vvp(1) to generate the vcd file; then
run gtkwave(1) with the generated vcd to get the waveform:
$ tbgen <mymodule.v >testbench.v
$ iverilog -o testbench.vvp testbench.v mymodule.v
$ vvp testbench.vvp
$ gtkwave simulation.vcd
The generated testbench works by, at each simulation step, setting each
input to a random value, until the duration of the test is over.
Rather than random values, the value of an input can be defined
explicitly during tbgen invocation by calling it with an argument of
the form "INPUTNAME:VALUE". For example, the following command sets
the input "data" to the constant value of "4b'1010":
$ tbgen "data:4b'1010" <mymodule.v >testbench.v
Rather than a constant value, the values of an input can increase or
decrease over time. Just invoke tbgen with the argument "INPUTNAME:i"
for increasing values, or with "INPUTNAME:d" for decreasing values.
For example, the following command makes the value of the input "data"
increase from "4'b0000" to "4'b1111" and back again over time:
$ tbgen data:i <mymodule.v >testbench.v
Rather than changing value one step at a time you can set the value of
an input to change at a given number of steps; just append the argument
with ":NSTEPS". For example, the following command increases the value
of "dataA" at each step, and increases the value of "dataB" at each 16
steps:
$ tbgen dataA:i:1 "dataB:i:16 <mymodule.v >testbench.v
Note that the clock and reset inputs (set with -c and -r) are special
inputs, and are not set randomly.
The testbench can dump the content of a memory of a given module at the
end of the simulation. To specify a memory to be dump, call tbgen with
an argument of the form "dump:MEMORY:FILE". For example, the following
command dumps the contents of the memory "data" in the module "ram" at
the end of the simulation to the file "memdump.txt":
$ tbgen dump:ram.data:memdump.txt <mymodule.v >testbench.v
Note that the module "ram" is instanciated in the DUT "mymodule.v". if
the memory is declared directly in "mymodule.v", there is no need to
prefix the memory name with a module path.
$ tbgen dump:data:memdump.txt <mymodule.v >testbench.v
SEE ALSO
gtkwave(1), iverilog(1)
BUGS
tbgen(1) is not a Verilog parser, it expects the module file to be well
written.
TBGEN(1)