C674x FastRTS : Resource conflict exception

That exception appears to be coming from sysbios.  Try the BIOS forum.

And a comment that might be relevant ...  These expressions combine together 16-bit shorts and 64-bit doubles.  That's legal C, but it is rather unusual.

Thanks and regards,

-George

The only possible way I see for an exception to occur because of the MPYDP is if the function sindp has a double-precision floating-point instruction just before its return, probably in the delay slots of the return branch.  Is this the case?

I assume you're aware the two versions of code produce different values.  It's no surprise that the generated code is different.

Thanks for your answers

I am using SYSBIOS.

I see (now) the difference beetween the two versions of code. In the first  case, I compute 0x4000*sin(0)  using  floating point, then convert to a short

In the second case, I convert sin(0) to a short, and multiply this short by 0x4000 (by shifting)

Double precision sinus is used.  Problem does not occur with Single precision (sinsp),  Problem does not occur with sin(1).

Archaeologist said:

The only possible way I see for an exception to occur because of the MPYDP is if the function sindp has a double-precision floating-point instruction just before its return, probably in the delay slots of the return branch.  Is this the case?

  Here is the assembly code  of  sindp(0) exit

(I linked c674xfastMath.lib and do not used mathlinb c or asm source)

LTpi: ; label if no arg. reduction
mpydp .m1 A5:A4, A5:A4, A7:A6 ; F = A*A
|| lddw .d2 *+B2[3], B5:B4 ; T = r8
|| extu .s1 A5,1,21,A2 ; reduced exp
|| mvkl .s2 1023-20,B1 ; MIN exp

cmplt .l1x A2,B1,A2 ; V = true for small exp
|| extu .s1 A1,31,0,A1 ; move sign to bit 31

lddw .d2 *+B2[4], A1:A0 ; S = r7
|| mv .l2x A1,B0 ; sign = bit 31 position

[A2] b .s2 b3 ; return small answer exit
|| [A2] or .l1x A5,B0,A5 ; set sign bit for small ans

nop 5 ; wait for F (or take b b3)

 ...

(*correction*)

(A2 was 1) next is not executed

Another problems.

In expsp.asm  and atansp.asm

.sect text should be replaced by .sect ".text:hand"

Otherwise code is not correctly linked. (In DSP L1P RAM) in my case.

Hi Pierre,

I was wondering if the issue with sindp causing a resource conflict exception was ever resolved? We're having a similar issue: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/130265/467600.aspx.

Thanks

Pierre,

We (Eric and I) tracked this down to the small answer return path of the sindp and cosdp functions (they are identical with a few extra lines for the cosdp function).  The m1 unit isn't allowed enough delay before the return branch and is still writing to register A7 on the first operation after returning.  If this next operation writes to A7, an exception is issued.  Here's the code from sindp starting at the mpydp instruction:

LTpi:                                           ; label if no arg. reduction

        mpydp   .m1     A5:A4, A5:A4, A7:A6     ; F = A*A

||      lddw    .d2     *+B2[3], B5:B4          ; T = r8

||      extu    .s1     A5,1,21,A2              ; reduced exp

||      mvkl    .s2     1023-20,B1              ; MIN exp

        cmplt   .l1x    A2,B1,A2                ; V = true for small exp

||      extu    .s1     A1,31,0,A1              ; move sign to bit 31

        lddw    .d2     *+B2[4], A1:A0          ; S = r7

||      mv      .l2x    A1,B0                   ; sign = bit 31 position

   [A2] b       .s2     b3                      ; return small answer exit

|| [A2] or      .l1x    A5,B0,A5                ; set sign bit for small ans

        nop             5                       ; wait for F (or take b b3)

A single nop between lddw || mv and the branch call should be sufficient to fix the vulnerability.  As for why the multiply in conjunction with the sindp call is at fault, it may have something to do with code that compiles into using the A7 register on the return.  We use sindp everywhere in our code, but only had issues when doing double precision multiplies on the results.

Hope this helps,

Geoff