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.