Open JL102 opened 11 months ago
jerryz123
commented
11 months ago The verilator backend now no longer uses the emulator.cc driver... it now uses the same TestDriver.v as verilog. So that help message, as well as many of the flags it describes are out-of-date.
JL102
commented
11 months ago The verilator backend now no longer uses the
emulator.ccdriver... it now uses the sameTestDriver.vas verilog. So that help message, as well as many of the flags it describes are out-of-date.
Understood. I looked at TestDriver.v and I see the vcdfile plusarg, but when trying this:
$ ./simulator-chipyard.harness-RocketConfig-debug +vcdfile=./out.vcd ../../tests/hello.riscvI get this output:
[UART] UART0 is here (stdin/stdout).
terminate called after throwing an instance of 'std::runtime_error'
what(): could not open +vcdfile=./out.vcd (did you misspell it? If VCS, did you forget +permissive/+permissive-off?)How do I output a vcd?
jerryz123
commented
11 months ago I believe the run-binary-debug make target should output VCDs. The files might not have .vcd extension, but they should be VCDs IIRC?
JL102
commented
11 months ago Got it, thanks! After passing BINARY=../../tests/hello.riscv into the make arguments too, it outputted a vcd and some other stuff into output/chipyard.harness.TestHarness.RocketConfig
JL102
commented
11 months ago Hm... There seems to be a significant reduction in performance between the Verilator testharnesses of Chipyard 1.9.1 and Chipyard 1.10.0.
In my local copy of both v1.9.1 and v1.10.0, I ran the same make debug CONFIG=RocketConfig, and then after building, ran time make run-binary-debug BINARY=../../tests/hello.riscv.
output/chipyard.harness.TestHarness.RocketConfig/hello.out, I see that it completed after 53,235 cycles.output/chipyard.harness.TestHarness.RocketConfig/hello.out, I see that it completed after 306,076 simulation cycles`.Just to check and make sure the variable was not the testbench compilation, I ran 1.9.1's testharness with 1.10.0's binary and vice versa. Switching the binaries had no impact on the simulation time (1.9.1's testharness took ~45 seconds and completed after 306,076 no matter which test binary it ran)
In my own test that I'm working on in my fork, I was used to the "actual" code starting to run after about 80k-100k cycles, but after syncing up my fork with the upstream, the same test takes about 280k cycles before the "actual" code starting to run. Is it known why it's taking so much longer for the testharnesses to run after the update?
jerryz123
commented
11 months ago Yes. We switched the verilator backend to use --timing, which uses a completely different simulation driver than the old mechanism. The timing-driven simulation is more faithful to real hardware, as it can simulate arbitrary clocks and delays.
To improve performance, you can try make run-binary-debug LOADMEM=1. This will use a fast loadmem mechanism to instantaneously copy the binary into target memory.
JL102
commented
11 months ago Understood, thank you!
matsbror
commented
11 months ago @JL102 I have an issue you may have a solution to (unrelated to this issue). I see you are on WSL2. Did you have a problem getting FireSim installed as part of the Chipyard setup? I can't get it to work in WSL2, but on a pure Linux host, it works.
JL102
commented
11 months ago @JL102 I have an issue you may have a solution to (unrelated to this issue). I see you are on WSL2. Did you have a problem getting FireSim installed as part of the Chipyard setup? I can't get it to work in WSL2, but on a pure Linux host, it works.
@matsbror Unfortunately I don't have a very satisfying solution. I was having the same issue as described in #1441, and after seeing this comment - https://github.com/ucb-bar/chipyard/issues/1441#issuecomment-1607767964 - I've been using using that command ever since. I haven't needed to use Firesim within Chipyard in my development environment.
At my workplace they have a VM built for using Firesim, and earlier this summer I was even having the same issue on the VM. (When Firesim was at the project root, with Chipyard as a submodule in target-design/chipyard, it was fine, but when Chipyard was at the project root with a Firesim submodule at software/firesim, it didn't work)
I tested it again now; when I ran the full build-setup.sh on 1.10.0, the FireMarshal build step failed with some weird error I'm unsure of. I then wiped chipyard, re-cloned, and checked out main. Then, the full build-setup.sh actually worked.
EDIT: I just tried the full setup script on my Ubuntu 22.04 server ("pure Linux", not WSL), 1.10.0, and it failed for a similar/same reason as on WSL, "failed to build workload br-base.json"
jerryz123
commented
11 months ago Can you post the full error message for failed to build workload?
Background Work
Chipyard Version and Hash
Affected release: 1.10.0 Affected hash: b7644b2455cc4bae190e811a5d8085f3aad85b87
Working release: 1.9.1 Working hash: 968b207ccade6f61d6f9bb2e19a54781d4a96f26
OS Setup
Other Setup
No response
Current Behavior
Note the help text:
When this help text is printed, there are two changes relevant to this issue:
EMULATOR OPTIONS no longer shows the command line options like --cycle-count, --vcd, etc.:
However, when checking emulator.cc, I can clearly see the command line options that are expected:
This implies to me that the "Please consult emulator.cc" line is a mistake.
At the bottom, I see an error:
And lastly, 3. using the command line options that are described in emulator.cc, and that used to work, are no longer recognized. For example:
Expected Behavior
I expect the help text to display something like this (Ran from chipyard release 1.9.1):
and for the emulator options to work, for example
--cycle-countand--vcd:Other Information
I tested this on release 1.10.0, 1.9.1, and on HEAD (from last night). 1.9.1 works as expected, 1.10.0 and HEAD do not.