Cache_ctrl.sv #671
Unanswered
Simonlovald
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
I am currently working on my master thesis using the old cache_ctrl as a case study.
My topic is formal verification, and I am trying to automatize the generation of a complete set of properties for the design.
While writing constraints for the design, I noticed some states that I am not really able to understand why they are needed.
I can't see a scenario where there is no tag_valid-input and no gnt, coming from state IDLE, which then makes the cache_ctrl enter the WAIT_GNT? here:
cva6/src/cache_subsystem/cache_ctrl.sv
Lines 258 to 268 in 485662f
From my understanding both the load-unit and the ptw will always send a tag-valid in the next clock cycle after receiving data_gnt from the cache_ctrl. So how can the cache_ctrl possibly ever enter WAIT_GNT?
Only situation I can imagine, is if the load-unit got an exception when receiving the data_gnt,
cva6/src/load_unit.sv
Lines 244 to 247 in 485662f
but then the load-cache_ctrl will be stuck in WAIT_GNT/WAIT_TAG, as there is no way the load-unit can receive another data_gnt while the cache_ctrl is waiting for a tag_valid and therefore will never issue a tag_valid... Sounds like a deadlock to me.
I am guessing this is related to issue #430
I am grateful for any help regarding the understanding of this design.
Thank you in advance.
Beta Was this translation helpful? Give feedback.
All reactions