VHDL: Why is it hard to desgin a floating point unit in hardware?Any good reference for digital architecture implementations of floating point arithmetic operations?The bitwise complement of a floating point number's binary representationHow 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
Does the fact that we can only measure the two-way speed of light undermine the axiom of invariance?
How do you earn the reader's trust?
Way of refund if scammed?
Salesforce bug enabled "Modify All"
How did the Allies achieve air superiority on Sicily?
Split into three!
Is it safe to redirect stdout and stderr to the same file without file descriptor copies?
Passport queue length in UK in relation to arrival method
Existence of a model of ZFC in which the natural numbers are really the natural numbers
What is the winged creature on the back of the Mordenkainen's Tome of Foes book?
JavaScript: Access 'this' when calling function stored in variable
A nasty indefinite integral
Were there any developed countries that became "undeveloped" for reasons other than war?
Is there a word for pant sleeves?
What does it mean for something to be strictly less than epsilon for an arbitrary epsilon?
Keeping the dodos out of the field
How many wires should be in a new thermostat cable?
Does ls -R make any sense with -d?
Caught with my phone during an exam
How to become an Editorial board member?
Variable does not Exist: CaseTrigger
What pc resources are used when bruteforcing?
Must every right-inverse of a linear transformation be a linear transformation?
Was murdering a slave illegal in American slavery, and if so, what punishments were given for it?
VHDL: Why is it hard to desgin a floating point unit in hardware?
Any good reference for digital architecture implementations of floating point arithmetic operations?The bitwise complement of a floating point number's binary representationHow 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 inspite of there being IEEE 754?
fpga vhdl floating-point
asked 4 hours ago
quantum231quantum231
4,0161562122
$endgroup$
|
show 2 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 inspite of there being IEEE 754?
fpga vhdl floating-point
asked 4 hours ago
quantum231quantum231
4,0161562122
$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
4 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
4 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
4 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
3 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
3 hours ago
|
show 2 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 inspite of there being IEEE 754?
fpga vhdl floating-point
asked 4 hours ago
quantum231quantum231
4,0161562122
$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 inspite of there being IEEE 754?
fpga vhdl floating-point
fpga vhdl floating-point
asked 4 hours ago
quantum231quantum231
4,0161562122
asked 4 hours ago
quantum231quantum231
4,0161562122
asked 4 hours ago
quantum231quantum231
4,0161562122
asked 4 hours ago
quantum231quantum231
4,0161562122
asked 4 hours ago
quantum231quantum231
4,0161562122
4,0161562122
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
4 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
4 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
4 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
3 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
3 hours ago
|
show 2 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
4 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
4 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
4 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
3 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
3 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
4 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
4 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
4 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
4 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
4 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
4 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
3 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
3 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
3 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
3 hours ago
|
show 2 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 3 hours ago
TEMLIBTEMLIB
1,8771713
$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
15 mins 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
12 mins 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 4 hours ago
pjc50pjc50
34.6k34288
$endgroup$
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
4 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
4 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
3 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
2 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 3 hours ago
TimWescottTimWescott
8,4991718
$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
2 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-desgin-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 3 hours ago
TEMLIBTEMLIB
1,8771713
$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
15 mins 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
12 mins 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 3 hours ago
TEMLIBTEMLIB
1,8771713
$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
15 mins 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
12 mins 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 3 hours ago
TEMLIBTEMLIB
1,8771713
$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 3 hours ago
TEMLIBTEMLIB
1,8771713
edited 3 hours ago
answered 3 hours ago
TEMLIBTEMLIB
1,8771713
answered 3 hours ago
TEMLIBTEMLIB
1,8771713
answered 3 hours ago
TEMLIBTEMLIB
1,8771713
1,8771713
$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
15 mins 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
12 mins 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
15 mins 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
12 mins 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
15 mins 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
15 mins 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
12 mins 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
12 mins 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 4 hours ago
pjc50pjc50
34.6k34288
$endgroup$
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
4 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
4 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
3 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
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 4 hours ago
pjc50pjc50
34.6k34288
$endgroup$
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
4 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
4 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
3 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
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 4 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 4 hours ago
pjc50pjc50
34.6k34288
answered 4 hours ago
pjc50pjc50
34.6k34288
answered 4 hours ago
pjc50pjc50
34.6k34288
answered 4 hours ago
pjc50pjc50
34.6k34288
34.6k34288
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
4 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
4 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
3 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
2 hours ago
add a comment |
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
4 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
4 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
3 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
2 hours ago
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
4 hours ago
$begingroup$
The Opencores has several floating point designs done by different people
$endgroup$
– quantum231
4 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
4 hours ago
$begingroup$
This specific link has a specific code for multiplication, hmmm
$endgroup$
– quantum231
4 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
3 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
3 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
2 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
2 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 3 hours ago
TimWescottTimWescott
8,4991718
$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
2 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 3 hours ago
TimWescottTimWescott
8,4991718
$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
2 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 3 hours ago
TimWescottTimWescott
8,4991718
$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 3 hours ago
TimWescottTimWescott
8,4991718
answered 3 hours ago
TimWescottTimWescott
8,4991718
answered 3 hours ago
TimWescottTimWescott
8,4991718
answered 3 hours ago
TimWescottTimWescott
8,4991718
8,4991718
$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
2 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
2 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
2 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
2 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-desgin-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
4 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
4 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
4 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
3 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
3 hours ago