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

[bugzilla-daemon@libre-soc.org]

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

--- Comment #14 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(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)

or would we have:

* two separate memory interfaces, each dedicated to different address ranges
* one L2 (L3?) cache, through which the CPU/GPU would read/write
  (note: as a Wishbone Slave)
* the RGBTTL Wishbone Master would *bypass* the L2 cache and go directly
  out to memory

if the L2 cache was write-through, then effectively i believe those are
the exact same thing?  the advantage of the 2nd being that it cannot
interfere with or be distracted by any page faults or misses in the L2 cache.

(the RGBTTL interface *has* to - without fail - be able to feed its
SRAM buffer and meet its scanline timing - without fail.  hence why
it is a Wishbone Master)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev