[lowrisc-dev] untethered rocket-chip simulation?

Dr Jonathan Kimmitt jrrk2 at cam.ac.uk
Mon Feb 4 15:45:51 GMT 2019


Do you get the same behaviour when you simulate with Verilator?

I don't know whether 4-state simulation with VCS has been tested that much.

If it works in Verilator, this strongly suggests that the simulation has 
gone to X.

If this X behaviour happens in the branch predictor, for example, then 
the whole simulation

will go to X quickly. Another thing to try is a different random seed, 
or setting everything to zero

with an appropriate macro instead of some random value.

Another approach would be to run the ISA tests to see if you overlooked 
writing to a vital register,

and/or to check if the Rocket you checked out is a stable release that 
has been through regressions.

On 04/02/2019 15:35, Gabriel L. Somlo wrote:
> On Mon, Jan 28, 2019 at 04:15:04PM -0500, Gabriel L. Somlo wrote:
>> On Mon, Jan 28, 2019 at 06:55:55PM +0000, Dr Jonathan Kimmitt wrote:
>>> I think your problem is that by default the Rocket net list is
>>> configured for 2-state simulation using Verilator, if you want
>>> to use 4-state simulation you need to configure the RANDOM_INIT...
>>> macros to do something sensible.
>> Oh, that's what all those RANDOMIZE_*_INIT `define options are for!
>>
>> Turns out, using
>>
>>    "-DRANDOMIZE_REG_INIT -DRANDOMIZE_MEM_INIT -DRANDOMIZE_DELAY=0.002"
>>
>> did the trick! Further tinkering with the content of
>> rocket-chip/bootrom/bootrom.S does cause the simulation to read from
>> mem_[0_]ext in behav_srams.v, through all the layers of AXI interfaces
>> and everything!
>>
>> Thanks for getting me unstuck (again :) !
> Along the same lines, now that I've figured out how to simulate the
> rocket-chip untethered with VCS (thanks again, Jonathan!), I've hit
> a new snag:
>
> As it turns out, everything rolls along fine until I try to access
> RAM (note, *not* MMIO, which is -- or should be -- uncached).
>
> Whenever I attempt a ld/lw or sd/sw instruction, the rocket chip seems
> to stall out. This does *not* happen when I get it to execute
> instructions out of RAM, when it seems to load 8 64-bit dwords into
> icache, and then proceed to execute them just fine. It's only when I
> try data loads or stores that things stall out, after *five* 64-bit
> dwords were accessed, presumably into/from dcache.
>
> I'm just curious if anyone's encoutered any weirdness with rocket's
> simulated behav_srams RAM module and/or the AXI wrapper they place
> around it, on the way to throwing it away and connecting the xilinx
> mig_7series in its place (while developing lowRISC) ?
>
> For the full details of the whole sad story, please have a look here:
>
> https://github.com/freechipsproject/rocket-chip/issues/1816
>
> Thanks again,
> --Gabriel
>   
>>> It’s also possible and rather naff that a random init could put
>>> the CPU into an unknown state in which case, the solution is to
>>> try a different random seed. An alternative is to customise the
>>> FIRRTL writer so that something comes out which is more what an
>>> ASIC engineer would expect, ie everything zero that needs to be
>>> zero on reset input.
>>>> On 28 Jan 2019, at 17:32, Gabriel L. Somlo <gsomlo at gmail.com> wrote:
>>>>
>>>> I'm trying to run the rocketchip through a simulator, but without
>>>> the (imho massive) tethering infrastructure that usually surrounds
>>>> it (gdb/fesvr/dtm/jtag), just to see how its bits and pieces wobble,
>>>> and to maybe see it tickle its AXI interface(s) to memory and MMIO.
>>>>
>>>> So I grabbed the current rocket sources and built one of the
>>>> configurations (shouldn't much matter which one, but in my
>>>> case I picked DefaultFPGASmallConfig):
>>>>
>>>>   git clone --recursive \
>>>>       https://github.com/freechipsproject/rocket-chip.git
>>>>
>>>>   make RISCV=${HOME}/RISCV -C rocket-chip/vsim \
>>>>        verilog CONFIG=DefaultFPGASmallConfig
>>>>
>>>> I wrote the smallest testbench wrapper I could think of, and also
>>>> replaced SimDTM (the default tether) with a stub returning 0s for
>>>> everything:
>>>>
>>>>   // begin FILE: tb.v
>>>>
>>>>   module testbench();
>>>>
>>>>     // clock & reset:
>>>>     reg clk = 1'b1;
>>>>     always #5 clk = ~clk;
>>>>     reg rst = 1'b1;
>>>>     initial #103 rst = 1'b0;
>>>>
>>>>     // DUT declaration:
>>>>     wire result;
>>>>     TestHarness dut (
>>>>         .clock(clk),
>>>>         .reset(rst),
>>>>         .io_success(result)
>>>>     );
>>>>
>>>>     // DUT simulation:
>>>>     initial begin
>>>>         $dumpfile("testbench.vcd");
>>>>         $dumpvars(0, testbench);
>>>>
>>>>         $monitor($time, " ########################################\n",
>>>>             "\t\tresult=%b\n", result,
>>>>             "\t\tpc=%h\n", dut.dut.tile.core.ex_reg_pc,
>>>>         );
>>>>
>>>>         repeat (3) begin
>>>>             repeat (10) @(posedge clk);
>>>>             $display("+10 cycles");
>>>>         end
>>>>         $finish;
>>>>     end
>>>>   endmodule // testbench
>>>>
>>>>   // stub "tether" to satisfy dependencies:
>>>>   module SimDTM(
>>>>     input clk,
>>>>     input reset,
>>>>     output        debug_req_valid,
>>>>     input         debug_req_ready,
>>>>     output [ 6:0] debug_req_bits_addr,
>>>>     output [ 1:0] debug_req_bits_op,
>>>>     output [31:0] debug_req_bits_data,
>>>>     input         debug_resp_valid,
>>>>     output        debug_resp_ready,
>>>>     input  [ 1:0] debug_resp_bits_resp,
>>>>     input  [31:0] debug_resp_bits_data,
>>>>     output [31:0] exit
>>>>   );
>>>>     assign debug_req_valid     =  1'b0;
>>>>     assign debug_resp_ready    =  1'b0;
>>>>     assign exit                = 32'h0;
>>>>
>>>>     assign debug_req_bits_addr =  7'h0;
>>>>     assign debug_req_bits_op   =  2'h0;
>>>>     assign debug_req_bits_data = 32'h0;
>>>>   endmodule // SimDTM
>>>>
>>>>   // end FILE: tb.v
>>>>
>>>> I tried building this with both iverilog and VCS, so either:
>>>>
>>>>   iverilog -s testbench -o tb.vvp tb.v \
>>>>     rocket-chip/src/main/resources/vsrc/AsyncResetReg.v \
>>>>     rocket-chip/src/main/resources/vsrc/EICG_wrapper.v \
>>>>     rocket-chip/src/main/resources/vsrc/plusarg_reader.v \
>>>>     rocket-chip/vsim/generated-src/freechips.rocketchip.system.DefaultFPGASmallConfig.v \
>>>>     rocket-chip/vsim/generated-src/freechips.rocketchip.system.DefaultFPGASmallConfig.behav_srams.v
>>>>
>>>> or:
>>>>
>>>>   vcs -q -nc -sverilog -top testbench -o tb.simv tb.v \
>>>>     rocket-chip/src/main/resources/vsrc/AsyncResetReg.v \
>>>>     rocket-chip/src/main/resources/vsrc/EICG_wrapper.v \
>>>>     rocket-chip/src/main/resources/vsrc/plusarg_reader.v \
>>>>     rocket-chip/vsim/generated-src/freechips.rocketchip.system.DefaultFPGASmallConfig.v \
>>>>     rocket-chip/vsim/generated-src/freechips.rocketchip.system.DefaultFPGASmallConfig.behav_srams.v
>>>>
>>>> When I run the simulation (either via 'vvp -N tb.vvp' or the
>>>> VCS-produced './tb.simv'), I would expect the core to spin around
>>>> the "hang" loop at 0x10040 (as per the included bootrom), or to
>>>> start knocking about the "main memory" in behav_srams.v if I changed
>>>> the reset vector to 0x8000_0000. Instead, the simulated rocket-chip
>>>> is stuck in an undefined state:
>>>>
>>>>     0 ########################################
>>>>     result=0
>>>>     pc=xxxxxxxxx
>>>>
>>>>   +10 cycles
>>>>   C 0: 0 [0] pc=[0000000Xxxxxxxxx] W[r 0=xxxxxxxxxxxxxxxx][0] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   C 0: 1 [0] pc=[0000000Xxxxxxxxx] W[r 0=xxxxxxxxxxxxxxxx][0] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   C 0: 2 [0] pc=[0000000Xxxxxxxxx] W[r 0=xxxxxxxxxxxxxxxx][0] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   C 0: 3 [0] pc=[0000000Xxxxxxxxx] W[r 0=xxxxxxxxxxxxxxxx][0] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   C 0: 4 [x] pc=[0000000Xxxxxxxxx] W[r x=xxxxxxxxxxxxxxxx][x] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   C 0: X [x] pc=[0000000Xxxxxxxxx] W[r x=xxxxxxxxxxxxxxxx][x] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   C 0: X [x] pc=[0000000Xxxxxxxxx] W[r x=xxxxxxxxxxxxxxxx][x] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   C 0: X [x] pc=[0000000Xxxxxxxxx] W[r x=xxxxxxxxxxxxxxxx][x] R[r x=xxxxxxxxxxxxxxxx] R[r x=xxxxxxxxxxxxxxxx] inst=[xxxxxxxx] DASM(xxxxxxxx)
>>>>   ...
>>>>
>>>> I'm sure I must be missing something (after all the rocket-chip
>>>> works just fine when hooked into the rest of lowRISC :).
>>>>
>>>> I'm wondering if anyone on this list ever encountered something
>>>> similar, and what the missing piece of the puzzle might have been.
>>>>
>>>> Thanks in advance for any clues,
>>>> --Gabriel
>>>>



More information about the lowrisc-dev mailing list