ISS mismatch on exception trigger debug entry

[silabs-oysteink]

ISS mismatch on exception trigger debug entry

Type

Indicate whether the type of problem you found:

• Likely ISS error

Steps to Reproduce

1. Use core-v-verif from my fork/branch: https://github.com/silabs-oysteink/core-v-verif/tree/etrigger_test
2. Use cv32e40x hash e65267768e371ce9bdbd3e6e40b24254c96e0689
3. ISS version v20221107.0
4. from cv32e40x/sim/uvmt run the following:
5. make clean_all test TEST=debug_test_etrigger USE_ISS=1 CV_CORE=cv32e40x

After running, the following ISS mismatch can be seen:

The cv32e40x goes to debug and executes the first debug handler instruction when an exception is encountered (PC = 0x1a110800 is the start of the debug code) while the ISS executes the first exception handler instruction (PC = 0x0 aligns with mtvec).

According to the debug spec V1.0.0, the debug entry should happen just before the first instruction of the trap handler is executed, but after all CSR updates for the exception.

From the test is seems like the ISS is first executing the first exception handler instruction before it enters debug mode.

[eroom1966]

@silabs-oysteink
I am trying to enable the instruction tracing to obtain additional information from the reference model
previously I had uncommented code in
./mk/uvmt/xrun.mk : line 351
to enable trace etc

It looks like this is no longer being used, so please let me know how to pass options to the reference model in the imperas control (.ic) file

[eroom1966]

I tried running the basic debug_test, and this fails on a csr read of TINFO

Info 18900: 'refRoot/cpu', 0x000000000000027c(main+1ae): Machine 7a4025f3 csrr    x11,tinfo
Info   MEMX 0x27c 0x27c 2 25f3
Info   MEMX 0x27e 0x27e 2 7a40
Info   x11 0000ecfb -> 00008060
Error (IDV) GPR register value mismatch (HartId:0, PC:0000027c):
Info (IDV)  0> GPR x11 - dut:00000004 ref:00008060

This would imply that the TINFO is powering up in an illegal state, as this should be readonly
Reset Value: 0x0000_8060
The RTL is returning value 0x0000_0004

https://docs.openhwgroup.org/projects/cv32e40x-user-manual/en/0.6.0/control_status_registers.html#trigger-info-tinfo

[silabs-oysteink]

@silabs-oysteink I am trying to enable the instruction tracing to obtain additional information from the reference model previously I had uncommented code in ./mk/uvmt/xrun.mk : line 351 to enable trace etc

It looks like this is no longer being used, so please let me know how to pass options to the reference model in the imperas control (.ic) file

@silabs-mateilga do you know how to pass these options to the ISS?

[silabs-oysteink]

I tried running the basic debug_test, and this fails on a csr read of TINFO

Info 18900: 'refRoot/cpu', 0x000000000000027c(main+1ae): Machine 7a4025f3 csrr    x11,tinfo
Info   MEMX 0x27c 0x27c 2 25f3
Info   MEMX 0x27e 0x27e 2 7a40
Info   x11 0000ecfb -> 00008060
Error (IDV) GPR register value mismatch (HartId:0, PC:0000027c):
Info (IDV)  0> GPR x11 - dut:00000004 ref:00008060

This would imply that the TINFO is powering up in an illegal state, as this should be readonly Reset Value: 0x0000_8060 The RTL is returning value 0x0000_0004

https://docs.openhwgroup.org/projects/cv32e40x-user-manual/en/0.6.0/control_status_registers.html#trigger-info-tinfo

@eroom1966 Are you using the RTL hash specified in the issue description? The value of the tinfo CSR was updated to reflect the new trigger types in that commit.

[eroom1966]

Also, I note that the following registers are still ignored

    // TODO silabs-hfegran: temp fix to work around issues
    rvviRefCsrCompareEnable(hart_id, `CSR_DCSR_ADDR,   RVVI_FALSE);
    rvviRefCsrCompareEnable(hart_id, `CSR_TDATA1_ADDR, RVVI_FALSE);
    rvviRefCsrCompareEnable(hart_id, `CSR_TINFO_ADDR,  RVVI_FALSE);
    // end TODO

When I enable these, I get immediate errors

Info 1: 'refRoot/cpu', 0x0000000000000080(_start): Machine 0000f197 auipc   x3,0xf
Info   MEMX 0x80 0x80 2 f197
Info   MEMX 0x82 0x82 2 0000
Info   x3 00000000 -> 0000f080
Error (IDV) CSR register value mismatch (HartId:0, PC:00000080):
Info (IDV)  0> CSR 7A4 (tinfo) - dut:00000004 ref:00008060
Info (IDV)  1> CSR 7B0 (dcsr) - dut:40000003 ref:40000413

https://docs.openhwgroup.org/projects/cv32e40x-user-manual/en/0.6.0/control_status_registers.html#debug-control-and-status-dcsr
Reset Value: 0x4000_0413

https://docs.openhwgroup.org/projects/cv32e40x-user-manual/en/0.6.0/control_status_registers.html#trigger-info-tinfo
Reset Value: 0x0000_8060

[eroom1966]

@eroom1966 Are you using the RTL hash specified in the issue description? The value of the tinfo CSR was updated to reflect the new trigger types in that commit.

I missed that, I had presumed it was in the ExternalRepos.mk

trying again

[silabs-oysteink]

Also, I note that the following registers are still ignored

    // TODO silabs-hfegran: temp fix to work around issues
    rvviRefCsrCompareEnable(hart_id, `CSR_DCSR_ADDR,   RVVI_FALSE);
    rvviRefCsrCompareEnable(hart_id, `CSR_TDATA1_ADDR, RVVI_FALSE);
    rvviRefCsrCompareEnable(hart_id, `CSR_TINFO_ADDR,  RVVI_FALSE);
    // end TODO

When I enable these, I get immediate errors

Info 1: 'refRoot/cpu', 0x0000000000000080(_start): Machine 0000f197 auipc   x3,0xf
Info   MEMX 0x80 0x80 2 f197
Info   MEMX 0x82 0x82 2 0000
Info   x3 00000000 -> 0000f080
Error (IDV) CSR register value mismatch (HartId:0, PC:00000080):
Info (IDV)  0> CSR 7A4 (tinfo) - dut:00000004 ref:00008060
Info (IDV)  1> CSR 7B0 (dcsr) - dut:40000003 ref:40000413

https://docs.openhwgroup.org/projects/cv32e40x-user-manual/en/0.6.0/control_status_registers.html#debug-control-and-status-dcsr Reset Value: 0x4000_0413

https://docs.openhwgroup.org/projects/cv32e40x-user-manual/en/0.6.0/control_status_registers.html#trigger-info-tinfo Reset Value: 0x0000_8060

Yes, there are some features from UM 0.6.0 that are not yet implemented in RTL. Therefore, the DCSR checks should be disabled until we get the mprven properly tied to 1. Tdata1 and tinfo should be ok to include though.

[eroom1966]

Hi Oystein,
I now have this executing without mis-compares (if I exclude dcsr comparisons)
The test itself fails for some other reason - I presume the test is asserting some UVM Error - but there is no miscompare

I will upload a copy of the modified ImperasDV for you to evaluate.

[silabs-oysteink]

Perfect! It is likely due to the test itself that it reports failed, as I just quickly made a smaller test than debug_test_trigger to expose the mismatch.

[eroom1966]

@silabs-oysteink sent you an email

[eroom1966]

any update on this issue ?

[silabs-oysteink]

Hi @eroom1966 I have now used the ISS version with the fix and the test now runs to completion without errors. I will close this issue. Thanks for the fix!