OpenCores

ORPSoC - OpenRISC Reference Platform SoC and Test Suite

Introduction

ORPSoC is the OpenRISC Reference Platform System-on-Chip. It follows ORP definition for memory and interrupt mapping peripherals and it can be used by developers of SoC as a starting point.

This second version of ORPSoC, contains an updated set of peripherals and testing suite. Most notably it makes use of the latest OpenRISC GNU toolchain port and simulation technologies. Currently ORPSoCv2 contains a minimal set of peripherals, compared to the previous incarnation. This is intentional as the aim is to provide a development platform along side the ORSoC development board, upon which the RTL for this version is based. ORPSoCv2 comes with an updated and more comprehensive testing suite. This ability to thoroughly develop software and hardware in parallel increases its appeal as a basic building block to be incorporated in, or the foundation of, larger systems.

Contents

Platform Overview

ORPSoCv2 contains software test suites which run on the different OpenRISC-based system models. Three levels of system modeling are available.

  • Event-driven simulation using Icarus Verilog, Mentor Graphics' Modelsim and Cadence NC-Verilog
  • Cycle-accurate simulation using Verilator and SystemC
  • Architectural level simulation using the OpenRISC 1000 architectural simulator, or1ksim

The software being executed in each of the three models is a set of tests, written in C and assembly, testing each part of the OpenRISC processor and platform, and is compiled with the OpenRISC GNU toolchain port.

The set of cores included in the RTL description of the ORPSoCv2 is as follows:

Download ORPSoC

The RTL source, test software and scripts can be downloaded from the OpenRISC project repository. The sources can be checked out with the following command:

svn co http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2

Project layout

The project layout and contents are now briefly described.Like all OpenCores projects, a strict organization and naming structure has been adhered to.
The RTL description of the system is under rtl/.
All software and utilities used during the tests are under sw/. Of note here are the sw/support/ and sw/utils/ paths, which contain library and utility programs respectively, rather than actual test case software.
Testbenches for event-driven and cycle-accurate simulation are under bench/. Some library models for event-driven simulation can be found under backend/.
All of the actual running of the models occurs under the sim/ path. In sim/bin/ is the main Makefile and assorted scripts required to run the test suits on the various platforms. And under sim/run/ is where the user should be when running them. When running the tests, a results/ path will be created under sim/ and removed again when the project is cleaned. All of the Verilator/cycle-accurate model compilation occurs in sim/vlt/ which is also removed when the project is cleaned.

Installing required tools

Getting going

There is a choice of three OpenRISC models to run the test software on. These are the architectural simulator, cycle-accurate and event-driven simulation models. Below are the instructions to install each of them. Note that you don't need to install every tool for ORPSoCv2 to run, only the tools supporting a specific model. However, GNU toolchain port is required to compile the test software that runs on the models. Note that the architectural simulator, OR1ksim, gets installedby the GNU toolchain installation script.

OpenRISC GNU toolchain port installation

Before any tests can be run, the OpenRISC GNU toolchain port must be built and installed. This provides the compiler, libraries and architectural simulator. Please visit the OpenRISC GNU toolchain port page for further information.

Event-driven simulators

An event-driven simulator is required to compile and run the RTL model of ORPSoCv2. The ORPSoCv2 scripts support Icarus Verilog, Mentor Graphics' Modelsim or Cadence NC-Verilog. Icarus is an open-source simulator, while the other two are proprietary and cost money. The installation and configuration of the Modelsim and Cadence simulators is left to the use. Described below is the installation procedure for the Icarus Verilog simulator.

Icarus Verilog

Icarus Verilog is an open-source Verilog simulation and synthesis tool. Their wiki has an extensive installation guide, but on most modern *nix distributions, such as Ubuntu or Debian, it can be easily installed by the system's package manager (apt, yum, emerge, etc.). The package is typically just called verilog. For instance, with apt under Ubuntu the installation command is:

sudo apt-get install verilog

However, if it is not available via the package manager on on your platform please see the Icarus Verilog project's installation guide.

Cycle-accurate simulator

A new and exciting addition to the ORPSoCv2 project is support for building a cycle-accurate model. This simulator is essentially a C++ model generated by some scripts, and is compiled by the system's compiler suite to create a simulation executable. All that is required for installation is some System C libraries, and a tool to convert the Verilog RTL code into a cycle-accurate C++ Model.

Cycle-accurate model generation with Verilator

