I agree, there's a bug. I think it's in post_norm_mul.vhd, in the
process that sets s_shl2 and s_shr2 (starting around line 145 in my
copy, though I may have made cosmetic changes). It executes the code:

if s_exp_10b(9)='1' or s_exp_10b="0000000000" then
-- the first condition was true, s_exp_10b is "-22"
v_shr1:=(others=>'0');
v_shl1:=("0000"&s_zeros) - s_exp_10a;
-- s_zeros is the number of zeros before the first '1' in
-- the 48-bit product, not counting the carry bit, 23.
-- s_exp_10a is opa's exponent ("7f") plus opb's exponent
-- ("01") minus the bias ("7f") -> "01", plus 1 if the product
-- was too big (but it isn't in this case). So V_shl1 becomes
-- 22. That's wrong for this case.
s_expo1 <= "000000001";
-- that would be the right value for the exponent, but the
-- shift should be just zero.

I think the code should be doing different things for a negative
s_exp_10b. I don't have the fix though.

By the way, this is a confirmation that the millions of test vectors
are a waste of time, as I said
http://tech.groups.yahoo.com/group/32bit_fpu/message/99


39


--- In 32bit_fpu@yahoogroups.com, "rambo_jvmhw" <rambo_jvmhw@...> wrote:
>
>
> Now my problem is that the multiplication of denormalized numbers does
> not quite add up.
> Take for example the following two numbers
> 0x00000001 (1.4E-45) by 0x3F800000 (1.0) should equal the former
> (0x00000001) but the FPU produces 0x00400000 (which is 5.877E-39).
>
> (Notice that 0x400000 is 1.0 in the mantissa but that might be
> coincidence.)
>
> Could someone else please confirm that.
>