C674x FastRTS : Resource conflict exception

Pierre_

Intellectual 480 points

Other Parts Discussed in Thread: SYSBIOS

Hi All

Can Someone explain to me why:

In debug Configuration, using c674xfastMath.lib

Compiler command Line :

-mv6740 -g --gcc --define=AUDIOEXPANSION --define=HAVE_CONFIG_H --include_path="C:/Program Files/Texas Instruments/C6000 Code Generation Tools 7.2.4/include" --include_path="D:\PRODUITS_SOFT\C67\ING2/include/" --include_path="C:\Program Files\Texas Instruments\dsplib/include/" --include_path="C:\Program Files\Texas Instruments\psp/packages/" --diag_warning=225 --abi=coffabi

Linker Command Line :

-mv6740 -g --gcc --define=AUDIOEXPANSION --define=HAVE_CONFIG_H --diag_warning=225 --abi=coffabi -z -m"ING2.map" --warn_sections -i"C:/Program Files/Texas Instruments/C6000 Code Generation Tools 7.2.4/lib" -i"C:/Program Files/Texas Instruments/C6000 Code Generation Tools 7.2.4/include" --reread_libs --rom_model

The following part of code

short mysine;
mysine = 0x4000 * sin(0);

leads to an error :

Exception at 0xc00712d4
EFR=0x2 NRP=0xc00712d4
Internal exception: IERR=0x10
Resource conflict exception
ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0xc007f314, sp = 0xc0000fe8.
xdc.runtime.Err[C674X_0] or.raise: terminating execution

**adress does not match with the inserted screenshot ***

But the following part of code works.

short mysine;

mysine = sin(0);

mysine *=0x4000;

Exception at Instruction MPYDP.M1 A5:A4,A7:A6,A5:A4.

over 14 years ago

George Mock over 14 years ago

TI__Guru**** 244340 points

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

Archaeologist over 14 years ago

TI__Guru* 84225 points

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.

Pierre_ over 14 years ago in reply to Archaeologist

Intellectual 480 points

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

Pierre_ over 14 years ago in reply to Pierre_

Intellectual 480 points

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.

Eric Chin over 14 years ago in reply to Pierre_

Prodigy 120 points

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

Geoff Dolan over 14 years ago in reply to Eric Chin

Prodigy 50 points

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

Code Composer Studio™︎

Code Composer Studio forum

C674x FastRTS : Resource conflict exception