RE: [fpu] Add/Sub Unit Test Vectors

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

> From: owner-fpu@opencores.org [mailto:owner-fpu@opencores.org]On Behalf
> Of Jamil Khatib
> Subject: Re: [fpu] Add/Sub Unit Test Vectors 
> 
....
> 
> I was not thinking of your code in this way but it
> seems the same as my idea except how do you enter the
> values to the C code.
> 
> > There will be as many lines as the user requested
> > from the C
> > program. Each line is one test vector.
> 
> Are The test  going to begenerated automatically
> "randomly" or user will enter each value?

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

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

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

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

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 

rudi