www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR-Definition von "issue latency" | execution time


Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte abschätzen wie lange ich für gewisse mathematische 
Operationen auf einem 32-bit AVR UC3 brauchen werde. Der Quellcode steht 
noch nicht, nur die analytischen Formeln.

Nun ist im Datenblatt (technical reference) nicht von "execution time" 
oder "clocks" die Rede sondern von issue latency. Das ist auch 
netterweise im Datenblatt definiert. Aber ich bin mir nicht sicher ob 
ich das richtig verstanden habe.

Im Datenblatt steht:
> Issue latency
> The issue latency represents the number of clock cycles required between
> the issue of the instruction and the issue of the following instruction.
> For some change-of-flow instructions, this includes the cycle penalty
> caused by the pipeline flush. The issue latency assumes, unless stated
> otherwise, that the instruction and data memories are able to return an
> instruction or data in a single cycle, which may not be true for slow
> program memories or data memories mapped on the HSB bus.

dabei ist eine "issue" definiert als:
> An instruction is issued when it leaves the ID stage and enters the EX stage.

Ist nun die "issue latency" die Zeit zwischen dem Erreichen der ID-Phase 
eines Befehls und dem Erreichen der ID-Phase des nächsten Befehls?
Das sagt mir doch im Prinzip wenig über die Zeit aus, die ein Befehl 
komplett braucht, oder?

Wie kann ich mir nun die Zeit ausrechnen die meine Berechnung wirklich 
braucht? Und zwar will ich nicht nur wissen, wann ich den nächsten 
Befehl in die Pipeline schieben kann, sondern auch wann ich das Ergbenis 
der Rechnung erhalte.

Dank im Voraus,
David

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Pipelining von Befehlen und Ausführungseinheiten gibt es zwei 
relevante Zeitparameter:

- Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung 
steht.

- Wie lange dauert es, bis der nächste Befehl bzw. die nächste Operation 
gestartet werden kann.

So kann ein partiell gepipelineter Multiplizierer beispielsweise 4 Takte 
benötigen, bis das Ergebnis feststeht, aber bereits nach 2 Takten die 
nächste Operation vertragen. Ein anderer vollständig gepipelineter 
Multiplizierer benötigt möglicherweise 5 Takte für das Ergebnis, 
akzeptiert aber in jedem Takt eine neue Operation. Welcher der beiden 
ist schneller?

Je komplexer eine CPU ist, desto schwieriger ist es, die Laufzeit auf 
dem Papier auszurechnen. Irgendwann geht es nur noch mit praktischer 
Erprobung, manchmal auch mit leidlich exakter Simulation.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: AVR im Betreff anführen, aber AVR32 meinen, ist wie links blinken 
und rechts abiegen ;-).

Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo A. K.,

irgendwie hast Du mir nicht wirklich auf meine Frage geantwortet oder 
übersehe ich da was?

A. K. schrieb:
> - Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung
> steht.
Genau das ist meine Frage.
>
> - Wie lange dauert es, bis der nächste Befehl bzw. die nächste Operation
> gestartet werden kann.
Das scheint ja die issue latency zu sein.

>
> So kann ein partiell gepipelineter Multiplizierer beispielsweise 4 Takte
> benötigen, bis das Ergebnis feststeht, aber bereits nach 2 Takten die
> nächste Operation vertragen. Ein anderer vollständig gepipelineter
> Multiplizierer benötigt möglicherweise 5 Takte für das Ergebnis,
> akzeptiert aber in jedem Takt eine neue Operation. Welcher der beiden
> ist schneller?

Das hängt ab wie viele Operationen ich ausführe. Bei n Operationen 
braucht man 4 + 2*(n-1) Takte (bei dem ersten Fall) bzw 5 + 1*(n-1) 
Takte beim anderen Fall. Dh bei nur einer Operation ist die erste Art 
der Multiplikation schneller. Sobald man mehr als 2 Operationen 
ausführen muss die ideal gepipelined werden können ist die zweite Art 
der Multiplikation schneller.
Aber warum fragst Du das?

