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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Jun 12 16:27:20 BST 2020


Cole Poirier <colepoirier at gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |colepoirier at gmail.com

--- Comment #4 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #3) 
> 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"

I think this is an especially good idea given the performance loss APUs usually
suffer from using system RAM. I think it also makes sense to have the faster
wider memory bus for the graphics data so we can have a less power hungry
'general' data bus (as in no 3D graphics, or anything requiring MASSIVE data
paths, and therefore lots of power hungry SERDES). Is this correct?

> in SBC circumstances, where power is a concern and speed is not, a single
> lane would be used, to a single OMI chip.
> 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.

I think this reconfiguration is key to expanding the market segments the chip
is suitable for use in.

> 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.

Should be quite an interesting and very complex challenge, hopefully for some
new recruits and not just you to do Luke.

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

More information about the libre-riscv-dev mailing list