[libre-riscv-dev] [Bug 132] SIMD-like nmigen signal for partitioning

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=132

--- Comment #9 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #8)
> https://forum.m-labs.hk/d/20-simd-partitionable-version-of-signal

we just need to give in -- it will be massively invasive because we need to
handle partitioning properly for things like multiply-by-small-constant,
extract sign bit, and all the other operations where we need to handle things
on a per-partition basis and don't just call add, xor, etc.

If we use the partition API where every Signal is converted to
PartitionedSignal, which is conceptually a Signal with a PartitionPoints, it
allows optimizing for the case where it is statically known at instantiation
time that only certain bit-positions will ever be partition boundaries. using a
straight mask won't allow that and PartitionPoints has a method to generate a
mask if needed.

the partitioned adder uses the above partition information to avoid inserting
the extra bits used for stopping carry propagation where not needed. if
PartitionedAdder was just given a mask, it would have to assume every bit could
be in a separate partition and would end up with a final adder twice as wide as
needed.

we should make a subtype of PartitionedPoints
(NaturallyAlignedPartitionPoints?) that guarantees that all partitions at both
instantiation and runtime are all power-of-2-sized and are naturally aligned
(start at a bit index that is a multiple of their size). This is required for
the current multiplier implementation, and by requiring N.A.P.P. instead of
just PartitionPoints, we allow the divider and other ALUs to have a way to
check at instantiation time that the partitions only partition down to the byte
level and that they don't ever have to handle a 24 or 40-bit partition, for
example.

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