Int to float

[hamster_nz]

Attached is some C code that compares:

- Generates 256 random complex numbers, between +/-2^23
- FFTs using doubles
- FFTs using floats
- FFTs using fixed point (implemented using "long longs") also using scaled sine/cos values.
- Prints the results

No external libraries are used - so "gcc -o my_fft my_fft.c -lm" will work.

Code: [Select]

Input integer data ranges from -8341031 to 8386818
Transform of   256 random complex numbers
=========================================
bin  ====  Doubles ==========  ==== Floats ===========  == err (double-float) ==  ====== Fixed point ====  == err (double-fixed) ==
  0, (-311468.32, -113157.76), (-311468.34,-113157.78), (      0.02,      0.02), (-311468.25,-113157.75), (      0.07,       0.01)
  1, (-450432.59,   73399.90), (-450432.56,  73399.89), (      0.03,      0.01), (-450432.25,  73399.75), (      0.34,       0.15)
  2, (  67731.35, -153482.60), (  67731.34,-153482.58), (      0.01,      0.03), (  67731.25,-153482.50), (      0.10,       0.10)
  3, ( 217357.98,  225662.18), ( 217357.98, 225662.14), (      0.01,      0.04), ( 217357.75, 225661.75), (      0.23,       0.43)
  4, (  83580.10,  536216.31), (  83580.08, 536216.31), (      0.03,      0.00), (  83580.00, 536216.00), (      0.10,       0.31)
  5, (  28770.92, -132197.57), (  28770.92,-132197.56), (      0.00,      0.01), (  28770.75,-132197.50), (      0.17,       0.07)
...
You can play with scaling factors on the double => fixed point conversion, as well has the scaling factor used in the sine / cosine table, and see what effects it has on the errors.

[BrianHG]

Maybe somebody (ie the OP) should write some code and evaluate its performance?

Not HDL, just C or Python or something... they will most likely need to do this for validation of their design anyway.

Maybe if they can give us a file with representative data we can write our own and report back.

Attached is some C code that compares:
....

Are you trapped in the C19 zone... I've also been doing a ton of things for the 8bit GPU thread.

[hamster_nz]

Are you trapped in the C19 zone... I've also been doing a ton of things for the 8bit GPU thread.

Not as much as trapped, more loitering with intent and actively looking for trouble.

It is a slow Sunday, and I happened to have some FFT code handy....

[ali_asadzadeh]

Guy thanks all for the feedback

My issue is where do you get a divide for GOWIN?  I know all the math routines, floating point and fixed point are all available for Altera FPGAs, including sine/cos/tan/square root/complex plane multiply, but, I never had to deal with a vendor limiting my ability to do basic math before as well as int<>float conversion unless we are talking over 15 years ago.

Gowin has lost of good IP cores, You can check a list in the attached pictures, But it does not have anything for floating points,
I managed to find several good Open FPU out there,
like this ones
https://opencores.org/projects/fpu100


Also I'm doing verilog or systemverilog , since it's very much like C and I have more than 20 year experince in C, though this is the first serious Big project I'm doing on a FPGA and I choose Gowin because of it's price and because the end result is a comercial product and it needed to be as cheap as possible.

oh, And I found this new link, it's super fantastic, It has all kind of float that you need!
https://github.com/dawsonjon/verilog-math

Though there is one minor problem, the python scripts do not run! but hopefully all the code is generated already.
I tried them in my command prompt like this

python float.py

And I can run this simple python script tough,

Code: [Select]

print("ASiDesigner")

I have very limited experience in python, like a beginner. so maybe I'm doing something wrong.

[BrianHG]

In you second photo IP, you have a fixed point divider.  So, I don't see your problem...
Just set the width and the fraction bits position to where you like and divide away...

Altera's LPM_DIVIDE has the same controls & I'm sure Xilinx also has the same.  It just calling the instance & parameter names will be different.

Multiply can be done straight inline in verilog, only divide was an issue.

In fact, you have a fir filter there as well as complex domain multiply.  Only the floating point and trig functions are missing.

[BrianHG]

Using this guy means you wont have to worry about converting between ints and floats, but you still get the floating point support, less gates and less clock cycles:  (However, you highest number is 29bits, and your smallest fraction is -24bits, way above what you seem to need.)
https://opencores.org/projects/qfp32

[ali_asadzadeh]

Thanks, Now all the pieces of the puzzle that I needed are complete, I'm writing the FSM for the whole DSP part For now,
Thanks for your help and support, I think I will post some results with in a few hours.

[rs20]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

[BrianHG]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

