[libre-riscv-dev] ModuleNotFoundError in soc.git

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Jun 18 07:36:10 BST 2019

tobias, hi,

i'm just, right now, getting to the point where a LD/ST Memory
Dependency Matrix is being debugged, and will need a L1 cache to be
added at some fairly path-critical point in the near future.  here's
the "stub" code which would need to be replaced with "activate some
cache lookup":


--- a/src/experiment/score6600.py
+++ b/src/experiment/score6600.py
@@ -558,6 +558,10 @@ class Scoreboard(Elaboratable):
         with m.If(self.ls_oper_i[3]): # ST bit of operand
             comb += memfus.st_i.eq(cul.issue_i | prior_ldsts)

+        # TODO: adr_rel_o needs to go into L1 Cache.  for now,
+        # just immediately activate go_adr
+        comb += cul.go_ad_i.eq(cul.adr_rel_o)
         # connect up address data
         comb += memfus.addrs_i[0].eq(cul.units[0].data_o)
         comb += memfus.addrs_i[1].eq(cul.units[1].data_o)

for context: see diagram in section "branch shadows", and
ignore the word "branch".

the way that the scoreboard system works is:

* the matrices express the full set of transitive relationships
between all Writes-after-Writes, Reads-after-Writes and

* obeying the Matrices "rules", damaging operations that need their
inputs to be created as outputs from other operations, are simply...
prevented from even beginning.  or, in the case of write-after-writes:
prevented from WRITING until the (earlier) write has first written.

there is an additional rule that has been added, in a "general
purpose" way, called "shadows", which is being used for multiple

* write-after-write (actually... full instruction-order commit preservation)
* predication
* branch shadows
* exceptions / traps

this latter includes LOAD/STORE exceptions and traps, which is where
"cache miss" and "L2 PTW illegal pages" come in to play.

the way it works is through the following rule:

* no instruction that MIGHT require itself and all instructions after
it to be "undone" (cancelled aka told "Go_Die") is permitted to write
(commit) to ANY resource, and, furthermore, no instruction(s)
FOLLOWING this one are likewise permitted to write (commit) to any

thus we have a "shadow" cast across future instructions.

ONLY when the instruction KNOWs that no possible exception could occur
is it permitted to "release" the shadow (successN is raised).  this
cancels not only the commit block across the *present* instruction, it
cancels the commit block across all the FUTURE instructions that this
instruction was holding up, as well.

and, clearly, "page miss" is such an exception that could, if not
dealt with in-order, cause significant damage.  thus, we have to HOLD
the instruction (and all future instructions) until such time as we
absolutely know, for certain, that the "page miss" event is NOT going
to happen.

so whilst the address may have been computed, "damage" (out-of-order
execution of LDs/STs) is prevented by the current instruction "holding
future instructions up" until the L1/L2 cache lookup / PTW is going to
be successful.

for now, i have a "dumb" system that assumes that no such damage can
occur (ever), hence why, once the address has been computed, it's
*immediately* assumed that the memory sub-system has (had) looked up

otherwise i have too many sub-systems to put in place and test, it's
quite hair-raising enough as it is.


More information about the libre-riscv-dev mailing list