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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu May 14 17:17:37 BST 2020


--- Comment #60 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
sub pseudocode:

* subf RT,RA,RB (OE=0 Rc=0)

    RT <- ¬(RA) + (RB) + 1

which is... b-a

and in alu/output_stage:

comb += self.o.cr0.eq(Cat(so, is_zero, is_positive, is_negative))

so bit 0 of CR0 is "is zero"
bit 1 is "is +ve"
bit 2 is "is -ve"

cmp pseudocode:

    if L = 0 then
        a <- EXTS((RA)[32:63] )
        b <- EXTS((RB)[32:63])
        a <- (RA)
        b <- (RB)
    if      a < b then c <-  0b100
    else if a > b then c <-  0b010
    else               c <-  0b001
    CR[4*BF+32:4*BF+35] <-  c || XER[SO]

and cmpi pseudocode:

    if L = 0 then a <-  EXTS((RA)[32:63])
    else a <-  (RA)
    if      a < EXTS(SI) then c <- 0b100
    else if a > EXTS(SI) then c <- 0b010
    else                      c <- 0b001
    CR[4*BF+32:4*BF+35] <- c || XER[SO]

so that is *a* less than B/immediate, bit 2 (-ve) is set)
*a* greater than B/immediate, bit 1 (+ve) is set)

which is the opposite of add/subtract.

i presume this is best implemented by calculating "a-b" (rather than b-a). 
in microwatt, there's comments at line 540 about this:


we can't invert the operands outside of the pipeline: that means
that the register port allocation system needs to have a "decoder" in it.

the inversion needs to be done *inside* the pipeline, not outside...
ok just checking alu/input_stage.py, ok yes that looks good.

i say "good", i mean "functional but messy as hell" :)

i wonder... i wonder if, rather than mess up the input stage *and* the
main stage, which involves two 64-bit MUXes, if it would not be better
to swap is_positive and is_negative in the *output* stage?

this would only be QTY 2 single-bit MUXes

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

More information about the libre-riscv-dev mailing list