ARM9 processor clock vs. effectiver clock (AT91SAM9260)

[c.b. (Gast)]

Hallo zusammen,

ich kämpfe seit Tagen mit dem Verständnis für das Clocksystem des 
AT91SAM9260. Ich hoffe ich kann meine Frage halbwegs verständlich 
formulieren...

Ich verwende einen Atmel AT91SAM9260 (ARM9). Code wird aus externem 
SDRAM (32bit Anbindung) ausgeführt. PLLA ist auf ~200MHz konfiguriert. 
Der Master Clock Controller ist so konfiguriert, dass am Procezzor 
200MHz ankommen und an der Bus Matrix 100Mhz. Instruction Cache ist 
deaktiviert.

Die 100Mhz kann ich am SDRAM messen und die 200MHz habe ich über den 
Clock-Output verifiziert.

So weit so gut. Auf den ersten Blick scheint alles zu stimmen...

Nun habe ich zu Testzwecken folgenden Programmausschnitt verwendet um 
eine LED zu toggeln. Für das toggeln benötigt der ARM exact 20 CPU 
Zyklen.

// Main loop
while (1)                       // 1 cycle
{
    PIO_Clear(&pinsLeds[0]);    // 6 cycle
    asm("nop \n"                // 1 cycle
        "nop \n"                // 1 cycle
        "nop \n"                // 1 cycle
        "nop \n");              // 1 cycle
    PIO_Set(&pinsLeds[0]);      // 6 cycle
    asm("nop \n"                // 1 cycle
        "nop \n"                // 1 cycle
        "nop \n");              // 1 cycle
}

Ich hätte nun erwartet, dass meine LED mit 10 MHz toggelt. Tut Sie aber 
nicht. Sie toggelt mit 600kHz! Aktiviere ich nun den Instruction Cache 
so toggelt die LED mit 2,5MHz.

Kann es sein, dass mich das SDRAM (100MHz) ausbremst? (Refesh ect...)

Ich hab einfach keine Erkärung dafür und hoffe nun auf diesem Weg eine 
Antwort zu bekommen.

Vielen Dank schonmal vorab.

[Marcus H. (mharnisch)]

c.b. schrieb:
> Instruction Cache ist deaktiviert.

Seufz! Alle ARM Applikationsprozessoren (also ab ARM92x, ARM94x)
sollten in jedem Fall mit eingeschalteten Caches betrieben
werden. Sonst hast Du von Deinen 200MHz Core Takt nicht viel.

> Nun habe ich zu Testzwecken folgenden Programmausschnitt verwendet um
> eine LED zu toggeln. Für das toggeln benötigt der ARM exact 20 CPU
> Zyklen.

Wie kommst Du darauf? Das hängt von mehreren Dingen ab:

1. Was macht der Compiler aus dem Code? Wieso benötigt ein while(1)
   einen Taktzyklus?

2. Welchen Takt/Latenz hast Du am PIO? Der hängt ja nicht direkt an
   der Busmatrix, sondern am APB Bus.

3. Wie schnell werden die Instruktionen geladen?

> Ich hätte nun erwartet, dass meine LED mit 10 MHz toggelt. Tut Sie aber
> nicht. Sie toggelt mit 600kHz! Aktiviere ich nun den Instruction Cache
> so toggelt die LED mit 2,5MHz.

Siehst Du!

> Kann es sein, dass mich das SDRAM (100MHz) ausbremst? (Refesh ect...)

Klar. Der Refresh kommt jedoch nur selten dazwischen. Solange der
I-Cache nicht angeschaltet war, wird jede Instruktion als
Einzelzugriff aus dem SDRAM geladen.

Gruß
Marcus

[c.b. (Gast)]

Marcus Harnisch schrieb:
> c.b. schrieb:
>> Instruction Cache ist deaktiviert.
>
> Seufz! Alle ARM Applikationsprozessoren (also ab ARM92x, ARM94x)
> sollten in jedem Fall mit eingeschalteten Caches betrieben
> werden. Sonst hast Du von Deinen 200MHz Core Takt nicht viel.

War nur zu Testzwecken. In der späteren Applikation ist der Cache 
natürlich angeschaltet.

Marcus Harnisch schrieb:
>> Nun habe ich zu Testzwecken folgenden Programmausschnitt verwendet um
>> eine LED zu toggeln. Für das toggeln benötigt der ARM exact 20 CPU
>> Zyklen.
>
> Wie kommst Du darauf? Das hängt von mehreren Dingen ab:
>
> 1. Was macht der Compiler aus dem Code? Wieso benötigt ein while(1)
>    einen Taktzyklus?

Ich hab die Assemblerbefehle der Testroutine gezählt :-)

Marcus Harnisch schrieb:
> 2. Welchen Takt/Latenz hast Du am PIO? Der hängt ja nicht direkt an
>    der Busmatrix, sondern am APB Bus.

Das ist interessant. Dem muss ich mal auf die Schliche gehen...

Marcus Harnisch schrieb:
>> Ich hätte nun erwartet, dass meine LED mit 10 MHz toggelt. Tut Sie aber
>> nicht. Sie toggelt mit 600kHz! Aktiviere ich nun den Instruction Cache
>> so toggelt die LED mit 2,5MHz.
>
> Siehst Du!

2,5MHz ist trotz aktiviertem Cach noch weniger als die erwarteten 10MHz.

[abc (Gast)]

Hallo,

ich kenn die SAM9 jetzt nicht im einzelnen, aber sind ja die nachfolger 
des RM9200. Ich hab dort auch eine weile gebraucht, um den ARM Kern auf 
volle leistung zu bringen. beim RM9200 gabs eine stelle wo man einen 
vorteiler für den Core takt einstellen konnte / welcher clock (MCK PLLA 
PLLB SCLK HCLK) verwendet werden soll, und wie der core tackt mit dem 
MCK synchronisiert werden soll. ggf gibts das immer noch, und es liegt 
dort ein problem vor.

ggf läuft er auch auf den 48 MHZ für den USB Part?

gruss

[c.b. (Gast)]

abc schrieb:
> beim RM9200 gabs eine stelle wo man einen
> vorteiler für den Core takt einstellen konnte / welcher clock (MCK PLLA
> PLLB SCLK HCLK) verwendet werden soll, und wie der core tackt mit dem
> MCK synchronisiert werden soll

Kann man einstellen. Clock ist PLLA vorteiler ist 0 somit sollte der 
core mit 200MHz laufen. MCK läuft mit 100MHz (gemessen)

abc schrieb:
> ggf läuft er auch auf den 48 MHZ für den USB Part?

Nein.

[Marcus H. (mharnisch)]

c.b. schrieb:
>> 1. Was macht der Compiler aus dem Code? Wieso benötigt ein while(1)
>>    einen Taktzyklus?
>
> Ich hab die Assemblerbefehle der Testroutine gezählt :-)

Und jeder Befehl dauert einen Taktzyklus?

> 2,5MHz ist trotz aktiviertem Cach noch weniger als die erwarteten 10MHz.

Aber so weit weg auch wieder nicht.

Poste doch mal den Assembler Code. Die Routine ist ja wahrscheinlich 
nicht so groß.

Gruß
Marcus

[cb (Gast)]

Marcus Harnisch schrieb:
> Poste doch mal den Assembler Code. Die Routine ist ja wahrscheinlich
> nicht so groß.

Werd ich gleich morgen früh erledigen (Sorcen hab ich nur in der Firma).

Kann es sein dass das Schreiben in PODR Register 2 MCK Zyclen benötigt 
(den Teil im Datenblatt verstehe ich nicht...) Dann wäre ich ja schon 
bei 5MHz.