Simulator treats plusargs as binary path

[yqszxx]

Impact: simulator

Tell us about your environment: Chipyard Version: 1.4.0, Hash 58076c OS: Linux ubuntu 5.8.0-40-generic #45~20.04.1-Ubuntu SMP Fri Jan 15 11:35:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Other: Followed the latest documentation, built the verilator simulator with default configs. What is the current behavior? Execute

./simulator-chipyard-RocketConfig +jtag_rbb_enable=1 --rbb-port=9823 ../../riscv-tools-install/riscv64-unknown-elf/share/riscv-tests/isa/rv32ui-p-addi

produces

This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 9823
[UART] UART0 is here (stdin/stdout).
terminate called after throwing an instance of 'std::runtime_error'
  what():  could not open +jtag_rbb_enable=1 (did you misspell it? If VCS, did you forget +permissive/+permissive-off?)

It seems that the simulator is treating the plusargs as binary path. What is the expected behavior? Behave as the help text says:

Usage: ./simulator-chipyard-RocketConfig [EMULATOR OPTION]... [VERILOG PLUSARG]... [HOST OPTION]... BINARY [TARGET OPTION]...

Other information

[abejgonzalez]

Seems like the argument is different i.e. rbb-port?: https://github.com/ucb-bar/chipyard/blob/58076cfb260a3be502d6d1c25b577da39277a7fc/generators/utilities/src/main/resources/csrc/emulator.cc#L67-L77

[yqszxx]

Thanks for your reply! I tried with the same arguments and in the exactly same order this morning, the problem just gone, weird but now working fine. I'll dig deeper next time this happens.

[hadirkhan10]

Hi, I am getting the exact same error while trying to connect the simulator with JTAG. Here is how I compiled the simulator:

make CONFIG=TinyRocketConfig

and then run the simulator with jtag enabled:

./simulator-chipyard-TinyRocketConfig +jtag_rbb_enable=1 --rbb-port=9823 $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv32ui-p-bne

I get the following output:

This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 9823
[UART] UART0 is here (stdin/stdout).
terminate called after throwing an instance of 'std::runtime_error'
  what():  could not open +jtag_rbb_enable=1 (did you misspell it? If VCS, did you forget +permissive/+permissive-off?)

[yqszxx]

Hi, I am getting the exact same error while trying to connect the simulator with JTAG. Here is how I compiled the simulator:

make CONFIG=TinyRocketConfig

and then run the simulator with jtag enabled:

./simulator-chipyard-TinyRocketConfig +jtag_rbb_enable=1 --rbb-port=9823 $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv32ui-p-bne

I get the following output:

This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 9823
[UART] UART0 is here (stdin/stdout).
terminate called after throwing an instance of 'std::runtime_error'
  what():  could not open +jtag_rbb_enable=1 (did you misspell it? If VCS, did you forget +permissive/+permissive-off?)

I found it weird when I use SmallNVDLARocketConfig config, it works as expected, but when using LargeBoomConfig, it complains about missing +jtag_rbb_enable=1 "binary".

And --rbb-port=9823 (EMULATOR OPTION) actually need to go before +jtag_rbb_enable=1 (VERILOG PLUSARG) as the help message said, but changing the order of these two arguments makes no different, which seems not related.

[hadirkhan10]

Have you been able to resolve this issue with the LargeBoomConfig?

[colinschmidt]

This behavior really shouldn't depend on CONFIG (aside from not including JTAG would cause it to not accept this option). So, to confirm, you can pass the exact same arguments to the simulators that only differ in CONFIG? It would be good to do a clean build of each of them before starting this test to make sure nothing else is out of date.

[hadirkhan10]

@yqszxx I cannot run the +jtag_rbb_enable=1 with the SmallNVDLARocketConfig as well. Same issue with it as well.

[hadirkhan10]

I noticed this issue arising in the chipyard version:1.3.0 in the configurations which did not set up JTAG. But in this latest version the docs says that by default every config is set up to include JTAG ports.

[yqszxx]

