[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths

[bugzilla-daemon at libre-soc.org]

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

--- Comment #68 from Jacob Lifshay <programmerjake at gmail.com> ---
looking through the code, you got what part_counts is mixed up:
https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part/layout_experiment.py;h=1f0b761a019fae0fd0005a52649c5f5ad080bea2;hb=48f1e8c97dd4adc9d9161e362f389fbf70506033#l94
You wrote:
>  94     # for each element-width (elwidth 0-3) the number of partitions is given
>  95     # elwidth=0b00 QTY 1 partitions:   |          ?          |
>  96     # elwidth=0b01 QTY 1 partitions:   |          ?          |
>  97     # elwidth=0b10 QTY 2 partitions:   |    ?     |     ?    |
>  98     # elwidth=0b11 QTY 4 partitions:   | ?  |  ?  |  ?  | ?  |
>  99     # actual widths of Signals *within* those partitions is given separately
> 100     part_counts = {
> 101         0: 1,
> 102         1: 1,
> 103         2: 2,
> 104         3: 4,
> 105     }


part_counts is actually a dict from elwid values to the number of parts *in a
single lane*, *not* the number of parts in the whole SIMD signal.

So, for the ALU's inputs/outputs (for the integer ALUs), part_counts' values
are the number of bytes (since a byte is the smallest integer elwid) in each
elwid type:
part_counts = {
    IntElWid.I8: 1, # i8 takes 1 byte
    IntElWid.I16: 2, # i16 takes 2 bytes
    IntElWid.I32: 4, # i32 takes 4 bytes
    IntElWid.I64: 8, # i64 takes 8 bytes
}

For the FP ALUs' inputs/outputs, part_counts' values are the number of 16-bit
words, since the smallest FP elwid is 16-bits:
part_counts = {
    FpElWid.F16: 1, # f16 takes 1 16-bit word
    FpElWid.BF16: 1, # bf16 takes 1 16-bit word
    FpElWid.F32: 2, # f32 takes 2 16-bit words
    FpElWid.F64: 4, # f64 takes 4 16-bit words
}

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