Cortex M3/M4: ISR overhead

[Walter T. (nicolas)]

Cortex M3/M4: ISR overhead


Hallo zusammen,

ich arbeite mich gerade durch das ARM-Assembler-Tutorial, was mal wieder 
ein paar grundsätzliche Fragen auf den Tisch geworfen hat.

Wie groß ist eigentlich der Overhead durch den Aufruf einer ISR? So 
ziemlich alles, was ich dazu finde, beschäftigt sich nur mit der Latenz 
beim Aufruf der ISR (Stacking und Prefetch). Da wird allgemein von 12 * 
w Takten bis zum Laden der ersten Instruktion der ISR ausgegangen (mit w 
der Anzahl der wait states des Speichers).

(Zum Stacking und Wait States hier: 
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors 
)

Ich finde allerdings keine Informationen zum Verlassen der ISR. (Die 
Information, die zu finden ist, bezieht sich hauptsächlich auf das 
Aneinanderreihen unterschiedlicher ISRs.) Das unstacking wird wohl 
mindestens noch einmal 12 Takte benötigen. Oder mehr?

Wenn ich auf einem STM32F446 mit 168 MHz eine ISR mit 1 MHz und einer 
NOP-Instruktion aufrufe - welche Auslastung habe ich dann?

Stacking + Prefetch: 12 Takte * 5 Waitstates
NOP:                  1 Takt
Unstacking:          12(?) Takte * 5 Waitstates
---
Summe:              121 Takte

121 Takte * 1 MHz/168 MHz = 72% Auslastung durch die NOP-ISR?

Der Wert muss falsch sein - sonst würde gar nichts mehr gehen, wenn ich 
eine ISR mit 44 Takten mit 1 MHz aufrufe (und das habe ich getestet).

Also berücksichtige ich zumindest schon die Wait States falsch. Aber wie 
geht es richtig?

[mkfifoforum; /dev/null < forum > /dev/random & (Gast)]

Beitrag "Cortex M3 Interrupt"

https://developer.arm.com/documentation/dui0552/a/the-cortex-m3-processor/exception-model/exception-entry-and-return

[Walter T. (nicolas)]

Genau. Einer der typischen Beiträge und eines der Dokumente, bei denen 
nur der Eintritt und nicht der Rückweg behandelt wird.

[mkfifoforum; /dev/null < forum > /dev/random & (Gast)]

Walter T. schrieb:
> Genau. Einer der typischen Beiträge und eines der Dokumente, bei denen
> ... nicht der Rückweg behandelt wird.

Exception return

Exception return occurs when the processor is in Handler mode and 
executes one of the following instructions attempts to set the PC to an 
EXC_RETURN value:

    an LDM or POP instruction that loads the PC

    an LDR instruction with PC as the destination

    a BX instruction using any register.

The processor saves an EXC_RETURN value to the LR on exception entry. 
The exception mechanism relies on this value to detect when the 
processor has completed an exception handler. Bits[31:4] of an 
EXC_RETURN value are 0xFFFFFFF. When the processor loads a value 
matching this pattern to the PC it detects that the operation is a not a 
normal branch operation and, instead, that the exception is complete. 
Therefore, it starts the exception return sequence. Bits[3:0] of the 
EXC_RETURN value indicate the required return stack and processor mode, 
as Table 2.17 shows. ...

[Niklas G. (erlkoenig)]

https://developer.arm.com/documentation/ddi0337/h/programmers-model/exceptions/exception-handling?lang=en

* There is a maximum of a 12 cycle latency from asserting the interrupt 
to execution of the first instruction of the ISR when the memory being 
accessed has no wait states being applied. The first instruction to be 
executed is fetched in parallel to the stack push.

* Returns from interrupts similarly take twelve cycles where the 
instruction being returned to is fetched in parallel to the stack pop.

* Tail chaining requires 6 cycles when using zero wait state memory. No 
stack pushes or pops are performed and only the instruction for the next 
ISR is fetched.

[Walter T. (nicolas)]

@Viele Sonderzeichen
Stop failing the Turing Test!

Niklas G. schrieb:
> * Returns from interrupts similarly take twelve cycles

Danke!

Fehlen nur noch die Wait States

[Niklas G. (erlkoenig)]

Walter T. schrieb:
> Stacking + Prefetch: 12 Takte * 5 Waitstates