Was ich eigentlich wissen wollte ist wo ich im Datenblatt zum AVR UC3 
[1] die Information finde wie lange die jeweiligen Instruktionen 
brauchen bis sie mir das Ergebnis liefern (also der erste Punkt in 
Deiner Auflistung).

A. K. schrieb:
> PS: AVR im Betreff anführen, aber AVR32 meinen, ist wie links blinken
> und rechts abiegen ;-).
Ähm, ok. Ich dachte AVR32 wäre eine Teilmenge von AVR. Schließlich 
beschriebt die ATMEL diese Familien unter einen Titel: [2] Aber Du hast 
wohl Recht, da das ja ein anderer MP ist.

Viele Grüße,
David

[1] http://atmel.com/dyn/resources/prod_documents/doc32002.pdf
[2] http://atmel.com/products/avr/default.asp?family_id=607

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David H. schrieb:

> irgendwie hast Du mir nicht wirklich auf meine Frage geantwortet oder
> übersehe ich da was?

Ich hatte irgendwann mal in AVR32 reingesehen aber keine Details im 
Kopf. Ähnliche Begriffe und verschiedene Zeiten abhängig von der 
Betrachtungsweise sind mir jedoch aus anderem Kontext gut bekannt und 
daraus ergab sich dieser nicht unmittelbar auf AVR32 bezogene Beitrag. 
In der Hoffnung es nützt dir was.

> Aber warum fragst Du das?

Eigentlich war das eine rhetorische Frage ;-). Sollte andeuten, dass es 
keine einfache Antwort gibt.

> Ähm, ok. Ich dachte AVR32 wäre eine Teilmenge von AVR.

AVR und AVR32 haben den Hersteller gemeinsam. Sonst nichts.

Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> irgendwie hast Du mir nicht wirklich auf meine Frage geantwortet oder
>> übersehe ich da was?
> [...] dieser nicht unmittelbar auf AVR32 bezogene Beitrag.
> In der Hoffnung es nützt dir was.
Ja die Unterscheidung der Zeitparameter war mit bewusst. Trotzdem danke! 
:-)

Wenn jemand genaueres weiß wäre ich für Details dankbar!
> Was ich eigentlich wissen wollte ist wo ich im Datenblatt zum AVR UC3
> die Information finde wie lange die jeweiligen Instruktionen
> brauchen bis sie mir das Ergebnis liefern.

Grüße, David

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David H. schrieb:

>> - Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung
>> steht.
> Genau das ist meine Frage.

Da die execution units des AVR32 anscheinen nicht pipelined sind ist das 
noch vergleichsweise einfach und man kann die Takte plus eventuelle im 
Text erwähnte Zusatztakte offenbar direkt einsetzen. Es wird allerdings 
durch den "accumulator cache" etwas verkompliziert, so dass auf manche 
Operationen (MAC in allen Varianten) je nach Kontext ggf. ein Takt drauf 
kommt.

> Das scheint ja die issue latency zu sein.

Es scheint hier keinen Unterschied zwischen den beschriebenen Varianten 
zu geben. Wobei man schon sehr genau lesen muss, denn im Text sind 
einige "wenns" und "abers" vergraben.

> Das hängt ab wie viele Operationen ich ausführe.

Auch, aber nicht nur. Wenn die aufeinanderfolgenden Operationen 
voneinander abhängen, dann ist die 4er Version immer schneller. Das 
war's worauf ich rauswollte.

Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo noch mal A. K.,

A. K. schrieb:
> David H. schrieb:
>>> - Wie lange dauert es, bis das Ergebnis eines Befehls zur Verfügung
>>> steht.
>> Genau das ist meine Frage.
> Da die execution units des AVR32 anscheinen nicht pipelined sind ist das
> noch vergleichsweise einfach und man kann die Takte plus eventuelle im
> Text erwähnte Zusatztakte offenbar direkt einsetzen.

Ja gut.
Also im Datenblatt steht
> This chapter presents the instructions in AVR32UC CPU, and the number of
> clock cycle they require to complete.
Da hätte ich erwartet, dass es eine tabellarische Übersicht gibt in 
der auch die execution cycles aufgelistet sind. Statt dessen steht diese 
Information verstreut im Kapitel "Instruction Cylce Summary" (einfach 
nach cycle suchen, nicht nach clock). Im letzten Unterkapitel "Code 
example" ist auch noch mal ein Beispiel mit den benötigten 
Ausführungszeiten aufgezeigt.