That's a nasty trick... I like... 

And it does work for 24bit signed integers, as in you feed the absolute value 23 bit int while feeding the sign/polarity, bit 24 into bit 32.

[ali_asadzadeh]

The Attached file contains the Synthesize  and max clock Frequency for some of the operations, I wonder if I could find a low resource 24-bit 256 bin FFT core and a faster CORDIC core so I can Increase the overall system Clock.

[gnuarm]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

Only works for IEEE format.  I'm not bothering with IEEE format because it is great overkill for my task. 

Interesting idea though.  Thing is, it's not really any less logic.  A direct to FP conversion uses all the same circuitry as the IEEE math, just programmed to do the conversion without the math.  In the general case it would use the adder because the adder has to support the full range of shifting while a multiply uses much less shifting unless it is designed to handle denorm numbers like in IEEE format, if the full spec is implemented.  I'm not implementing NaN either.

[BrianHG]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

Only works for IEEE format.  I'm not bothering with IEEE format because it is great overkill for my task. 

Funny, the cores the OP is looking at are IEEE format.

[SiliconWizard]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

That's a nasty trick... I like... 

And it does work for 24bit signed integers, as in you feed the absolute value 23 bit int while feeding the sign/polarity, bit 24 into bit 32.

But you still need a FP multiplier. That's not cheap. Isn't just scaling, which is the main (and only?) thing needed here for int to FP conversion (unless I missed something), much simpler than a full multiplier?
(Of course if you already have the multiplier, that's a moot point.)

[BrianHG]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

That's a nasty trick... I like... 

And it does work for 24bit signed integers, as in you feed the absolute value 23 bit int while feeding the sign/polarity, bit 24 into bit 32.

But you still need a FP multiplier. That's not cheap. Isn't just scaling, which is the main (and only?) thing needed here for int to FP conversion (unless I missed something), much simpler than a full multiplier?
(Of course if you already have the multiplier, that's a moot point.)

Just a few posts up, we have the op linked to a full FP 754 unit and I added a link to a limited one with the range of 2^-24 to 2^29 exponent floating point unit which only takes 2 clocks to add/subtract/multiply & 31 clocks to divide, but uses less gates, less FPGA resources.

[hamster_nz]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

That's a nasty trick... I like... 

And it does work for 24bit signed integers, as in you feed the absolute value 23 bit int while feeding the sign/polarity, bit 24 into bit 32.

But you still need a FP multiplier. That's not cheap. Isn't just scaling, which is the main (and only?) thing needed here for int to FP conversion (unless I missed something), much simpler than a full multiplier?
(Of course if you already have the multiplier, that's a moot point.)

Just a few posts up, we have the op linked to a full FP 754 unit and I added a link to a limited one with the range of 2^-24 to 2^29 exponent floating point unit which only takes 2 clocks to add/subtract/multiply & 31 clocks to divide, but uses less gates, less FPGA resources.

I am left wondering, is it common for FP units to have specific optimizations for "divide by a power of two", or is there too many corner cases to make it worthwhile...

[gnuarm]

Just to troll and make people cry out in pain, how about this idea to the OP's question:

For int value x, create the denormal number x * 2^(-126) (which is easy to create with simple wiring directly & without scanning for a leading 1, because it's guaranteed denormal*), and then just pass it through a float32 multiplier with a hard-coded float32 value 2^126. Hoorah, an int-to-float32 converter with naught but simple wiring and a dead standard float32 multiplier unit!

I'll see myself out.

PS/ * Yes, I know this only works for 23 bit integers, not 24 bit integers. :-)

That's a nasty trick... I like... 

And it does work for 24bit signed integers, as in you feed the absolute value 23 bit int while feeding the sign/polarity, bit 24 into bit 32.

But you still need a FP multiplier. That's not cheap. Isn't just scaling, which is the main (and only?) thing needed here for int to FP conversion (unless I missed something), much simpler than a full multiplier?
(Of course if you already have the multiplier, that's a moot point.)

Not sure.  It greatly depends on the design of the floating point multiplier.  My present design uses a fixed point multiplier and an accumulator to perform all the operations for floating point other than the manipulations of the exponent and sign bit and a 2 input mux to shift the scale for normalizing vs. denormalizing. 

The multiplier is a logic block in an FPGA, while a barrel shifter has to be made from the fabric (unless the tools are very crafty).  It's a bit analogous to the DFT vs. the FFT.  If you need all the possible shifts or frequency bins, then you use the multiplier or FFT.  If you only need a few possible shifts or frequency bins then you use the mux or the DFT.