[libre-riscv-dev] libresoc memory architecture

[Jacob Lifshay]

On Wed, Jun 24, 2020, 14:11 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wednesday, June 24, 2020, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > One note:
> > conventional wisdom is that once your outside of the stuff that's local
> to
> > a core (and even some before then), all interfaces are non-speculative.
> > That also greatly simplifies the required hardware support for spectre,
> > since otherwise it's very easy to leak data from one core to another
> > through shared speculative hardware.
>
>
> there was a paper somewhere that yehowshua srnt about this, about L1, L2
> and MMU and SMP design that did properly deal with this.
>
> the basic principle if i understand it was that each object had a "mini
> cache" in front of it.  L1 had a mini L1 cache, L2 likewise and so on.
>
> these minicaches were speculative-capable and the thing they were fronting
> for was not.
>

that's a pretty good idea that I've been thinking about for a while -- I
don't recall if I independently invented it or not.

>
> in other words the minicache is compliant with the offer-exchange-complete
> protocol and the thing behind it is take-it-or-leave-it.
>

The way I imagined it is implemented a little differently...

>
> in _other_ words the minicache stores the *offers* (which contain both
> address *and* data) and the thing behind it stores the "completions".
>
> in this way, because the minicache contains the data at the "offer" phase
> no speculative operations EVERRRR hit the thing behind it.  no evictions,
> no resource utilisation, nothing.
>
> consequently there is no opportunity for speculative harm.
>

except for resource utilization conflicts at shared minicaches -- we still
need to watch out for that.

Jacob