Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #20067 > unrolled thread

two fpu compared

Back to article view | Back to comp.arch.embedded

Contents

  two fpu compared al.basili@gmail.com (alb) - 2015-02-12 08:30 +0000
    Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-12 10:51 +0100
      Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-13 14:14 +0000
        Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-13 16:23 +0100
          Re: two fpu compared Colin Paul de Gloucester <not_a_real_email@address.com> - 2015-02-13 17:37 +0100
            Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-16 08:01 +0000
              Re: two fpu compared Colin Paul de Gloucester <not_a_real_email@address.com> - 2015-02-16 11:43 +0100
                Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-17 10:35 +0000
                  Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-17 12:18 +0100
                    Re: two fpu compared George Neuner <gneuner2@comcast.net> - 2015-02-17 09:26 -0500
                      Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-17 16:47 +0100
                        Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-17 20:54 +0200
          Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-16 07:58 +0000
            Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-16 09:53 +0100
              Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-16 09:47 +0000
                Re: two fpu compared Richard Damon <Richard@Damon-Family.org> - 2015-02-16 08:27 -0500
          Re: two fpu compared Nobody <nobody@nowhere.invalid> - 2015-02-23 00:13 +0000
        Re: two fpu compared George Neuner <gneuner2@comcast.net> - 2015-02-13 18:43 -0500
        Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-14 15:30 +0000
          Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-14 23:19 +0200
            Re: two fpu compared Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-02-14 23:28 +0100
            Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-15 14:33 +0000
              Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-17 20:53 +0200
                Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-18 01:55 +0000
                  Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-18 17:54 +0200
                    Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-18 16:52 +0000
                      Re: two fpu compared Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-02-18 18:12 +0100
                        Re: two fpu compared Robert Wessel <robertwessel2@yahoo.com> - 2015-02-18 18:02 -0600
                          Re: two fpu compared Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-02-19 09:42 +0200
                            Re: two fpu compared Robert Wessel <robertwessel2@yahoo.com> - 2015-02-19 11:04 -0600
                              Re: two fpu compared Reinhardt Behm <rbehm@hushmail.com> - 2015-02-19 23:26 +0800
                      Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-18 19:18 +0200
                        Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-19 02:28 +0200
                        Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-19 16:29 +0000
                          Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-21 16:07 +0200
    Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-12 11:26 +0000
    Re: two fpu compared "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2015-02-12 12:29 +0100
    Re: two fpu compared Dennis <dennis@none.none> - 2015-02-12 09:45 -0600

Page 1 of 2  [1] 2  Next page →

#20067 — two fpu compared

Hi everyone,

assuming two differently implemented FPU, both validated against the 
IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I 
be sure that provided the inputs operands are the same the result would 
be the same bit wise?

BACKGROUND: our dear customer wanted to verify that the control law 
specified is correctly implemented by means of comparing output with a 
golden model. Now the golden model is running on a standard PC, with 
matlab, a pile of mathematical libraries and a processor that is 
humongous compared to our little embedded unit. I've already warned 
the customer that bitwise comparison might only be viable if precision 
wise the two calculations are equally configured (single precision, 
rounding, etc.). Are there any other elements to consider?

Moreover, we are driving a PWM with the control law on a 8bit, or max 
10bit precision, so most of that fine grain precision would not be used 
anyway.

Any comment/pointer/suggestion is appreciated.

Al

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[toc] | [next] | [standalone]

#20068

On 12/02/15 09:30, alb wrote:
> Hi everyone,
> 
> assuming two differently implemented FPU, both validated against the 
> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I 
> be sure that provided the inputs operands are the same the result would 
> be the same bit wise?
> 
> BACKGROUND: our dear customer wanted to verify that the control law 
> specified is correctly implemented by means of comparing output with a 
> golden model. Now the golden model is running on a standard PC, with 
> matlab, a pile of mathematical libraries and a processor that is 
> humongous compared to our little embedded unit. I've already warned 
> the customer that bitwise comparison might only be viable if precision 
> wise the two calculations are equally configured (single precision, 
> rounding, etc.). Are there any other elements to consider?
> 
> Moreover, we are driving a PWM with the control law on a 8bit, or max 
> 10bit precision, so most of that fine grain precision would not be used 
> anyway.
> 
> Any comment/pointer/suggestion is appreciated.
> 
> Al
> 