The tool which generates the C++ model is Verilator. It is a free and open-source tool, developed and maintained by Wilson Snyder et al. at Veripool.org. The generated C++ uses the SystemC simulation kernel and libraries. It is compiled with your system's C++ compiler to create a standalone simulation executable.

What is meant by “cycle-accurate”?

“Cycle-accurate” indicates that the simulation is only accurate to a resolution of the defined clock(s) in the system. This abstracts away what happens to signals between clock edges, removing the ability to account for signal propegation and other asynchronous effects. The values of synchronous signals are updated on the appropriate clock edge, and the propregation of these values is also immediately evaluated. This simplifies the job of the simulator, increasing performance in terms of number of cycles calculated per second, however the trade off is a loss of accuracy, for example wire and logic propagation delays cannot be modeled.
Although the current test suite does not take full advantage of this substantial increase in simulation performance, expect revisions in the future to include tests of much larger software sets such as the Linux kernel and other complex software libraries.

Installation of Verilator and supporting libraries

Generating the cycle-accurate model from the RTL code with Verilator, and then compiling it together to generate the simulation executable requires the Verilator tool and the SystemC libraries.

Following are the SystemC library installation instructions. Next is instructions on installing the two supporting Perl libraries used by Verilator; Verilog-Perl and System-Perl. Lastly, Verilator itself is installed. The following instructions are expanded upon those contained at Veripool's Verilator page.

Installing the SystemC library

The SystemC library can be obtained from the Open SystemC Initiative (OSCI) website. The Standards Download page contains the link to download the core SystemC language and examples archive, however registration with the OSCI is required first.
Once the package is downloaded and extracted, follow the provided README for full compilation and installation instructions.
A quick installation instruction list for most Linux platforms is provided below, starting in the systemc-x.x.x directory:

# mkdir objdir; cd objdir
# export CXX=g++
# ../configure (note that this configures the current location as the permanent location of the systemc library)
# make

If using SystemC version 2.2.0, and make errors out with the following:

../../../../src/sysc/utils/sc_utils_ids.cpp: In function int 'sc_core::initialize()':
../../../../src/sysc/utils/sc_utils_ids.cpp:110: error: 'getenv' is not a member of std
../../../../src/sysc/utils/sc_utils_ids.cpp:111: error: 'strcmp' was not declared in this scope

Then change the includes in the file systemc-2.2.0/src/sysc/utils/sc_utils_ids.cpp to look like the following:

#include <cstdlib>
#include <string.h>
#include "sysc/utils/sc_report.h"
using namespace std;

and re-run make. Hopefully this will be addressed in the next release of SystemC:

# make

When make has completed, continue with:

# make install
# make check (optional)

Add export SYSTEMC=/path/to/systemc-x.x.x to ~/.bashrc

Installing Verilog-Perl

Download the latest release of Verilog-Perl by visiting its CPAN site.
Currently the latest release can be downloaded from here.
Extract it and follow the instructions in the include README file. A quick installation instruction list for most Linux platforms is provided:

# perl Makefile.PL
# make
# make test (optional)
# sudo make install

Installing System-Perl

Download the latest release of System-Perl by visiting its CPAN site.
Currently the latest release can be downloaded from here.
Extract it and follow the instructions in the included README file. A quick installation instruction list for most Linux platforms is provided:

# perl Makefile.PL

It's possible the following message will be displayed:

-Info: Your SystemC distribution has NOT been patched to allow sc_bv
        tracing. Type 'make sc_patch' to attempt the edits.v
        See the README file for details.

If so, perform the patch:

# make sc_patch

Then continue with, again:

# perl Makefile.PL (ignore it if it says it's not patched - it is)
# make
# make test (optional)
# sudo make install

Add export SYSTEMPERL=/path/to/systemperl_kit to ~/.bashrc

Installing Verilator
Finally, the Verilator install can be done a couple of ways. Using either the latest sources from the repository, or from a packaged release. ORPSoCv2 works with Verilator version 3.710 onwards (the very latest as of May '09).
Please see Verilator's installation page for instructions. Further instructions can be found in the README file included with the Verilator sources. A quick installation instruction list for most Linux platforms is provided below. It uses the method of a repository checkout with git (please install git-core with your package manager if it's not on your system):

# git clone http://git.veripool.org/git/verilator
# cd verilator
# autoconf
# ./configure
# make
# make test (recommended)
# sudo make install

