VHDL: Why is it hard to design a floating point unit in hardware?Any good reference for digital architecture implementations of floating point arithmetic operations?Digital Architecture Design Question: Fast way to perform a floating point exponential operationHow to convert a floating point number to integer, using VHDL?VHDL 2008 fixed and floating point type synthesis support?Microcontrollers with Floating Point HardwareWhy is Floating point non-synthesizable in verilogSTM32F4 - Floating point unit ( FPU )FPGA Floating-point to Unsigned 32bitsSTM32 non floating point unit chipsfloating point conversion VHDL 2008
Team member is vehemently against code formatting
What is this dime sized black bug with white on the segments near Loveland Colorodao?
size of pointers and architecture
Why is this integration method not valid?
A nasty indefinite integral
DeleteCases using two lists but with partial match?
Is the default 512 byte physical sector size appropriate for SSD disks under Linux?
How to safely discharge oneself
How to become an Editorial board member?
What was the primary motivation for a historical figure like Xenophon to create an extensive collection of written material?
What defines a person who is circumcised "of the heart"?
Department head said that group project may be rejected. How to mitigate?
Is there any mention of ghosts who live outside the Hogwarts castle?
Is there a word for pant sleeves?
Split into three!
Proto-Indo-European (PIE) words with IPA
Why do testers need root cause analysis?
Why "strap-on" boosters, and how do other people say it?
Is it OK to look at the list of played moves during the game to determine the status of the 50 move rule?
Can the Conjure Barrage spell stack with the Disarming Attack or Trip Attack Battle Master maneuvers?
Nunc est bibendum: gerund or gerundive?
(For training purposes) Are there any openings with rook pawns that are more effective than others (and if so, what are they)?
Meaning of "half-crown enclosure"
How does the Earth's center produce heat?
VHDL: Why is it hard to design a floating point unit in hardware?
Any good reference for digital architecture implementations of floating point arithmetic operations?Digital Architecture Design Question: Fast way to perform a floating point exponential operationHow to convert a floating point number to integer, using VHDL?VHDL 2008 fixed and floating point type synthesis support?Microcontrollers with Floating Point HardwareWhy is Floating point non-synthesizable in verilogSTM32F4 - Floating point unit ( FPU )FPGA Floating-point to Unsigned 32bitsSTM32 non floating point unit chipsfloating point conversion VHDL 2008
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
Floating point calculation basically involves representing units in a scientific notation and then deciding how many bits to devote to the manitssa and exponent. Therefore, all calculations involving FP numbers involve these two quanities which must be manipulated. This sounds simple enough and is not hard to do on paper.
I have always come across description of floating point hardware design as being difficult and heard/read things like multiplying and dividing a number by 1 may not give the same result. This perhaps has something to do with how numbers are "unrolled" when arithmetic is to be performed.
Shouldn't there be a unified approach to how floating point hardware is designed in hardware? Why is design and verification of such a hardware considered to be difficult and challenging in spite of there being IEEE 754?
fpga vhdl floating-point
edited 26 mins ago
Ken Williams
1032
asked 9 hours ago
quantum231quantum231
4,0211562122
$endgroup$
|
show 3 more comments
$begingroup$
Floating point calculation basically involves representing units in a scientific notation and then deciding how many bits to devote to the manitssa and exponent. Therefore, all calculations involving FP numbers involve these two quanities which must be manipulated. This sounds simple enough and is not hard to do on paper.
I have always come across description of floating point hardware design as being difficult and heard/read things like multiplying and dividing a number by 1 may not give the same result. This perhaps has something to do with how numbers are "unrolled" when arithmetic is to be performed.
Shouldn't there be a unified approach to how floating point hardware is designed in hardware? Why is design and verification of such a hardware considered to be difficult and challenging in spite of there being IEEE 754?
fpga vhdl floating-point
edited 26 mins ago
Ken Williams
1032
asked 9 hours ago
quantum231quantum231
4,0211562122
$endgroup$
3
$begingroup$
ieee 754 tells you what the results must be, not how to do it. If you can come up with a quicker way to get exactly the same results, then you could sell your idea to chip manufacturer. The payoff for them is they could reduce their chip area and so improve yield. You know there are several ways to multiply two numbers together, right? One or another might be a better fit for your process. Start with schoolbook, and improve with various clever factorisations and identities.
$endgroup$
– Neil_UK
9 hours ago
$begingroup$
I assume this would be a major area of research and people come with new methods from time to time?
$endgroup$
– quantum231
9 hours ago
2
$begingroup$
I imagine because there are a lot of design tradeoffs and objectives that can be prioritized because no only are you working with logic on paper, you're also working with silicon gates. It's like op-amps...they all do the same thing yet no standard design with thousands of varieties.
$endgroup$
– Toor
9 hours ago
3
$begingroup$
IEEE 754 makes it harder to implement, not easier. Just look at Xilinx offering and their deviation from 754: xilinx.com/support/documentation/ip_documentation/… There are many corner cases to handle for floating point
$endgroup$
– Jonathan Drolet
9 hours ago
$begingroup$
Bipolar Integrated Technology (aka BIT) fielded ASIC chips that provided floating point done just as you suggest. That would be prior to 1990, as I was working with one of the engineers from there on a separate project using the MIPS R2000 around 1987-ish. I cannot say how complete they were in terms of implementing IEEE 754, though. I'm pretty sure they didn't implement the full specification. BIT was located in the Beaverton, Oregon area.
$endgroup$
– jonk
9 hours ago
|
show 3 more comments
$begingroup$
Floating point calculation basically involves representing units in a scientific notation and then deciding how many bits to devote to the manitssa and exponent. Therefore, all calculations involving FP numbers involve these two quanities which must be manipulated. This sounds simple enough and is not hard to do on paper.
I have always come across description of floating point hardware design as being difficult and heard/read things like multiplying and dividing a number by 1 may not give the same result. This perhaps has something to do with how numbers are "unrolled" when arithmetic is to be performed.
Shouldn't there be a unified approach to how floating point hardware is designed in hardware? Why is design and verification of such a hardware considered to be difficult and challenging in spite of there being IEEE 754?
fpga vhdl floating-point
edited 26 mins ago
Ken Williams
1032
asked 9 hours ago
quantum231quantum231
4,0211562122
$endgroup$
Floating point calculation basically involves representing units in a scientific notation and then deciding how many bits to devote to the manitssa and exponent. Therefore, all calculations involving FP numbers involve these two quanities which must be manipulated. This sounds simple enough and is not hard to do on paper.
I have always come across description of floating point hardware design as being difficult and heard/read things like multiplying and dividing a number by 1 may not give the same result. This perhaps has something to do with how numbers are "unrolled" when arithmetic is to be performed.
Shouldn't there be a unified approach to how floating point hardware is designed in hardware? Why is design and verification of such a hardware considered to be difficult and challenging in spite of there being IEEE 754?
fpga vhdl floating-point
fpga vhdl floating-point
edited 26 mins ago
Ken Williams
1032
asked 9 hours ago
quantum231quantum231
4,0211562122
edited 26 mins ago
Ken Williams
1032
asked 9 hours ago
quantum231quantum231
4,0211562122
edited 26 mins ago
Ken Williams
1032
edited 26 mins ago
Ken Williams
1032
edited 26 mins ago
Ken Williams
1032
1032
asked 9 hours ago
quantum231quantum231
4,0211562122
asked 9 hours ago
quantum231quantum231
4,0211562122
asked 9 hours ago
quantum231quantum231
4,0211562122
4,0211562122
3
$begingroup$
ieee 754 tells you what the results must be, not how to do it. If you can come up with a quicker way to get exactly the same results, then you could sell your idea to chip manufacturer. The payoff for them is they could reduce their chip area and so improve yield. You know there are several ways to multiply two numbers together, right? One or another might be a better fit for your process. Start with schoolbook, and improve with various clever factorisations and identities.
$endgroup$
– Neil_UK
9 hours ago
$begingroup$
I assume this would be a major area of research and people come with new methods from time to time?
$endgroup$
– quantum231
9 hours ago
2
$begingroup$
I imagine because there are a lot of design tradeoffs and objectives that can be prioritized because no only are you working with logic on paper, you're also working with silicon gates. It's like op-amps...they all do the same thing yet no standard design with thousands of varieties.
$endgroup$
– Toor
9 hours ago
3
$begingroup$
IEEE 754 makes it harder to implement, not easier. Just look at Xilinx offering and their deviation from 754: xilinx.com/support/documentation/ip_documentation/… There are many corner cases to handle for floating point
$endgroup$
– Jonathan Drolet
9 hours ago
$begingroup$
Bipolar Integrated Technology (aka BIT) fielded ASIC chips that provided floating point done just as you suggest. That would be prior to 1990, as I was working with one of the engineers from there on a separate project using the MIPS R2000 around 1987-ish. I cannot say how complete they were in terms of implementing IEEE 754, though. I'm pretty sure they didn't implement the full specification. BIT was located in the Beaverton, Oregon area.
$endgroup$
– jonk
9 hours ago
|
show 3 more comments
3
$begingroup$
ieee 754 tells you what the results must be, not how to do it. If you can come up with a quicker way to get exactly the same results, then you could sell your idea to chip manufacturer. The payoff for them is they could reduce their chip area and so improve yield. You know there are several ways to multiply two numbers together, right? One or another might be a better fit for your process. Start with schoolbook, and improve with various clever factorisations and identities.
$endgroup$
– Neil_UK
9 hours ago
$begingroup$
I assume this would be a major area of research and people come with new methods from time to time?
$endgroup$
– quantum231
9 hours ago
2
$begingroup$
I imagine because there are a lot of design tradeoffs and objectives that can be prioritized because no only are you working with logic on paper, you're also working with silicon gates. It's like op-amps...they all do the same thing yet no standard design with thousands of varieties.
$endgroup$
– Toor
9 hours ago
3
$begingroup$
IEEE 754 makes it harder to implement, not easier. Just look at Xilinx offering and their deviation from 754: xilinx.com/support/documentation/ip_documentation/… There are many corner cases to handle for floating point
$endgroup$
– Jonathan Drolet
9 hours ago
$begingroup$
Bipolar Integrated Technology (aka BIT) fielded ASIC chips that provided floating point done just as you suggest. That would be prior to 1990, as I was working with one of the engineers from there on a separate project using the MIPS R2000 around 1987-ish. I cannot say how complete they were in terms of implementing IEEE 754, though. I'm pretty sure they didn't implement the full specification. BIT was located in the Beaverton, Oregon area.
$endgroup$
– jonk
9 hours ago
3
3
$begingroup$
ieee 754 tells you what the results must be, not how to do it. If you can come up with a quicker way to get exactly the same results, then you could sell your idea to chip manufacturer. The payoff for them is they could reduce their chip area and so improve yield. You know there are several ways to multiply two numbers together, right? One or another might be a better fit for your process. Start with schoolbook, and improve with various clever factorisations and identities.
$endgroup$
– Neil_UK
9 hours ago
$begingroup$
ieee 754 tells you what the results must be, not how to do it. If you can come up with a quicker way to get exactly the same results, then you could sell your idea to chip manufacturer. The payoff for them is they could reduce their chip area and so improve yield. You know there are several ways to multiply two numbers together, right? One or another might be a better fit for your process. Start with schoolbook, and improve with various clever factorisations and identities.
$endgroup$
– Neil_UK
9 hours ago
$begingroup$
I assume this would be a major area of research and people come with new methods from time to time?
$endgroup$
– quantum231
9 hours ago
$begingroup$
I assume this would be a major area of research and people come with new methods from time to time?
$endgroup$
– quantum231
9 hours ago
2
2
$begingroup$
I imagine because there are a lot of design tradeoffs and objectives that can be prioritized because no only are you working with logic on paper, you're also working with silicon gates. It's like op-amps...they all do the same thing yet no standard design with thousands of varieties.
$endgroup$
– Toor
9 hours ago
$begingroup$
I imagine because there are a lot of design tradeoffs and objectives that can be prioritized because no only are you working with logic on paper, you're also working with silicon gates. It's like op-amps...they all do the same thing yet no standard design with thousands of varieties.
$endgroup$
– Toor
9 hours ago
3
3
$begingroup$
IEEE 754 makes it harder to implement, not easier. Just look at Xilinx offering and their deviation from 754: xilinx.com/support/documentation/ip_documentation/… There are many corner cases to handle for floating point
$endgroup$
– Jonathan Drolet
9 hours ago
$begingroup$
IEEE 754 makes it harder to implement, not easier. Just look at Xilinx offering and their deviation from 754: xilinx.com/support/documentation/ip_documentation/… There are many corner cases to handle for floating point
$endgroup$
– Jonathan Drolet
9 hours ago
$begingroup$
Bipolar Integrated Technology (aka BIT) fielded ASIC chips that provided floating point done just as you suggest. That would be prior to 1990, as I was working with one of the engineers from there on a separate project using the MIPS R2000 around 1987-ish. I cannot say how complete they were in terms of implementing IEEE 754, though. I'm pretty sure they didn't implement the full specification. BIT was located in the Beaverton, Oregon area.
$endgroup$
– jonk
9 hours ago
$begingroup$
Bipolar Integrated Technology (aka BIT) fielded ASIC chips that provided floating point done just as you suggest. That would be prior to 1990, as I was working with one of the engineers from there on a separate project using the MIPS R2000 around 1987-ish. I cannot say how complete they were in terms of implementing IEEE 754, though. I'm pretty sure they didn't implement the full specification. BIT was located in the Beaverton, Oregon area.
$endgroup$
– jonk
9 hours ago
|
show 3 more comments
3 Answers
3
active
oldest
votes
$begingroup$
The standard is well designed and there are subtle details that ease implementation, for example, when rounding, the carry from the mantissa can overflow to the exponent. Or integer comparisons can be used for floating point compares...
But, an FPU is a big heap of combinatorial mess, besides adding, multiplying, dividing, there are barrel shifters to align matissas, leading zeros counters, rounding, flags (imprecise, overflow, ...), NaN and denormals (which need additional hardware for calculations, particularly for mul/div, or at least trigger an exception for software emulation).
And most FPUs also need to do conversions to/from integer and between formats (float,double). That conversion hardware can be mostly implemented through existing floating point hardware, but it incurs additional multiplexers and special cases...
Then, there is pipelining. Depending on the transistor budget and frequency, either add/sub/mul can have the same throughput, or double precision can be slower, which can incur additional complexity in the pipeline. Modern FPU now have a pipelined multiply-add operator.
For division, it is always iterative, it can be a separate unit or reuse the multiplier-adder for Newton-Raphson or Goldshmidt. And while you are busy making a divider, you look for ways to tweak it for square roots...
Validation is complex because there are many corner cases. There are a few systematic test suites with test patterns for "interesting" cases about all the rounding modes but things like fast multipliers or dividers are too complex to test easily.
Iterative dividers can have non obvious bugs (for example the famous Pentium bug in its SRT radix 4 divider), multiplicative (Newton) are difficult to test exact rounding (some bugs in old IBM computers).
Formal methods are now used to prove these parts.
Modern FPUs also implement SIMD hardware, where FP operators are instantiated several times for parallel processing.
There is also the case of the x87 and MC68881/2 FPUs which can calculate decimal conversions, hyperbolic and trigonometric operations. These operations are microcoded and use basic FP operators, they are not directly implemented in hardware.
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
$endgroup$
$begingroup$
The Standard suffers a bit from trying to serve all purposes, and thus being too complicated to serve some while lacking features needed to serve others. For example, questions about the cases when it should guarantee "perfectly" rounded results were based upon whether that would be possible, rather than upon whether the costs would be worth the benefits for all applications. For many purposes, a computation that yields a result within two units in the last place would be more useful than one which yields a perfectly-rounded result but takes twice as long,...
$endgroup$
– supercat
5 hours ago
$begingroup$
...and on many implementations, computing a result within two ULP would take less than half as long as computing a perfectly-rounded result (as a simple example, computingx*(1/1.234567)will yield a value within a couple ulp ofx/1.234567, but will be much faster than computing the latter value). There are times when perfect rounding is useful or even necessary, but having a means of specifying when it isn't necessary would also have been useful.
$endgroup$
– supercat
5 hours ago
$begingroup$
@supercat Yes. For things like divisions, inverse square root... they are often implemented for graphics using pipelined Newton-Raphson on the FPU multiply-add hardware. Denormals are often flushed to zero (for example in DSPs, GPUs). The default rounding mode "round to nearest-even" is slighly easier to implement than the other modes (to infinity, to zero), because of rounding, so sometimes it is the only mode available.
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
The standard was designed by a Mathematician, W. Kahan, and tried to address the shortcomings of previous formats, notably DEC VAX. The first implementation, the 8087, was a rather slow implementation but with extended precision and lots of microcode for a "math library in a chip".
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
I've read some of Kahan's papers, and in most cases where things have evolved contrary to what Kahan advocated, I think Kahan's approach would have been better, but he did make a few mistakes. I think the Standard would have benefited from having an unsigned zero along with signed infinitesimals; 1/(tiny * tiny) should yield +Inf, but 1/0 should yield NaN, to avoid the asymmetry with zero. Still, parts of the Standard fail to consider that cost/benefit trade-offs are different in different kinds of application.
$endgroup$
– supercat
2 hours ago
add a comment |
$begingroup$
Having a look on opencores might give some hints e.g.: https://opencores.org/websvn/filedetails?repname=openfpu64&path=%2Fopenfpu64%2Ftrunk%2Ffpu_mul.vhd
The trouble with floating point is the large number of annoying corner cases. Integer operations have no concept of NaN, but it appears a lot in floating point. Numbers must also be normalised and denormalised correctly.
answered 9 hours ago
pjc50pjc50
34.6k34288
$endgroup$
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
9 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
9 hours ago
$begingroup$
@quantum231 yes, that's why pjc50 used that code snippet to illustrate why floating point is hard to do right: It's a humongous mess of handling special conditions.
$endgroup$
– Marcus Müller
9 hours ago
$begingroup$
Well, any nontrivial design will be complex and have a lot of conditions to be met. I shall study the code in detail later.
$endgroup$
– quantum231
7 hours ago
add a comment |
$begingroup$
Even if you don't handle all the corner cases, floating-point addition or subtraction of two well-formed numbers requires significant logic, because the scale of the mantissa can dramatically change -- consider the problem (in decimal) of the problem 1.9999 - 1.9993 = 0.0007. In floating point the location of the decimal point must be discovered, which isn't trivial, and the mantissa and exponent adjusted. This is even without trying to deal with NaN or denormalized numbers.
All the mention of handling the special cases is quite valid, but even if you put the onus of avoiding special cases on the system designer (which is not uncommon with floating-point IP intended for DSP applications), your floating point arithmetic is still more expensive than equivalent-sized fixed-point arithmetic.
Witness the latest Altera/Intel FPGAs, which have "DSP blocks" that are twinned, and will either do n-bit (I think it's 32-bit, but I'm not sure) fixed-point math in each block, or will do the same-sized floating-point math in one pair of blocks -- so going to floating point not only loses precision (because you only have 25 effective bits of mantissa in an IEEE 32-bit floating point), but uses twice the resources, with very limited handling of corner cases.
answered 8 hours ago
TimWescottTimWescott
8,5091718
$endgroup$
$begingroup$
We live in age where nm resolution in fabrication has become quite small and logic resource in FPGAs is quite cheap. What difference does it make how much logic is required for a FPU that complies fully with IEEE 754?
$endgroup$
– quantum231
7 hours ago
$begingroup$
Well, again, look at Altera parts. The FPU can be a big part of a processor if it's fully IEEE compliant. In an FPGA that's filled with a DSP algorithm, those "sorta-compliant" blocks allow far more computation in the same amount of silicon than fully compliant ones would -- and FPGA DSP is often limited by the number of blocks you can afford.
$endgroup$
– TimWescott
5 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("schematics", function ()
StackExchange.schematics.init();
);
, "cicuitlab");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "135"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f439327%2fvhdl-why-is-it-hard-to-design-a-floating-point-unit-in-hardware%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
The standard is well designed and there are subtle details that ease implementation, for example, when rounding, the carry from the mantissa can overflow to the exponent. Or integer comparisons can be used for floating point compares...
But, an FPU is a big heap of combinatorial mess, besides adding, multiplying, dividing, there are barrel shifters to align matissas, leading zeros counters, rounding, flags (imprecise, overflow, ...), NaN and denormals (which need additional hardware for calculations, particularly for mul/div, or at least trigger an exception for software emulation).
And most FPUs also need to do conversions to/from integer and between formats (float,double). That conversion hardware can be mostly implemented through existing floating point hardware, but it incurs additional multiplexers and special cases...
Then, there is pipelining. Depending on the transistor budget and frequency, either add/sub/mul can have the same throughput, or double precision can be slower, which can incur additional complexity in the pipeline. Modern FPU now have a pipelined multiply-add operator.
For division, it is always iterative, it can be a separate unit or reuse the multiplier-adder for Newton-Raphson or Goldshmidt. And while you are busy making a divider, you look for ways to tweak it for square roots...
Validation is complex because there are many corner cases. There are a few systematic test suites with test patterns for "interesting" cases about all the rounding modes but things like fast multipliers or dividers are too complex to test easily.
Iterative dividers can have non obvious bugs (for example the famous Pentium bug in its SRT radix 4 divider), multiplicative (Newton) are difficult to test exact rounding (some bugs in old IBM computers).
Formal methods are now used to prove these parts.
Modern FPUs also implement SIMD hardware, where FP operators are instantiated several times for parallel processing.
There is also the case of the x87 and MC68881/2 FPUs which can calculate decimal conversions, hyperbolic and trigonometric operations. These operations are microcoded and use basic FP operators, they are not directly implemented in hardware.
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
$endgroup$
$begingroup$
The Standard suffers a bit from trying to serve all purposes, and thus being too complicated to serve some while lacking features needed to serve others. For example, questions about the cases when it should guarantee "perfectly" rounded results were based upon whether that would be possible, rather than upon whether the costs would be worth the benefits for all applications. For many purposes, a computation that yields a result within two units in the last place would be more useful than one which yields a perfectly-rounded result but takes twice as long,...
$endgroup$
– supercat
5 hours ago
$begingroup$
...and on many implementations, computing a result within two ULP would take less than half as long as computing a perfectly-rounded result (as a simple example, computingx*(1/1.234567)will yield a value within a couple ulp ofx/1.234567, but will be much faster than computing the latter value). There are times when perfect rounding is useful or even necessary, but having a means of specifying when it isn't necessary would also have been useful.
$endgroup$
– supercat
5 hours ago
$begingroup$
@supercat Yes. For things like divisions, inverse square root... they are often implemented for graphics using pipelined Newton-Raphson on the FPU multiply-add hardware. Denormals are often flushed to zero (for example in DSPs, GPUs). The default rounding mode "round to nearest-even" is slighly easier to implement than the other modes (to infinity, to zero), because of rounding, so sometimes it is the only mode available.
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
The standard was designed by a Mathematician, W. Kahan, and tried to address the shortcomings of previous formats, notably DEC VAX. The first implementation, the 8087, was a rather slow implementation but with extended precision and lots of microcode for a "math library in a chip".
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
I've read some of Kahan's papers, and in most cases where things have evolved contrary to what Kahan advocated, I think Kahan's approach would have been better, but he did make a few mistakes. I think the Standard would have benefited from having an unsigned zero along with signed infinitesimals; 1/(tiny * tiny) should yield +Inf, but 1/0 should yield NaN, to avoid the asymmetry with zero. Still, parts of the Standard fail to consider that cost/benefit trade-offs are different in different kinds of application.
$endgroup$
– supercat
2 hours ago
add a comment |
$begingroup$
The standard is well designed and there are subtle details that ease implementation, for example, when rounding, the carry from the mantissa can overflow to the exponent. Or integer comparisons can be used for floating point compares...
But, an FPU is a big heap of combinatorial mess, besides adding, multiplying, dividing, there are barrel shifters to align matissas, leading zeros counters, rounding, flags (imprecise, overflow, ...), NaN and denormals (which need additional hardware for calculations, particularly for mul/div, or at least trigger an exception for software emulation).
And most FPUs also need to do conversions to/from integer and between formats (float,double). That conversion hardware can be mostly implemented through existing floating point hardware, but it incurs additional multiplexers and special cases...
Then, there is pipelining. Depending on the transistor budget and frequency, either add/sub/mul can have the same throughput, or double precision can be slower, which can incur additional complexity in the pipeline. Modern FPU now have a pipelined multiply-add operator.
For division, it is always iterative, it can be a separate unit or reuse the multiplier-adder for Newton-Raphson or Goldshmidt. And while you are busy making a divider, you look for ways to tweak it for square roots...
Validation is complex because there are many corner cases. There are a few systematic test suites with test patterns for "interesting" cases about all the rounding modes but things like fast multipliers or dividers are too complex to test easily.
Iterative dividers can have non obvious bugs (for example the famous Pentium bug in its SRT radix 4 divider), multiplicative (Newton) are difficult to test exact rounding (some bugs in old IBM computers).
Formal methods are now used to prove these parts.
Modern FPUs also implement SIMD hardware, where FP operators are instantiated several times for parallel processing.
There is also the case of the x87 and MC68881/2 FPUs which can calculate decimal conversions, hyperbolic and trigonometric operations. These operations are microcoded and use basic FP operators, they are not directly implemented in hardware.
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
$endgroup$
$begingroup$
The Standard suffers a bit from trying to serve all purposes, and thus being too complicated to serve some while lacking features needed to serve others. For example, questions about the cases when it should guarantee "perfectly" rounded results were based upon whether that would be possible, rather than upon whether the costs would be worth the benefits for all applications. For many purposes, a computation that yields a result within two units in the last place would be more useful than one which yields a perfectly-rounded result but takes twice as long,...
$endgroup$
– supercat
5 hours ago
$begingroup$
...and on many implementations, computing a result within two ULP would take less than half as long as computing a perfectly-rounded result (as a simple example, computingx*(1/1.234567)will yield a value within a couple ulp ofx/1.234567, but will be much faster than computing the latter value). There are times when perfect rounding is useful or even necessary, but having a means of specifying when it isn't necessary would also have been useful.
$endgroup$
– supercat
5 hours ago
$begingroup$
@supercat Yes. For things like divisions, inverse square root... they are often implemented for graphics using pipelined Newton-Raphson on the FPU multiply-add hardware. Denormals are often flushed to zero (for example in DSPs, GPUs). The default rounding mode "round to nearest-even" is slighly easier to implement than the other modes (to infinity, to zero), because of rounding, so sometimes it is the only mode available.
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
The standard was designed by a Mathematician, W. Kahan, and tried to address the shortcomings of previous formats, notably DEC VAX. The first implementation, the 8087, was a rather slow implementation but with extended precision and lots of microcode for a "math library in a chip".
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
I've read some of Kahan's papers, and in most cases where things have evolved contrary to what Kahan advocated, I think Kahan's approach would have been better, but he did make a few mistakes. I think the Standard would have benefited from having an unsigned zero along with signed infinitesimals; 1/(tiny * tiny) should yield +Inf, but 1/0 should yield NaN, to avoid the asymmetry with zero. Still, parts of the Standard fail to consider that cost/benefit trade-offs are different in different kinds of application.
$endgroup$
– supercat
2 hours ago
add a comment |
$begingroup$
The standard is well designed and there are subtle details that ease implementation, for example, when rounding, the carry from the mantissa can overflow to the exponent. Or integer comparisons can be used for floating point compares...
But, an FPU is a big heap of combinatorial mess, besides adding, multiplying, dividing, there are barrel shifters to align matissas, leading zeros counters, rounding, flags (imprecise, overflow, ...), NaN and denormals (which need additional hardware for calculations, particularly for mul/div, or at least trigger an exception for software emulation).
And most FPUs also need to do conversions to/from integer and between formats (float,double). That conversion hardware can be mostly implemented through existing floating point hardware, but it incurs additional multiplexers and special cases...
Then, there is pipelining. Depending on the transistor budget and frequency, either add/sub/mul can have the same throughput, or double precision can be slower, which can incur additional complexity in the pipeline. Modern FPU now have a pipelined multiply-add operator.
For division, it is always iterative, it can be a separate unit or reuse the multiplier-adder for Newton-Raphson or Goldshmidt. And while you are busy making a divider, you look for ways to tweak it for square roots...
Validation is complex because there are many corner cases. There are a few systematic test suites with test patterns for "interesting" cases about all the rounding modes but things like fast multipliers or dividers are too complex to test easily.
Iterative dividers can have non obvious bugs (for example the famous Pentium bug in its SRT radix 4 divider), multiplicative (Newton) are difficult to test exact rounding (some bugs in old IBM computers).
Formal methods are now used to prove these parts.
Modern FPUs also implement SIMD hardware, where FP operators are instantiated several times for parallel processing.
There is also the case of the x87 and MC68881/2 FPUs which can calculate decimal conversions, hyperbolic and trigonometric operations. These operations are microcoded and use basic FP operators, they are not directly implemented in hardware.
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
$endgroup$
The standard is well designed and there are subtle details that ease implementation, for example, when rounding, the carry from the mantissa can overflow to the exponent. Or integer comparisons can be used for floating point compares...
But, an FPU is a big heap of combinatorial mess, besides adding, multiplying, dividing, there are barrel shifters to align matissas, leading zeros counters, rounding, flags (imprecise, overflow, ...), NaN and denormals (which need additional hardware for calculations, particularly for mul/div, or at least trigger an exception for software emulation).
And most FPUs also need to do conversions to/from integer and between formats (float,double). That conversion hardware can be mostly implemented through existing floating point hardware, but it incurs additional multiplexers and special cases...
Then, there is pipelining. Depending on the transistor budget and frequency, either add/sub/mul can have the same throughput, or double precision can be slower, which can incur additional complexity in the pipeline. Modern FPU now have a pipelined multiply-add operator.
For division, it is always iterative, it can be a separate unit or reuse the multiplier-adder for Newton-Raphson or Goldshmidt. And while you are busy making a divider, you look for ways to tweak it for square roots...
Validation is complex because there are many corner cases. There are a few systematic test suites with test patterns for "interesting" cases about all the rounding modes but things like fast multipliers or dividers are too complex to test easily.
Iterative dividers can have non obvious bugs (for example the famous Pentium bug in its SRT radix 4 divider), multiplicative (Newton) are difficult to test exact rounding (some bugs in old IBM computers).
Formal methods are now used to prove these parts.
Modern FPUs also implement SIMD hardware, where FP operators are instantiated several times for parallel processing.
There is also the case of the x87 and MC68881/2 FPUs which can calculate decimal conversions, hyperbolic and trigonometric operations. These operations are microcoded and use basic FP operators, they are not directly implemented in hardware.
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
edited 8 hours ago
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
answered 8 hours ago
TEMLIBTEMLIB
1,8971713
1,8971713
$begingroup$
The Standard suffers a bit from trying to serve all purposes, and thus being too complicated to serve some while lacking features needed to serve others. For example, questions about the cases when it should guarantee "perfectly" rounded results were based upon whether that would be possible, rather than upon whether the costs would be worth the benefits for all applications. For many purposes, a computation that yields a result within two units in the last place would be more useful than one which yields a perfectly-rounded result but takes twice as long,...
$endgroup$
– supercat
5 hours ago
$begingroup$
...and on many implementations, computing a result within two ULP would take less than half as long as computing a perfectly-rounded result (as a simple example, computingx*(1/1.234567)will yield a value within a couple ulp ofx/1.234567, but will be much faster than computing the latter value). There are times when perfect rounding is useful or even necessary, but having a means of specifying when it isn't necessary would also have been useful.
$endgroup$
– supercat
5 hours ago
$begingroup$
@supercat Yes. For things like divisions, inverse square root... they are often implemented for graphics using pipelined Newton-Raphson on the FPU multiply-add hardware. Denormals are often flushed to zero (for example in DSPs, GPUs). The default rounding mode "round to nearest-even" is slighly easier to implement than the other modes (to infinity, to zero), because of rounding, so sometimes it is the only mode available.
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
The standard was designed by a Mathematician, W. Kahan, and tried to address the shortcomings of previous formats, notably DEC VAX. The first implementation, the 8087, was a rather slow implementation but with extended precision and lots of microcode for a "math library in a chip".
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
I've read some of Kahan's papers, and in most cases where things have evolved contrary to what Kahan advocated, I think Kahan's approach would have been better, but he did make a few mistakes. I think the Standard would have benefited from having an unsigned zero along with signed infinitesimals; 1/(tiny * tiny) should yield +Inf, but 1/0 should yield NaN, to avoid the asymmetry with zero. Still, parts of the Standard fail to consider that cost/benefit trade-offs are different in different kinds of application.
$endgroup$
– supercat
2 hours ago
add a comment |
$begingroup$
The Standard suffers a bit from trying to serve all purposes, and thus being too complicated to serve some while lacking features needed to serve others. For example, questions about the cases when it should guarantee "perfectly" rounded results were based upon whether that would be possible, rather than upon whether the costs would be worth the benefits for all applications. For many purposes, a computation that yields a result within two units in the last place would be more useful than one which yields a perfectly-rounded result but takes twice as long,...
$endgroup$
– supercat
5 hours ago
$begingroup$
...and on many implementations, computing a result within two ULP would take less than half as long as computing a perfectly-rounded result (as a simple example, computingx*(1/1.234567)will yield a value within a couple ulp ofx/1.234567, but will be much faster than computing the latter value). There are times when perfect rounding is useful or even necessary, but having a means of specifying when it isn't necessary would also have been useful.
$endgroup$
– supercat
5 hours ago
$begingroup$
@supercat Yes. For things like divisions, inverse square root... they are often implemented for graphics using pipelined Newton-Raphson on the FPU multiply-add hardware. Denormals are often flushed to zero (for example in DSPs, GPUs). The default rounding mode "round to nearest-even" is slighly easier to implement than the other modes (to infinity, to zero), because of rounding, so sometimes it is the only mode available.
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
The standard was designed by a Mathematician, W. Kahan, and tried to address the shortcomings of previous formats, notably DEC VAX. The first implementation, the 8087, was a rather slow implementation but with extended precision and lots of microcode for a "math library in a chip".
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
I've read some of Kahan's papers, and in most cases where things have evolved contrary to what Kahan advocated, I think Kahan's approach would have been better, but he did make a few mistakes. I think the Standard would have benefited from having an unsigned zero along with signed infinitesimals; 1/(tiny * tiny) should yield +Inf, but 1/0 should yield NaN, to avoid the asymmetry with zero. Still, parts of the Standard fail to consider that cost/benefit trade-offs are different in different kinds of application.
$endgroup$
– supercat
2 hours ago
$begingroup$
The Standard suffers a bit from trying to serve all purposes, and thus being too complicated to serve some while lacking features needed to serve others. For example, questions about the cases when it should guarantee "perfectly" rounded results were based upon whether that would be possible, rather than upon whether the costs would be worth the benefits for all applications. For many purposes, a computation that yields a result within two units in the last place would be more useful than one which yields a perfectly-rounded result but takes twice as long,...
$endgroup$
– supercat
5 hours ago
$begingroup$
The Standard suffers a bit from trying to serve all purposes, and thus being too complicated to serve some while lacking features needed to serve others. For example, questions about the cases when it should guarantee "perfectly" rounded results were based upon whether that would be possible, rather than upon whether the costs would be worth the benefits for all applications. For many purposes, a computation that yields a result within two units in the last place would be more useful than one which yields a perfectly-rounded result but takes twice as long,...
$endgroup$
– supercat
5 hours ago
$begingroup$
...and on many implementations, computing a result within two ULP would take less than half as long as computing a perfectly-rounded result (as a simple example, computing
x*(1/1.234567) will yield a value within a couple ulp of x/1.234567, but will be much faster than computing the latter value). There are times when perfect rounding is useful or even necessary, but having a means of specifying when it isn't necessary would also have been useful.$endgroup$
– supercat
5 hours ago
$begingroup$
...and on many implementations, computing a result within two ULP would take less than half as long as computing a perfectly-rounded result (as a simple example, computing
x*(1/1.234567) will yield a value within a couple ulp of x/1.234567, but will be much faster than computing the latter value). There are times when perfect rounding is useful or even necessary, but having a means of specifying when it isn't necessary would also have been useful.$endgroup$
– supercat
5 hours ago
$begingroup$
@supercat Yes. For things like divisions, inverse square root... they are often implemented for graphics using pipelined Newton-Raphson on the FPU multiply-add hardware. Denormals are often flushed to zero (for example in DSPs, GPUs). The default rounding mode "round to nearest-even" is slighly easier to implement than the other modes (to infinity, to zero), because of rounding, so sometimes it is the only mode available.
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
@supercat Yes. For things like divisions, inverse square root... they are often implemented for graphics using pipelined Newton-Raphson on the FPU multiply-add hardware. Denormals are often flushed to zero (for example in DSPs, GPUs). The default rounding mode "round to nearest-even" is slighly easier to implement than the other modes (to infinity, to zero), because of rounding, so sometimes it is the only mode available.
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
The standard was designed by a Mathematician, W. Kahan, and tried to address the shortcomings of previous formats, notably DEC VAX. The first implementation, the 8087, was a rather slow implementation but with extended precision and lots of microcode for a "math library in a chip".
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
The standard was designed by a Mathematician, W. Kahan, and tried to address the shortcomings of previous formats, notably DEC VAX. The first implementation, the 8087, was a rather slow implementation but with extended precision and lots of microcode for a "math library in a chip".
$endgroup$
– TEMLIB
3 hours ago
$begingroup$
I've read some of Kahan's papers, and in most cases where things have evolved contrary to what Kahan advocated, I think Kahan's approach would have been better, but he did make a few mistakes. I think the Standard would have benefited from having an unsigned zero along with signed infinitesimals; 1/(tiny * tiny) should yield +Inf, but 1/0 should yield NaN, to avoid the asymmetry with zero. Still, parts of the Standard fail to consider that cost/benefit trade-offs are different in different kinds of application.
$endgroup$
– supercat
2 hours ago
$begingroup$
I've read some of Kahan's papers, and in most cases where things have evolved contrary to what Kahan advocated, I think Kahan's approach would have been better, but he did make a few mistakes. I think the Standard would have benefited from having an unsigned zero along with signed infinitesimals; 1/(tiny * tiny) should yield +Inf, but 1/0 should yield NaN, to avoid the asymmetry with zero. Still, parts of the Standard fail to consider that cost/benefit trade-offs are different in different kinds of application.
$endgroup$
– supercat
2 hours ago
add a comment |
$begingroup$
Having a look on opencores might give some hints e.g.: https://opencores.org/websvn/filedetails?repname=openfpu64&path=%2Fopenfpu64%2Ftrunk%2Ffpu_mul.vhd
The trouble with floating point is the large number of annoying corner cases. Integer operations have no concept of NaN, but it appears a lot in floating point. Numbers must also be normalised and denormalised correctly.
answered 9 hours ago
pjc50pjc50
34.6k34288
$endgroup$
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
9 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
9 hours ago
$begingroup$
@quantum231 yes, that's why pjc50 used that code snippet to illustrate why floating point is hard to do right: It's a humongous mess of handling special conditions.
$endgroup$
– Marcus Müller
9 hours ago
$begingroup$
Well, any nontrivial design will be complex and have a lot of conditions to be met. I shall study the code in detail later.
$endgroup$
– quantum231
7 hours ago
add a comment |
$begingroup$
Having a look on opencores might give some hints e.g.: https://opencores.org/websvn/filedetails?repname=openfpu64&path=%2Fopenfpu64%2Ftrunk%2Ffpu_mul.vhd
The trouble with floating point is the large number of annoying corner cases. Integer operations have no concept of NaN, but it appears a lot in floating point. Numbers must also be normalised and denormalised correctly.
answered 9 hours ago
pjc50pjc50
34.6k34288
$endgroup$
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
9 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
9 hours ago
$begingroup$
@quantum231 yes, that's why pjc50 used that code snippet to illustrate why floating point is hard to do right: It's a humongous mess of handling special conditions.
$endgroup$
– Marcus Müller
9 hours ago
$begingroup$
Well, any nontrivial design will be complex and have a lot of conditions to be met. I shall study the code in detail later.
$endgroup$
– quantum231
7 hours ago
add a comment |
$begingroup$
Having a look on opencores might give some hints e.g.: https://opencores.org/websvn/filedetails?repname=openfpu64&path=%2Fopenfpu64%2Ftrunk%2Ffpu_mul.vhd
The trouble with floating point is the large number of annoying corner cases. Integer operations have no concept of NaN, but it appears a lot in floating point. Numbers must also be normalised and denormalised correctly.
answered 9 hours ago
pjc50pjc50
34.6k34288
$endgroup$
Having a look on opencores might give some hints e.g.: https://opencores.org/websvn/filedetails?repname=openfpu64&path=%2Fopenfpu64%2Ftrunk%2Ffpu_mul.vhd
The trouble with floating point is the large number of annoying corner cases. Integer operations have no concept of NaN, but it appears a lot in floating point. Numbers must also be normalised and denormalised correctly.
answered 9 hours ago
pjc50pjc50
34.6k34288
answered 9 hours ago
pjc50pjc50
34.6k34288
answered 9 hours ago
pjc50pjc50
34.6k34288
answered 9 hours ago
pjc50pjc50
34.6k34288
34.6k34288
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
9 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
9 hours ago
$begingroup$
@quantum231 yes, that's why pjc50 used that code snippet to illustrate why floating point is hard to do right: It's a humongous mess of handling special conditions.
$endgroup$
– Marcus Müller
9 hours ago
$begingroup$
Well, any nontrivial design will be complex and have a lot of conditions to be met. I shall study the code in detail later.
$endgroup$
– quantum231
7 hours ago
add a comment |
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
9 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
9 hours ago
$begingroup$
@quantum231 yes, that's why pjc50 used that code snippet to illustrate why floating point is hard to do right: It's a humongous mess of handling special conditions.
$endgroup$
– Marcus Müller
9 hours ago
$begingroup$
Well, any nontrivial design will be complex and have a lot of conditions to be met. I shall study the code in detail later.
$endgroup$
– quantum231
7 hours ago
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
9 hours ago
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
9 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
9 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
9 hours ago
$begingroup$
@quantum231 yes, that's why pjc50 used that code snippet to illustrate why floating point is hard to do right: It's a humongous mess of handling special conditions.
$endgroup$
– Marcus Müller
9 hours ago
$begingroup$
@quantum231 yes, that's why pjc50 used that code snippet to illustrate why floating point is hard to do right: It's a humongous mess of handling special conditions.
$endgroup$
– Marcus Müller
9 hours ago
$begingroup$
Well, any nontrivial design will be complex and have a lot of conditions to be met. I shall study the code in detail later.
$endgroup$
– quantum231
7 hours ago
$begingroup$
Well, any nontrivial design will be complex and have a lot of conditions to be met. I shall study the code in detail later.
$endgroup$
– quantum231
7 hours ago
add a comment |
$begingroup$
Even if you don't handle all the corner cases, floating-point addition or subtraction of two well-formed numbers requires significant logic, because the scale of the mantissa can dramatically change -- consider the problem (in decimal) of the problem 1.9999 - 1.9993 = 0.0007. In floating point the location of the decimal point must be discovered, which isn't trivial, and the mantissa and exponent adjusted. This is even without trying to deal with NaN or denormalized numbers.
All the mention of handling the special cases is quite valid, but even if you put the onus of avoiding special cases on the system designer (which is not uncommon with floating-point IP intended for DSP applications), your floating point arithmetic is still more expensive than equivalent-sized fixed-point arithmetic.
Witness the latest Altera/Intel FPGAs, which have "DSP blocks" that are twinned, and will either do n-bit (I think it's 32-bit, but I'm not sure) fixed-point math in each block, or will do the same-sized floating-point math in one pair of blocks -- so going to floating point not only loses precision (because you only have 25 effective bits of mantissa in an IEEE 32-bit floating point), but uses twice the resources, with very limited handling of corner cases.
answered 8 hours ago
TimWescottTimWescott
8,5091718
$endgroup$
$begingroup$
We live in age where nm resolution in fabrication has become quite small and logic resource in FPGAs is quite cheap. What difference does it make how much logic is required for a FPU that complies fully with IEEE 754?
$endgroup$
– quantum231
7 hours ago
$begingroup$
Well, again, look at Altera parts. The FPU can be a big part of a processor if it's fully IEEE compliant. In an FPGA that's filled with a DSP algorithm, those "sorta-compliant" blocks allow far more computation in the same amount of silicon than fully compliant ones would -- and FPGA DSP is often limited by the number of blocks you can afford.
$endgroup$
– TimWescott
5 hours ago
add a comment |
$begingroup$
Even if you don't handle all the corner cases, floating-point addition or subtraction of two well-formed numbers requires significant logic, because the scale of the mantissa can dramatically change -- consider the problem (in decimal) of the problem 1.9999 - 1.9993 = 0.0007. In floating point the location of the decimal point must be discovered, which isn't trivial, and the mantissa and exponent adjusted. This is even without trying to deal with NaN or denormalized numbers.
All the mention of handling the special cases is quite valid, but even if you put the onus of avoiding special cases on the system designer (which is not uncommon with floating-point IP intended for DSP applications), your floating point arithmetic is still more expensive than equivalent-sized fixed-point arithmetic.
Witness the latest Altera/Intel FPGAs, which have "DSP blocks" that are twinned, and will either do n-bit (I think it's 32-bit, but I'm not sure) fixed-point math in each block, or will do the same-sized floating-point math in one pair of blocks -- so going to floating point not only loses precision (because you only have 25 effective bits of mantissa in an IEEE 32-bit floating point), but uses twice the resources, with very limited handling of corner cases.
answered 8 hours ago
TimWescottTimWescott
8,5091718
$endgroup$
$begingroup$
We live in age where nm resolution in fabrication has become quite small and logic resource in FPGAs is quite cheap. What difference does it make how much logic is required for a FPU that complies fully with IEEE 754?
$endgroup$
– quantum231
7 hours ago
$begingroup$
Well, again, look at Altera parts. The FPU can be a big part of a processor if it's fully IEEE compliant. In an FPGA that's filled with a DSP algorithm, those "sorta-compliant" blocks allow far more computation in the same amount of silicon than fully compliant ones would -- and FPGA DSP is often limited by the number of blocks you can afford.
$endgroup$
– TimWescott
5 hours ago
add a comment |
$begingroup$
Even if you don't handle all the corner cases, floating-point addition or subtraction of two well-formed numbers requires significant logic, because the scale of the mantissa can dramatically change -- consider the problem (in decimal) of the problem 1.9999 - 1.9993 = 0.0007. In floating point the location of the decimal point must be discovered, which isn't trivial, and the mantissa and exponent adjusted. This is even without trying to deal with NaN or denormalized numbers.
All the mention of handling the special cases is quite valid, but even if you put the onus of avoiding special cases on the system designer (which is not uncommon with floating-point IP intended for DSP applications), your floating point arithmetic is still more expensive than equivalent-sized fixed-point arithmetic.
Witness the latest Altera/Intel FPGAs, which have "DSP blocks" that are twinned, and will either do n-bit (I think it's 32-bit, but I'm not sure) fixed-point math in each block, or will do the same-sized floating-point math in one pair of blocks -- so going to floating point not only loses precision (because you only have 25 effective bits of mantissa in an IEEE 32-bit floating point), but uses twice the resources, with very limited handling of corner cases.
answered 8 hours ago
TimWescottTimWescott
8,5091718
$endgroup$
Even if you don't handle all the corner cases, floating-point addition or subtraction of two well-formed numbers requires significant logic, because the scale of the mantissa can dramatically change -- consider the problem (in decimal) of the problem 1.9999 - 1.9993 = 0.0007. In floating point the location of the decimal point must be discovered, which isn't trivial, and the mantissa and exponent adjusted. This is even without trying to deal with NaN or denormalized numbers.
All the mention of handling the special cases is quite valid, but even if you put the onus of avoiding special cases on the system designer (which is not uncommon with floating-point IP intended for DSP applications), your floating point arithmetic is still more expensive than equivalent-sized fixed-point arithmetic.
Witness the latest Altera/Intel FPGAs, which have "DSP blocks" that are twinned, and will either do n-bit (I think it's 32-bit, but I'm not sure) fixed-point math in each block, or will do the same-sized floating-point math in one pair of blocks -- so going to floating point not only loses precision (because you only have 25 effective bits of mantissa in an IEEE 32-bit floating point), but uses twice the resources, with very limited handling of corner cases.
answered 8 hours ago
TimWescottTimWescott
8,5091718
answered 8 hours ago
TimWescottTimWescott
8,5091718
answered 8 hours ago
TimWescottTimWescott
8,5091718
answered 8 hours ago
TimWescottTimWescott
8,5091718
8,5091718
$begingroup$
We live in age where nm resolution in fabrication has become quite small and logic resource in FPGAs is quite cheap. What difference does it make how much logic is required for a FPU that complies fully with IEEE 754?
$endgroup$
– quantum231
7 hours ago
$begingroup$
Well, again, look at Altera parts. The FPU can be a big part of a processor if it's fully IEEE compliant. In an FPGA that's filled with a DSP algorithm, those "sorta-compliant" blocks allow far more computation in the same amount of silicon than fully compliant ones would -- and FPGA DSP is often limited by the number of blocks you can afford.
$endgroup$
– TimWescott
5 hours ago
add a comment |
$begingroup$
We live in age where nm resolution in fabrication has become quite small and logic resource in FPGAs is quite cheap. What difference does it make how much logic is required for a FPU that complies fully with IEEE 754?
$endgroup$
– quantum231
7 hours ago
$begingroup$
Well, again, look at Altera parts. The FPU can be a big part of a processor if it's fully IEEE compliant. In an FPGA that's filled with a DSP algorithm, those "sorta-compliant" blocks allow far more computation in the same amount of silicon than fully compliant ones would -- and FPGA DSP is often limited by the number of blocks you can afford.
$endgroup$
– TimWescott
5 hours ago
$begingroup$
We live in age where nm resolution in fabrication has become quite small and logic resource in FPGAs is quite cheap. What difference does it make how much logic is required for a FPU that complies fully with IEEE 754?
$endgroup$
– quantum231
7 hours ago
$begingroup$
We live in age where nm resolution in fabrication has become quite small and logic resource in FPGAs is quite cheap. What difference does it make how much logic is required for a FPU that complies fully with IEEE 754?
$endgroup$
– quantum231
7 hours ago
$begingroup$
Well, again, look at Altera parts. The FPU can be a big part of a processor if it's fully IEEE compliant. In an FPGA that's filled with a DSP algorithm, those "sorta-compliant" blocks allow far more computation in the same amount of silicon than fully compliant ones would -- and FPGA DSP is often limited by the number of blocks you can afford.
$endgroup$
– TimWescott
5 hours ago
$begingroup$
Well, again, look at Altera parts. The FPU can be a big part of a processor if it's fully IEEE compliant. In an FPGA that's filled with a DSP algorithm, those "sorta-compliant" blocks allow far more computation in the same amount of silicon than fully compliant ones would -- and FPGA DSP is often limited by the number of blocks you can afford.
$endgroup$
– TimWescott
5 hours ago
add a comment |
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f439327%2fvhdl-why-is-it-hard-to-design-a-floating-point-unit-in-hardware%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
$begingroup$
ieee 754 tells you what the results must be, not how to do it. If you can come up with a quicker way to get exactly the same results, then you could sell your idea to chip manufacturer. The payoff for them is they could reduce their chip area and so improve yield. You know there are several ways to multiply two numbers together, right? One or another might be a better fit for your process. Start with schoolbook, and improve with various clever factorisations and identities.
$endgroup$
– Neil_UK
9 hours ago
$begingroup$
I assume this would be a major area of research and people come with new methods from time to time?
$endgroup$
– quantum231
9 hours ago
2
$begingroup$
I imagine because there are a lot of design tradeoffs and objectives that can be prioritized because no only are you working with logic on paper, you're also working with silicon gates. It's like op-amps...they all do the same thing yet no standard design with thousands of varieties.
$endgroup$
– Toor
9 hours ago
3
$begingroup$
IEEE 754 makes it harder to implement, not easier. Just look at Xilinx offering and their deviation from 754: xilinx.com/support/documentation/ip_documentation/… There are many corner cases to handle for floating point
$endgroup$
– Jonathan Drolet
9 hours ago
$begingroup$
Bipolar Integrated Technology (aka BIT) fielded ASIC chips that provided floating point done just as you suggest. That would be prior to 1990, as I was working with one of the engineers from there on a separate project using the MIPS R2000 around 1987-ish. I cannot say how complete they were in terms of implementing IEEE 754, though. I'm pretty sure they didn't implement the full specification. BIT was located in the Beaverton, Oregon area.
$endgroup$
– jonk
9 hours ago