It is normal to view floating point operations as slightly imprecise -
there is a rule that you never compare floating point data with ==.
Even if you are careful to have the same precision and rounding in the
calculations, there may be other factors - for at least some operations,
I believe there can be different results from two IEEE754 compatible
implementations.

More importantly, however, is that normally you don't want full IEEE754
compliance - the overhead is too much.  Typically, FPU hardware does not
provide full support - you need to have extra software handling as well.
 In some aspects, non-compliant code can be significantly more
efficient.  For example, with "-ffast-math" in gcc, the compiler can
turn "x = y + z - y" into "x = z", while in compliant mode it has to do
the full calculation as stated, even though it is slower and gives less
accurate results.  And for square root, some FPU's may have a fast
"approximate square root" function that is good enough and much faster.

The only way to be really sure of bit-accurate results is to use the
same software floating point library on each system.  But since the
"golden model" here is a system that you have no control of (matlab plus
external libraries - and different "standard PC's" can have different
details in their FPU's), it is basically impossible to guarantee
bit-accurate copies of the results.

[toc] | [prev] | [next] | [standalone]

#20077

Hi David,

David Brown <david.brown@hesbynett.no> wrote:
[]
>> assuming two differently implemented FPU, both validated against the 
>> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I 
>> be sure that provided the inputs operands are the same the result would 
>> be the same bit wise?
[]
> 
> It is normal to view floating point operations as slightly imprecise -
> there is a rule that you never compare floating point data with ==.
> Even if you are careful to have the same precision and rounding in the
> calculations, there may be other factors - for at least some operations,
> I believe there can be different results from two IEEE754 compatible
> implementations.

the extra bit I got recently is that the result is converted to an 
integer of 11bit which, a priori, means that a lot of the low bit 
precision from the 32bit is anyhow lost.

Indeed I could calculate what the integer LSB corresponds to in terms of 
floating point representation and be more confident on the comparison 
(i.e. if floating point results are not bitwise equal does not necessary 
mean the integer result is going to be different).

> More importantly, however, is that normally you don't want full IEEE754
> compliance - the overhead is too much.  Typically, FPU hardware does not
> provide full support - you need to have extra software handling as well.

AFAIK the implementation we have is 'full IEEE754' and floating points 
operations are using directly the hardware (unless gcc is configured 
otherwise).

> In some aspects, non-compliant code can be significantly more
> efficient.  For example, with "-ffast-math" in gcc, the compiler can
> turn "x = y + z - y" into "x = z", while in compliant mode it has to do
> the full calculation as stated, even though it is slower and gives less
> accurate results.  And for square root, some FPU's may have a fast
> "approximate square root" function that is good enough and much faster.

I see your point, this is certainly an extra bit of info since our 
harwdare is not that performing either and a soft implementation might 
actually be faster.

> The only way to be really sure of bit-accurate results is to use the
> same software floating point library on each system.  But since the
> "golden model" here is a system that you have no control of (matlab plus
> external libraries - and different "standard PC's" can have different
> details in their FPU's), it is basically impossible to guarantee
> bit-accurate copies of the results.

Still can be a viable approach if the result is converted to integer 
with a much lower precision. It is a bet though, since we cannot be 
absolutely sure that it would be the case.

Al

[toc] | [prev] | [next] | [standalone]

#20078

On 13/02/15 15:14, alb wrote:
> Hi David,
> 
> David Brown <david.brown@hesbynett.no> wrote:
> []
>>> assuming two differently implemented FPU, both validated against the 
>>> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I 
>>> be sure that provided the inputs operands are the same the result would 
>>> be the same bit wise?
> []
>>
>> It is normal to view floating point operations as slightly imprecise -
>> there is a rule that you never compare floating point data with ==.
>> Even if you are careful to have the same precision and rounding in the
>> calculations, there may be other factors - for at least some operations,
>> I believe there can be different results from two IEEE754 compatible
>> implementations.
> 
> the extra bit I got recently is that the result is converted to an 
> integer of 11bit which, a priori, means that a lot of the low bit 
> precision from the 32bit is anyhow lost.
> 
> Indeed I could calculate what the integer LSB corresponds to in terms of 
> floating point representation and be more confident on the comparison 
> (i.e. if floating point results are not bitwise equal does not necessary 
> mean the integer result is going to be different).
> 
>> More importantly, however, is that normally you don't want full IEEE754
>> compliance - the overhead is too much.  Typically, FPU hardware does not
>> provide full support - you need to have extra software handling as well.
> 
> AFAIK the implementation we have is 'full IEEE754' and floating points 
> operations are using directly the hardware (unless gcc is configured 
> otherwise).
> 
>> In some aspects, non-compliant code can be significantly more
>> efficient.  For example, with "-ffast-math" in gcc, the compiler can
>> turn "x = y + z - y" into "x = z", while in compliant mode it has to do
>> the full calculation as stated, even though it is slower and gives less
>> accurate results.  And for square root, some FPU's may have a fast
>> "approximate square root" function that is good enough and much faster.
> 
> I see your point, this is certainly an extra bit of info since our 
> harwdare is not that performing either and a soft implementation might 
> actually be faster.
> 
>> The only way to be really sure of bit-accurate results is to use the
>> same software floating point library on each system.  But since the
>> "golden model" here is a system that you have no control of (matlab plus
>> external libraries - and different "standard PC's" can have different
>> details in their FPU's), it is basically impossible to guarantee
>> bit-accurate copies of the results.
> 
> Still can be a viable approach if the result is converted to integer 
> with a much lower precision. It is a bet though, since we cannot be 
> absolutely sure that it would be the case.
> 
> Al
> 

What this all boils down to is that the client wants to be sure that the
code is "correct" - but has an unreasonable and restrictive definition
of "correct".  It would be better to make this clear /now/, before you
end up contracted to produce code that is impossible to make (since it
must match the bit-exact results from matlab on "a standard PC", even
though these results could vary between different "standard PC's").

Figure out what the client /actually/ needs, such as a variation of +/-3
on the 10-bit PWM output, and tell them that this is a sensible goal.

[toc] | [prev] | [next] | [standalone]

#20079

On February 13th, 2015, David Brown explained:
|-------------------------------------------------------------------------|
|"What this all boils down to is that the client wants to be sure that the|
|code is "correct" - but has an unreasonable and restrictive definition   |
|of "correct".  It would be better to make this clear /now/, before you   |
|end up contracted to produce code that is impossible to make (since it   |
|must match the bit-exact results from matlab on "a standard PC", even    |
|though these results could vary between different "standard PC's").      |
|                                                                         |
|Figure out what the client /actually/ needs, such as a variation of +/-3 |
|on the 10-bit PWM output, and tell them that this is a sensible goal."   |
|-------------------------------------------------------------------------|

This reminds me of Chapter 97 Your Customers Do Not Mean What They Say
of Kevlin Henney (editor), "97 Things Every Programmer Should Know:
Collective Wisdom from the Experts", O'Reilly Media, 2010,
 HTTP://Shop.OReilly.com/product/9780596809492.do

With best regards,
Colin Paul de Gloucester

[toc] | [prev] | [next] | [standalone]

#20095

Hi Paul,

Colin Paul de Gloucester <not_a_real_email@address.com> wrote:
[]
> This reminds me of Chapter 97 Your Customers Do Not Mean What They Say
> of Kevlin Henney (editor), "97 Things Every Programmer Should Know:
> Collective Wisdom from the Experts", O'Reilly Media, 2010,
> HTTP://Shop.OReilly.com/product/9780596809492.do

Hey thanks for the pointer, I love those kinds of books and I'm already 
on it! Not that it will help me solve my problems with the customer but 
it's a good start ;-)

Al

[toc] | [prev] | [next] | [standalone]

#20101

On February 16th, 2015, Al posted:
|------------------------------------------------------------------------|
|"Colin Paul de Gloucester <not_a_real_email@address.com> wrote:         |
|[]                                                                      |
|> This reminds me of Chapter 97 Your Customers Do Not Mean What They Say|
|> of Kevlin Henney (editor), "97 Things Every Programmer Should Know:   |
|> Collective Wisdom from the Experts", O'Reilly Media, 2010,            |
|> HTTP://Shop.OReilly.com/product/9780596809492.do                      |
|                                                                        |
|Hey thanks for the pointer, I love those kinds of books and I'm already |
|on it!"
|------------------------------------------------------------------------|

Hi Al,

You are welcome.

|------------------------------------------------------------------------|
|"Not that it will help me solve my problems with the customer but       |
|it's a good start ;-)                                                   |
|                                                                        |
|Al"                                                                     |
|------------------------------------------------------------------------|

You can't have everything :)

Regards,
Colin Paul

[toc] | [prev] | [next] | [standalone]

#20109

Hi Paul,

Colin Paul de Gloucester <not_a_real_email@address.com> wrote:
[]
> |------------------------------------------------------------------------|
> |"Not that it will help me solve my problems with the customer but       |
> |it's a good start ;-)                                                   |
> |                                                                        |
> |Al"                                                                     |
> |------------------------------------------------------------------------|
> 
> You can't have everything :)

<OT>
I did not know alpine could quote in such a 'fancy' way! Do you use 
anything on top of it? What about double quoting?
</OT>

Al

[toc] | [prev] | [next] | [standalone]

#20110

On 17/02/15 11:35, alb wrote:
> Hi Paul,
> 
> Colin Paul de Gloucester <not_a_real_email@address.com> wrote:
> []
>> |------------------------------------------------------------------------|
>> |"Not that it will help me solve my problems with the customer but       |
>> |it's a good start ;-)                                                   |
>> |                                                                        |
>> |Al"                                                                     |
>> |------------------------------------------------------------------------|
>>
>> You can't have everything :)
> 
> <OT>
> I did not know alpine could quote in such a 'fancy' way! Do you use 
> anything on top of it? What about double quoting?
> </OT>
> 
> Al
> 

Colin's style of quotation is ugly and non-standard, messes up threading
and branches, and is completely useless when there is more than one
level of quotation.  He has been asked many times, by many people, to
stop using it - and has always disregarded them.  So please do not
attempt to copy it.

[toc] | [prev] | [next] | [standalone]

#20112

On Tue, 17 Feb 2015 12:18:59 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 17/02/15 11:35, alb wrote:
>> Hi Paul,
>> 
>> Colin Paul de Gloucester <not_a_real_email@address.com> wrote:
>> []
>>> |------------------------------------------------------------------------|
>>> |"Not that it will help me solve my problems with the customer but       |
>>> |it's a good start ;-)                                                   |
>>> |                                                                        |
>>> |Al"                                                                     |
>>> |------------------------------------------------------------------------|
>>>
>>> You can't have everything :)
>> 
>> <OT>
>> I did not know alpine could quote in such a 'fancy' way! Do you use 
>> anything on top of it? What about double quoting?
>> </OT>
>> 
>> Al
>> 
>
>Colin's style of quotation is ugly and non-standard, messes up threading
>and branches, and is completely useless when there is more than one
>level of quotation.  He has been asked many times, by many people, to
>stop using it - and has always disregarded them.  So please do not
>attempt to copy it.

It looks like HTML quoting rendered into plain text.  Could be the
editor and he doesn't known how to turn it off.

George

[toc] | [prev] | [next] | [standalone]

#20113

On 17/02/15 15:26, George Neuner wrote:
> On Tue, 17 Feb 2015 12:18:59 +0100, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 17/02/15 11:35, alb wrote:
>>> Hi Paul,
>>>
>>> Colin Paul de Gloucester <not_a_real_email@address.com> wrote:
>>> []
>>>> |------------------------------------------------------------------------|
>>>> |"Not that it will help me solve my problems with the customer but       |
>>>> |it's a good start ;-)                                                   |
>>>> |                                                                        |
>>>> |Al"                                                                     |
>>>> |------------------------------------------------------------------------|
>>>>
>>>> You can't have everything :)
>>>
>>> <OT>
>>> I did not know alpine could quote in such a 'fancy' way! Do you use 
>>> anything on top of it? What about double quoting?
>>> </OT>
>>>
>>> Al
>>>
>>
>> Colin's style of quotation is ugly and non-standard, messes up threading
>> and branches, and is completely useless when there is more than one
>> level of quotation.  He has been asked many times, by many people, to
>> stop using it - and has always disregarded them.  So please do not
>> attempt to copy it.
> 
> It looks like HTML quoting rendered into plain text.  Could be the
> editor and he doesn't known how to turn it off.
> 

He's using a text-based email client/newsreader (alpine, a descendent of
the venerable pine), so it is unlikely that HTML is involved directly -
although it could be a poor attempt at imitating HTML quotations.

Either he thinks it is "cool" to be different from everyone else, or
someone else has configured his newsreader and he doesn't know how to
fix it.

[toc] | [prev] | [next] | [standalone]

#20115

On 17.2.2015 г. 17:47, David Brown wrote:
> On 17/02/15 15:26, George Neuner wrote:
>> On Tue, 17 Feb 2015 12:18:59 +0100, David Brown
>> <david.brown@hesbynett.no> wrote:
>>
>>> On 17/02/15 11:35, alb wrote:
>>>> Hi Paul,
>>>>
>>>> Colin Paul de Gloucester <not_a_real_email@address.com> wrote:
>>>> []
>>>>> |------------------------------------------------------------------------|
>>>>> |"Not that it will help me solve my problems with the customer but       |
>>>>> |it's a good start ;-)                                                   |
>>>>> |                                                                        |
>>>>> |Al"                                                                     |
>>>>> |------------------------------------------------------------------------|
>>>>>
>>>>> You can't have everything :)
>>>>
>>>> <OT>
>>>> I did not know alpine could quote in such a 'fancy' way! Do you use
>>>> anything on top of it? What about double quoting?
>>>> </OT>
>>>>
>>>> Al
>>>>
>>>
>>> Colin's style of quotation is ugly and non-standard, messes up threading
>>> and branches, and is completely useless when there is more than one
>>> level of quotation.  He has been asked many times, by many people, to
>>> stop using it - and has always disregarded them.  So please do not
>>> attempt to copy it.
>>
>> It looks like HTML quoting rendered into plain text.  Could be the
>> editor and he doesn't known how to turn it off.
>>
>
> He's using a text-based email client/newsreader (alpine, a descendent of
> the venerable pine), so it is unlikely that HTML is involved directly -
> although it could be a poor attempt at imitating HTML quotations.
>
> Either he thinks it is "cool" to be different from everyone else, or
> someone else has configured his newsreader and he doesn't know how to
> fix it.
>
>

Oh everybody please do not start such a nonsense, I thought we were past
that.

Dimiter

[toc] | [prev] | [next] | [standalone]

#20094

Hi David,

David Brown <david.brown@hesbynett.no> wrote:
[]
>> the extra bit I got recently is that the result is converted to an 
>> integer of 11bit which, a priori, means that a lot of the low bit 
>> precision from the 32bit is anyhow lost.
>> 
>> Indeed I could calculate what the integer LSB corresponds to in terms of 
>> floating point representation and be more confident on the comparison 
>> (i.e. if floating point results are not bitwise equal does not necessary 
>> mean the integer result is going to be different).
>> 
[]
> 
> What this all boils down to is that the client wants to be sure that the
> code is "correct" - but has an unreasonable and restrictive definition
> of "correct".  It would be better to make this clear /now/, before you
> end up contracted to produce code that is impossible to make (since it
> must match the bit-exact results from matlab on "a standard PC", even
> though these results could vary between different "standard PC's").

Sound advice. Indeed I underestimated the impact of this /restriction/ 
and since we are still in the conceptual phase it would be worth to give 
a heads up to everyone so that we won't fall short during testing.

> Figure out what the client /actually/ needs, such as a variation of +/-3
> on the 10-bit PWM output, and tell them that this is a sensible goal.

We know what's the precision required on the current output (like 0.1% 
FSR) and I could, given the current regulation response, provide what's 
the precision required at the output of the floating point calculation 
(with the float_to_int as last operation).

