Lard Execution Environment
Test Vector Generation
Validating LARD and circuit models using Test Vectors
In order to check that a circuit correctly implements the behaviour
specified by the coresponding LARD model we take the following steps:
- Implement a simulatable model of the circuit using the schematic
entry or other package of our choice;
- Run the coresponding LARD model in some sort of testbench
environment that exercises all important behaviours;
- Define a mapping from the LARD channels that are inputs to or
outputs from the model to the coresponding signals in the circuit;
- Capture test vectors from the LARD simulation;
- Run a circuit simulation driven by and checked against the test
vectors.
The li module tvec supports steps 3 and 4 of this process.
"Slow" Test Vectors
We do not require that the timing characteristics of the LARD and
circuit models match exactly in order to say that they are equivalent;
for example when two transitions in the LARD occur concurrently we are
happy for either one to occur before or after the other in the
circuit. The approach taken here is to make the tests "slow", so in
this case will will wait for a long time and then check that both
transitions did eventually occur. This is not entirely satisfactory
for an asynchronous system but it will do for now! The idea is that
the block under test's outputs are temporarily disconnected from the
environment. Inputs from the environment are applied as usual, and a
long period of time is allowed to elapse. At the end of this period
it is reasonable to assume that all outputs from the block have
reached stable values, which are captured and are passed to the
environment. The environment will respond by applying the next
inputs.
The practical effect of this is that when you run your LARD simulation
for test vector generation it will behave differently from usual - it
will be slower. However if your system is delay insensitive this
should not change the ultimate result of the simulation.
Defining a mapping from channels to signals
For each LARD channel there will exist in the coresponding circuit
- A request signal;
- An acknowledge signal;
- Any number of data signals or buses.
The mapping from channels to these signals must define the names of
these signals, how the channel data maps onto the data signals, and
the protocols that apply to the signals. Describing this mapping is
the first task of the tvec module.
When li is invoced with the tvec module specified each channel in the
selector display has a button "vectors". This button should be
enabled for each input to or output from the block for which vectors
must be generated.
The channels that are selected are displayed in the channel list in
the tvec window. When a channel is chosen from this list its details
are shown in the other panes of the window.
The first stage in the configuration is to specify for each channel
- Whether it is an input or and output;
- What protocol is uses (2 or 4 phase, early or broad, and whether
the request and acknowledge signals are active high or active low);
- What names the request and acknowledge signals have.
The next stage is to define each of the data signals that coresponds
to that channel. The basic procedure is:
- For each signal or bus that is associated with the channel, press
"new vector" to add a new entry to the vector list.
- Give the circuit name of the bus or signal.
- Select which bit(s) of the channel data corespond to that signal
or bus.
This last point is best described with a few examples:
- A channel of type chan(void), i.e. a noput channel:
- In this case there are no data signals or buses; do not press "new
vector".
- A channel of type chan(bool), which has a single data signal:
- Press "new vector" once and enter the name of the data signal in
the "vector name" box. The vector setup area will look like this:
To indicate that a single bit from the data is mapped onto the signal,
click on "0". This box is then set to red:
- A channel of type chan(int), which coresponds to a 4-bit bus:
- Press "new vector" once and enter the name of the bus in the
"vector name" box. To indicate that the 4 least significant bits of
the data are mapped onto the signal, click on "0", "1", "2" and "3".
Alternatively click left on "0" and click middle on "3" to select all
3. The setup area then looks like this:
- A channel of type chan(int) representing a word-aligned
address, i.e. the least significant two bits are always 0 in the LARD
model and have no coresponding signals in the circuit:
- Press "new vector" once and enter the name of the bus in the
"vector name" box. To indicate that the 30 most significant bits of
the data are mapped onto the signal, click left on "2" click middle on
"31". Then to indicate that these bits corespond to bits 2-31 of the
bus rather than bits 0-30, enter 2 in the "lsb offset" box. The setup
area then looks like this:
- A channel of type
chan(record(a::bool,
b::bool))
where there is one circuit signal for each boolean field a and b:
- Press "new vector" once and enter the name of the signal
coresponding to field a. Click on bit 0 of field 0 to map field a to
this signal:
Press "new vector" a second time and enter the name of the signal
corespoinding to field b. Click on bit 0 of field 1 to map field b to
this signal:
Note that once a bit has been allocated to one vector it is shown in
grey in other vector displays and cannot be selected again.
- A channel of type
chan(record(a::bool,
b::bool))
where there is a two-bit bus with one bit for each boolean
field a and b:
- Press "new vector" once and enter the name of the bus. Click on
bit 0 of field 0 and bit 0 of field 1 to map these two bits to the
bus:
- A channel of type chan(int), which coresponds to a 31 bit bus
and a signle sign bit signal in the circuit:
- Press "new vector" once and enter the name of the bus in the
"vector name" box. Select bits 0 to 31. The setup area then looks
like this:
Press "new vector" again and enter the name of the sign bit signal.
Select bit 31.
Having defined this mapping it is important to remember to save this
information by choosing "test vector configuration" in the save
configuration dialog.
More Complex Mappings
Examples of more complex mappings are:
- Inverted (active low) buses;
- Buses with a one-hot encoding rather than a binary encoding.
The tvec module cannot provide a menu of every possible
mapping. Instead a facility is provided to call an arbitary tcl
function to perform the desired mapping. The name of this tcl
function, if any, is given for each vector in the Mapping Function
box.
A function "invert" to invert each bit of a bus has been provided in
the current version. So to define a bus where the circuit uses an
active low encoding, enter "invert" in the Mapping Function box.
Other functions may be provided in future versions, but the user is
free to implement their own at any time.
Other Setup
Before vector generation can start is is also necessary to set up the
following:
- The name of the file to which the test vectors should be saved
(it is also possible to have the vectors appear in a window for test
purposes);
- The test vector time interval;
- The test vector setup time.
- A scale factor to map from LARD time units to TimeMill time.
- The name of the subcircuit to which the test vectors will be applied.
- The names of any inputs or outputs to this circuit which are not controlled by the test vectors but which must still be connected, e.g. reset.
Before test vectors are generated it is also necessary to compile the
program with the channels_tvec library in place of the standard
channels library.
Generating Vectors
Having performed all of the necessary setup (or having loaded a
suitably setup previous configuration) you must press the "start"
button to initialise the test vector generation system. Having done
this you may run the simulation as usual; as it runs test vectors will
be output to the file that was specified. You should arange for the
simulation to end when all the vectors have been applied.
The vectors represent repititions of the following cycle (where
v is the vector interval and s is setup time):
- At time 0, for all input channels where a communication will
occur, the data is applied.
- At time s, for all input channels where a communication
will occur, an event is applied to the request signal.
- At time v:
- For all inputs where a communication is expected to have
completed, it is verified that an event has occured on the acknowledge
signal.
- For all outputs where a communication is expected to have
occured, the data is checked and it is verified that an event has
occured on the request signal.
- For all outputs where a communication will complete, an event is
applied to the acknowledge signal.
This description necessarily uses 2-phase terminology since the LARD
simulation knows nothing about the timing of the additional 4-phase
transitions. It is up to the system that applies the vectors to the
circuit simulation to handle the additional 4-phase behaviour by
applying and checking for the extra transitions.
The test vector file contains a header part which describes the
protocol information (necessary for the 4-phase code mentioned above)
followed by test commands. The meaning of these commands should be
evident.
Once the simulation has finished, press "Done". This closes the test
vector file.
Applying Vectors to the TimeMill Model
Having sucessfully generated a .tvec file, run the program
tvec2epic. This reads the .tvec file and generates a .ntl
netlist file and a .c C model. Then run TimeMill with a script
similar to the following:
TIME=1000000
CONF=foofoo.cfg
TECH=/home/amulinks/EPIC/technology/typical/cmn5_3.3v_typ.pwr
OUTFILE=foofoo
NETLIST="phil.ntl foofoo.ntl reset_gen.ntl"
VECFILE=foofoo.tvec
export VECFILE
timemill -F -t $TIME -c $CONF -p $TECH -o $OUTFILE -n $NETLIST -fm foofoo.c
When TimeMill runs, the C model will read the vectors from the .tvec
file and apply them to the circuit. Any errors will be reported using
the standard TimeMill error reporting mechanism. For example:
Simulation time progresses to 50000.000 nsWARNING: Data mismatch on dout.
Simulation time progresses to 70000.000 nsWARNING: Data mismatch on dout.
Simulation time progresses to 100000.000 nsWARNING: Data mismatch on dout.
Simulation time progresses to 120000.000 nsWARNING: Data mismatch on dout.
Simulation time progresses to 150000.000 nsWARNING: Data mismatch on dout.
Simulation time progresses to 180000.000 nsWARNING: Data mismatch on dout.