Add export VERILATOR_ROOT=/path/to/verilator_kit to ~/.bashrc

The SystemC model toolchain should now be ready to compile ORPSoCv2.

Performing the tests

The following sections outline running the different tests with different simulation models of the ORPSoCv2. All test commands are issued from the sim/run/ path. To run an individual test, name the test(s) on the command line when calling make.
For in-depth documentation of the test compilation and execution, please read the main makefile for the project, sim/bin/Makefile. This information should probably be migrated to a README file in the project at a later stage.

Architectural simulation

From the sim/run/ path, run:

# make sim-tests

This compiles each software test, links its binary to the run directory and calls or32-elf-sim, also known as or1ksim. The results are logged in the sim/results/ path.

Cycle-accurate simulation

From the sim/run/ path, run:

# make vlt-tests

This first generates cycle-accurate model of the ORPSoCv2 using Verilator, then loops for each software test, linking a memory file for the model to load into the run directory. The results are logged in the sim/results/ path.
For VCD output, add VCD=1 to the make line.
By default this build only has an internal SRAM memory (SDRAM is disabled) and UART communication enabled.

Event-driven simulation

To run the tests with the Icarus Verilog simulator, from the sim/run/ path, run:

# make rtl-tests

The simulator to be used for the tests is by default Icarus Verilog, however the use of Modelsim and Cadence simulators can be set from the command line.

To use Modelsim, set the SIMULATOR shell variable to vsim like so:

# make rtl-tests SIMULATOR=vsim

To use NC-Verilog, set the SIMULATOR shell variable to ncverilog like so:

# make rtl-tests SIMULATOR=ncverilog

How the event-driven simulation is compiled and run

The testing script creates a loop, and for each test compiles the RTL model and the test software (generating appropriate memory files). The simulator is then run, with the results logged in the sim/results/ path. This sim/results/ path contains all output from the simulator, including VCD dumps.

Event-driven simulator options
Logging

By default, the processor's execution status is logged to a file in the sim/results path. This can be disabled, resulting in faster simulation time by setting NO_SIM_LOGGING=1 when calling make rtl-tests

VCD generation

For VCD output, add VCD=1 to the make rtl-tests line. Note that this will slow down simulation.

Model external memory

By default the model uses an internal SRAM preloaded with the application, because it's faster. If external SDRAM is enabled, the simulation changes so that the built-in bootloader loads the application out of external flash memory (via SPI bus) and into SDRAM, before starting execution from the code it copied. This results in much longer simulation time. It can be enabled by setting USE_SDRAM=1 when calling make-rtl

Ethernet

Currently the ethernet MAC is disabled by default due to no software accessing it. It can be enabled by changing the top level ORPSoCv2 HDL file, or adding USE_ETHERNET=1 to the make-rtl command line.

UART printout

UART printout can be enabled by adding UART_PRINTF=1 to the make line. This requires that the software support library is also compiled with this defined, so to enable UART printf'ing after other tests, a clean-sw must be run first to ensure the software will be recompiled. Note that this will slow down simulation, as the slow UART line must be simulated, instead of using a quicker trick within the simulator to issue printfs.

Event-driven simulation with GDB stub module via VPI

It is possible to compile a version of the ORPSoCv2 with Icarus Verilog which includes software modules that implement a GDB stub, allowing debugging of the simulated OpenRISC system. The GDB stub software is equivalent to what is in the debug proxy, but in this case is interfacing to the JTAG "lines" of the simulated design via C functions linked to the simulation through the verilog procedural interface. This is useful as it provides an equivalent interface and functionality with the physical target. It enables the ability to follow internal signals with greater ease when debugging. Problems seen in the physical target can hopefully be recreated simply by providing the same stimulus from the debugger, and solved with greater ease by following internal states via wavedumps or similar.

To start the event-driven simulation with GDB support, from the sim/run/ path, run:

# make rtl-debug

As noted in the event-driven simulation options section, for increased performance, detailed logging of the simulation is disabled by default, as is the SDRAM controller and memory model. UART output is enabled by default.

To end the simulation, issue a detach command from the GDB console. This will disconnect GDB, close down the GDB server and issue a $finish in the simulation.

Using your own software in simulation

It is possible to use the ORPSoCv2 makefile to compile the design to run other software. Outlined below is how to compile and run your own software in the cycle accurate and event-driven simulation models. The architectural simulator is already a "standalone" model, so its compilation is not covered here, only its usage.

