Subversion Repositories t48

Compiling the VHDL Code

-----------------------

VHDL compilation and simulation tasks take place inside in sim/rtl_sim

directory. The project setup supports only the batch mode of certain

simulators. However, there should be no problems to integrate the testbench

and RTL code into arbitrary simulation environments.

The main file for compilation is Makefile.hier which contains all information

regarding the dependencies of the source files and their compilation

order. There is a dedicated file for each supported simulator that maps the

generic information of Makefile.hier to object files specific to the given

simulator.

Compilation is based on the make-utility, thus invocation looks like this:

$ make -f Makefile.

where  denotes one of the supported simulators:

  * Makefile.ghdl

    Tristan Gingold's GHDL simulator/compiler, a VHDL front-end for gcc.

    http://ghdl.free.fr/

  * Makefile.simili

    VHDL Simili, a VHDL simulator by Symphony EDA

    http://www.symphonyeda.com/

Make will analyze all VHDL files (RTL and testbench code) and elaborate all

three testbench top-levels if appropriate for the chosen simulator:

  * tb_behav_c0

    The main testbench for regression testing.

    Instantiates the plain t48_core and provides internal RAM (256 bytes) and

    ROM (2k bytes) plus 2k bytes of external ROM.

  * tb_t8048_behav_c0

    The testbench for the t8048 sample system.

  * tb_t8039_behav_c0

    The testbench for the 8039 sample system.

To delete all intermediate data, each Makefile has a 'clean' target:

$ make -f Makefile. clean

Preparation of the ROM Files

----------------------------

All testbenches listed above need two files in hex-format. They contain the

program for the T48 core and are loaded into internal and external ROM at

simulation startup. Their existance is mandatory as they are referenced in the

VHDL code of the ROM model lpm_rom.vhd. In case they are missing, the

simulation will stop immediately after elaborating the design.

These files are:

  * t48_rom.hex

    Internal ROM contents at address range 000H to 7FFH.

    Intel hex format, starting at address 000H.

  * t48_ext_rom.hex

    External ROM contents at address range 800H to FFFH.

    Intel hex format, starting at address 000H.

The verification flow for the T48 project generates these two files

automatically from the assembler source files.

All regression tests and the general purpose software is organized in a cell

structure. Currently, this means that the software for a cell is contained in

a dedicated directory where the assembler run takes place. In the future,

there will be more aspects to a cell.

Assembling, linking and putting the hex-files in place is under the control of

the make-mechanism. E.g. to assemble the source code of a cell, issue the

following command:

$ make -f $VERIF_DIR/include/Makefile.cell

This generates the linker file (test.p) and distributes its contents to the

required ROM files for internal and external program ROM. The target 'simu'

copies these files automatically to the simulation directory. So most likely,

for running a test case or any other software, you will want to issue:

$ make -f VERIF_DIR/include/Makefile.cell simu clean

The only supported assembler is Alfred Arnold's macroassembler AS. See

  http://john.ccac.rwth-aachen.de:8000/as/

Verification Environment

------------------------

The verification environment consists of a number of test programs. They are

all self-checking. I.e. after testing the targeted functionality, they emit a

pass/fail information. This information is detected by the testbench which

stops the simulation and prints out the simulation result. This is the default

mechanism for stopping the VHDL simulation.

Pass/fail is signalled by a certain sequence of the accumulator contents:

  1) Accumulator contains AAH

  2) Accumulator contains 55H

  3) Accumulator contains 01H   -> Pass

     Accumulator contains 00H   -> Fail

The detection is modelled like a state machine and in case the sequence is of

bytes inside the accumulator does not match, the detection process restarts

from the beginning. This mechanism is part of all verification tests.

The complete regression suite can be executed with the run_regression.pl

script. For each test cell, it steps through the sequence

  1) Assemble the source code

  2) Run the compiled VHDL design (currently only GHDL)

  3) Optionally perform a dump compare against the C-model

It is highly recommended to redirect the output of run_regression.pl into a

file. Otherwise, analyzing the messages related to each test cell is almost

impossible.