[libre-riscv-dev] [Bug 305] Create Pipelined ALU similar to alu_hier.py

[bugzilla-daemon at libre-soc.org]

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

--- Comment #16 from Michael Nolan <mtnolan2640 at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #15)
> (In reply to Michael Nolan from comment #14)
> > (In reply to Luke Kenneth Casson Leighton from comment #13)
> > 
> > > with "carry_in" being *generated* by ALUInputStage, ALUInputData should
> > > *not* have "carry_in" as a field.
> > 
> > We still need a carry_in from XER for things like add with carry. 
> 
> ah doh, yes you are absolutely right.
> 
> hmm hmmm sooo....
> 
> actually.... the default action from the if elif batch is to copy that
> carry_in from the input spec over to the output spec.
> 
> 
> > 
> > > the reason is because it will never be set by the *user* of this stage,
> > > and consequently a dangling wire will end up being created.
> > > -----
> > > 
> > > what's "so" intended for?
> > 
> > Summary Overflow.
> 
> okaay.  so if it's a generated output, set only as a result as part of the
> operation (in the 2nd or 3rd stage), it should *not* be in the ispec(), only
> in the ospec() for later stage(s)

Summary Overflow is "sticky". Once one instruction sets the overflow bit,
summary overflow gets set until it's cleared by a mtspr instruction.
Effectively for each instruction it's (so = so | ov). That's why it's included
in the input stage.

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