This would allow indeed to have a reasonable target for the verification 
and avoid unattainable objectives.

[toc] | [prev] | [next] | [standalone]

#20097

On 16/02/15 08:58, alb wrote:
> Hi David,
> 
> David Brown <david.brown@hesbynett.no> wrote:
> []
>>> the extra bit I got recently is that the result is converted to an 
>>> integer of 11bit which, a priori, means that a lot of the low bit 
>>> precision from the 32bit is anyhow lost.
>>>
>>> Indeed I could calculate what the integer LSB corresponds to in terms of 
>>> floating point representation and be more confident on the comparison 
>>> (i.e. if floating point results are not bitwise equal does not necessary 
>>> mean the integer result is going to be different).
>>>
> []
>>
>> What this all boils down to is that the client wants to be sure that the
>> code is "correct" - but has an unreasonable and restrictive definition
>> of "correct".  It would be better to make this clear /now/, before you
>> end up contracted to produce code that is impossible to make (since it
>> must match the bit-exact results from matlab on "a standard PC", even
>> though these results could vary between different "standard PC's").
> 
> Sound advice. Indeed I underestimated the impact of this /restriction/ 
> and since we are still in the conceptual phase it would be worth to give 
> a heads up to everyone so that we won't fall short during testing.
> 

The sooner you get this sorted, the better.  It is usual for there to be
a certain amount of re-negotiation of specifications during a project's
lifetime (since few customers really know /exactly/ what they need at
the beginning, and few developers know /exactly/ what they can deliver).
 But it is never a good idea to start out agreeing to something you know
