[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

--- Comment #17 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #12)
> Assuming we're building a higher than 2W version, I think we should double
> the int/fpmul to 8x32-bit per core or maybe even quadruple it to 16x32-bit
> and add more cores to 8 or 16 or more cores.

at 2.0 ghz this would start to put out some serious numbers :)
i'll do a walk-through separately so we are eyes-open on the layout and
wire count.

> The div and transcendental
> pipelines wouldn't probably need to be expanded since they would probably
> still have enough throughput.

the number of Function Units front-ends (aka "Reservation Stations") is
something we have to keep an eye on.  above 30 FUs is pretty serious
size territory for the Dependency Matrices.

> Also, it might be worthwhile to add one more
> core and disable one at manufacture time as a way to increase yield.

that's a good idea.  have to bear in mind that current leakage occurs
regardless of whether the silicon is in use or not.

> If possible, I think we should implement a cache-coherent memory interface
> over the PCIe bus so we can just have the host's linux kernel schedule
> processes as usual between the host POWER9 processor and the GPU, acting
> like the GPU is just more processor cores to schedule. That will allow nice
> things like using the GPU as extra CPU cores to help accelerate compile or
> other tasks and being able to use Kazan without needing lots of in-kernel
> GPU queues and stuff.

oo interesting.

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