[libre-riscv-dev] [Bug 126] Make Div core conditional (enable signal)

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=126

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #1)
> the way to save power is to make the pipeline registers not change their
> value, not by adding conditional logic to completely combinatorial blocks.

They're combinatorial... however they are sometimes connected to other
combinatorial blocks and sometimes connected via pipeline classes and the
combinatorial blocks *do not know which*

Therefore, there are two choices:

1. Have logic that makes decisions inside the blocks (out_do_z)

2. Completely redesign absolutely every single combinatorial block, of which
there must now be over 50, to have an indicator (o_valid) which tells the
ongoing block if the output is to be switched...

... and then have some way of identifying when StageChain is used and when
pipeline registers are used.

Total mess, huge amount of work, and getting rid of the clean isolation and
transparent data independence in the process.

InputMux and OutputMux are bad enough as it is, reading ctx.muxid. These are
literally the only classes that break the rule of total separation between data
and data passing, and even then, there is no combinatorial block that ever does
anything other than pass ctx through.

That rule is just about to get broken with early in and early out bypassing,
but that's another story.

> this is because saving power occurs in cmos when the smallest number of
> gates switches from their previous state to a new state. switching all the
> gates to 0 or 1 actually uses lots of power in the clock cycle transitioning
> from in-use to idle.

It means adding an external "stall" capability, in effect.  6600 pipelines
*never* stall. Saving power however is a good reason to break that rule.

Or, in the case of the ReservationStations system: if the (unary) muxid is
nonzero, data shall be passed along the register pipeline chain, and left alone
if not.

That would do the trick. Only data that had a (unary) muxid would be
propagated.  It would require that the muxid be always (unconditionally)
propagated down the registers, whilst the data was *conditionally* propagated.


> In my opinion, this should be done outside the div core, it should be done
> in fpdiv/pipeline.py, which is where the pipeline registers are actually
> created.

Sort-of, by using SimpleHandshake, yes. This needs to be replaced with a
unary-muxid-understanding class with cancellation capability.  Will discuss on
the other bugreport.


> if debugging, all you have to do is view the data-valid signal as well as
> the data signals,

What happens in fpmul and fpadd, they check out_do_z.  Zeros get propagated
down the chain. Nothing changes.

So I add signals to view in gtkwave on every sequential phase, prenorm, align,
processing, postnorm, output.

Then I set the same input values in fpmux.py

The data propagates and is CLEARLY visible, no confusion, because, clearly, if
it's nonzero, it got there because the previous pipeline registers put it
there.

This is NOT the case with DivCore.

DivCore has the operator permanently active.

Zero input starts IMMEDIATELY generating spurious data, which immediately
begibs propagating down the pipeline.  I wasted... about an hour trying to work
out why on earth I was seeing 0x7000000 0x7f0000 0x7ff000 0x7ffff00 going down
the pipeline in the Div stages.

Finally I realised it was because operator defaults to zero, which ACTIVATES
actual DIV computation.

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