is impossible!

>> Figure out what the client /actually/ needs, such as a variation of +/-3
>> on the 10-bit PWM output, and tell them that this is a sensible goal.
> 
> We know what's the precision required on the current output (like 0.1% 
> FSR) and I could, given the current regulation response, provide what's 
> the precision required at the output of the floating point calculation 
> (with the float_to_int as last operation).
> 
> This would allow indeed to have a reasonable target for the verification 
> and avoid unattainable objectives.
> 

That sounds a good plan.  It will also ensure that your hardware will
meet your goals (hint - 10-bit PWM is /not/ good enough for 0.1%
precision - the LSB in any signal is always noise).

[toc] | [prev] | [next] | [standalone]

#20099

Hi David,

David Brown <david.brown@hesbynett.no> wrote:
[]
> The sooner you get this sorted, the better.  It is usual for there to be
> a certain amount of re-negotiation of specifications during a project's
> lifetime (since few customers really know /exactly/ what they need at
> the beginning, and few developers know /exactly/ what they can deliver).
> But it is never a good idea to start out agreeing to something you know
> is impossible!

Couldn't agree more, we've spent nearly 4 months on spec clarifications 
and we're not done yet!

>> We know what's the precision required on the current output (like 0.1% 
>> FSR) and I could, given the current regulation response, provide what's 
>> the precision required at the output of the floating point calculation 
>> (with the float_to_int as last operation).
>> 
>> This would allow indeed to have a reasonable target for the verification 
>> and avoid unattainable objectives.
>> 
> 
> That sounds a good plan.  It will also ensure that your hardware will
> meet your goals (hint - 10-bit PWM is /not/ good enough for 0.1%
> precision - the LSB in any signal is always noise).

