[libre-riscv-dev] Fall 2022 Interfaces

[Luke Kenneth Casson Leighton]

On Fri, Jun 12, 2020 at 1:38 PM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
>
> > that may not be enough to handle framebuffers as well as run an OS.
> > framebuffers are scarily demanding of memory bandwidth and they absolutely
> > MUST have total absolute top priority.
>
>
>  The OMI interface has 3200MT/s which is the same spec as DDR4.

3200 million transactions/sec, let's assume 8 bytes.  that's 3200
megabytes per second.  25 gigabit / 8 equals 3.125 so that fits with
the math , there.  one 25 gigabit lane provides 3200 million 8-bit
transactions per second (3.125).

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!

bear in mind that that is *just* the framebuffer hardware.  the CPU -
the GPU - is contending for the exact same memory resource.

we cannot possibly expect the GPU to operate effectively at that kind
of resource-starved level.  bear in mind that not only the GPU 3D
Vulkan / bitmap / texturisation data has to go over that same
interface, the Operating System *also* has to swap in and out as well

to get that down to only 5% of total bandwidth, going to 64 bytes per
transaction would, if i am reading this correctly, require *eight* of
those 25 gigabit per second SERDES.

and that alone is going to be mental as far as power consumption is
concerned.  i don't exactly know what the power consumption of a
single lane 25 gigabit SERDES is going to be, i am trying to recall
the conversations last year with Rudi when i visited him: it will
however be extremely important to find out.

i have a *vague* recollection of a number somewhere around 300mW.  if
we assume that to be correct, then those 10x Rx and 14x Tx would be
somewhere around *eight watts* just for the SERDES alone!


so here we have the basis of actionpoints, which i would suggest be
put into the bugtracker (otherwise we'll lose track, which i'm
starting to do, already, thank you gmail)

* to make a decision as to what top level of visual performance is
needed (maximum resolution, maximum framerate)
* calculate the framebuffer data transfer rate for that.
* to decide some top level of GFLOPs and MTriangles/sec (and other
waffly figures for the GPU side)
* estimate the memory bandwidth for the GPU side
* decide if we want to develop a hardware compression algorithm
between memory and framebuffer (an augmentation of Richard Herveille's
RGBTTL framebuffer RTL)
* find out the power consumption in 45nm for these SERDES
* talk to Rudi to see if he can do a SERDES PHY for us
* talk to SymbioticEDA likewise
* talk to Dmitri from LIP6.fr to see what he can do, whether a stable
50 GHz clock is achievable in 45nm (i understand from Dmitri that for
a given target clock - 25 gbit/sec in this case - you need the PLL to
do double the clockrate)

l.