[libre-riscv-dev] libresoc memory architecture

[Luke Kenneth Casson Leighton]

On Wednesday, June 24, 2020, Cesar Strauss <cestrauss at gmail.com> wrote:

> On 06/23/2020 19:14, Luke Kenneth Casson Leighton wrote:
> > with the hardware providing the range-checking (and also enforcing the
> > read/write by using the range-checking at the time of the write) we do
> > not need to have an MMU at all in order to get testable code.
> >
> > this is really very simple and does not need any kludges.  as i said:
> > the hardware *already exists* (in the Decoder) because the Decoder has
> > to route the request to the right peripheral anyway.
> >
> > so the Decoder *knows* whether the address will succeed or not.  it's
> > just that the "take-it-or-leave-it" Wishbone contract prevents and
> > prohibits us from being able to do that check *unless* the actual
> > request is performed.
> >
> > by which time it's too late as far as speculative execution is
> > concerned: "damage" will have been done that is irreversible, and we
> > are most definitely not going to do a Transaction / Rollback
> > architecture, taking snapshots of memory.  that would be an insanely
> > complex project.
> >
> > all that is needed is to expose that address-check information -
> > information which *already exists* at the hardware level - via a
> > "checker" function.
> >
> > this one very simple augmentation provides the means for us to turn
> > the "take-it-or-leave-it" atomic-only single issue requests into
> > "offer exchange complete" parallel-capable multi-issue speculative
> > requests.
>
> As I understand it, Wishbone has already a concept of an intelligent
> "interconnect", which connects Masters to Slaves in the bus (it's not
> necessarily a cross-bar, but it can be).


indeed.


>
> The role of this "interconnect" is to arbitrate masters, decode the
> address, route the master CYC_O signal to the selected peripheral CYC_I,
> and even raise a bus error in case the address is invalid.


yes, this is my understanding and expectation, too.


>
> So, I'm just saying that Wishbone has already a concept for the Decoder
> function you just described above.


indeed:


https://git.libre-soc.org/?p=nmigen-soc.git;a=blob;f=nmigen_soc/wishbone/bus.py;hb=HEAD#l204

although that implementation actually broadcasts (whoops) without doing
range checking.

the nmigen-soc CSR Decode class i believe does slightly better.


unfortunately, as i mentioned: by virtue of the wishbone protocol being
atomic "take it or leave it", the only way to check if the Decode would
succeed is to *do* the operation.




> Furthermore, Wishbone has a pipelined transfer mode, where addresses and
> data are presented in sequence, and the acknowledgements (or bus errors,
> maybe) can come later, in order.


again, unfortunately, the pipelined transfer mode implements a
take-it-or-leave-it protocol, where the requests are overlapped and can in
no way be speculatively cancelled.

here it gets spectacularly complex because now you have two overlapping
potential speculative pipelined requests, where cancellation of earlier
ones *must* by definition result in cancellation of later ones.

[that's if we preserve order (Total Store Order).  under Weak Memory Model
it is not necessary to exactly preserve order, just the appearance of
preserving it as far as programs are concerned.]


Wishbone tags maybe can be used for out-of-order acknowledgements, I think.


i did an analysis here:

https://bugs.libre-soc.org/show_bug.cgi?id=397#c5

from what i can gather the tags must respect one of four timing
constraints, and fit the information into one of four types.

someone else may have better luck however i was not able to see how to
honour the existing tag type requirements.

what we would need is not a cycle type.  a cycle is enabled indefinitely to
indicate "busy"

it is not exactly address-only either and there is no address "acknowledge"
tag.

it is not data type either because we need *address* checking.

ultimately i think we actually need to add a *fifth* tag, TGA_I, to allow
"is address valid?" checking.

this would fulfil the "House Contract of Sale" offer phase, as it would
allow the potential "buyer" to say yes or no WITHOUT damaging memory.

we also need a way for the sender to HOLD data transfer.  right now,
STALL_I is generated by the *slave*.

we need the *MASTER* to be in control of that process, and in addition we
need the Master to be able to cancel the transaction entirely.

if simple existing wishbone implementations will cope with full
cancellation of requests i will be really surprised and delighted.

l.







-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68