Sometimes a little bit of noise can help. Indeed the noise we get from 
the current reading is injected in the regulation loop and may help get 
the precision wanted. If precision is defined as RMS over the output 
current, my 1-2 LSB can provide a gaussian shape whose RMS (or sigma or 
stdev or FWHM) is exactly my 0.1%. I could have a 1bit output and attain 
the required precision if switching frequency is high enough.

This is a bit OT w.r.t. the current thread and is still an open question 
on my side. I'll post something one day on this other subject, but I'm 
not yet there.

Al

[toc] | [prev] | [next] | [standalone]

#20102

On 2/16/15 4:47 AM, alb wrote:
> Hi David,
>
> David Brown <david.brown@hesbynett.no> wrote:

>> That sounds a good plan.  It will also ensure that your hardware will
>> meet your goals (hint - 10-bit PWM is /not/ good enough for 0.1%
>> precision - the LSB in any signal is always noise).
>
> Sometimes a little bit of noise can help. Indeed the noise we get from
> the current reading is injected in the regulation loop and may help get
> the precision wanted. If precision is defined as RMS over the output
> current, my 1-2 LSB can provide a gaussian shape whose RMS (or sigma or
> stdev or FWHM) is exactly my 0.1%. I could have a 1bit output and attain
> the required precision if switching frequency is high enough.
>
> This is a bit OT w.r.t. the current thread and is still an open question
> on my side. I'll post something one day on this other subject, but I'm
> not yet there.
>
> Al
>

