AURIX™ Forum Discussions

[User19650]

Hi All,

I have a piece of code which makes use of divisions. The fixed-point version was guaranteed to not cause exception, because of the data flow through the algorithm (still required commenting for QA).
The numerator and denominator come from ADC readings, so absolute precision is limited.

I'm moving the code to single-precision floating point on Aurix.
In this case, I see an option in replacing the division (DIV.F) with a multiplication by the square of the reciprocal sqrt, obtained by using QSEED.F, with a single Newton-Raphson iteration.

Theoretically - from the FPU timing table - the 2 options should have very similar latency, but the repeat rate could favour the reciprocal sqrt, which could be a factor, because there's more than one division to calculate.
Additionally, the "guaranteed no exception" would not need justification in this case.

Has anyone tried something similar ?

Is QSEED.F supported by compilers or should I get down writing assembly code to make use of it ?

[NeMa_4793301]

I don't believe the compilers emit qseed. There is a DSPLib library that has some functions that use qseed, as well as other hand-crafted assembly optimizations.

It's on MyICP here:
https://myicp.infineon.com/sites/microcontrollers-aurix_customer_doc/Lists/MyICP%20Customer%20Docume...

[User13836]

The TASKING C compiler won't generate the qseed.f instruction. But the sqrtf library function is using this instruction in the flavor using the hardware FPU (libcs_fpu.a). Here it's used in an inline assembly code sequence:

/* get reciprocal of the square root (6.75 bits accuracy) */
__asm(" QSEED.F %0,%1 \n": "=d" (xn):"d" (arg): );

Best regards,
Ulrich

TASKING tools support staff

[User19650]

Thx for the prompt reply.

That is my impression as well - been looking through Tasking libraries and there's no reciprocal sqrt entry there.

[User19650]

Thanks ulrichk.

That's useful.