Closed gjmabo closed 4 years ago
In the test flow that is used by the Travis regression, the programs are loaded at runtime using a simulated Debug Transport Module and riscv-fesvr
. The program is written into memory as part of the simulation, not with a readmemh.
To understand, a bit more, you can understand the following files: This one is the "master" side driven by the test flow, which decides what program it wants to run and requests it to write memory:
This is the "slave" side which receives the command from the above and translates it into Verilog VPI calls:
This is the verilog code that actually wiggles the dmi*
wires on the Rocket Chip System top level to use the debug module to write the program into memory:
Thanks a lot for your reply. It helped a lot! Now I'm wondering about two other things: First, does that mean that the front-end server acts as the HTIF, or are they separate things? And, if I wanted to run a simulation with another program (say a HelloWorld written by me), how could I tell the front-end server to run that program instead of one of the default asm-tests?
(To answer gjmabo's question) You could use the GCC for RISCV (from riscv-toolchain) to compile your HelloWorld.c then feed the output binary code file to simv as in https://github.com/freechipsproject/rocket-chip/blob/master/vsim/Makefrag-verilog
@mwachs5 One follow up question, in your answer you mentioned "vsrc/SimDTM.v" is the module "that actually wiggles the dmi*
wires". But in the VCD waveform dumped out from emulator or VCS doesn't include this process. Because for example Dhrystone has thousands of instructions, and I suppose it will spend more than 1K cycles to load the instructions from a binary file into the SimAXIMem module, but it doesn't.
Thank you.
PS. IC design hardware guy here, limited knowledge about C++, feeling dizzy while reading through the fesvr code.
Jim
@jwang-us how are you running your simulation? Your intuition is correct, you should see lots of wiggling and several simulation minutes spent just loading the program over the DMI if the fesvr is in use. When running with +verbose on, you'll see lots of time spent executing instructions in the < 0x1000 range, which is the debug module.
There are certainly ways to make the CPU execute code (for example, by using a readmemh to put it into memory or ROM), which is why I ask how exactly you are running your simulation.
@mwachs5 Thanks for your response. It's my mistake that I missed the loading sequence in the waveform. After your confirmation, I went back and found that the loading sequence happend after 11Kns. It seems like even if there are several loading activity before 11K ns out of memory, but the address is 'h100. Still trying to understand what is happening there.
@jwang-us , I have a hex file for a C code and want to load it to the memory. Could you tell me how to do it using the MakeFrag-Verilog file/readmemh? Should i pass the hex file as a argument to some switch in the Make file? Thanks!
@gjmabo , do you mind sharing what you did? Thanks!
Hi, I'm currently working on a project with the rocket core. We're trying to run some come code bare-metal and doing simulations using the VLSI flow. My question is, how are the programs loaded into the memory of the SoC generated by RocketChip? I was expecting something in the line of
reg [31:0] memory [0:64*1024/4-1]; initial $readmemh("firmware.hex", memory);
within the verilog files of the srams, but there isn't anything like that. I was wondering if, instead of that, the code is "loaded" by the Chisel source code, and then hardwired in the verilog, or something like that.
Any tips on this would be appreciated :)