The RTL simulation with Ariane core has "Illegal Instruction" error. (Ariane core)

[AltiumHanChou]

Describe the bug

The RTL simulation result (modelsim) in "single-core mode" exist "Illegal Instruction" error.

To Reproduce

1. Setup environment variable.
2. cd <ESP root>/socs/xilinx-vcu118-xcvu9p/
3. make grlib-xconfig Save and close it.
4. make esp-xconfig I change core to "Ariane", cache's implementation to "SystemC + HLS" and checked "Use Caches" box.
   
5. make llc-hls && make l2-hls
6. make sim
7. run -a(In modelsim)

Expected behavior

The correctly simulation result I get should be like this :

  ...
 # Hello from ESP!
  ...

But the simulation stucked like this :

And the simulation did not keep go on anymore. (I suspended it after I wait 20 min)
I checked the log file trace_hart_0.log.

Excerpt :

...
563129600000ns    43677 M 0000000080000044 0 3002a073 csrrs          t0, mstatus           t0  :0000000000000000
563705600000ns    43722 M 0000000080000048 1 0002d863 bgez           t0, pc + 16           t0  :0000000000000000
564140800000ns    43756 M 0000000080000058 0 00000297 auipc          t0, 0x0               t0  :0000000080000058
564166400000ns    43758 M 000000008000005c 0 00000297 auipc          t0, 0x0               t0  :000000008000005c
564704000000ns    43800 M 0000000080000060 0 30529073 csrw           t0, mtvec             t0  :000000008000005c
564729600000ns    43802 M 0000000080000064 0 30529073 csrw           t0, mtvec             t0  :000000008000005c
Exception @564742400000, PC: 0000000080000068, Cause: Illegal Instruction, 
				tval: 00000000f0000053
565305600000ns    43847 M 000000008000005c 0 00000297 auipc          t0, 0x0               t0  :000000008000005c
565318400000ns    43848 M 0000000080000060 0 30529073 csrw           t0, mtvec             t0  :000000008000005c
565344000000ns    43850 M 0000000080000064 0 30529073 csrw           t0, mtvec             t0  :000000008000005c
Exception @565356800000, PC: 0000000080000068, Cause: Illegal Instruction, 
				tval: 00000000f0000053
565587200000ns    43869 M 000000008000005c 0 00000297 auipc          t0, 0x0               t0  :000000008000005c
565600000000ns    43870 M 0000000080000060 0 30529073 csrw           t0, mtvec             t0  :000000008000005c
565625600000ns    43872 M 0000000080000064 0 30529073 csrw           t0, mtvec             t0  :000000008000005c
Exception @565638400000, PC: 0000000080000068, Cause: Illegal Instruction, 
...

After 564729600000ns it occur Illegal Instruction error.

Screenshots

Log file : trace_hart_0.log

Desktop (please complete the following information):

• OS: CentOS 7
• CAD tools versions:
  (CIC) Xilinx Vivado 2019.2
  (CIC) Systemc 2.3.1
  (CIC) modelsim 2020.1
  (CIC) STRATUS_19.12.100

Additional context

[davide-giri]

Hi, thanks for reporting this.

Just to make sure, could you run the same simulation but by selecting the SystemVerilog implementation of the caches in the GUI? Does that work?

There have been a few fixes/changes in the SystemVerilog caches recently that may not have been mirrored in the SystemC caches.

Thanks!

[AltiumHanChou]

Hi @davide-giri ~

It seems got same error which like above. Log file : trace_hart_0.log

BTW, you mention SystemVerilog caches recently has fixes/changes. Did it has already in the latest release (2021.1.0)?
The version I use now is 2021.1.0 .

[davide-giri]

Ok, so you have the issue regardless of the cache implementation choice. We are going to look into this and let you know soon.

I just meant to say that the SystemVerilog implementation has diverged slightly from the SystemC one, but both should work fine.

[paulmnt]

Hi @AltiumHanChou
I am not able to reproduce the illegal instruction error you report when selecting the SystemVerilog implementation of the caches. Could you please share with us the full simulation log, including the printouts that occur while the design is loaded by Modelsim?

