[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
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
> If so, that seems reasonable.
> > 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
> 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.
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the libre-riscv-dev