Was ich aber nicht gefunden habe ist, wie lange die Befehle der FPU 
brauchen. Ich nehme mal an das wird dann die issue latency (+1?) sein.

> durch den "accumulator cache" etwas verkompliziert, so dass auf manche
> Operationen (MAC in allen Varianten) je nach Kontext ggf. ein Takt drauf
> kommt.
Du meinst, wenn es dann nicht im Cache ist und noch geladen werden muss, 
dass dann kommt noch mindestens ein Takt drauf kommt?

>> Das scheint ja die issue latency zu sein.
> Es scheint hier keinen Unterschied zwischen den beschriebenen Varianten
> zu geben. Wobei man schon sehr genau lesen muss, denn im Text sind
> einige "wenns" und "abers" vergraben.
Meinst Du damit, dass also idR die execution cycles = issue latency?

>> Das hängt ab wie viele Operationen ich ausführe.
> Auch, aber nicht nur. Wenn die aufeinanderfolgenden Operationen
> voneinander abhängen, dann ist die 4er Version immer schneller. Das
> war's worauf ich rauswollte.
Ja stimmt. Das sollte wirklich nicht vergessen werden.

Bin jetzt schon weiter gekommen! Danke. Der Inhalt von den Datenblättern 
ist halt nicht trivial.

Grüße, David

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David H. schrieb:

> Was ich aber nicht gefunden habe ist, wie lange die *Befehle der FPU*
> brauchen. Ich nehme mal an das wird dann die issue latency (+1?) sein.

Da die FPU ausdrücklich als "optional" angeführt ist: Bist du sicher 
dass dein Exemplar überhaupt eine drin hat? Mein Eindruck ist, dass 
dieses Kapitel ein Vorgriff auf die Zukunft ist.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David H. schrieb:

> Meinst Du damit, dass also idR die execution cycles = issue latency?

So sieht es beim AVR32UC aus.

NB: Ich habe grad auf meiner Platte eine Techref vom AVR32AP gefunden, 
in der es durchaus einen Unterschied gibt. Aber dieser Core hat eine 
andere Pipeline.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf der Webseite finde ich keinen AVR32, bei dem eine FPU erwähnt wird. 
Ich denke nicht, das Atmel sowas verschweigen würde. Ich finde nur 
einiges Geschwurbel, das auf eine nicht näher dokumentierte zukünftige 
Version mit FPU vertröstet. Wenn du sowas brauchst, wär's vielleicht 
besser du suchst anderswo die Laufzeiten zusammen.

Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> David H. schrieb:
>
>> Was ich aber nicht gefunden habe ist, wie lange die *Befehle der FPU*
>> brauchen. Ich nehme mal an das wird dann die issue latency (+1?) sein.
>
> Da die FPU ausdrücklich als "optional" angeführt ist: Bist du sicher
> dass dein Exemplar überhaupt eine drin hat? Mein Eindruck ist, dass
> dieses Kapitel ein Vorgriff auf die Zukunft ist.
Ich habe das Gerät selber noch nicht. Ich bin im Moment nur am 
Schauen/Analysieren ;-).

A. K. schrieb:
> Auf der Webseite finde ich keinen AVR32, bei dem eine FPU erwähnt wird.
> Ich denke nicht, das Atmel sowas verschweigen würde. Ich finde nur
> einiges Geschwurbel, das auf eine nicht näher dokumentierte zukünftige
> Version mit FPU vertröstet.
Das habe ich bis vor kurzem auch so gesehen. Dann habe ich aber jemanden 
getroffen der auf dem EVK1100 (Eval Board von Atmel) ein MP mit FPU hat 
(angeblich). Genauer weiß ich es auch nicht.
Nur komisch, dass Atmel davon spricht, als ob es das schon gäbe: 
http://atmel.com/products/AVR/fpu.asp?family_id=607

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Zukunftsmusik:
> http://www.atmel.com/dyn/corporate/view_detail.asp...
Alles klar. Danke für den Link!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.