With respect to the HLS-based implementation of the caches, I am regenerating the RTL and will update you shortly. I noticed, however, that you are using Stratus 19.2. Our SystemC for the caches has been tested with Stratus 18.5 and we have noticed that the tool version does matter, most likely because of bugs fixes and the introduction of new features in Stratus HLS.

[paulmnt]

One quick thought: did the toolchain compilation work correctly for both rv32imc (ibex) and rv64imad (ariane) versions of the RISC-V compiler?

ESP provides both scripts to generate the toolchains, which are based on the official RISC-V toolchain repository. These scripts should be run on different clean shell environments and I would also target two different installation folders. Particularly, both scripts must define the RISCV variable as export RISCV=${TARGET_DIR} and that's why I would recommend running them in separate environments using different TARGET_DIR. The scripts will ask you to indicate a default when you run them:

esp/utils/toolchain/build_riscv32imc_toolchain.sh for Ibex
esp/utils/toolchain/build_riscv_toolchain.sh for Ariane

[AltiumHanChou]

Hi @paulmnt ~

Log file : modelsim_Ariane.log

[paulmnt]

Thank you. Seems like the design has been loaded correctly, including SystemVerilog caches.
Also, the boot loader is executing correctly, but that runs in non cacheable address space, using the bootrom.

Could you please try checking that the program has been compiled and dumped to text file correctly?
Using the hello world systest.c on master, you should obtain the text file
esp/socs/xilinx-vcu118-xcvu9p/modelsim/ram.srec

and its content should match this txt:
ram.txt

HLS is still generating resources: will update you soon on SystemC version.

[AltiumHanChou]

One quick thought: did the toolchain compilation work correctly for both rv32imc (ibex) and rv64imad (ariane) versions of the RISC-V compiler?

ESP provides both scripts to generate the toolchains, which are based on the official RISC-V toolchain repository. These scripts should be run on different clean shell environments and I would also target two different installation folders. Particularly, both scripts must define the RISCV variable as export RISCV=${TARGET_DIR} and that's why I would recommend running them in separate environments using different TARGET_DIR. The scripts will ask you to indicate a default when you run them:

esp/utils/toolchain/build_riscv32imc_toolchain.sh for Ibex
esp/utils/toolchain/build_riscv_toolchain.sh for Ariane

According the tutorial, I set both in scripts like this :

set ESP_ROOT_PATH="~/ESP_Platform"
# risc-v toolchain environment
setenv RISCV        ${ESP_ROOT_PATH}"/riscv"
setenv RISCV32IMC   ${ESP_ROOT_PATH}"/riscv32imc"
setenv PATH ${PATH}:${ESP_ROOT_PATH}"/riscv/bin":${ESP_ROOT_PATH}"/riscv32imc/bin"

Is this correct ?

[paulmnt]

yes: this looks correct. I just sent the object dump just as a sanity check, but at this point I expect you will see no diff.

If the program is also compiled correctly, the only other difference I see with respect to the recommended setup is Modelsim's version. Xilinx recommends Modelsim 2019.2 for Vivado 2019.2, but I believe newer versions should work as well.

[AltiumHanChou]

Thank you. Seems like the design has been loaded correctly, including SystemVerilog caches.
Also, the boot loader is executing correctly, but that runs in non cacheable address space, using the bootrom.

Could you please try checking that the program has been compiled and dumped to text file correctly?
Using the hello world systest.c on master, you should obtain the text file
esp/socs/xilinx-vcu118-xcvu9p/modelsim/ram.srec

and its content should match this txt:
ram.txt

HLS is still generating resources: will update you soon on SystemC version.

Yes. It looks same like the file you gave me above.

yes: this looks correct. I just sent the object dump just as a sanity check, but at this point I expect you will see no diff.

If the program is also compiled correctly, the only other difference I see with respect to the recommended setup is Modelsim's version. Xilinx recommends Modelsim 2019.2 for Vivado 2019.2, but I believe newer versions should work as well.

OK ~ I will ask workstation to downgrade the modelsim version to 2019.2, and try again.
Thanks~

[paulmnt]

Hi @AltiumHanChou ,

this one was a silly Makefile issue: when switching processor core from the GUI without cleaning the simulation folder (e.g. with make sim-distcleam), the links to the program executable were not updated. This has been fixed on commit b143261

[paulmnt]

This issue should be fixed on the ESP devel branch