Software image creation

First of all, it is necessary to understand how the models are supplied with code to execute.

ELF files

Both the architectural and cycle accurate level simulators can load ELF executable files into their internal memories before execution. See below for specific information about passing ELF files to each simulator.

Verilog Memory (VMEM) files

By default, the event-driven and cycle accurate simulations attempt to load a memory image from a VMEM file using the Verilog $readmemh system call. For more information on VMEM files, see this page. The file it expects to find is named sram.vmem in the same directory as the user is running the simulation. Note that the cycle accurate model attempts to load this VMEM file if not provided with an ELF file at runtime.

Software image requirements

Regardless of how the software is loaded, all models expect to begin execution from the OpenRISC's reset vector, 0x100, so ELFs must contain a section which contains code at this address, and VMEM files must contain the appropriate code at this address also.

Creating a Verilog MEMory file

The simplest way to create a VMEM file is by passing the binary image of the application to the bin2vmem tool included in ORPSoCv2. For the simulator to use the resulting image, it must be present in the current working directory, and named sram.vmem.

Creating a VMEM file from a compiled executable in or32-elf format takes two steps. First the ELF must be copied to a simple binary representation, and second, the binary must then be converted into VMEM format. The first step can be done with the standard binutils objcopy tool.

# or32-elf-objcopy -O binary myapp.or32elf myapp.bin

Next the VMEM file can be generated from the raw binary dump of the executable. To convert this binary image to a VMEM file, a utility which is included with ORPSoCv2 can be used. It is in the sw/utils path and is called bin2vmem.

# bin2vmem myapp.bin > myapp.vmem

Finally the myapp.vmem should be copied, or symbolically linked, to the local file sram.vmem before running the simulation.

Using the l.nop instruction to control the simulation

The test software uses a handy technique to control to the simulation from the software being executed on the processor. The OpenRISC l.nop instruction's immediate field is used to signal certain events to the simulation.

Both the RTL and System-C testbenches contain modules supporting the use of the l.nop instruction for several tasks. It is possible to print status reports, print characters, and end the simulation, by loading different values into the 16-bit immediate value of the l.nop instruction. The Embecosm tutorial on building and optimizing a cycle-accurate model of the OpenRISC processor contains a good explanation of how this works, and an example of inserting these instructions into C code.

An example of a C function that would report a value and then end the simulation would look the following (from sw/support/support.c):

#define NOP_EXIT     0x0001     /* End of simulation */

void exit (int i)
{
    asm("l.add r3,r0,%0": : "r" (i));
    asm("l.nop %0": :"K" (NOP_EXIT));
    while (1);
}

It is recommended this method is used to gracefully finish the simulation.

Architectural level simulation

The simplest way to run the architectural simulator with your own executable is to call it, and pass the configuration file included with ORPSoC, sim/bin/or1ksim-orpsocv2.cfg.

# or32-elf-sim -f ../bin/or1ksim-orpsocv2.cfg myapp.or32

See the OR1ksim project page for more information on using it.

Event-driven simulation with Icarus Verilog

The event-driven simulation tests are configured mainly by a single command file for Icarus. This command file is generated for each test. Another generated file is a header file defining some things such as the name of the test. To generate these files, make a single event-driven simulation with something like make rtl-tests TESTS=basic-nocache. Inspect the file icarus.scr.generated that gets created in the sim/run path. This is the command file that is given to icarus with the -c option when the model is compiled. It specifies the include paths, search paths for the source, top level and library files and some extra defines, depending on the options given for the test.

When the model is compiled by Icarus, an executable is created, called a.out by default. Running the simulation with Icarus' runtime engine, vvp starts the simulation. As mentioned above, custom software can be placed in the file sram.vmem which gets loaded at runtime by the simulation.

user@host:~/orpsocv2/sim/run$ vvp a.out

A log file can be specified with the -l option. Read the runtime engine's manual page for more options (man vvp.)

Output, such as execution log or VCDs, will be found in the ../results path, with the name of the TEST specified above.

The event-driven simulation with the GDB stub can also be launched like this by first making the design once automatically with make rtl-debug, and then launched again without the script.

user@host:~/orpsocv2/sim/run$ vvp -M../../bench/verilog/vpi/c -mjp_vpi a.out

Event-driven simulation with other simulators

