head 1.1; branch 1.1.1; access ; symbols noReleaseTag: noVendorName:1.1.1; locks ; strict; comment @# @; 1.1 date 2003.; author doru; state Exp; branches; next ; date 2003.; author doru; state Exp; branches ; next ; desc @@ 1.1 log @Initial revision @ text @ Testing
Main Page   Modules   Related Pages  



FPGA prototyping

Detailed Description

Testing strategy
When testing a certain entity, the following testing strategy was adopted:
Two kinds of tests were conducted on pAVR:
Testing pAVR modules
Each pAVR module was separately tested.
The particular tests carried out are presented below, grouped by the entities under test:
Testing the pAVR entity
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).

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.
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.

Testing pAVR as a whole actually means designing and running binaries that put pAVR on extreme situations.
The following tests are done:

Generated on Tue Dec 31 20:26:31 2002 for Pipelined AVR microcontroller by doxygen1.2.16
@ log @Importing into repository the new directory structure. @ text @@