At that point the spec needs to be a limit on the error of the average 
signal over a specified time period, likely also with a limit on 
peak-to-peak ripple on the signal (remember, your PWM is likely to 
generate some ripple on the signal unless something on the other end is 
just decoding the PWM).

Note also that the ripple provides an effective upper limit on the 
possible precision of the results (which improves as the time period for 
the measurement gets longer).

And yes, noise in the output can get you past the quantization noise 
limit, as long as you can average over a long enough period of time. 
Years ago I built systems that measure values to much higher precision 
than the native ADC precision by time averaging, and sometimes needing 
to add a tiny bit of noise to make it work. You did need to make sure 
the system was stable enough that the value didn't change over the 
measurement period.

[toc] | [prev] | [next] | [standalone]

#20160

On Fri, 13 Feb 2015 16:23:15 +0100, David Brown wrote:

> What this all boils down to is that the client wants to be sure that the
> code is "correct" - but has an unreasonable and restrictive definition of
> "correct".

Or maybe they just want to be sure that they have a *precise*
specification in case they ever need to source perfectly-compatible parts,
or perform simulations or analysis whose results aren't rendered
meaningless by "minor" differences between implementations.

There are situations where you need different implementations to be able
to perform identical calculations on identical inputs and obtain
*identical* results, down to the least-significant bit. In such
cases, whether the results are "correct" is often less relevant than
whether they're consistent.

