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.

RTOS/TMS320C6748: Understanding SYSBIOS benchmarks

Part Number: TMS320C6748
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

DSP:  C6748

SYSBIOS:  6.75.00.12

Board:  Custom hardware

I don't understand how to read the SYSBIOS timing benchmarks for HWI's.  What I'm trying to answer is:  "What is the SYSBIOS overhead for processing a HWI"?  To answer this question you have to consider three cases.  In all three cases, assume the application is running at the TASK level prior to the HWI, and it isn't executing within a HWI_disable() block of code, nor is it executing within a SLOOP.

1.  ISR doesn't post a semaphore to wake up a TASK, nor does it post a SWI.

2.  ISR posts a semaphore to wake up a TASK.

3.  ISR posts a SWI.

In all cases, the HWI fires and the CPU is off to the HWI vector table.  From there it goes to the HWI dispatcher, which eventually calls our ISR.  Our ISR executes, and then returns to the HWI dispatcher.  Dispatcher figures out where to go next.  I can profile my ISR to figure out how long it takes to execute, but I can't figure out how to piece together the rest of the times from the SYSBIOS benchmarks provided.

Interrupt Latency:  The SYSBIOS users guide says this is the time maskable interrupts are disabled.  Furthermore it says it is the time from the interrupt firing to the first instruction of the interrupt dispatcher.  Those two statements seem to contradict each other.  Not sure if I need this number or not.  The C674x number is 205 cycles.

HWI dispatcher prolog:  Defined in the SYSBIOS users guide as the time from when the interrupt fires until the user's ISR is called.  The C674x number is 127 cycles.  But wait, this is 127 cycles but the Interrupt Latency is 205 cycles.  I think this is the number I need to answer "Interrupt fires to execute first instruction in my ISR".

HWI dispatcher epilog:  Defined in the SYSBIOS users guide as the time from returning from my ISR to finishing up the HWI dispatcher work.  The C674x number is 159 cycles.  Seems like I'll need this number as well.

HWI dispatcher:  Not defined in the SYSBIOS users guide.  The C674x number is 281 cycles.  You would think this should be the prolog + the epilog, but it doesn't add up (close but not exact).

HWI to blocked TASK:  Defined in the SYSBIOS users guide to be time from the start of an ISR that posts a semaphore to the execution of the 1st instruction in the TASK.  However the diagram below this description includes the time from when the HWI fires and the prolog, which contradicts the description.  The C674x number is 445 cyles.

HWI to SWI:  Defined in the SYSBIOS users guide to the be time from the start of an ISR that posts a SWI, to the execution of the 1st instruction in that SWI.  However the diagram below this description includes the time from when the HWI fires and the prolog, which contradicts the description.  The C674x number is 271.

Here is my best guess at answering the three cases.

1.  prolog + epilog = 127 + 159 = 286 cycles.  This ignores Interrupt latency, because I think that is trying to define the total time maskable HWI's are disabled.  It also doesn't include the HWI dispatcher, because I think that is covered with the prolog + epilog.  Problably need to include one or the other in this calculation, but not sure.  Confused.

2.  prolog + epilog + HWI to blocked TASK = 127 + 159 + 445 = 731 cycles.  If the HWI to block task description is wrong and the diagram is right, then this should only be 445 cycles.  Confused.

3.  prolog + epilog + HWI to SWI = 127 + 159 + 271 = 557 cycles.  If the HWI to SWI description is wrong and the diagram is right, then this should only be 227 cycles.  But that can't be true, as 227 is less than the prolog + epilog.  Confused.

Thanks, Dean

  • Hi Dean,

    Dean Hofstetter said:

    Interrupt Latency:  The SYSBIOS users guide says this is the time maskable interrupts are disabled.  Furthermore it says it is the time from the interrupt firing to the first instruction of the interrupt dispatcher.  Those two statements seem to contradict each other.  Not sure if I need this number or not.  The C674x number is 205 cycles.

    The interrupt latency is the prolog plus the maximum time we disable interrupts in the kernel. 

    Dean Hofstetter said:

    HWI dispatcher:  Not defined in the SYSBIOS users guide.  The C674x number is 281 cycles.  You would think this should be the prolog + the epilog, but it doesn't add up (close but not exact).

    The Hwi Dispatcher is prolog + empty ISR + epilog. 

    Dean Hofstetter said:

    HWI to blocked TASK:  Defined in the SYSBIOS users guide to be time from the start of an ISR that posts a semaphore to the execution of the 1st instruction in the TASK.  However the diagram below this description includes the time from when the HWI fires and the prolog, which contradicts the description.  The C674x number is 445 cyles.

    It is the start of the ISR, not the start of the Hwi function. So the prolog is included. Ditto for the Swi description/diagram.

    Note: you can look at the file <BIOS install>\packages\ti\sysbios\examples\generic\benchloop\benchloop.c to see the code that generates these numbers.

    Does this clear things up?

    Todd

  • Interrupt latency.  After reading the definition in the SYSBIOS users guide, and then your definition above, I'm still confused.  Since SYSBIOS can be configured to have HWI's interrupt other HWI's, I would think the Interrupt latency would be closer to the HWI dispatcher prolog definition.  I think what you mean by this number is the following:

    1.  Assume HWI's can't interrupt other HWI's

    2.  Prolog + the part of the epilog where interrupts are still disabled.

    The benchmark "HWI dispatcher" should be renamed "Hardware Interrupt returning to same TASK".  At any rate, here is how I think I need to proceed to measure my HWI load on the system.

    1.  If my HWI doesn't include SYSBIOS calls to post a SWI or post a Semaphore, then use the "HWI dispatcher" time.

    2.  If my HWI includes a SYSBIOS call to a post a SWI, then use "Hardware Interrupt to SWI interrupt" time.

    3.  If my HWI includes a SYSBIOS call to post a Semaphore, then use "Hardware Interrupt to blocked Task" time.

    Finally it doesn't say if the benchmark numbers provided are:  min, max, or avg.  I'm assuming avg.  You would have to throw a few cycles onto all the numbers if you had a cache miss for each L1P or L1D (or both).

    Thanks, Dean

  • Dean Hofstetter said:

    The benchmark "HWI dispatcher" should be renamed "Hardware Interrupt returning to same TASK".  At any rate, here is how I think I need to proceed to measure my HWI load on the system.

    1.  If my HWI doesn't include SYSBIOS calls to post a SWI or post a Semaphore, then use the "HWI dispatcher" time.

    Yes

    Dean Hofstetter said:

    2.  If my HWI includes a SYSBIOS call to a post a SWI, then use "Hardware Interrupt to SWI interrupt" time.

    Yes

    Dean Hofstetter said:

    3.  If my HWI includes a SYSBIOS call to post a Semaphore, then use "Hardware Interrupt to blocked Task" time.

    Yes

    Dean Hofstetter said:

    Finally it doesn't say if the benchmark numbers provided are:  min, max, or avg.  I'm assuming avg.  You would have to throw a few cycles onto all the numbers if you had a cache miss for each L1P or L1D (or both).

    The are averaged.  The benchloop example is included within kernel releases to show exactly how the benchmarks are collected.