source: trunk/softs/tests_ccvcache_v4/README@ 265

Last change on this file since 265 was 232, checked in by alain, 14 years ago

Introducing the elementary tests for a TSAR mono-cluster
mono-processor platform with MMU using the vci_cc_vcache_v4
such as the "tsarv4_mono_mmu".
(assemby level tests written by Manuel Bouyer)

File size: 2.4 KB
Line 
1This is a very basic framework for running regression tests against
2a mips32+vcache2 platform. Here's the layout of this directory:
3
4plaform/
5 contains the soclib platform description and simulation executable.
6 It should be compiled before starting tests.
7 It includes a very simple component "vci_exit". It has a single
8 write-only 32bit register. When a value is written, the
9 caba code does a "exit(data)", using the value written to
10 the register. This allows to stop the simulator from software
11 and pass an exit value to the calling shell. The framework uses
12 this (with other things, see below) to determine if a test
13 is successfull. The simulator will exit with a non-0 exit status
14 after 100000 cycles (and a message to stderr), so the tests are
15 expected to be simple.
16 The platform has a tty, which is redirected to a file along with
17 the simlulator's output. The test framework may search for specific
18 strings in this file to determine if a test was successfull.
19common/
20 Some common functions, ldscripts, etc ... used by the tests.
21 It has a subr.S which holds usefull subroutines, such as
22 print() and printx().
23Makefile.inc
24 included from the test's Makefiles. Basic stuff to compile a
25 mips32 ELF executable for a test. It expects a test.S,
26 add the subr.S from common and eventually additionnal object
27 files.
28test_*/
29 these directories holds the test themselves. They have a run
30 script which does what is needed to compile and run a test,
31 print "test failed" or "test passed" on stdout, and clean the
32 directory if it's successfull. A sample script will call
33 make, then run the simulator with srdout/stderr redirected
34 to a file. If the simulator exists with a 0 status, this
35 script search for some strings in the output (that the
36 test program would have printed). This is an additionnal way
37 to check that all worked properly.
38 Tests are written in assembly; as we're testing for very specific
39 conditions (such as an instruction in a branch's delay slot on
40 a page boundary), we don't want the compiler to optimise things
41 or otherwise reorder instructions.
42 If the test was successfull, the 'run' script cleanups the
43 directory. Otherwise the 'run.out' file is available to
44 start looking at what's wrong.
45run_tests
46 runs all the test_*/run scripts - the goal being that
47 all of them print "test passsed" :). Directories are explicitely
48 listed in the run_tests script (order does matter to have a readable
49 output)
Note: See TracBrowser for help on using the repository browser.