[libre-riscv-dev] [Bug 376] Assess 40/45 nm 2022 target and interfaces

[bugzilla-daemon at libre-soc.org]

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

--- Comment #18 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #14)
> (In reply to Jacob Lifshay from comment #13)
> 
> > > this for the video framebuffer and the video framebuffer only.
> > 
> > That doesn't really work, since the GPU will need lots of memory bandwidth
> > into the framebuffer since that's where it will be rendering to, potentially
> > drawing over the same pixels several dozen times. To support that, the
> > memory bandwidth of both the framebuffer and everything else needs to be
> > spread across all available memory interfaces.
> 
> ok let's think it through, internally.  would we have:
> 
> * two separate memory interfaces, each dedicated to different address ranges
> * one L2 (L3?) cache, through which *both* memory interfaces have to go,
> first
>   (note: the CPU/GPU as a Wishbone Slave, the RGBTTL HDL as a Master)

I think what would work the best is for the RGBTTL HDL and every core to be a
(extended) wishbone master to the L2 (L3?) cache, where the cache logic is the
arbiter and is designed to give the RGBTTL HDL highest priority and everything
else round robin (or other) priority. Saving power on scan-out when the data is
already in cache seems like a good idea, also, the memory interfaces would be
the tightest bottleneck, why require more accesses to go through them when that
can be avoided?

The memory interfaces would be organized into one larger super-interface where
each memory interface would be responsible for odd or even cache-block-sized
address blocks. The idea is that accessing something laid out contiguously in
physical address space would approximate balancing evenly across both memory
interfaces.

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