Welcome to the Cortex-M3 DesignStart video on how to run an integration test in simulation. This video outlines the tools that are required to run a
test and introduces the RTL and the simulation tests that come with the DesignStart package. The video then demonstrates how to run a basic test
and gives you step-by-step instructions to follow. After you have successfully run this test, you will then be able to run other DesignStart RTL
simulation tests on your own.
Before you run the simulation you need to install GNU Make, GNU GCC, and GNU Binutils with the minimum versions shown here. The tests supplied
in the package contain pre-compiled binaries. But if you want to compile them yourself, we recomend use the ARM Keil compiler, which is
Windows only.
The Kiel compiler is optional and is available to download from this address.
The Kiel compiler is optional and is available to download from this address and has a free evaluation license included.
To run the simulation tests, you will also need a Verilog simulator.Mentor ModelSim, Cadence IUS, or Synopsys VCS, with the minimum version shown
here, are supported Verilog simulators.
As part of a full system built using standard Verilog, Cortex-M3 DesignStart includes a processor that is provided in two formats. The first format, using
obfuscated RTL, works out of
the box. Here, the RTL exposes the architectural registers, but not the sequence of execution of instructions of the program. The second format is
the cycle model, also called the DSM. To use this, you must install a free licence following the instructions provided with the download. The
advantage of the cycle model is that more internal registers are exposed, and a log file can be generated. The Tarmac log shows every instruction
as it executes, and all of the memory accesses performed by the core. We therefore recommend using the cycle model.
The Cortex M3 DesignStart Execution Testbench provides a series of simulation tests located here. These tests show whether the deliverables have
been set up correctly and demonstrate certain behaviors of the processor. This video will demonstrate how to run hello, the most basic of
these tests. The hello test is a simple test written in C that verifies whether the testbench is running correctly. During development, you should always
check that the hello test runs successfully when you are investigating any issues. This test is not intended to perform any real checking, but can be
useful to determine whether other tests that fail are identifying a design problem. If the hello test fails, then the issue is less likely to be about the design,
and more likely to be about the testbench not running correctly.
To simplify validation of the package, a precompiled binary is supplied for the hello test and all of the other tests. These binaries are located inside each
test folder in a directory called precompiled. In a minute, when we run the hello test, we will use the precompiled binary.
To compile the tests yourself, you will need to use the ARM Keil compiler, which is Windows only.
Alternatively, you can use GCC or RVCT. If you need to revert to the precompiled tests, simply copy the binary to the test directory, shown here.
Running tests in the simulator is similar to running any other program. There are two steps involved. First, you need to compile the RTL, and then run
the test. Both of these steps must be done in the execution testbench directory.
Before you can run a test, you must compile the RTL. When you compile the RTL, you must specify the simulator, and also choose to use the DSM or
not. From the execution testbench directory enter make compile SIMULATOR=mti DSM=yes You can use DSM=no if you have had problems
installing the DSM. Check that the compilation is successful.
If the RTL compilation fails, then you will see this error. You can find further information about the problem in the _compile.log file, shown here.
When you have successfully compiled the RTL, run the hello test from the testbench directory with the
command make run TESTNAME=hello SIMULATOR=mti DSM=yes. Again you can also use DSM=no, if you compiled the code with
obfuscated RTL. The test will take a few moments to complete (test on screen running). If successful, the test will return TEST PASSED. Note that in this
test, the printf output is redirected to the UART output via UART0. The testbench contains a UART capture model which prints text to the screen, and
also ends the test when it receives a special character. If you entered DSM=yes, you can see the cm_tarmac.log file generated in the testbench
directory.
If the test is unsuccessful and does not print these results, then there is an issue with your simulation environment or your
installation of Cortex-M3 DesignStart. Ensure that you have installed all of the requirements as outlined at the beginning of this video. If the different
parts of the design do not match, you might see a problem like this as you try to run a test. If you’re unable to solve your problems, the
ARM community can offer support and assistance.
In this video we have looked at the resources required for creating a test environment for running the Cortex-M3 DesignStart RTL simulation tests.
We have also seen how to compile the RTL and run one of the precompiled tests. If this has been
successful, it means that you are ready to run the other simulation tests and then begin to customise the RTL. The remaining tests each focus on a
specific aspect of the design, and should all pass without modification. The RTL and Testbench User Guide contains further information on running
additional tests that are delivered in the DesignStart package. And for guidance when customizing the RTL, see the DesignStart Customization Guide.If
you have any questions that arise from when running the tests yourself, the ARM community can offer support and assistance.