I noticed this issue arising in the chipyard version:1.3.0 in the configurations which did not set up JTAG. But in this latest version the docs says that by default every config is set up to include JTAG ports.

In fact I'm using 1.4.0, it does have its configuration set up with a JTAG port. Umm, still weird.

[colinschmidt]

You two seem to be reporting conflicting information: in one case SmallNVDLARocketConfig does work with jtag and in the other it doesn't. There was a modification of the argument parsing code between version 1.3.0 and 1.4.0 so if you could both move to 1.4.0 and confirm two configs that have JTAG enabled but where one does not parse the same set of runtime arguments correctly it will be easier to debug and get to a solution.

[hadirkhan10]

@colinschmidt to make things simpler, I am currently using chipyard version: 1.4.0. I am generating a verilator simulator for the TinyRocketConfig using the make CONFIG=TinyRocketConfig. The simulator is created and a simple test is passing on it. Now I am trying to debug it with JTAG. For that I pass the +jtag_rbb_enable=1 flag but the simulator doesn't recognize this flag and says did you misspell something?

[colinschmidt]

Ok. I've confirmed this issue, thanks for the help narrowing it down. As a quick workaround, wrapping that flag in +permissive and +permissive-off works for me.

./simulator-chipyard-TinyRocketConfig +permissive +jtag_rbb_enable=1 +permissive-off $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-add
This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 40931
[UART] UART0 is here (stdin/stdout).
Attempting to accept client socket

These types of arguments should need that special parsing so I'll look into a real fix.

[hadirkhan10]

Thanks @colinschmidt, this resolves the issue for me :)

[michael-etzkorn]

I think if you move the plusargs behind the binary it works. (My simulation still hangs though¯\(ツ)/¯)

[Yuxin-Yu]

Hello, I encountered a similar problem. When I use a series of BOOM simulation files to execute bare metal executables in software/coremark, I will report an error.Like:

yyx@yyx-virtual-machine:~/riscv/projects/Chipyard-yyx/software/coremark$ ../../sims/verilator/simulator-chipyard-LargeBoomConfig overlay-O3/coremark.bare.riscv

This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 40895
[UART] UART0 is here (stdin/stdout).
terminate called after throwing an instance of 'std::runtime_error'
what(): bad syscall #2147505920

It will report an error only for the executable file generated by the - O3 compilation option, and there is no problem when using the executable file corresponding to - O2 or - O1.For example:

yyx@yyx-virtual-machine:~/riscv/projects/Chipyard-yyx/software/coremark$ ../../sims/verilator/simulator-chipyard-LargeBoomConfig overlay-O1/coremark.bare.riscv

This emulator compiled with JTAG Remote Bitbang client. To enable, use +jtag_rbb_enable=1.
Listening on port 39831
[UART] UART0 is here (stdin/stdout).
Start run coremark.
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 1485510
Total time (secs): %f
Iterations/Sec : %f
ERROR! Must execute for at least 10 secs for a valid result!
Iterations : 5
Compiler version : GCC9.2.0
Compiler flags : -O1 -mcmodel=medany -static -std=gnu99 -fno-common -nostdlib -nostartfiles -lm -lgcc -T ../riscv64-baremetal/link.ld
Memory location : Please put data memory location here
(e.g. code in flash, data on heap etc)
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0xf24c

Do you know how to fix it,thanks

[waseem-10xe]

Hello, I encountered a same problem. When I use a series of BOOM large configuration simulation files to execute bare metal executables in software/coremark, I will report an error like below:

Command that I run: (/home/waseem/Desktop/chipyard/.conda-env) waseem@waseem-10xe:~/Desktop/chipyard/sims/verilator$ ./simulator-chipyard.harness-LargeBoomV3Config /home/waseem/Desktop/chipyard/software/coremark/riscv-coremark/coremark.bare.riscv

Results i get: [UART] UART0 is here (stdin/stdout). terminate called after throwing an instance of 'std::runtime_error' what(): bad syscall #2147500800

Screenshot of simulation: