[Libre-soc-bugs] [Bug 755] add grev instruction (OP_GREV)

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Wed May 18 06:35:04 BST 2022


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

--- Comment #57 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #56)
> ok so the key difference as to why i designed grevlut the way it is,
> is to bring in *two* bits (A[i] and A[i^crossover]) into the binary LUT.
> 
> the cascade effect of the application of multiple LUTs results in
> e.g. ANDing or NANDing of multiple bits, which is how the magic
> constants 0x11111111 0x10101010 0x10001000 0x10000000 emerge,
> and it turns out that 0x77777777 0x70707070 etc and many more
> can be created as well.

neat!

> the AOI trick *cannot do that* because the bits A[i] and A[i^crossover]
> are treated as *independent*

that's not true, see:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=26558305c986c30f6f786e77769c566c6104f085

This has the exact same aoi matrix that I proposed, just the inputs from sh are
changed. it still has latency 6x aoi gates plus misc stuff on sh and
input/output xor layers.

it *can* generate 0x1000100010001 because the aoi matrix has the input/outputs
invertable, giving you and-ing via de-morgan inversion of the or-gates inside
the aoi matrix.

I added in the thing where the aoi gates taking input from the left have
different imm bits than the input from the right in the grev butterfly wires.
(sorry, I can't think of a good way to describe it textually.)

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


More information about the libre-soc-bugs mailing list