- Om oss
- Plattformar och lösningar
- Utvecklingsverktyg och arbetsmetodik
Simulating ORPSoC using ISim
2012-03-12Publicerad av Sven-Åke Andersson
In Design Suite 13.2 the default HDL simulator is ISim. The ORPSoC package is setup to run ModelSim. To be able to use ISim we will modify the ModelSim scripts to run ISim instead. For more information about ISim, read the ISim HDL simulator blog entry. For more information about running simulations, see this page.
We will add a subdirectory called isim in the atlys directory and define the following simulation environment.
Using environment variables
To simplify the setup we define two environment variables and add these two lines in our .bashrc file:
Setting up the simulation project file
The simulation project file <orpsoc_sim.prj> contains all verilog files that are included in the simulation setup and that will be compiled and elaborated when running ISim. Here are the first lines of this file:
Setting up the command file
The command file contains all the command line options sent to the fuse program when running the compilation and elaboration. For some reason we can't use environment variables in the command file.
-i <dir> points to a directory holding include files needed during simulation
-L <Lib> includes a precompiled verilog library from Xilinx
Set test conditions
The file <test-defines.v> is used for setting up test conditions and selecting a testcase. The variable TEST_NAME_STRING defines which test to run. We select <or1200-simple> and copy the modified <test-defines.v> file to the directory <$ATLYS_HOME/isim/include> before starting the compilation. I cant find this file in the current version of ORPScC but you can make your own adding the defines shown here below.
Preloading DDR2 memory
The program that will be executed during the simulation will reside in the DDR2 memory. To enable the preloading of the DDR memory we add the following line in the <test-defines.v> file:
The name of the loaded image is <sram.vmem> and it must reside in the directory $ATLYS_HOME/isim. For now we will copy the file from $ORPSOC_HOME/sim/run. Later on we will write our own c-programs and generate the <sram.vmem> file.
The system starts by executing some code out of the bootrom module. This module is typically on the processor's instruction bus at address 0xf0000100 and will contain some instructions - enough to do some basic bootstrapping. The file <rom.v> contains the bootrom code. It is possible to add our own bootstrapping code but we will modify the <rom.v> file and enable the built-in boot code.
Compilation and elaboration
Use the following command to run the compilation and elaboration. We must remember to include the Xilinx glbl file (work.glbl):
fuse work.orpsoc_testbench work.glbl -f command/isim_commands.def -o test.exe
Here is the result after compilation:
Running a simulation
The executable file is named test.exe. We use the following command to run a simulation:
./test.exe -tclbatch tcl/run_test.tcl
The run_test.tcl file looks like this:
The simulation finishes after 15-20 minutes and displays the following text:
We have a working simulation setup. This is what the final setup looks like:
During the simulation all the signal activity has been stored in the file <isim.wdb>. We can use the ISim GUI to look at all the signal waveforms using this command:
isimgui -view isim.wdb
Analyzing the design
Using the waveform viewer we can analyze our design and look for errors. We will start by investigating the clock generation and the reset sequence. Let's take a closer look at the clkgen0 block.
From the waveform plot we can see that the incoming clock (sys_clk_in) runs at 100 MHz, the output clock (wb_clk_o) that feeds the OpenRISC processor and the wishbone bus runs at half the frequency (50MHz) and the DDR2 interface clock (ddr2_if_clk_o) runs at 267MHz. The dcm0_locked signal goes high when the DCM generates stable clocks.
Now let's take a look at the cpu (or1200_top0) and see what happens after reset.
From the waveform plot we can see that the processor boots from address 0xf0000100 and starts executing the bootstrap code in the bootrom.
Calibrating the DDR2 memory interface
From this plot we can see that the DDR2 memory takes almost 40us before it responds. We notice that the calib_done signal coming from the DDR2 interface goes high after 39us. That is the time it takes for the DDR2 memory controller to calibrate itself.
Is there a way to skip this calibaration time in the simulation?
I am not an expert in writing makefiles. This whole flow can run from a makefile but that is something that can wait.