how to accelerate HWI responce?

Which version of BIOS 6.x and XDC are you using?   Can you please provide complete version?

2 guesses:

(1)  CPU might not be running at full speed.   Use the ROV->Clock module view and check the time counter.  Default counter should update every 1ms.  If you run for 10seconds, you should see ~10,000 in this view.  Using my watch, I somehow I managed to run/halt at almost exactly 10 seconds in the screenshot below.

(2)  If you have code or data in external memory, make sure that your L1 and L2 cache are enabled.  And also check to make sure that the MAR bits for the memory regions on your board are enabled.  The picture below shows that L2 cache is disabled. 

You can enable the L2 by making a new platform using the platform wizard, or you can include 2 lines like the following in your .cfg file.  Be careful that you don't place any code or data in this same area as cache is shared between RAM and cache.  You can check your .map file to be sure you don't have conflict.

var Cache = xdc.useModule('ti.sysbios.family.c64p.Cache');
Cache.initSize.l2Size = Cache.L2Size_128K;

-Karl-

thanks for your reply, Karl.

I checked code as your say,

clock is right, 300MHz., and Cache is OK ( I use L1P 32K, L1D 32K as cache,) L2 is used in private.

I have a question:

what is C6748 's max interrupt response ability (with BIOS6)?

It seemed that It can't catch up to 100us-period interrupt sources,  as I test.

Is there any authority datasheet about such information?

btw, my bios version is :6.21.00.13

xdc version is :3.16.02.32

oh, I have another strange question:

In a HWI procedure, I append such code:

"Hwi_clearInterrupt(x);"

when program runing awhile, the HWI doesn't respond at all. why? How to locate the bug?

Karl, I traced Hwi responce, here is the code execution analysis:

that means:  

        After interrupt is asserted, It takes 6235 cycles to due with it and back to previous code.

       In worst situation, It takes 9000 cycles from step1 to step12.

       is this normal?

last Friday, I checked response with oscillograph.

the normally HWI response delay(Interrupt occur to enter C function) is 6~8us(12 us MAX.).

TMS320C6748 is 300MHz, which means it takes 1800~2400 cycles.

anyone, pls take a look.

Hi,

I've been able to replicate your results here in our lab. I'm investigating the behavior now and will report back soon.

Alan DeMars

SYS/BIOS Kernel Team

After running a few experiments here locally, I'm certain that the poor performance you're experiencing is entirely due to inefficient cache utilization.

Using the latest SYS/BIOS (6.32.02.39) and XDC (3.21.01.21) tools, I obtained the following relevant benchmark results using the default cache settings:

Hwi prolog             2422    /* this is interrupt-to-user ISR time in cycles */
Hwi epilog             1636    /* this is time to return from user ISR to background */
Hwi dispatcher         864     /* this is round trip from interrupt back to background with a nop ISR */

The Hwi prolog time maps pretty closely to the 2492 cycles getting to your ISR.

Notice that the total Hwi dispatcher time is significantly less than the simple addition of the prologue and epilog. This is due to all of the dispatcher code having been pulled into the cache by the two previous benchmark threads.

Here are the numbers I get by following Karl's suggestion of allocating 128K bytes of L2 Cache memory:

Hwi prolog             1780
Hwi epilog             558
Hwi dispatcher         398

I'm not sure exactly why the times improved so much. I'm not very familiar with the 674's L2 cache behavior.

Below are the numbers I get simply by re-running the benchmarks without resetting the board in between runs (ie preserving the cache contents):

Hwi prolog             396
Hwi epilog             215
Hwi dispatcher         264

The above behavior is what I expected. Once the dispatcher code has been pulled into cache, the interrupt-to-isr time should be VERY fast.

I strongly urge you to upgrade to the latest SYS/BIOS and XDCTOOLS which will allow you to more easily configure your L2 cache.

Alan

thanks a lot, Alan.

your last result sounds great. But I think It can hardly occure in "Real execution environment". Because from one interrupt to another, the CACHE may be flushed out totally.

I have a suggestion:  can you give user an options to locate "the core thread switch code".

So user can put these code into L2 cache, which could improve the SYS/BIOS 's performance.

I hope you're still out there Alan...

I have a similar problem.  My concern is consistency in responding to a particular interrupt. Right now it can vary by over 500ns!

1) I have used the System Analyzer.  I have looked and looked and looked but cannot understand how you are able to count the number of cycles during various parts of the HWi response.  Please elaborate.

2) I followed your suggestions putting HWL, KNL, vectors, heap, etc in L2 RAM.  L2 is set to half cache, half RAM.  There was no change to timing on the scope. But the oscilloscope may be fooling me.  I need to count response cycles.

Kurt --

Please open a new thread in the future.  We tend to ignore threads that are in the "closed" state.

Have you played with your interrupt mask?   You should make the mask for your important interrupt "ALL" and use "SELF" for the less important interrupts.  ALL will mask all other interrupts while your important interrupt is running.  And SELF will allow your important interrupt to preempt the less important interrupt.

Are you using the -mi10 or similar compiler option so that the compiler will not disable interrupts for long periods?

-Karl-