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?
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.
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
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)?
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.
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.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.