[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 #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Yehowshua from comment #2)
> > 4k is 1200 megabytes per second: 37.5% *percent* of the total memory
> > bandwidth consumed by a 4k 60fps framebuffer!  and if people wanted
> > 120 fps instead, that's now a staggering 75% of a single OMI interface
> > dedicated to the framebuffer!
> 
> Raptor was saying that they were really looking for 1080p @60fps.
> So we shouldn't be worried about 4k for now.

ok great.  so that's only (!) 500 mbytes / sec.  just to check:
>>> 1920*1080*4
8294400
>>> 1920*1080*4*60
497664000
>>> 1920*1080*4*60/1e6
497.664

500*8 = 4 gigabits / sec.  so any PCIe (or other SERDES) would need to be
a minimum 4 GHz just to transfer the memory required to keep the framebuffer
100% occupied.

i am inclined to seriously recommend at least two separate OMI interfaces
(with the option to use them in parallel), one to be connected to a video
DRAM chip, the other to be connected to a "OS / GPU" memory DRAM chip,
with the option to say "i don't care about that, just use one or both for
general shared memory"

in SBC circumstances, where power is a concern and speed is not, a single
lane would be used, to a single OMI chip.

in SBC circumstances where power is not a concern and speed is, but there
is a requirement for higher-performance general-purpose CPU/GPU workloads
without demanding video, the two lanes would be dedicated to talk in parallel
to a single dual-ported OMI chip

*or*

the two lanes would be connected to *striped* memory (interleave odd/even
banks using low-bits of the address), across two separate OMI DRAMs

in the "video card" scenario, the two lanes would again connect to separate
OMI DRAMs, *however*, the framebuffer would *specifically* be mapped to
*only* one of those OMI DRAMs, and the OS memory specifically mapped to
the *other* OMI DRAM.

supporting this would need some quite complex dynamic Wishbone Bus Arbiters,
with an awful lot of MUXes on the address and data lines.  great care will
be needed to ensure that latency is not introduced.

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