Key things to avoid are unsafe optimisations (-ffast-math etc,
i.e. anything which allows the compiler to pretend that floats
observe the same rules as reals), extended intermediate precision (use
-ffloat-store and/or -fexcess-precision=standard), fused multiply-add (use
-ffp-contract=off and/or -mno-fused-madd), and transcendental functions
(these invariably have to be implemented in software or avoided altogether).

[toc] | [prev] | [next] | [standalone]

#20084

On 13 Feb 2015 14:14:06 GMT, al.basili@gmail.com (alb) wrote:


>AFAIK the implementation we have is 'full IEEE754' and floating points 
>operations are using directly the hardware (unless gcc is configured 
>otherwise).

It technically may be compliant, but not necessarily in hardware.

I'm not aware of *any* implementation that's fully 754/854 compliant
in hardware.  Every chip I have ever seen leaves most rounding modes
and NaN handling to software/firmware.

George.

[toc] | [prev] | [next] | [standalone]

#20087

alb <al.basili@gmail.com> wrote:
 
> David Brown <david.brown@hesbynett.no> wrote:

>>> assuming two differently implemented FPU, both validated against the 
>>> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I 
>>> be sure that provided the inputs operands are the same the result would 
>>> be the same bit wise?
 
>> It is normal to view floating point operations as slightly imprecise -
>> there is a rule that you never compare floating point data with ==.

