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

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Tue Jul 30 00:58:32 BST 2019


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

--- Comment #3 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> (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)

the problem with this approach is that it is a pseudo-solution to saving power.
the combinatorial blocks don't know the previous state of the outputs (they
have no flip-flops) so can't reproduce it.

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

you wouldn't need to redesign everything if the code reading o_valid assumes
it's 1 when o_valid doesn't exist.

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

stagechain just copies o_valid from the last stage -- simple.

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

In my opinion, having all the combinatorial blocks required to be conditional
is a more flagrant violation of cleanliness.

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

note that for the div pipe, since the first compute stage is in the same
pipeline stage as the actual numbers are input, early-in would not be needed
for integers or fp.

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

just think of it as stages that don't have valid data have X for the data
lines, the X is just selected to be the previous value that was in the
flip-flops since that saves power.

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

if you want divcore to output zeros for zero inputs, just swap the values in
DivPipeCoreOperation so SqrtRem is numbered 0. this works since sqrt(0) == 0.
div doesn't do that since it solves for the largest q that satisfies dividend
>= divisor * q, when divisor is 0, obviously the largest q is all 1s.

this will also have the benefit of finding cases where we are still using magic
numbers instead of the named values, since those places will break.

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


More information about the libre-riscv-dev mailing list