[libre-riscv-dev] partitioned compare and mux

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Feb 7 02:21:41 GMT 2020


(sorry, needs to be on list michael, this is major internal design
functionality)

On Friday, February 7, 2020, Michael Nolan <mtnolan2640 at gmail.com> wrote:

> .
>
> So this isn't being done to simplify the partitioned comparison itself,
> but to simplify the logic using it (partitioned min/max or whatever)?


yes.  if we assume potential for 5 or 6 muxes, that's a lot of
bit-propagation.


> If so, that seems reasonable.


appreciated


>
> >
> > so ah many apologies, if you agree with the assessment above, you know
> where you solved the issue of 0xf instead of 0x1, that needs to revert to y
> |=
> > masklist_bits[i] and then gt_combiner being modified to propagate the
> LSB (result) from each partition over the entire partition.
>
> This shouldn't change the structure of the logic *that* much.


i figured it wouldn't


> I'm
> already propogating the output of the most significant bit of each
> partition over to the least, so I think all that I'd need to change is
> removing the gates that disable the output if the current partition
> isn't the least significant bit.


basically if one partition bit is set, that's the condition to ripple the
intermediary output up to when the next partition bit is set.

it's a chain of crossbars again, basically.  partition bit indicates "take
from previous crossbar or take from intermediate output".

interestingly we actually need that as a function in the vector predicate
mask code so if you can create a module for it that would be real handy.

i forget the standard name for it. sbf or something.  or sif.  set before
first, set including first.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


More information about the libre-riscv-dev mailing list