PS: Warum multiplizierst du die Takte mit den Waitstates? Die Waitstates 
gibt es nur beim Flash-Zugriff. Beim Exception-Eintritt/Austritt wird 
aber typischerweise lediglich auf das interne SRAM zugegriffen, es sei 
denn du hast einen externen SRAM/SDRAM dran... Lediglich das Laden der 
nächsten Instruktion aus dem Flash kann Waitstates bedeuten, aber das 
wird laut o.g. Zitat parallel zum Stack sichern/laden durchgeführt, 
ist also "gratis".

[Tassilo H. (tassilo_h)]

Warum eigentlich 5 Waitstates?

Die 5 Waitstates gelten doch für das Lesen aus dem ROM, aber der Stack 
wird doch wohl hoffentlich im internen RAM mit 0 Waitstates liegen. Also 
5 Waitstates für das Holen der ersten Instruktion, ggf. auch noch mal 
für den vorigen Zugriff auf die Vektortabelle, und das Stacking selber 0 
Waitstates...

[Walter T. (nicolas)]

Niklas G. schrieb:
> PS: Warum multiplizierst du die Takte mit den Waitstates?

Ich habe keine Ahnung, wie die wait states behandelt werden. Deswegen 
frage ich ja. Ich finde überall:

"
The interrupt latency listed in table 1 makes a number of simple 
assumptions:

    The memory system has zero wait state (and with resources not being 
used by other bus masters)
    The system level design of the chip does not add delay in the 
interrupt signal connections between the interrupt sources and the 
processor
    The Interupt service is not blocked by another current running 
exception/interrupt service
    For Cortex-M4, with FPU enabled, the lazy stacking feature is 
enabled (this is the default)
    The current executing instruction is not doing an unaligned 
transfer/bitband transfer (which can take 1 extra transfer cycle)
"
In Tabelle 1 stehen eben jene 12 Takte für M3/M4.

In einem anderen Dokument hatte ich eine Aussage in der Art "bei 2 wait 
states erhöht sich das auf 22 Takte" gelesen. Das Dokument war (glaube 
ich) von Joseph Yiu. Weil der nicht dafür bekannt ist, Unsinn zu 
schreiben, habe ich das sehr ernst genommen. Aber ich finde es gerade 
nicht wieder.

Deswegen die Unsicherheit, wie die berücksichtigt werden sollen.

[Nachtrag] Ich bin meine Browser-Historie durchgegangen und finde diese 
"22-Takte"-Aussage nicht wieder. Also wohl ein Verleser.

Komplett ohne Einfluss kann der Wert aber auch nicht sein. Sonst wäre 
die obige Annahme nicht nötig.

[Niklas G. (erlkoenig)]

Walter T. schrieb:
> The memory system has zero wait state (and with resources not being
> used by other bus masters)

Der SRAM hat meistens keine Wait States, es sei denn der DMA greift 
gerade darauf zu.

Walter T. schrieb:
> In einem anderen Dokument hatte ich eine Aussage in der Art "bei 2 wait
> states erhöht sich das auf 22 Takte" gelesen.

Wait States worauf? Wenn die sich auf den SRAM beziehen, ist das klar. 
Aber IIRC haben die meisten SRAMs von Mikrocontrollern keine Wait 
States. Allerdings brauchen die LDR/STR-Instruktionen 2 Takte statt 
einem, aber das ist kein SRAM-Waitstate sondern eine Eigenschaft des 
Prozessorkerns, und der Exception-Ein/Austritt des Prozessorkerns 
braucht eben 12 Takte.

Ganz anders sieht das übrigens bei den Cortex-A aus: Dort kann ein 
Zugriff auf das externe SDRAM schnell mal Hunderte Takte brauchen, und 
außerdem gibt es kein automatisches Stacking der Register, sondern nur 
ein sehr begrenztes Banking. Die Software muss dort im Exception-Handler 
die Register sichern, was dann auch Assembler erfordert.

[Walter T. (nicolas)]

Niklas G. schrieb:
> Der SRAM hat meistens keine Wait States, es sei denn der DMA greift
> gerade darauf zu.

Okay, so kann man "memory system" natürlich auch lesen.

Also wäre die Rechnung einfach:

Stacking + Prefetch ISR:     12 Takte
NOP:                          1 Takt
bl:                           2 Takte
Unstacking + Prefetch main() 12 Takte
---
Summe:                       27 Takte

27 Takte * 1 MHz/168 MHz = 16% Auslastung durch die NOP-ISR

Das ist deutlich erfreulicher.