Open GTumbush opened 3 years ago
GTumbush
commented
3 years ago Something seems wrong with github's image attachment feature. I've tried attaching pdf, jpg, and png and keep getting "Something went really wrong, and we can't process that file." I'll send the image to @MikeOpenHWGroup and @strichmo
MikeOpenHWGroup
commented
3 years ago @GTumbush, here is your image:
MikeOpenHWGroup
commented
3 years ago @GTumbush asked:
Have you seen this before?
No, but now that you've brought this to light, I can see how it may happen.
Are plans to rework mm_ram?
@strichmo and I have discussed this more than once. A good example of what I'd like to see implemented is in the Ibex testbench: https://github.com/lowRISC/ibex/tree/master/dv/uvm/icache/dv/ibex_icache_mem_agent
Bug Title
non-clocking decode of mm_ram writes causes test to stop early
Type
Steps to Reproduce
make gen_corev-dv test COREV=YES TEST=corev_rand_interrupt Currently cannot reproduce in core-verif.
I had to run corev_rand_interrupt 200 times to see this issue.
Additional context
I've ran into a corner case issue in which a write to mm_ram is followed by data_addr_i=0x2000_2004 and the test stops. I think the detection of writes to the peripheral register in mm_ram should be clocked, not combinatorial.
The attached waveform is from the core-v-verif testbench cloned in late January and retargeted to a core using CLIC interrupts. I cannot share this code. What is happening: 1) Instruction sw x6, 4(x30) is executed. x30=0x2A988 2) A write to address 0x2A98C occurs 3) At the same time data_req_i deasserts data_addr_i changes 0x2000_0004 which in mm_ram is recognized as exit_valid 4) The test ends early.
To determine which signal causes this wait in uvmt_cv32_firmware_test.sv to be satisfied I recoded the wait as a fork/join_any disable fork in order to spawn 3 threads and print out which wait was satisfied. The exit_valid was satisfied. Signal exit_valid can not be seen asserting in a waveform since it is a glitch. wait ((vp_status_vif.exit_valid == 1'b1) || (vp_status_vif.tests_failed == 1'b1) || (vp_status_vif.tests_passed == 1'b1));
Have you seen this before? Are plans to rework mm_ram? If no to both I can clone the latest core-v-verif and see if I can replicate and then do a PR with a fix.