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