[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