[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
Sat Jun 13 00:02:06 BST 2020


--- Comment #21 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #19)
> (In reply to Luke Kenneth Casson Leighton from comment #17)
> > (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 got 1TFLOP/s for 16 fma/clock/core with 16 cores, that's more than half
> the PS4's performance.

those are deeply impressive numbers :)  the cross-over post explains however
that the number of RSes - and the data cache line widths etc. - are starting
to get rather scary.

48 LD/ST Reservation Stations would mean 96 160-bit PortInterfaces,
which is 15,360 wires coming into a single block!

we would be much better off going to 128-bit SIMD, which would have the
unfortunate side-effect of cutting scalar performance by another factor
of 2 in speed if there were register usage that could not be scheduled

> > > 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 we set up each core as a different power domain (which will also help
> with idle power), the disabled core could be powered-down.

(you still get current leakage even when powered down, is my point)

> We should probably also widen the instruction decoders to decode 3 or 4
> 32-bit instructions per cycle.

yes.  this will almost certainly be necessary, because we would have far more
instructions to keep the monstrous number of RSes "fed".

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

More information about the libre-riscv-dev mailing list