Re: [fpu] fdiv

[Rudolf Usselmann <rudi@inet.co.th>]

on 8/20/00 20:45, Jamil Khatib at jamilkhatib75@yahoo.com wrote:
>> 
>> Hmm, I believe post normalization should be done by
>> the individual
>> cores. May be we can combine it later.
>> 
> 
> But do not you think that some numbers should be left
> denormalized? you can refere to
> http://www.geocities.com/SiliconValley/Pines/6639/docs/fp_summary.html

Yes, that's correct. Some numbers can't be normalized.

> Anyhow if we do normalization after each operation
> where the denormalized numbers are going to come from?

Either from user input or as a result from a operation.

You have to normalize after each operation. The denormalized
outputs are exceptions.

> (fdiv takes the denormalized numbers)

It has to be able to accept both, normalized and denormalized.


>> 
>> I do mean rounding. When you divide 1 by 3 for
>> example,
>> you need to round properly.
>> This could probably be a separate block, except then
>> each
>> core (add/sub, mul, div) will have to provide some
>> additional
>> bits of the fraction. I think it would be easier for
>> now
>> to include that function in tot the individual cores
>> as well.
>> We can always later optimize and combine features.
>> 
> 
> 1/3 = 0.333333333..... until all bits are used. in
> this case no rounding is needed because you consumed
> all bits but when you downconvert the extended format
> (higher no. of bits) to the single format you need to
> decided how to remove the extra bits (rounding) thats
> why I think the rounding is done only when you convert
> from higher bits to lower one. every thing else should
> be done by the arithmetic operation itself
> (div,mul....)

OK, lets clarify terminolagy. When you say "extended" format
I'm thinking of 64+ bit floating point.

Every block need to do rounding. The output of the add/sub
unit before rounding and normalization is 27 bits. (one hidden
bit, 23 bits fraction, 3 extra bits for precision to do rounding).

Since the result of each floating point core is going back to the
register file, it has to be properly rounded.

Lets just agree that each block does it's own rounding for now.

>> 
>> You are welcome to attend my Verilog class mid
>> October in Bangkok !
>> 
> Thanks for your explaination and invitation but could
> you please tell me what is the difference from
> synthesis point of view?

No, synthesis does not care. But it's very important for simulation.

>>>> There is no need for a reset.
>>>> 
> 
> why ?

exactly: why ?

>> 
>> oops, forgot:
>> input [1:0]        round_mode;
>> 
> 
> Depends if we are going to round in the fdiv itself or
> a seperate core because you duplicate it for each
> execution unit in the FPU.

I realize we are duplicating for now, but it will simplify the
design phase. We can always combine later.


>> Ahm, there is no extended format. We only do single
>> precision
>> floating point.
> 
> I mean internal representation of the numbers

Internally the numbers are represented in the least number of
bit that are needed. For add/sub, 27 bit fraction, 8 bit exponent
before romlization/rounding.

> will you be updating the fmul soon?

No, probably not. I'm working on add/sub - trying to figure out
rounding.


> Thanks for your help
> Jamil Khatib
 

rudi