• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 548 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6713B: NAN resulting from floating point match even FADCR and FMCR round mode set to 0

steven avritch
Prodigy 60 points
Part Number: TMS320C6713B

We are running a simple filter recursion equation y(n) = b0*x(n) + b1*x(n-1) + b2*x(n-2) - a0*y(n-1) - a1*y(n-2)

We had a case where a certain combination of filter coefficients cause the filter to become unstable resulting in overflow.

Under some cases, we get a filter output of infinity (0x7F800000) ... this is the expected behavior.

However, in other cases, we get a filter output of NaN (0x7FFFFFFF).  This is not expected.

We are setting the round mode in FADCR and FMCR to their default value of 0 (Round toward nearest representable floating-point number)

So the question... why could either a ADDSP or an MYPSP produce a NaN value of 0x7FFFFFFF.  Shouldn't the ALU be forcing the output to a valid floating point number (even if that number is infinity?

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the team.
    Can you please share if you use Processor SDK RTOS? Which version?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 60 points

    We are not using any COTS RTOS, libraries, etc..   it is 100% our own embedded software.

    But I do believe we have the answer.  Per the IEEE 754 Floating Point Standard, there are a number of combinations of SRC1 and SRC2 that result in an "indeterminate" result which produces the NaN.  The rounding function within the DSP does not eliminate the NaN for indeterminate results.  Thus, -infinity + infinity will create a NaN and rounding function will not alter the NaN result (no matter which rounding mode is selected).

    Our recursion equation had an unintended scenario where 2 of the summation terms could go to +/- infinity, thus creating the condition for a NaN per the IEEE standard.  Of course the NaN then propagates to all the further downstream math, compares, etc.

    Since the hardware doesn't have a method to eliminate possibility of a NaN (that I'm aware of), defensive coding is needed to detect and account for the NaN.

    Regards,

    Steve

  • 0 in reply to steven avritch
    TI__Guru** 114410 points
    Steve,

    The C6000 compiler does adhere to to IEEE 754 Floating Point Standard so what you have found is most likely the root cause for the NaN reported by your filtering code. Let us know if you need further assistance on this I can have some of our DSP compiler/design experts comment on this setup.

    Regards,
    Rahul