openhwgroup / core-v-verif

Functional verification project for the CORE-V family of RISC-V cores.

Home Page:https://docs.openhwgroup.org/projects/core-v-verif/en/latest/index.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ISS MISMATCH (minhv=1) mepc misalignment

silabs-krdosvik opened this issue · comments

ISS MISMATCH (minhv=1) mepc misalignment

Short explanation:

Running modified clic test “mret_with_minhv” (with induced error) and get this mismatch:
image

The core correctly clears the mepc lower bits to get XLEN/8 alignment, but at that address there is no instruction, causing the core to take an illegal instruction exception.

(https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc)#)
image

More detailed explanation:

The problematic code:
Test “mret_with_minhv” contains this code snippit:
image

In the code snippit we see:

  1. That mcause gets the following values: minhv=1, mpp=0x3 and mpie=0.
  2. We store the address of label 1, which contain the address of label 2 (where an addi instruction is stored) to mepc (using the t0 register).
  3. Then, when running mret (and ignoring the fact that the address stored in mepc is forced misaligned), we would expect to run the instruction stored at the address stored in mepc, in other words the instruction stored in label 2 (addi).

What is happening (by analysing the object dump):

image

  • We see step 1), 2) and 3) marked in the object dump.
  • We see that the address 6142 is stored in mepc, and we can see that the least significant bytes of address 6142 are 6246 (follow blue arrow).
  • By looking at the PC addresses shown in the object file we can illustrate the memory as follows:
    image
  • When executing the mret the reference/iss execute the instruction at the address stored at 6142, which is 00_00_62_46 and contains a c.mv instruction. In the c code file we saw that lable 2 contained an addi instruction, we believe this is exchanged to an c.mv instruction by the compiler.

Correct behavior:
The clic spec states that we should clear the mepc lower bits to get XLEN/8 alignment. In our case that means that the core should execute the instruction stored at address 6140, 62460F0F. the core input 62460F0F gives an illegal instruction.

Type

  • Functionally incorrect behavior

Steps to Reproduce

  1. git clone git@github.com:openhwgroup/core-v-verif.git
  2. cd core-v-verif/
  3. git checkout cv32e40x/dev
  4. rm -rf cv32e40x
  5. git clone git@github.com:silabs-krdosvik/cv32e40x-dv.git cv32e40x
  6. cd cv32e40x
  7. git checkout clic-iss-problem
  8. cd sim/uvmt/
  9. make test TEST=clic CFG=clic_default

Hi Kristine,

Can I request that you run the simulation above, capturing the rvvi database.
In order to do this, you should only need to do the two following things

  1. set environment variable in your shell
    export IMPERAS_RVVI_DEBUG=1

  2. add the following +define to your simulation run
    +define+IDV_INCLUDE_TRACE2BIN

After running your simulation, you should have a directory called rvvi.db
Please provide this to me for analysis

Of course.
I will send you an email with the rvvi.db folder.

@silabs-krdosvik
Apologies in advance, the database produced is a little short - can I ask you to increase the number of MISMATCHES, so that the simulation continues for a few more cycles.
In my execution it exits exactly on the instruction here

Info   mstatus 00001800 -> 00001880 [SD:0 XS:0(Off) FS:0(Off) MPP:3 VS:0(Off) MPIE:0->1 MIE:0]
Info   mcause 70390002 -> 78390002 [Interrupt:0 minhv:1 mpp:3 mpie:0->1 mpil:57 Code:2(Virtual supervisor software interrupt)]
Info (IDV) rvviDecode.rvvi_trace2log.process_event @ 1439630: RET,0,29212,00006132,"30200073 mret                   ",,,,CSR300(mstatus)=0000000000001880 CSR342(mcause)=0000000078390002,
Info (IDV) rvviDecode.rvvi_trace2log.process_event @ 1439650: EXC,0,29213,62460f0e,"0000     c.illegal              ",,,,CSR300(mstatus)=0000000000001800 CSR341(mepc)=0000000062460f0e CSR342(mcause)=0000000030390002,
rvviRefShutdown

Please increase the MISMATCHES to 100 and re-run
sorry for the inconvenience
Also could you please provide the full log from your simulation run, enabling instruction trace in teh .ic file
--trace --tracechange --traceshowicount --monitornets

and also enabling the RVVI logging
+define+IDV_TRACE2LOG=1

thx
Lee

I see, of course, no problem.

I will send you an email with the new version of the rvvi.db folder and also the xrun-clic.log file, which is what I believe is the full log (correct me if I am mistaken).

Please increase the MISMATCHES to 100

I have set the IDV_MAX_ERRORS parameter to 100 and now the ImperasDV VERIFICATION REPORT reports 33 mismatches instead of only 6. I tell you this in case I somehow have misunderstood and there was another parameter you wanted me to change.

(The new configuration additions are now merged to the branch "clic-iss-problem" on my cv32e40x-dv fork.)
(You might have to remove the postfix ".100-mismatches" on the folder and file I have sent you.)

The MISMATCH disappears when updating our ISS version.

@silabs-krdosvik can we close this issue ?

Yes. the issue is closed.