-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
csr exception state with external debug request during illegal instruction entry #548
Comments
I see that the riscv-dv can generate handshakes (writes to a specific memory address) to enable update of core internal state.
The full description is in the riscv-db documentation: Maybe we need to add these handshakes to the virtual peripheral and use those events to update the ISS? |
I looked at this simulation and this seems like an ISS (or tracer) issue to me. The RTL is simply honoring the debug request after the dret completes (but dret needs to go through DECODE, FLUSH_EX, FLUSH_WB states, which opens up the door for the debug request to come in after DRET started its execution but before it completes). |
Hi @eroom1966 @strichmo Is this issue still being looked at or has it been solved? |
still open, I have not had time to investigate a good way to schedule the haltreq signal, I will get some time today to re-investigate |
is this problem still valid given the new core-v-verif setup with ImperasDV |
The steps to reproduce are provided at the top of the issue report. Having said that, they rely on GitHub repos and branches that may no longer exist. I'll give it a go... |
As luck would have it, @silabs-oysteink's fork/branch of core-v-verif used to identify this issue does still exist. Alas, SteveR's fork/branch of the cv32e40p for this issue does not exist. I will try a few hashes of the cv32e40p that are of similar vintage, but if I do not reproduce the issue it will be an inconclusive result. |
I have no clue if this ancient branch of my core-v-verif is in any useful state today, use at your own risk ;) |
OK, I have had no luck recreating this in simulation, probably because of the issue's dependence on two "ancient branches", one of which no longer exists. However, I believe we can close this issue for the following reasons:
@Silabs-ArjanB, I leave leave it to you to decide if this issue can be closed or not. Having said that, I do not believe this specific scenario is explicitly called out in the Debug DVplan. Row 62 is close, but not exactly the same. The functional coverage for the row 62 is in core-v-verif/cv32e40p/env/uvme/cov/uvme_debug_covg.sv and according to the RTL Freeze report, this coverage was hit. I think the condition we want is to assert the |
It is up to the current maintainers of the CV32E40P. I would say if it has not been fixed, do not close it. |
There is a high change this is a TB issue, yet I agree with @Silabs-ArjanB this should be first tested. Best |
Bug Title
CSR DECP and MECP miscompare when external debug request is granted during execution of an illegal instruction.
Component
Component:Verif
I suspect the cause of the miscompare is in the reference model.
The miscompares are:
UVM_ERROR @ 685665.300 ns : uvmt_cv32_step_compare.sv(96) reporter [Step-and-Compare] dpc expected=0x000056f6 and actual=0x00030900 PC=0x1a110800
UVM_ERROR @ 685665.300 ns : uvmt_cv32_step_compare.sv(96) reporter [Step-and-Compare] mepc expected=0x000054c8 and actual=0x000056f6 PC=0x1a110800
UVM_ERROR @ 685665.300 ns : uvmt_cv32_step_compare.sv(96) reporter [Step-and-Compare] mstatus expected=0x00001880 and actual=0x00001800 PC=0x1a110800
The sequence in the core appears to be:
Steps to Reproduce
Use this core-v-verif:
https://github.com/silabs-oysteink/core-v-verif
Branch: silabs-oysteink_random-debug
Common.mk should be changed to point to the head of the CV32E40P branch referenced:
CV32E40P_REPO ?= https://github.com/strichmo/cv32e40p
CV32E40P_BRANCH ?= strichmo/temp/tracer_with_ebrk
#2020-10-08
-CV32E40P_HASH ?= 90c23eb
+CV32E40P_HASH ?= head
Testcase executed with Xcelium 20.03.009
% makecv32 comp_corev-dv gen_corev-dv test TEST=corev_rand_debug SEED=-2058259982 CFG=no_pulp
The text was updated successfully, but these errors were encountered: