[Arm-netbook] libre 64-bit risc-v SoC

[mike.valk at gmail.com]

2017-04-28 14:58 GMT+02:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

>
>  in the case where you have something that falls outside of the custom
> silicon (a newer CODEC for example) then yes, an FPGA would *possibly*
> help... if and only if you have enough bandwidth.
>

That is what I was talking about.


>
>  video is RIDICULOUSLY bandwidth-hungry.  1920x1080 @ 60fps 32bpp
> is... an insane data-rate.  it's 470 MEGABYTES per second.  that's
> what the framebuffer has to handle, so you not only have to have the
> HDMI (or other video) PHY capable of handling that but the CODEC
> hardware has to be able to *write* - simultaneously - on the exact
> same memory bus.
>

I Overestimated the capabilities of an FPGA. I've just read You need
two/four FPGA linked to do H264 in realtime. Or a full new one. FPGA's also
are usually are very slow.

I found a nice presentation on using FPGA's for video codecs.
https://www.ece.cmu.edu/~ece796/seminar/10/seminar/FPGA.ppt

The most facinating option I found is to reconfigure the FPGA for each
processing step.


>
>  the point is: if you're considering using an FPGA to accelerate video
> it's gonna be a *really* big and expensive FPGA, and you would need to
> implement something like PCIe just to cope with the communications
> between the two.
>
>  costs just escalated way beyond market value.
>
>  this is why companies just simply... abandon one SoC and do another
> one which has an improved custom CODEC silicon which *does* handle the
> newer CODEC(s).
>

Hmm. So for longevity the video decoder should be outside the SoC and be
serviceable... Nah just buy a new EOMA card and keep the rest. ;-)

Speaking of which any plans for a en/decoder module(IP Block is therm
right?) in the new SoC? Or leaving that out?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20170428/4b1eab98/attachment.html>