The other supported simulators, Modelsim and NC-Verilog, can also have their "support" files generated in the manner described above, but running them is a little different to Icarus. It should be easy for those familiar with their simulator to generate the model for one test, and replace the sram.vmem file to run the model with other software.

Cycle-accurate simulation

To compile the cycle-accurate model executable, simply run make prepare-vlt command from the sim/run path.

The resulting executable, Vorpsoc_top is in the sim/vlt path. Run it with the -h option for usage instructions.

By default the simulator looks for a VMEM (sram.vmem) file to load into RAM and execute. It expects this file to be in the current working directory. It is also possible to specify an OR32 ELF format file to load. If an ELF file is specified, the VMEM file is not loaded.

Refer to the section on VMEM file creation in the even-driven simulation section above. Specifying an ELF to load is detailed below.

Cycle accurate model usage

There are a few options that can be enabled when using the cycle accurate model. To see the complete list of options run it with the -h option on the command line. Following are a few (but not all) of these options.

Load a program

By default the cycle accurate model looks for the VMEM file sram.vmem in the current working directory to load and execute. It is also possible to specify an OR32 ELF file instead of the default VMEM file. Use the -f or --program options followed by the name of the OR32 ELF to load. Note that the linker must have placed the program entry at the reset vector address, 0x100. Note that when the ELF file is specified, the VMEM file is no longer used or required.

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top -f myapp.or32

Enable debugging via GDB

Enabling the RSP server inside the model allows GDB to connect and control the system. The model will stall early on (if the software test is very short it may finish and exit before the debug stub can take control of the processor) and wait for a connection from GDB. Use the -r switch to enable the RSP server, and optionally specify a port, the default is 51000.

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top -r portNum

Enable logging

It is possible to create a log of the processor's execution during the simulation. There are two options - creating a human readable or a binary log file.

Standard log file (human readable)

Run the Vorpsoc_top executable and specify on the command line ,with -l or --log, the output file. This creates a file which is immediately readable.

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --log executed.log

Note that generating a human readable log file effects perfomance as file I/O is a relatively slow thing. Expect simulations to run at less than 50% of the speed they would without logging enabled. With logging enabled during the included Dhrystone software test, the model ran at one third the usual speed.

Binary log file

It is possible to generate a binary format log file. This method impacts performance less than generating a human readable file. Use the -b or --binlog switch when running ORPSoC.

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --binlog executed.binlog

This method of logging impacts performance by only a few percent, and results in a log file one quarter the size of the human readable log file.

Reading a binary log file

To read the generated binary log file, compile the software in the sw/utils path (this is done when compiling any software for the ORPSoC tests) and use the binlog2readable tool in that path. Provide the binary log's file name to the tool and it will generate all output to a file (specified with -o) or, by default, to stdout.

user@host:~/orpsocv2/sim/run$ ../../sw/utils/binlog2readable executed.binlog -o executed.log

There are options to skip a certain number of instructions in the log, or start from a certain number of instructions from the end of a log (useful when only the last, say 10k instructions executed, are of interest in a very large log file.) Run the tool without any options to see usage instructions.

user@host:~/orpsocv2/sim/run$ ../../sw/utils/binlog2readable executed.binlog --last 1000 | less

Bus transactions log

It's also possible to generate a log of bus transactions in the system during simulation. Use the -u or --bus-log switches, and optionally specify a log filename (default is bus_trans.log) and start time in nanoseconds for the logging to begin (default is immediately.)

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --bus-log

The log file will contain lines like the following:

Time   Master Type  Sel   Addr  Slave   Data   Cycles
20920 ns   M0      R     f   00004d7c  S0   d8133000   1
21040 ns   M2      R     8   000062c4  S0   44485259   1

The first column is the time at which the ACK for the transactions was issued. The master is the number of the master issuing the request, type is R for read, W for write, sel indicates the 4-bit select signal on the Wishbone bus indicating byte, half-word or word transaction, address of the transaction, the number of the slave, the data read or written and finally the number of cycles taken for the transaction.

In the two example lines above we can see the first is an access from master 0, which is the OR1200's instruction master port, reading a whole word from address 0x4d7c, which is served by slave 0, and the data slave 0 returned is the instruction 0xd8133000, and it took 1 cycle before the acknowledge was issued after the master was granted.
The second line shows an from master 2, the OR1200's data port, accessing a single byte (the lowest byte as we're in big endian configuration) at address 0x62c4, and the same slave responds with the byte 0x44 in 1 cycle.

