The original document begins with a short introduction and the following list of sections. From this point on, very little has changed from the original document.
Testing will be accomplished by running a number of test sequences. Each sequence will test a few functions of the chip, and, hopefully, nearly all functions of the chip will be tested thoroughly by at least one of these test sequences. At the end of every simulation (i.e. every set of sequences) the errors detected during that simulation will be written to a file, Simulation_Errs_File (specified in the test_template.h file).
Each sequence will be divided into three parts:
start_sequence("configuration_file_name", "packets_log_file_name",
"stats_log_file_name", "errs_contr_log_file_name",
<quick>, <fast_ins>)
which will do two things. First, it will put Arctic in configuration
mode and set it up according to what is specified in the file
"configuration_file_name", or it will skip configuration altogether if
"configuration_file_name" has a value of zero. The <quick>
argument is a flag that will ``cheat,'' i.e. configure Arctic
without using the maintenance interface, if set to 1. Secondly,
the task opens all the files to which data will be written during
the test sequence. These files will be accessed with three
Verilog ``Multi Channel Descriptors.''
Running the test will involve alternating run and store procedures. A number of actions will take place, and then the current state of the system will be stored. After that, new actions can take place and the current state will be appended to the files created before.
``Actions'' refer to any data or information sent into the chip after configuration. Each action in this system is performed with a Verilog function call. Some of these actions have prefixes such as `` mn'' or `` in'' because they are defined within a Verilog module by that name. At this time, there are seven different kinds of actions:
If any log file does not correspond exactly with the appropriate check file (ignoring don't care fields), error messages explaining the error will be printed to the screen and to a file, Simulation_Errs_File (which is specified in the test_template.h header). When errors are detected, the simulation may halt. If HALT_ON_ERR (also defined in test_template.h) is set to 1, execution of the simulation will halt at the end of a sequence when errors are detected. If it is 0, the simulation will continue.
Also note that this HALT_ON_ERR bit determines whether or not the system will halt when link errors are detected. These errors can occur at any time, not just at the end of a sequence. Error messages caused by link errors will also be written to Simulation_Errs_File.
There are two parts to the file. The first part is a list of Packet Library Files. Each Packet Library that is to be used in the test needs to appear in this file. These libraries must appear as filenames given relative to the test_drv directory. After all packet libraries are given, the keyword sequences must appear. This word must be at the beginning of a line, and it must be on the line by itself. An arbitrarily long list of test sequences will follow. Please note, while the system allows sequences to be run without specifying Configure Files (if the user wants to run a sequence without re-configuring), the system will not be able to run unless the first sequence in the list configures Arctic.
Each test sequence is specified by number as in test001 or test999 or any other number. We have specified how the sequences will appear on disk. The program run_test will enter each test sequence directory and splice the appropriate code into the right location in test_drv.v, and then run the simulation. The code for each test sequence is assumed to be in the file test***.code (i.e. for the test sequence test004, the code should be in /sequences/test004/test004.code). The format for a test sequence is given above.
Just to add a little sugar, all white space will be treated equally in the test description files, so the actual text format does not matter. Just list the packet libraries, then write the word sequences, and then list all the sequences. Also, on every line, all text following the symbol `` #'' will be treated as a comment and will be ignored.
There is a single command line option. The -b switch tells the system to use a compiled and back annotated description of the chip rather than a Verilog behavioral description.
integer packet_word_addr, packet_id; reg [15:0] packet_word0, packet_word1; //Assume packet_id has been set to some known value. //Remember integers function as 32 bit registers in Verilog packet_word_addr = get_packet_addr(packet_id); packet_word0 = packet_arr[packet_word_addr]; packet_word1 = packet_arr[packet_word_addr+1];In this way, all words in a packet can be accessed. It is up to the module or task calling get_packet_addr to keep track of how long the desired packet is. get_packet_addr will return 0 if the given <packet_id> is invalid.
At many places in this section the file names themselves will be specified. Usually, these are of the form test*.<ext> where `` *'' is an identifier unique to each test sequence and `` <ext>'' is some extension. Here, we specify that this unique identifier, `` *'' must be a three digit decimal number ranging from 000 to 999. This is required because the length of the filenames (in characters) must be kept constant.
After these two words come the packets themselves. Each packet begins with a newline followed by a 32-bit packet identifier (also split into two 16 bit parts followed by a newline) and then the 16 bit words of the packet are given one by one with a newline after each one. Each new packet follows immediately after the previous one. No restriction is placed on the what form the packet itself must take, except that the first 2 data words (the first 32-bit word in the payload) must be the 32-bit identifier given before. Finally, after the last packet, a 32-bit trailer will follow. This trailer is also split into 16 bit parts. It is guaranteed to be different from every possible packet identifier. The format is further detailed below.
It must be stated that the specified fields in the packet identifier are used only to aid the programmer in differentiating between packets. The only requirement on the packet identifiers that is needed to make the program work is that all identifiers must be unique each time the program is compiled.
Following is the exact format of this file with each type of word defined exactly.
[31:16] header 0 \n
[15:0] header 0 \n
[31:16] header 1 \n
[15:0] header 1 \n
\n (added for readability)
[31:16] packet identifier \n
[15:0] packet identifier \n
[15:0] packet word 0 (uproute) \n
[15:0] packet word 1 (downroute) \n
[15:0] packet word 2 (partid & len) \n
[31:16] packet identifier (first data word) \n
[15:0] packet identifier (second data word) \n
[15:0] third data word \n
.
.
.
(next packet)
\n
[31:16] packet identifier \n
[15:0] packet identifier \n
[15:0] packet word 0 (uproute) \n
.
.
.
(after last packet)
[31:16] trailer \n
[15:0] trailer \n
header0 [31:0]
[31:0] - Total number of 16-bit words in the file
header1 [31:0]
[31:0] - Total number of packets stored in the file
packet_identifier [31:0]
[31] - Unused. Should be set to 0 unless needed for some
reason
[30:29] - Output port number (0-3) out of which the packet is
to leave (or 0 if not needed)
[28:24] - The size of the whole packet in # of 32 bit words.
Note that this is not the number of 16 bit
words. The length field is kept this way to
be consistent with the length field in the
actual packet.
[23] - 1 iff the packet is a priority packet
[22] - 1 iff the packet should generate a crc error
[21] - 1 iff the packet should generate a length error
[20:15] - Identifier saying which packets file this packet's in
[14] - Always 0
[13:4] - Identifier saying which configuration file was used
to generate this packet (This will be the number of
the first test sequence where this configuration
appears). Alternatively, if this is being used in a
packet library where this field is not needed, it
can be used simply as a generic field to
differentiate packets in any way.
[3] - 0 if this packet was designed to go into a
particular input port.
1 otherwise
[2] - Unused. Should be set to 0 unless needed for some
reason
[1:0] - The input port this packet is meant to be sent into
if one needs to be specified, or 0 otherwise.
trailer [31:0]
[31:0] - Always one value (1f00_0000)
This file is also stored as a sequence of hexadecimal numbers, starting with a 68-bit header, a newline, and a list of 68-bit words (each followed by a newline), one for every packet to be inserted into the system. Packet insertion commands must be listed in order of increasing time.
[67:0] header \n
[67:0] packet insertion command \n
[67:0] packet insertion command \n
[67:0] packet insertion command \n
.
.
.
header [67:0]
[67:32] - Always zero
[31:0] - The number of packets to be inserted into the system
packet insertion command [67:0]
[67:36] - Time (in # of cycles) after starting that the packet
should be sent in.
[35:4] - Packet identifier
[3] - Always zero
[2:1] - Input Port the packet is inserted into
[0] - Always zero
[71:0] - received packet record or buffer free record
[71:0] - received packet record or buffer free record
.
.
.
[71:0] - received packet record or buffer free record
[71:0] - trailer
received packet record [71:0]
[71:40] - Packet identifier
[39:38] - Always 0
[37:36] - Output Port packet was sent from
[35:33] - Always 0
[32] - 1 iff received packet matches the transmitted packet
bit for bit
[31:0] - Time in # of cycles after the beginning of a sequence
that the packet was finished being transmitted
from ARCTIC
buffer free record [71:0]
[71:35] - The number 1e0000000 (37 bits)
[34] - Always zero
[33:32] - The input port the buffer free signal came from
[31:0] - Time in # of cycles after the beginning of a sequence
that the buffer free signal was given.
trailer [71:0]
[71:0] - The number 1f_0000_0000_0000_0000
The corresponding check file has nearly the same format. Major
differences are as follows:
\n [35:0] - header (0_0000_0001) \n [35:0] - Port 0 packets statistic \n [35:0] - Port 0 priority statistic \n [35:0] - Port 0 up statistic \n . . . [35:0] - Port 3 down statistic \n [35:0] - Port 3 idle statistic \n [35:0] - Port 3 wait statistic \n (If a second report follows..... these lines are added) \n [35:0] - header (0_0000_0001) \n [35:0] - Port 0 packets statistic \n [35:0] - Port 0 priority statistic \n . . . \n [35:0] - trailer (0_0000_0000) \nAgain, the check file is the same format, except that x's may be inserted into fields that are not important.
Each report consists of a newline, followed by a 17 bit value set to 1, followed by 4 17-bit words (each corresponding to the errors information for one port and each followed by a newline), followed by two 17-bit words giving the status of the control register (in a weird format), followed by a single 17-bit word holding the buffer free counters.
The 4 error words will be arranged in port order, starting with port 0 and continuing to port 3. The control word format is just plain strange because of the move from an 8-port to a 4-port arctic. The first 2 bits appear at the beginning of the first word and the last 16 appear at the end of the second. The format for the buffer free count word is given in the Arctic user's manual. Since this word is only 16 bits long, we add a 0 in bit location 17. After the last report there is a newline followed by a 17 bit 0.
\n
[16:0] header (0_0000_0000_0000_0001) \n
[16:0] error word for port 0 \n
[16:0] error word for port 1 \n
[16:0] error word for port 2 \n
[16:0] error word for port 3 \n
[33:17] control status report \n
[16:0] control status report \n
[16:0] buffer free report\n
(If a second report follows..... these lines are added)
\n
[16:0] header (0_0000_0000_0000_0001) \n
[16:0] error word for port 0 \n
[16:0] error word for port 1 \n
.
.
.
\n
[16:0] trailer (0_0000_0000_0000_0000) \n
error word [16:0]
[16:15] - Always set to 0 (unused)
[14:13] - Buffer free error count
[12] - ICLK error
[11:10] - Route error count
[9:8] - Idle error count
[7:6] - Length error count
[5:4] - Frame error count
[3:2] - Overflow error count
[1:0] - CRC error count
control status report [33:0]
[33:32] - Control Status word bits [17:16]
[31:16] - Always zero
[15:0] - Control Status word bits [15:0]
The format of the control status word is given in the Arctic user's
manual as it is too lengthy to detail here.
buffer free report [16:0]
[16] - Always set to 0 (unused)
[15:0] - Buffer Free Counter Word
The format of the Buffer Free Counter word is given in the Arctic
user's manual as it is too lengthy to detail here.
Again, the check file is the same format, except that x's may be inserted into fields that are not important.
[31:0] header (0000_0000) \n [31:0] Port 0 configuration word 0 \n [31:0] Port 0 configuration word 1 \n [31:0] Port 0 configuration word 2 \n [31:0] Port 0 configuration word 3 \n [31:0] Port 0 configuration word 4 \n [31:0] Port 1 configuration word 0 \n [31:0] Port 1 configuration word 1 \n . . .A definition of the bits in each of these configuration registers is given in the Arctic user's manual and is too lengthy to detail here.
If the header contains the value 1, then the file contains only 5 configuration words. These five words will be broadcast to the entire chip.
[31:0] header (0000_0001) \n [31:0] configuration word 0 \n [31:0] configuration word 1 \n [31:0] configuration word 2 \n [31:0] configuration word 3 \n [31:0] configuration word 4 \n