Closed sushakam closed 1 year ago
Thank you for pointing this out! It must have occured during code clean up. Best
Hello @pphilippos, Thank you for the quick turnaround. While you are here, I've noticed that building the provided benchmarks using the provided script causes the RTL simulation to stall, even when the start address is updated to match the output of the build script. I use the rv32im GNU toolchain as outlined in the readme. Here is my build (for the sort benchmark):
#!/bin/bash
export TOOL_DIR=/opt/riscv32im_custom
$TOOL_DIR/bin/riscv32-unknown-elf-gcc -march=rv32im -std=gnu99 CProgram.cpp -O3 -ffreestanding -Wl,-Bstatic -o firmware.elf -Wextra -Wshadow -Wundef -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wredundant-decls -g -pedantic -ffreestanding -fpermissive
$TOOL_DIR/bin/riscv32-unknown-elf-objcopy -O binary firmware.elf firmware.bin
$TOOL_DIR/bin/riscv32-unknown-elf-objdump -s -t -r -d -f --source firmware.elf > objdump.txt
cat objdump.txt | grep "start address"
rm firmware.elf
Copying the new firmware from sort to RTL sim folder outputs:
bash run.sh
Icarus Verilog version 11.0 (stable) ()
Copyright 1998-2020 Stephen Williams
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
translate: /usr/lib/x86_64-linux-gnu/ivl/ivlpp -v -L -Wredef-chg -F"/tmp/ivrlg25e8fb9c3" -f"/tmp/ivrlg5e8fb9c3" -p"/tmp/ivrli5e8fb9c3" | /usr/lib/x86_64-linux-gnu/ivl/ivl -v -C"/tmp/ivrlh5e8fb9c3" -C"/usr/lib/x86_64-linux-gnu/ivl/vvp.conf" -- -
Icarus Verilog Preprocessor version 11.0 (stable) ()
Copyright (c) 1999-2020 Stephen Williams (steve@icarus.com)
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
./system.v:16: warning: redefinition of macro DEB from value '1' to '0'
Using language generation: IEEE1800-2005,no-specify,xtypes,icarus-misc
PARSING INPUT
LOCATING TOP-LEVEL MODULES
PrefixSum1x8x32bit Top_Level
... done, 0 seconds.
ELABORATING DESIGN
./cpu.v:350: warning: Port 1 (data1) of ALUbranch expects 33 bits, got 32.
./cpu.v:350: : Padding 1 high bits of the port.
./cpu.v:350: warning: Port 2 (data2) of ALUbranch expects 33 bits, got 32.
./cpu.v:350: : Padding 1 high bits of the port.
./cpu.v:388: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:388: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:388: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:389: warning: @* is sensitive to all 4 words in array 'reg_pend_v'.
./cpu.v:389: warning: @* is sensitive to all 4 words in array 'reg_pend_v'.
./cpu.v:391: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:391: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:392: warning: @* is sensitive to all 4 words in array 'reg_pend_v'.
./cpu.v:392: warning: @* is sensitive to all 4 words in array 'reg_pend_v'.
./cpu.v:395: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:395: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:397: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:397: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:398: warning: @* is sensitive to all 32 words in array 'reg_pend'.
./cpu.v:399: warning: @* is sensitive to all 32 words in array 'reg_pend'.
testbench.v:142: warning: Port 3 (StartAddress) of System expects 21 bits, got 32.
testbench.v:142: : Pruning 11 high bits of the expression.
testbench.v:142: warning: Port 4 (StackPointer) of System expects 30 bits, got 32.
testbench.v:142: : Pruning 2 high bits of the expression.
... done, 0.02 seconds.
RUNNING FUNCTORS
-F cprop ...
... Iteration detected 0 optimizations.
... Look for dangling constants
... done
-F nodangle ...
... scan for dangling signal and event nodes. (scomplete=F, ecomplete=F)
... 1 iterations deleted 547 dangling signals and 0 events.
... scan for dangling signal and event nodes. (scomplete=T, ecomplete=F)
... 2 iterations deleted 547 dangling signals and 118 events.
... done
CALCULATING ISLANDS
... done, 0 seconds.
CODE GENERATION
... invoking target_design
... done, 0.01 seconds.
STATISTICS
lex_string: add_count=1372 hit_count=12973
Compiling VVP ...
... VVP file version 11.0 (stable)
testbench.v:106: Warning: Calling system function $fread() as a task.
testbench.v:106: The functions return value will be ignored.
Compile cleanup...
... Linking
... Removing symbol tables
... Compiletf functions
... 841 functors (net_fun pool=524288 bytes)
198 logic
0 bufif
0 resolv
317 signals
... 753 filters (net_fil pool=524288 bytes)
... 5152 opcodes (147456 bytes)
... 1141 nets
... 841 vvp_nets (1048544 bytes)
... 4 arrays (208 words)
... 24 memories
24 logic (136040 words)
0 real (0 words)
... 222 scopes
... 0.027137 seconds, 19264.0/10916.0/5276.0 KBytes size/rss/shared
Running ...
...execute EndOfCompile callbacks
...propagate initialization events
...execute StartOfSim callbacks
...run scheduler
VCD info: dumpfile test.vcd opened for output.
VCD warning: $dumpvars: Unsupported argument type (vpiPackage)
And does not progress past this point.
I'm working in a research group that plans to use this repo for some preliminary measument/experimentation. Have any changes been made to the building process of the benchmarks? I realize the GNU compiler has likely evolved since this codebase was initailly developed, but I have not been able to pinpoint a reason for it stalling, particularly since the simulation runs fine with the pre-build binaries.
Please let me know if you have any suggestions or if this issue has been brought up previously. I'll continue debuging and place another issue if I resolve the situation. Take care.
Hakam
Thanks. For the sort benchmark you need to remember to uncomment/replace the respective custom instuctions. The out-of-the-box example is for the adder. If you have the same issue for the adder/standard benchmarks I can try to test it with a new version of GCC at some point.
Again, thanks for the quick response. As it stands, cloning the repo and running
rm RTL_and_simulation/firmware.bin
cp Benchmarks/sort/firmware.bin #copy pre-compiled verison from 2 years ago
bash RTL_and_simulation/run.sh
produces 0 as results since the custom instruction is not set up
while re-building by (assuming build.sh has been updated to point to the riscv toolchain dir):
bash Benchmarks/sort/build.sh
rm RTL_and_simulation/firmware.bin
cp Benchmarks/sort/firmware.bin #locally build binary
bash RTL_and_simulation/run.sh
Then updating the starting address in testbench.v
stalls. The fact that the starting address changes for the same benchmark file leads me to believe that there have been some important changes to riscv GNU. I'll keep you posted on any developments from my end. Take care.
Hakam
Happy to help and hear more about your progress. If I find time will try with a new toolchain version too.
Hello Philippos,
Good news, the project works with an older revision of the riscv toolchain (I got it working with rev 629c67e). I unfortunately dont have a reason for why the new versions of the toolchain dont work. I'll add some notes to this in the readme and place a pull request. I'll also link this thread in an insue on the GNU toolchain. Take care.
Hakam
Hello, I think I found the issue: you also need to chenge the byte address for the start of the objdump inside testbench.
For example byte_address=32'h00010094;
I need to mention this in the readme, but in the future it would be better to be more automated and not a quick hack.
I fixed the Readme to remind to check the byte_address
. Let me know if this fixed the issue. Thanks again for mentioning this, happy to help more
Fantastic. Worked on our end. I also went ahead and added the automation using a simple bash script and issued a pull request. Feel free to review it whenever. We are up and running on our end. I greatly appreciate your help. Take care.
Line 167 of cpu.v is missing a curly brace.
bash run.sh
fails without this fix.3'h2: begin num1 ={32{data1[31]}},data1}; num2 = {32'b0,data2}; end
is changed to
3'h2: begin num1 ={{32{data1[31]}},data1}; num2 = {32'b0,data2}; end ___^