RE: [fpu] Add/Sub Unit Test Vectors

[Jamil Khatib <jamilkhatib75@yahoo.com>]

> The C program will randomly generate the values.
> Some of the options to the C program will be to
> suppress/request
> generations of INF and NAN 'numbers'.

thats fine;

> 
> > what Do you think about the parsing of the
> commands in
> > C? what types of commands you want? (operation &
> > values )
> 
> Here is what I sent to Damjan in an previous email:
> 
> The C program should take the following arguments:
> 
> - operation type(s) any combination of
> add,sub,mul,div
> - suppress/generate INF
> - suppress/generate NAN
> - suppress generate denormalized numbers ?????
> - perhaps others ....

I'd suggest to add an option to enter formelae in
order to test some special equations that are known to
give some expected results.

> 
> > but the errors are excpected to be much less and
> you
> > do not need always to check the bits (32 or may be
> > later 80)
> 
> That is correct.

So I'd suggest to add it to teh spec

>  
> > So lets stay generic and high performance side,
> agree?
> 
> I would rather use the following two definitions:
> a) Performance optimized
> b) Area optimized
> 
> I would like to classify the cores I'm building as
> performance
> tuned.
> 
> > But I think you can get some good performance with
> > piplined architecutres on FPGAs
> 
> Terms such as "good performance" and high
> performance" etc. are
> subjective.
> You will have difficulties to get the FASU core
> running in an FPGA
> at 400Mhz. The way the FASU core is today, it will
> already run in
> an FPGA at 40Mhz (Xilinx Virtex -4).
> 
> The point was that a FPGA implementation might not
> really want an
> Performance tuned unit, but rather a Area tuned
> unit, as Area constrains
> are typically more critical in FPGAs. Of course this
> is all subjective,
> and up to the end user to choose which core s/he
> wants.

I agree with you on that
> 
> > This template is only a guid line not a must
> 
> fine
> 
> > One thing we should consider in all cores that we
> have
> > to support larger internal sizes (more than 23) or
> to
> > support double precision internally to allow
> > compatiblility with the IEEE std calculations and
> > results. "I'll give more information about this
> point
> > later"
> 
> This is only 50% correct.
> 

Sorry I meant to say to support the extended format
not double. This is a requierment by IEEE std.
and It is also logical to make calculations on large
bits more than your representation, the old
calculators for example displays10 digits but
calculates internally upto 13 digit.

There are some reasons for that, for IEEE std this is
needed to determine exact and inexact numbers.

>From math point of view you will have error in the
last digit due to rounding and since your result have
to be correct you should user higher no of digits.

> The only reason we need "higher resolutions"
> internally, is for
> accuracy. Nothing to do with double precision. For
> double precision,
> you have to do exactly the same. There is also
> nothing in IEEE that
> says you need to implement a double precision core
> to achieve single
> precision. So, depending on the function you will
> have to add a few
> bits to the fraction, and then round properly.
> 
Regards
Jamil Khatib 




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