[libre-riscv-dev] Yehowshua Tasks

[Luke Kenneth Casson Leighton]

On Tue, Jun 16, 2020 at 2:50 PM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
> >
> > it is *not* ok to have phase 1 proceed, the notification go back, "yes
> > there is room in the cache for you" followed in phase 2 "actually i lied,
> > we need to raise an exception now”.
>
>         Right. So I read through the Minerva cache and understand about
>         98% of it. There is a cache miss signal. And also a bus error signal
>         for example, if the cache tries to flush to the main memory via the
>         wishbone bus and it fails, it will raise bus_err.

ok the bus_err one would be an exception, and would fall into phase (1).

the cache miss signal: that would be an indicator to the FSM that
further work needs to be done.  this would i imagine still be part of
phase (1).

i *believe* this is taken care of by the time we get to the
LoadStoreUnitInterface.  i.e. i anticipate that CachedLoadStoreUnit
will use the cache-miss signal to determine if it should check the
address on the outgoing Wishbone Bus.

i.e., from CachedLoadStore Unit:

Phase (1) for a LOAD

- put the address into the cache.  get a "ok or cache miss" (this on same cycle)
- if "miss", put the address out onto the WB Bus (this may take
another cycle and that's ok)

we must HOLD LoadStoreUnit.m_stall indefinitely until such time as
EITHER the cache OR the WB Bus comes back with "yes this will succeed
100% if allowed to proceed".

Phase (2) for a LOAD

- ONLY after the first phase (m_valid but not m_load_error) is raised
will the external dependency tracker drop "m_stall"


it will be absolutely critical to have a unit test (and preferably a
Formal Correctness test) that confirms that at no time will
m_load_error be raised during Phase (2).


>         What is the difference between hold off and go die?

they're shadow matrix signals.  the logic is actually brain-dead
simple (only a few gates)
https://libre-soc.org/3d_gpu/shadow.jpg

* "hold off" prevents write.  it delineates phase 1 and phase 2.
that's both its definition and its job.  i believe it corresponds
directly to LoadStoreInterface.m_stall [or possibly x_stall.  there's
no documentation here, and x_ and m_ are non-standard conventions].

* "go die" will terminate all current state (full hard reset), free
all held resources, without causing any damage of any kind.  this has
to be done on the same clock cycle that the "die" is raised. (not on a
"sync" in other words).

another word for "go die" would be simply "cancel" or "reset".  i'm
not seeing any evidence of anything in Minerva loadstore.py which
suggests that such cancellation is possible.

so that would be a specific task that would need to be added.

>         I’m trying to write a simple unit bench for minerva L1Cache today.
>         Is there an NLNet task covering this?

no - feel free to make one, and refer to the archives (here).

also please do create one for investigating adding "cancel" (go_die)
to loadstore.py.  it should do a full hard-reset (withdraw all pending
states back to idle without causing any "damage")

l.