Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20687 Discussions

ALTERA_FP_FUNCTIONS Single Precision Multiplier doesn't seem to support subnormal numbers

ZAhma1
Beginner
735 Views

I am trying to use a Single Precision Floating Point multiplier as generated by QSys in Quartus Prime 16.1.2. We are using an Arria 10 device so the option I have is to use the ALTERA_FP_FUNCTIONS module.

 

After running some tests, I found that the device doesn't support the entire range of IEEE 754 numbers, specifically the subnormal (or denormal numbers). If the IP encounters a subnormal number, it sets the output to 0. This produces incorrect results especially if the output is to be fed into another IP like a multiplier (or divider), causing an error that propagates.

 

Is there a solution to this problem? Are there any updates to the ALTERA_FP_FUNCTION IP to provide subnormal number support? Would moving to Quartus 19 help solve the issue?

0 Kudos
1 Solution
AnandRaj_S_Intel
Employee
559 Views

Yes, I got the problem.

However Altera floating-point IP cores do not support denormal/subnormal  number inputs. If the input is a denormal value, the IP core forces the value to zero and treats the value as a zero before going through any operation.

 

Hence we are seeing output zero.

 

Regards

Anand

View solution in original post

0 Kudos
7 Replies
AnandRaj_S_Intel
Employee
559 Views

Hi Ahmad,

 

You have to check the output of ALTERA_FP_FUNCTION when valid signal is high.

you can check with example design from user guide

Please share you design or image.

 

Regards

Anand

0 Kudos
ZAhma1
Beginner
559 Views

Hi Anand,

 

As you may be aware with most FPGA IPs, there is no data valid signal. You just have to wait the suggested number of cycles and hope the output is correct.

 

I've created a sample project with the IP in question and also added a testbench which will run the problem cases. I'll attach them here.

0 Kudos
ZAhma1
Beginner
559 Views

And here is the testbench

0 Kudos
AnandRaj_S_Intel
Employee
559 Views

Hi Ahmad,

 

Check your testbench rest signal. Its is not properly handled and also reset is active high.

without testbench IP works as expected.

 

Regards

Anand

fp_mul.JPG

0 Kudos
ZAhma1
Beginner
559 Views

Hi Anand,

 

I don't understand what you mean by "reset is not properly handled". The testbench applies an active high reset at the start after which the test begins and reset is pulled low. I see you've done the same thing in your test.

 

Also if you see the testbench there are three tests. Test 1 is *supposed* to pass. This is the same output in your run and my testbench.

report( lf & "------------------ TEST 1 ------------------------" & lf & " This should pass" ); wait until falling_edge(s_clk); s_a <= X"3fc00000"; -- 1.5 s_b <= X"3fc00000"; -- 1.5 expected_q := X"40100000"; -- 2.25

 

Test 2 and 3 fail with the IP. These are the tests that show the IP doesn't support subnormal numbers. But you don't seem to have run these tests.

 

report( lf & "------------------ TEST 2 ------------------------" & lf & " Multiply subnormal number to a regular number" & lf & " The output should be a regular number, but will likely be 0" & lf & " This will probably fail" ); wait until falling_edge(s_clk); s_a <= X"00781136"; -- 1.10264e-38 (subnormal) s_b <= X"3fc00000"; -- 1.5 (not subnormal) expected_q := X"01ba0cf5"; -- 6.83442e-38 (not subnormal) report( lf & "------------------ TEST 3 ------------------------" & lf & " Multiply two regular numbers that should produce a subnormal number" & lf & " The output should be a subnormal number, but will likely be 0" & lf & " This will probably fail" ); wait until falling_edge(s_clk); s_a <= X"1ff7f0d6"; -- 1.05007e-19 (not subnormal) s_b <= X"1ff7f0d6"; -- 1.05007e-19 (not subnormal) expected_q := X"00781150"; -- 1.10265e-38 (subnormal)  

 

 

 

0 Kudos
AnandRaj_S_Intel
Employee
560 Views

Yes, I got the problem.

However Altera floating-point IP cores do not support denormal/subnormal  number inputs. If the input is a denormal value, the IP core forces the value to zero and treats the value as a zero before going through any operation.

 

Hence we are seeing output zero.

 

Regards

Anand

0 Kudos
ZAhma1
Beginner
559 Views

OK. That's what I thought. Thanks for clarifying.

 

Thanks!

--Zohair

0 Kudos
Reply