11:32 a.m.
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
12:55 p.m.
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. 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.
Sent from my iPhone
On 28 Jan 2019, at 17:32, Gabriel L. Somlo <gsomlo(a)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
3:15 p.m.
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 :) !
--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(a)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
>
9:35 a.m.
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(a)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
> >
>
9:45 a.m.
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(a)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
>>>
2:25 p.m.
On Mon, Feb 04, 2019 at 03:45:51PM +0000, Dr Jonathan Kimmitt wrote:
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.
I don't know why I was so pig-headedly determined to use VCS or
iverilog (probably something to do with clinging to one's hammer and
nails :)
I finally bit the bullet and rewrote my testbench in C++, and slowed
myself down enough to actually read the Verilator 101 documents
available out there, and managed to get it all to build (still
untethered, since I *really* don't want to have to deal with fsvr and
all that extra rigging).
Sure enough, seems to work happily, and not stall at all, when the
simulation is done under Verilator.
Now, on to making sure the stuff it writes to MMIO actually makes
sense, before trying to synthesize it...
Thanks, as usual, for providing the necessary clue stick :)
--G
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(a)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
> > > >
1458
days inactive
1465
days old
5 comments
2 participants
participants (2)
-
Dr Jonathan Kimmitt -
Gabriel L. Somlo