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

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=376

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #23)
> (In reply to Luke Kenneth Casson Leighton from comment #21)
> > (In reply to Jacob Lifshay from comment #19)
> > > > > 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)
> 
> I meant something like having a mosfet in the power line to the whole core,
> so the entire power supply could be turned off. Assuming that mosfet wasn't
> garbage, the power usage for the whole core could be reduced to the
> microwatt level.

apologies: you're still not getting it.  even the *existence* of the gates,
even when fully powered down, with zero oower connected in any way, shape or
form, *still* causes not insignificant current leakage.

this shows up particularly badly in the design of GSM ASICs.  thousands of
correlators are required to get an initial lock within "seconds" expected by
users... or... and then they are "powered down" exactly as you suggest.

unfortunately even their very existence, even powered down, causes current
leakage, adversely affecting power consumption and draining battery life.

the solution had to involve "A-GPS" where the LAT/LONG (or even just one of
those) was obtained from the bearest celltower.  this reduced the correlator
search soace to the point where a decent DSP could handle the job instead.


> > > 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".
> 
> We would also want to build a better branch predictor (TAGE?) since we would
> have a higher power/area budget.

yes, agreed.  cancelling 40 Reservation Stations on a regular basis is not an
amusing prospect.

> Both of those changes would potentially also drastically improve scalar
> performance, approaching that of some modern desktop processors at
> equivalent clock speeds.

one very nice thing about SimpleV is that the VL (Vector Length) can be thrown
into the branch tag XOR/hash/thing.

this would give a different prediction at the end of a loop, right just when
you need different decision-making about which way a branch is likely to go.

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