untethered rocket-chip simulation?
by Gabriel L. Somlo
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
4 years, 8 months
FPGA utilization stats
by Gabriel L. Somlo
After successfully building chip_top.bit in fpga/board/nexys4_ddr,
how would one get a set of up-to-date FPGA resource utilization
statistics, similar to what's shown at the bottom of
https://www.lowrisc.org/docs/untether-v0.2/fpga-demo/ ?
I tried digging through vivado.log, but none of the (many) numbers
reported in there stuck out as immediately useful.
Do I have to bring up the Vivado GUI and poke around with it, or
is there a way to collect the info from vivado.log, or have I just
missed it by not looking carefully enough?
Thanks much,
--Gabriel
4 years, 8 months
Re: [lowrisc-dev] Re: make cpio error
by Dr Jonathan Kimmitt
Dear Dinesh,
The Debian RISCV developers (Manuel Montecelo, Karsten Merker and
Aurelien Jarno) have worked their
magic and updated the repositories to a consistent working set (merging
in the latest glibc amongst other things)
and I have updated the lowRISC installation scripts if you want to
update from git and try it again (it worked for me).
On 28/12/2018 11:17, Dinesh Thirumurthy wrote:
> Thanks Jonathan.
>
> Regards,
> Dinesh
>
>
> On Fri, Dec 28, 2018 at 4:42 PM Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk
> <mailto:jrrk2@cam.ac.uk>> wrote:
>
> Those manual hacks shouldn't be necessary any more. The Debian
> guys will fix up
>
> the repository when they get back from Christmas/New Year
> holidays. You can consult
>
> the archives of the lowrisc mailing list to find information on
> the provenance of the unstable Debian port.
>
> On 28/12/2018 11:03, Dinesh Thirumurthy wrote:
>> Hi,
>>
>> Thanks Jonathan. I will look at the prebuilt rootfs.
>>
>> The complete debootstrap log is at:
>> https://github.com/hakrdinesh/e/blob/master/nexys/debootstrap.log
>>
>> I believe during make cpio:
>>
>> work/mybootstrap.sh is trying to get older revisions of 3 libraries.
>>
>> From what is currently present at:
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/libf/libffi/
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/s/systemd/
>>
>> The following change should hopefully remove the missing files
>> problem.
>>
>> diff --git a/work/mybootstrap.sh b/work/mybootstrap.sh
>> index 3e82e4a..6789798 100644
>> --- a/work/mybootstrap.sh
>> +++ b/work/mybootstrap.sh
>> @@ -15,10 +15,10 @@ sudo chroot work/debian-riscv64-chroot
>> /debootstrap/debootstrap --second-stage
>> sudo mkdir -p -m 777 work/debian-riscv64-chroot/tmp
>> #Fetch the last few unreleased packages
>> cd work/debian-riscv64-chroot/tmp
>> -wget
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/s/systemd/libud...
>> -wget
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/s/systemd/libsy...
>> +wget
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/s/systemd/libud...
>> +wget
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/s/systemd/libsy...
>> ##wget
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/d/db5.3/libdb5....
>> -wget
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/libf/libffi/lib...
>> +wget
>> http://www.debianmirror.de/debian-ports/pool-riscv64/main/libf/libffi/lib...
>> cd ../../..
>> #Install the unreleased packages
>> sudo chroot work/debian-riscv64-chroot dpkg -i `ls -1
>> work/debian-riscv64-chroot/tmp | sed 's=^=tmp/='`
>> dt@marina:~/l/lowrisc-chip/debian-riscv64$
>>
>> Thanks.
>>
>> Also, I ran into missing files, which I let make ignore for now.
>>
>> dt@marina:~/l/lowrisc-chip/debian-riscv64$ git diff
>> diff --git a/work/makefile.inc b/work/makefile.inc
>> index 257a02f..dce5675 100644
>> --- a/work/makefile.inc
>> +++ b/work/makefile.inc
>> @@ -17,9 +17,9 @@ init: ../rootfs.tar.xz work/busyboxinit.sh
>> rm -rf bin etc dev home lib proc sbin sys tmp usr mnt nfs
>> root run init
>> mkdir -p bin etc dev home lib proc sbin sys tmp usr mnt
>> nfs root run usr/bin usr/lib usr/sbin usr/share/perl5
>> usr/share/udhcpc lib/riscv64-linux-gnu usr/lib/riscv64-linux-gnu
>> # usr/share/sysvinit
>> cp -p work/usr-share-udhcpc-default.script
>> usr/share/udhcpc/default.script
>> - cp -p ${CHROOT_PATH}/sbin/mount.nfs ./sbin
>> + -cp -p ${CHROOT_PATH}/sbin/mount.nfs ./sbin
>> cp -p ${CHROOT_PATH}/sbin/switch_root ./sbin
>> - cp -p ${CHROOT_PATH}/bin/busybox ./bin
>> + -cp -p ${CHROOT_PATH}/bin/busybox ./bin
>> cp -p ${CHROOT_PATH}/lib/ld-linux-riscv64-lp64d.so.1 ./lib
>> cp -p ${CHROOT_PATH}/lib/riscv64-linux-gnu/libblkid.so.1
>> ./lib/riscv64-linux-gnu
>> cp -p
>> ${CHROOT_PATH}/lib/riscv64-linux-gnu/libcom_err.so.2
>> ./lib/riscv64-linux-gnu
>> @@ -37,7 +37,7 @@ init: ../rootfs.tar.xz work/busyboxinit.sh
>> cp -p ${CHROOT_PATH}/lib/riscv64-linux-gnu/libresolv.so.2
>> ./lib/riscv64-linux-gnu
>> cp -p ${CHROOT_PATH}/lib/riscv64-linux-gnu/librt.so.1
>> ./lib/riscv64-linux-gnu
>> cp -p
>> ${CHROOT_PATH}/lib/riscv64-linux-gnu/libselinux.so.1
>> ./lib/riscv64-linux-gnu
>> - cp -p ${CHROOT_PATH}/lib/riscv64-linux-gnu/libtirpc.so.1
>> ./lib/riscv64-linux-gnu
>> + -cp -p ${CHROOT_PATH}/lib/riscv64-linux-gnu/libtirpc.so.1
>> ./lib/riscv64-linux-gnu
>> cp -p ${CHROOT_PATH}/lib/riscv64-linux-gnu/libuuid.so.1
>> ./lib/riscv64-linux-gnu
>> cp work/busyboxinit.sh init
>> chmod +x init
>>
>> The files were mount.nfs, busybox, libtirp.so.1
>>
>> Apologies for the continuous complaints, just sharing the hiccups
>> as I try various commands in the documentation.
>>
>> Regards,
>> Dinesh
>>
>>
>> On Fri, Dec 28, 2018 at 2:14 PM Dr Jonathan Kimmitt
>> <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote:
>>
>> As discussed in the archives of this mailing list and in the
>> lowrisc
>> documentation,
>>
>> The Debian build procedure can occasionally fail because it
>> is based on
>> the unstable distribution.
>>
>> In this case the workaround is to use the pre-build archives
>> from
>> github, as discussed in the
>>
>> quickstart page. Meanwhile I will attempt to reproduce your
>> result and
>> see if omitting some optional
>>
>> package or changing the instructions will solve the problem.
>>
>> pre-build rootfs is here:
>> https://github.com/lowRISC/lowrisc-chip/releases/download/v0.6-rc4/rootfs...
>>
>> On 28/12/2018 07:43, Dinesh Thirumurthy wrote:
>> > Hi,
>> >
>> > Complete outpiut of 'make cpio' is at
>> > https://github.com/hakrdinesh/e/blob/master/nexys/cpio.out
>> >
>> > Thank you.
>> >
>> > Regards,
>> > Dinesh
>> >
>> >
>> >
>> >
>> > On Fri, Dec 28, 2018 at 12:38 PM Dinesh Thirumurthy <
>> > dinesh.thirumurthy(a)gmail.com
>> <mailto:dinesh.thirumurthy@gmail.com>> wrote:
>> >
>> >> Hi,
>> >>
>> >> Following instructions at
>> >> https://www.lowrisc.org/docs/download-install-debian/
>> >> On running make cpio
>> >> I get this error:
>> >>
>> >> sudo tar cJf - -C work/debian-riscv64-chroot . >
>> ../rootfs.tar.xz
>> >> rm -rf bin etc dev home lib proc sbin sys tmp usr mnt nfs
>> root run init
>> >> mkdir -p bin etc dev home lib proc sbin sys tmp usr mnt
>> nfs root run
>> >> usr/bin usr/lib usr/sbin usr/share/perl5 usr/share/udhcpc
>> >> lib/riscv64-linux-gnu usr/lib/riscv64-linux-gnu #
>> usr/share/sysvinit
>> >> cp -p work/usr-share-udhcpc-default.script
>> usr/share/udhcpc/default.script
>> >> cp -p work/debian-riscv64-chroot/sbin/mount.nfs ./sbin
>> >> cp: cannot stat
>> 'work/debian-riscv64-chroot/sbin/mount.nfs': No such file
>> >> or directory
>> >> work/makefile.inc:17: recipe for target 'init' failed
>> >> make: *** [init] Error 1
>> >> dt@marina:~/l/lowrisc-chip/debian-riscv64$ ls
>> >> work/debian-riscv64-chroot/sbin/
>> >> agetty cfdisk e2image fsck fsfreeze
>> isosize
>> >> mkfs mkfs.minix raw start-stop-daemon.REAL
>> >> tune2fs
>> >> badblocks chcpu e2label fsck.cramfs fstab-decode
>> killall5
>> >> mkfs.bfs mkhomedir_helper resize2fs sulogin
>> >> unix_chkpwd
>> >> blkdiscard ctrlaltdel e2mmpstatus fsck.ext2 fstrim
>> ldconfig
>> >> mkfs.cramfs mkswap runuser swaplabel
>> >> unix_update
>> >> blkid debugfs e2undo fsck.ext3 getty
>> logsave
>> >> mkfs.ext2 pam_tally sfdisk swapoff
>> >> wipefs
>> >> blkzone dumpe2fs fdisk fsck.ext4 hwclock
>> losetup
>> >> mkfs.ext3 pam_tally2 shadowconfig swapon
>> >> zramctl
>> >> blockdev e2fsck findfs fsck.minix
>> installkernel mke2fs
>> >> mkfs.ext4 pivot_root start-stop-daemon switch_root
>> >> dt@marina:~/l/lowrisc-chip/debian-riscv64$
>> >>
>> >> How do I fix/overcome this?
>> >>
>> >> Thanks.
>> >>
>> >> Regards,
>> >> Dinesh
>> >>
>> >>
>>
4 years, 8 months