[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

Cole Poirier <colepoirier@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |colepoirier@gmail.com

--- Comment #4 from Cole Poirier <colepoirier@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.
[snip]
> 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.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev