mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM7 + Wait States = wieviel MIPS?


Autor: Bri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe da mal eine dumme Frage bezüglich eines ARM7 von Atmel 
(AT91SAM7A2). Der ARM kann mit maximal 30MHz getaktet werden. Ein Takt 
ist also 33.3ns lang. Der Flash ist einer mit 55ns. Also habe ich 2 wait 
states im advanced memory controller eingestellt. Der Flash ist mit 
einem 16Bit Datenbus mit dem ARM verbunden. D.h. für 32 Bit ARM Befehle 
muss zwei mal gelesen werden. Das bedeutet doch, dass ein Befehl, der 
normal zur Ausführung 1 Takt benötigt, durch die wait states 5 (1 + 2 + 
2) Takte dauert. Wie wirkt sich die interne pipeline darauf aus? 
Benötigt der Befehl effektiv dann nur 1 Takt oder doch 5?

Der Hintergrund meiner Frage ist der, das ich eigentlich der Meinung bin 
bei der PLL als Faktor 5 eingestellt zu haben. (6MHz externer Quarz) Mit 
einer einfachen Schleife, 1.5Mio Durchläufen, einer Stoppuhr und einer 
LED hab ich aber so ca. 4-5 MIPS ermittelt, was für einen 30MHz ARM 
etwas enttäuschend wäre. Oder hängt das mit der Schleife zusammen, das 
die ein Leeren der pipeline und damit eine relativ niedrige 
Geschwindigkeit verursacht?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thumb instruction set verwenden, dann sind die Befehle nur 16 Bit breit. 
Das ist bei AT91 bei >30MHz auch aus internem Flash sinnvoll.

Für Durchsatztest ist eine kleine Schleife wenig sinnvoll, es sei denn 
man weiss ganz genau was da Zyklus für Zyklus abläuft, denn der 
Sprungbefehl rechnet sich etwas anders.

Besser: die Schleife mit 100 NOPs anfüttern, damit der Einfluss des 
Sprungbefehls entfällt.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MIPS werden mit dem Drystone test ermittelt und selbst da gibt es 
Mutationen. Offiziell hat der ARM7 bereits 1,9 CPI (clocks per cycle) im 
Schnitt fuer alle Befehle. Trotzdem kann der core 0,9 MIPS/MHz 
erreichen, das liegt an der Messmethode.
Der Tip von AK ist auf jeden Fall richtig, bei einem externen 16-bit Bus 
ist Thumb Code nicht nur kleiner sondern auch schneller. Wenn der Code 
jedoch von einem min. 32-bit Bus ohne WS ausgefuehrt wird, dann ist ARM 
code schneller. Ist was laengeres das zu erklaeren, ich hab das schon 
mehrmals versucht in der Vergangenheit.
Deine gemessenen 4-5 Mio Befehle / Sek erscheinen mir absolut 
realistisch bei der gegebenen Bus Struktur. Fuer kleine schnelle 
Routinen, z.B. Regelalgorithmen, diese Teile ins interne SRAM und von 
dort viel schneller abarbeiten. Das ergibt Geschwidigkeit dort wo du sie 
brauchst.

hth, Robert

Autor: Bri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für euro Infos. Das mit dem Thumb-Code hab ich schon gewusst. Ich 
hab jetzt auch mal die Messchleife etwas umgestellt und 1000 NOPs + 
Schleife gemacht. Es kommen jetzt so ca. 5,1 MIPS raus. Es scheint aber 
doch noch ein Problem mit der PLL zu geben. Ich habe grad über den JTAG 
Adapter das Clock Status Register ausgelesen und da waren die Bits für 
Master Clock enable und PLL enable seltsamerweise nicht gesetzt. Liegt 
das daran das ich den ARM mit "halt" angehalten habe?

@ Robert, also du meinst ich soll mir keine Sorgen machen, wenn der ARM 
nur 5Mio Befehle pro Sekunde ausführt, obwohl der core clock 30MHz ist 
(bzw. sein sollte)?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter der Annahme dass du ARM Code ausführst passt es doch perfekt. Pro 
16bit Wort benötigt der Bus bei 2 waitstates 3 Takte, macht 6 Takte pro 
Befehl. 30MHz/6=5.

Die Laufzeit des Befehls selbst spielt hier keine Rolle. Es bremst der 
instruction fetch. Befehle können letztlich nicht schneller ablaufen als 
sie aus dem Speicher geholt werden können (Caches oder LPC2000-MAM in 
kleiner Schleife mal ausgenommen).

Dieser AT91 ist nicht dafür gebaut, Befehle mit vollem Tempo aus 
externem Speicher ausführen zu können. Erst recht nicht wenn dieser 
Speicher nur 16bit breit ist.

Autor: Bri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich glaub ich muss mich damit abfinden, dieser AT91SAM7A2 ist nicht 
grad der Renner. :-) Aber das ist nicht weiter schlimm, es ist sowieso 
erstmal nur zum testen und lernen gedacht. Die andere Frage mit dem 
PLLEN und MCKEN hat sich erledit. Ich habe vom Programm aus die Register 
in den RAM schreiben lassen und dann per JTAG die Werte von dort 
gelesen. Also die PLL ist aktiviert und der Master clock auch.

Danke für eure Hilfe.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bri wrote:
> Ein Takt
> ist also 33.3ns lang. Der Flash ist einer mit 55ns. Also habe ich 2 wait
> states im advanced memory controller eingestellt.

Müsste hier nicht auch ein Wait-State reichen? Dadurch würde die 
Geschwindigkeit des Busses doch schon halbiert. Mit 3 Wait-States 
drittelst du doch den Durchsatz.

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.