In pymem.py, it is written: "conversely: addr_ok_o must *ONLY* be asserted if there is a HUNDRED PERCENT guarantee that the memory request will be fulfilled."
When running test_issuer_mmu.py, on the LDSTExceptionTestCase(), I noticed that addr_ok_o is unexpectedly raised, on the same cycle as exc_happened (run "gtkwave issuer_simulator.gtkw", see "ld/st port interface" section).
I think this wasn't supposed to happen, even if the LDSTCompUnit didn't seem to actually care in this case.
yes, that's critically important that no possible indicator of success or
permitting of proceeding to a stage that REQUIRES 100% guaranteed completion.
this is down to the "House Contract Of Sale" protocol, which is:
Wishbone is a "TAKE IT OR LEAVE IT" Contract. you get someone walking
up to you on the street, saying, "buy my goods at reduced price! take it
or leave it!".
Speculative multi-issue execution *cannot* work on top of a take-it-or-leave-it
Contract. you *have* to have a "conditional offer" phase. ONLY past the
"Exchange" point does it become a 100% cast-iron guaranteed requirement to
addr_ok_o is is part of the "Exchange" process, stating
that there are no objections to proceeding to "Complete"
if addr_ok_o is being raise at the *same time* as an indication that the
"Offer" is *REJECTED* (exc_happened) then that's extremely serious.
It can also be more easily seen to happen with test_misalign_mmu() in src/soc/experiment/test/test_ldst_pi.py
I guess it has to do with LoadStore1 being derived from PortInterfaceBase, which seems to unconditionally raise addr_ok_o on receiving an addr.ok. Maybe it should somehow consult its derived class before doing so.
exceptions are the way that the "Offer" is refused. because we are only
just now starting to add exceptions, there will be a lot of areas that
need to support the "House Sale" protocol.
up until now, if a problem ever occurred, it was completely ignored!
there is even no error-checking on any wishbone bus exchanges, only