core-v-verif
core-v-verif copied to clipboard
openhwgroup
Improvements: Checking
Use this issue to gather all ideas to improve or highlight long-term issues with any of the following:
- Self-checking test support
- Assertion methodology
- ISS integration
- ISS/RTL debug (e.g. tracer, step-and-compare interface)
Add comments for all ideas to this issue. Please try to refrain from deeper discussion of inidividual items. A separate issue should be opened to enable and record that discussion.
- ISS/RTL debug: Need a well defined interface between ISS and RTL that both sides can work towards. The current method of probing directly into the RTL is relatively error prone, not documented and not very scalable. Possibly the RISC-V Formal Interface (RVFI) can be used for this purpose.
Wow! I am so glad to see your post on this @Silabs-ArjanB. All of the items you mention have been discussed internally among the verif team, including the RVFI idea. I was worried that we were going to need to "convince" you and @davideschiavone.
Tracer this is related to the RVFI-like interface. Currently the Tracer is located in the cv32e40p repo. With a well defined interface we could move the Tracer into core-v-verif and implement the tracer as a passive UVM Agent that sources transactions for checking, coverage, etc.
Enable ISS to be disabled in run-time for working around issues on a temporary basis.
Try to "hide" clocking of the step and compare interface. RTL wires look "funny" due to long periods of idle RTL clock when the ISS is clocking.
Add assertions or other checking for individual instruction latency (end-to-end or through individual pipeline elements)
Implement pipeline monitor owned by verification to track instruction execution through the pipeline to check against ISS. Implement pipeline monitor as a UVM agent. Decouple checks into scoreboard checks from the ISS and the pipeline monitor, such that timings of different checking events may be skewed accordingly.
Create more abstract CSR checking interface to enable checking of CSRs with any of the following: Read/Write from instructions or hardware-writable updates
Create more abstract CSR checking interface to enable checking of CSRs with any of the following: Read/Write from instructions or hardware-writable updates
I like this idea. @datum-dpoulin has expressed interest in generating a UVM RAL model of the CSRs. I haven't pursued it as we do not have a way to use it with any known reference models. However, it might be useful for coverage.
Please refer to issue #439 for a more focused discussion of the Tracer/RVFI.