URL
https://opencores.org/ocsvn/pavr/pavr/trunk
Subversion Repositories pavr
[/] [pavr/] [trunk/] [doc/] [html/] [group__pavr__test.html] - Rev 6
Compare with Previous | Blame | View Log
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<title>Testing</title>
<link href="doxygen.css" rel="stylesheet" type="text/css">
</head><body>
<!-- Generated by Doxygen 1.2.16 -->
<center>
<a class="qindex" href="main.html">Main Page</a> <a class="qindex" href="modules.html">Modules</a> <a class="qindex" href="pages.html">Related Pages</a> </center>
<hr><h1>Testing</h1><table border=0 cellpadding=0 cellspacing=0>
<tr><td colspan=2><br><h2>Modules</h2></td></tr>
<tr><td nowrap align=right valign=top><a class="el" href="group__pavr__test__bugs.html">Bugs</a></td></tr>
<tr><td nowrap align=right valign=top><a class="el" href="group__pavr__fpga.html">FPGA prototyping</a></td></tr>
</table>
<hr><a name="_details"></a><h2>Detailed Description</h2>
<dl compact><dt><b>
Testing strategy</b><dd>
When testing a certain entity, the following <b>testing</b> <b>strategy</b> was adopted: <ul>
<li> embed that entity into a larger one that also includes all other ingredients needed for a real-life simulation of the tested entity. Typical such `other ingredients' are RAMs and multiplexers. <li> run custom VHDL tests that test as much as possible of the functionality of the device under test. Extreme cases are the first situations to be tested. </ul>
<br>
Two kinds of tests were conducted on pAVR: <ul>
<li> every module of pAVR was separately tested as described in the testing strategy above. <li> pAVR as whole was tested as described in the testing strategy above. </ul>
<br>
</dl><dl compact><dt><b>
Testing pAVR modules</b><dd>
Each pAVR module was separately tested. <br>
The particular tests carried out are presented below, grouped by the entities under test: <ul>
<li> <b>utilities</b> defined in `std_util.vhd' <br>
The associated test file is `test_std_util.vhd'. <br>
The utilities defined in `std_util.vhd' here are: <ul>
<li> type conversion routines often used throughout the other source files in this project <li> basic arithmetic functions <li> sign and zero-extend functions <br>
Both are tested in `test_std_util.vhd'. <br>
Extreme cases and typical cases are considered. <br>
<li> vector comparision function <br>
Tested in `test_std_util.vhd'. <br>
Extreme cases and typical cases are considered. <br>
</ul>
<li> <b>ALU</b> <br>
The associated tests are defined in `test_pavr_alu.vhd'. They consist of checking the ALU output and flags output for all ALU opcodes, one by one, for all of these situations: <ul>
<li> carry in = 0 <li> carry in = 1 <li> additions generate overflow <li> substractions generate overflow </ul>
There are 26 ALU opcodes to be checked for each situation. <li> <b>Register</b> <b>File</b> <br>
The associated tests are defined in `test_pavr_register_file.vhd'. <br>
The following tests are done: <ul>
<li> read all ports, one at a time <ul>
<li> read port 1 (RFRD1) <li> read port 2 (RFRD2) <li> write port (RFWR) <li> write pointer register X (RFXWR) <li> write pointer register Y (RFYWR) <li> write pointer register Z (RFZWR) </ul>
<li> combined RFRD1, RFRD2, RFWR <br>
They should work simultaneousely. <li> combined RFXWR, RFYWR, RFZWR <br>
They should work simultaneousely. <li> combined RFRD1, RFRD2, RFWR, RFXWR, RFYWR, RFZWR <br>
That is, all RF ports are accessed simultaneousely. They should do their job. <br>
However, note that the pointer registers are accessible for writting by their own ports but also by the RF write port. Writing them via pointer register write ports overwrites writing via general write port. Even though concurrent writing could happen in a perfectly legal AVR implementation, AVR's behavior is unpredictible (what write port has priority). We have chosen for pAVR the priority as mentioned above. </ul>
<li> <b>IO</b> <b>File</b> <br>
The associated tests are defined in `test_pavr_io_file.vhd'. <br>
The following tests are performed on the IOF: <ul>
<li> test the IOF general write/read/bit processing port. <br>
Test all opcodes that this port is capable of: <ul>
<li> wrbyte <li> rdbyte <li> clrbit <li> setbit <li> stbit <li> ldbit </ul>
<li> test the IOF port A. <br>
Port A is intended to offer to pAVR pin-level IO connectivity with the outside world. <br>
Test reading from and writing to Port A. <br>
Test that Port A pins correctly take the appropriate logic values (high, low, high Z or weak high). <li> test Timer 0. <ul>
<li> test Timer 0 prescaler. <li> test Timer 0 overflow. <li> test Timer 0 interrupt. </ul>
<li> test External Interrupt 0. <br>
Test if each possible configuration (activation on low level, rising edge or falling edge) correctly triggers External Interrupt 0 flag. </ul>
<li> <b>Data</b> <b>Memory</b> <br>
The tests defined in `test_pavr_dm.vhd' are simple read-write confirmations that the Data Memory does its job. </ul>
</dl><dl compact><dt><b>
Testing the pAVR entity</b><dd>
pAVR as a whole was tested by building an upper entity that embedds a pAVR, its Program Memory and some multiplexers. Those multiplexers are meant to give Program Memory control to the test entity (for properly setting up Program Memory contents) or to pAVR (while pAVR is actually being monitored as it executes intructions from the Program Memory). <br>
<br>
The binary file that will be executed by pAVR during the test is automatically loaded into the Program Memory using an ANSI C utility, TagScan. The test entity has a number of tags spread over the source code, as comments. The TagScan utility reads the binary file to be loaded, scans the test file, and inserts VHDL statements into the properly tagged places. These statements load the Program Memory using its own write port. This way of initializing the Program Memory seems more general (and surely more interesting) than using file IO VHDL functions. <br>
The TagScan utility is also used for other purposes. For example, for inserting a certain header in all source files. It is heavily used as a general preprocessor. <br>
<br>
Testing pAVR as a whole actually means designing and running binaries that put pAVR on extreme situations. <br>
The following tests are done:
<ul>
<li> <strong> Interrupts </strong> <br>
This exercises pAVR interrupt handling. <br>
All interrupts are tested. <br>
The associated peripherals (Port A, Timer 0 and External Interrupt 0) are
put in a variety of conditions. <br>
Results: <br>
tbd
<li> <strong> General test </strong> <br>
This is a hand-written assembler source that is meant to be assembled and
run on pAVR. <br>
It exercises each of pAVR instructions, one by one. <br>
It tries to put pAVR in most difficult situations, for each instruction. For
example, it exercises:
<ul>
<li> concurrent stalls
<li> stalls combined with 32 bit instructions
<li> stalls combined with intructions that change the instruction flow
<li> control hazard candidates (stress the Program Memory Manager and
the Stall and Flush Unit)
<li> data hazard candidates (stress the Bypass Unit)
</ul>
Results: <br>
Passed OK. The verification consisted of checking each instruction, each
intermediate result and each relevant intermediate internal state.
<table border="1" cellspacing="0" cellpadding="4">
<tr>
<th> Assembler
<th> Clocks
<th> Instructions
<th> CPI
<tr>
<td> avrasm32, by Atmel
<td> 667
<td> 361
<td> 1.85
</table>
<li> <strong> Sieve </strong> <br>
Sieve of Eratosthenes; finds the the first 100 prime numbers. <br>
Written in ANSI C. <br>
Results:
<table border="1" cellspacing="0" cellpadding="4">
<tr>
<th> Compiler
<th> Clocks
<th> Instructions
<th> CPI
<tr>
<td> avr-gcc, O0
<td> 12170
<td> 8851
<td> 1.37
<tr>
<td> avr-gcc, O3
<td> 11946
<td> 8824
<td> 1.35
</table>
<li> <strong> TagScan </strong> <br>
Exercises string manipulating routines. <br>
Written in ANSI C. <br>
Results:
<table border="1" cellspacing="0" cellpadding="4">
<tr>
<th> Compiler
<th> Clocks
<th> Instructions
<th> CPI
<tr>
<td> tbd
<td> tbd
<td> tbd
<td> tbd
</table>
<li> <strong> C compiler </strong> <br>
Written in ANSI C. <br>
Results:
<table border="1" cellspacing="0" cellpadding="4">
<tr>
<th> Compiler
<th> Clocks
<th> Instructions
<th> CPI
<tr>
<td> tbd
<td> tbd
<td> tbd
<td> tbd
</table>
<li> <strong> Waves </strong> <br>
Simulates waves on the surface of a liquid. <br>
Written in ANSI C. <br>
Uses floating point numbers (observation: the avr-gcc compiler seems to
take about 200 pAVR clocks per floating point operation). <br>
A mesh of only 5x5 points is considered, and only 5 iterations
are done. Bigger values make the simulation unacceptably long on
the available computer. <br>
Checking the result is done by converting the array of 25 floats
into a scaled array of 25 chars, copying these chars from Data
Memory (by hand), constructing a 3D image of the result, and
comparing it to a reference 3D image. <br>
Results: <br>
Passed OK. As expected, the chars array to be tested exactly matches
the reference array.
<table border="1" cellspacing="0" cellpadding="4">
<tr>
<th> Compiler
<th> Clocks
<th> Instructions
<th> CPI
<tr>
<td> avr-gcc
<td> 209,175
<td> 122,236
<td> 1.71
</table>
</ul>
<br>
</dl><hr><address align="right"><small>Generated on Tue Dec 31 20:26:31 2002 for Pipelined AVR microcontroller by
<a href="http://www.doxygen.org/index.html">
<img src="doxygen.png" alt="doxygen" align="middle" border=0
width=110 height=53></a>1.2.16 </small></address>
</body>
</html>