Disable performance summary

By default, at the conclusion of the simulation, some performance statistics are printed to standard out. To disable this use the -q for quiet, or --no-perf-summary switches on the command line.

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top -q

Profiling of the executed program

It is possible to generate profiling information of the application run in the simulator.

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --profile or32app.profile

This option will output profiling information to the file or32prof.out. When the file name is not specified, the default file sim.profile is used.

The resulting profiling data file can be processed with the profiler included with the the architectural simulator (which is installed by default by the toolchain script) or32-elf-profile.

# or32-elf-profile -g or32app.profile

VCD generation

VCD generation can be enabled on the command line when running the cycle accurate model. Due to the speed of the cycle accurate simulation, a great deal of VCD data is generated in a short period of time. For short simulations, the resulting VCD files are not so large, but for longer simulations they become prohibitively large to generate and browse. There are two ways to solve this. One is to limit the depth of the design hierarchy that the VCD will contain (TODO.) The other is to define time boundaries for VCD generation. VCD generation can be turned on or off at any desired time.

To generate a VCD for the entire length of the simulation run the executable with the -v or --vcdon option:

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --vcdon

Enable VCD generation to a specific file, can be done with the following:

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --vcdfile mydump.vcd

Define some time limits for dumping (in nano seconds) like so:

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --vcdfile mydump.vcd --vcdstart 15000 --vcdstop 25000

One or both of the VCD stop/start times can be specified.

Note that VCD generation adversely affects the rate of simulation.

Memory dump

It is possible to dump all, or parts of, the system's RAM contents when the simulation finishes.

Specify a file, and the bounds of the memory area (in hex format with preceeding 0x) to dump to a file when simulation ends, like so:

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top --memdump memdump.bin 0x2000 0x10000

If no filename is specified the file vorpsoc_ram.bin is used. If no memory bounds are specified the entire contents of RAM are dumped. If only a single memory bound is given the memory from the base to this address is output.

The generated file format is binary. View the dump with hexdump piped to less: hexdump -C memdump.bin | less

Currently only dumping of the internal SRAM memory mapped from 0x00000000 is possible. For other areas or modules, it's possible to run the simulation with GDB attached and dump memory contents that way at the end of a simulation.

Note: it is confusing to know which way is correct for representing data stored in the memory array of a simulated big-endian machine's RAM, which is being simulated on a little-endian machine. The generated binary dump file outputs the bytes as they should appear if addressing them on the OpenRISC via software or the debugger. Ie. the byte at address 0 is output so it appears at address 0 in hexdump -C, which prints the data byte at a time (it is assumed hexdump-C is starting at byte 0 of word 0). Potentially this is incorrect if the dumped data is to be interpretted by a program on the little-endian machine (ie. this data looks big-endian in hexdump -C but it's actually the wrong-way around). A switch to choose endianness of dumped data will probably be implemented in the future.

Crash monitor

Running the cycle accurate model with the -c switch will enable a function which monitors the instruction bus and checks if the processor has jumped to a region without any code (unused memory in the model is zeroed)

user@host:~/orpsocv2/sim/run$ ../vlt/Vorpsoc_top -c

Although far from detecting all crash scenarios, it is handy for bringing to light bugs in code or hardware that are effecting the processor's execution. Something nice which could be added is checking if the wishbone bus is locked due to an illegal access or somesuch, or perhaps deduction of areas the processor should be allowed to execute in from the ELF file, and raising the alarm if the PC strays from this area.

Higher performance cycle accurate model

It is possible to compile the model with profiling data, resulting in substantial performance increases. The following outlines how to generate a profiled model.

It is recommended to first clean the ORPSoC install.

user@host:~/orpsocv2/sim/run$ make clean

Generate the profiled cycle accurate model. This will take a while, depending on your PC.

user@host:~/orpsocv2/sim/run$ make prepare-vlt-profiled

To Do

  • Expand the software test suite (further OR1200 CPU specific tests, uClibc tests, ecos tests, LTP?)
  • More FPU tests
  • VPI debug make target for other simulators
  • Refine ethernet tests

Page Maintainer

This web page is maintained by

Pages specific to individual OpenRISC projects are maintained by their developers.

Top
© copyright 1999-2010 OpenCores.org, equivalent to ORSoC AB, all rights reserved. OpenCores®, registered trademark.