[libre-riscv-dev] libresoc memory architecture
programmerjake at gmail.com
Wed Jun 24 22:40:08 BST 2020
On Wed, Jun 24, 2020, 14:11 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> On Wednesday, June 24, 2020, Jacob Lifshay <programmerjake at gmail.com>
> > One note:
> > conventional wisdom is that once your outside of the stuff that's local
> > 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.
More information about the libre-riscv-dev