(snip)

> the extra bit I got recently is that the result is converted to an 
> integer of 11bit which, a priori, means that a lot of the low bit 
> precision from the 32bit is anyhow lost.

Are you sure the calculation should be done in floating point?
Without more details, I suspect it could be done in fixed point,
the results would not vary depending on implementations, and
everyone would be happy.

(There is only one question left, and that is the way division
works when one operand is negative.)
 
> Indeed I could calculate what the integer LSB corresponds to in terms of 
> floating point representation and be more confident on the comparison 
> (i.e. if floating point results are not bitwise equal does not necessary 
> mean the integer result is going to be different).

Small rounding differences can easily lead to differences when
converted to fixed point.
 
>> More importantly, however, is that normally you don't want full IEEE754
>> compliance - the overhead is too much.  Typically, FPU hardware does not
>> provide full support - you need to have extra software handling as well.
 
> AFAIK the implementation we have is 'full IEEE754' and floating points 
> operations are using directly the hardware (unless gcc is configured 
> otherwise).

I forget now exactly what "full IEEE754" is, but denormals are one
that you have to watch. Personally, I think denormals were a bad
idea, though.
 
(snip)

>> The only way to be really sure of bit-accurate results is to use the
>> same software floating point library on each system.  But since the
>> "golden model" here is a system that you have no control of (matlab plus
>> external libraries - and different "standard PC's" can have different
>> details in their FPU's), it is basically impossible to guarantee
>> bit-accurate copies of the results.

Or use fixed point.
 
> Still can be a viable approach if the result is converted to integer 
> with a much lower precision. It is a bet though, since we cannot be 
> absolutely sure that it would be the case.

-- glen

[toc] | [prev] | [next] | [standalone]

#20090

On 14.2.2015 г. 17:30, glen herrmannsfeldt wrote:
> alb <al.basili@gmail.com> wrote:
>
>> David Brown <david.brown@hesbynett.no> wrote:
>
>>>> assuming two differently implemented FPU, both validated against the
>>>> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I
>>>> be sure that provided the inputs operands are the same the result would
>>>> be the same bit wise?
>
>>> It is normal to view floating point operations as slightly imprecise -
>>> there is a rule that you never compare floating point data with ==.
>
> (snip)
>
>> the extra bit I got recently is that the result is converted to an
>> integer of 11bit which, a priori, means that a lot of the low bit
>> precision from the 32bit is anyhow lost.
>
> Are you sure the calculation should be done in floating point?
> Without more details, I suspect it could be done in fixed point,
> the results would not vary depending on implementations, and
> everyone would be happy.

Sometimes the choice to do something using an FPU is not because things
cannot be done using the integer unit but just because one needs the
horsepowers the FPU adds to the chip. Was the case with me on my
netMCA-3 design - the FPU did make things a bit more complicated but
using it was the only way to do what I did. Apart from the sheer
ops per clock cycle it (being 64 bit of course, 32 bit FPU-s are
pretty much useless) gave me the dynamic range I needed (32 bits
integers would not have sufficed and multiprecision would have
slowed things down beyond any practical usability).

> (There is only one question left, and that is the way division
> works when one operand is negative.)

Why is that, what pitfalls do you envisage? "Normally" one would
divide the absolute values and just xor the sign bits after that,
you must have something else/more to it than that in mind.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web