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

[Luke Kenneth Casson Leighton]

On Thursday, February 6, 2020, Michael Nolan <mtnolan2640 at gmail.com> wrote:

> Luke Kenneth Casson Leighton <lkcl at lkcl.net> writes:
>
> >
> > yes, because when the mask is [0b1111] this indicates to the unit test
> that there is only 1 number and that the partitioning is off.  therefore
> the correct answer is 0b0001 when comparing 0x0000 to 0x0000
> >
> > this being a bit complicated, the partition mask gets explicitly set to
> 0b0000 at line 112
> > https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/
> ieee754/part/test/test_partsig.py;h=29a26faabcbe38085eabf161beb75d
> 215c8851d0;hb=HEAD#l112
> >
> > 0xF would be the correct answer if all partitions were *on* i.e. the 16
> bit input was subdivided into four nibbles.
>
> I think we might be on different pages. The hardware is producing a
> result of 0x1 for (0x0000 == 0x0000) when the partition mask is 0b000
> (according to the VCD at least), but to me it looks like the test is
> *expecting* a value of 0xF.


yep you're right.  a "detect first bit set" function is needed, and to be
called at line 105


>
>
>
> > which i believe is correct here except zero assertions are missing here,
> line 60:
> > https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/
> ieee754/part_cmp/formal/proof_eq_gt_ge.py;h=1118bd444b59f643f182ed960d445a
> 11b0c121ca;hb=HEAD#l60
> >
> > assert out[1] == 0 and
> > assert out[2] == 0
> >
> > likewise further down
>
> Oops, yep I forgot those, they should be there in the latest commit.


great.


>
> --Michael
>


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