[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