[libre-riscv-dev] [Bug 257] Implement demo Load/Store queueing algorithm

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=257

--- Comment #25 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #24)
> (In reply to Luke Kenneth Casson Leighton from comment #23)
> > also, we're not doing an SMP core for the october 2020 deadline, because we
> > are only doing a single core.
> > 
> > therefore L1 and L2 SMP cache coherency is not needed.
> 
> Ok, we can write the code to basically have whatever cache coherency stuff
> gets written when getting the memory interface working and not worry about
> the L2 or other cores existing at all, treating it as a writethrough
> transparent cache.

basically, yes.  we're only going to be running at 25 mhz (possibly 100 mhz)
because there's no PLL, and no clock gating.

therefore yes even the L2 can be cut.

> The design I'm working on is integrated closely enough
> with the L1 cache that it will still need at least a little of the coherence
> protocol to support atomics, 

remember, i said already that atomic memory operations are taken care of
by the Address / Memory Dependency Matrices.

they are already split out into individual (single) operations, each one
isolated from (batches of) LOADs and (batches of) STOREs.

so there's strictly speaking no need to implement any kind of coherence
protocol, because as things stand it's never going to be active.

yes it's over-zealous, it is however just a side-effect of how the
address-matching / memory-dependency matrices.


> but it can be built to have a WishBone
> interface adaptor.

ok good.  does it implement this algorithm?

https://bugs.libre-soc.org/show_bug.cgi?id=216#c23
https://libre-soc.org/3d_gpu/mem_l0_to_l1_bridge_v2.png

-- 
You are receiving this mail because:
You are on the CC list for the bug.