Re: [fpu] fdiv

[Jamil Khatib <jamilkhatib75@yahoo.com>]

> > 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.

Still I did not get your point.
it seems to me either to normalize or not to normalize
I can not make special cases

> 
> >> 
> >> 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.

this is called the double precision


> 
> 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).

as far as I know the minimum extended number of bits
that should be supported by IEEE is 32 bit for
fraction including the hidden bit  and 11 bit for
exponent

> 
> 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.
> 

OK but we will have more hardware

> >> 
> >> 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.
> 

are you sure in VHDL there is also some differences
thats why I am asking

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

to start from a defined state

> >> 
> >> 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.

OK in the next release we should start from the
documentation to get more effecient design without
duplication and confusions

> 
> 
> >> 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.
> 

see above note.

> > will you be updating the fmul soon?
> 
> No, probably not. I'm working on add/sub - trying to
> figure out
> rounding.
> 
> 

so let me know the results

> > Thanks for your help
> > Jamil Khatib
>  
> 
> rudi
> 

Jamil



__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/