[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
https://bugs.libre-soc.org/show_bug.cgi?id=376
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.
[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.
More information about the libre-riscv-dev
mailing list