STM32F334: CCM Speedup

[Michael H. (overthere)]

Hallo,

der STM32F334 hat 64MHz, aber der Flash kommt nicht bei häufigen 
Sprüngen nicht nach und braucht daher 2 Waitstates wenn er springt. Bei 
72MHz zugar 3.

Jetzt habe ich mal nachgemessen wieviel Vorteil es bei einer iterativen 
Routine gibt: 1.09ms mit CCM und 1.57ms ohne CCM für max=10000

Mein persönliches Fazit: Es bringt etwas, häufig genutzen Code dahin zu 
verfrachten.

Edit: Mir ist bewusst, dass die funktion keinen Sinn macht...

uint64_t sumup(int max){
  int a=0;
  while(max>0){
    a=max;
    max=max-1;
   }
  return a;
}

[Samuel C. (dragonsam)]

Ich würde deinen Post gerne verstehen, weil es an sich ein interessantes 
Thema ist. Leider finde ich deine Sätze ziemlich unverständlich.

> der STM32F334 hat 64MHz, aber der Flash kommt nicht bei häufigen
> Sprüngen nicht nach und braucht daher 2 Waitstates wenn er springt. Bei
> 72MHz zugar 3.
Vor'm abschicken bitte selbst noch durchlesen.
Definiere häufig.

> Jetzt habe ich mal nachgemessen wieviel Vorteil es bei einer iterativen
> Routine gibt: 1.09ms mit CCM und 1.57ms ohne CCM für max=10000
Vorteil gegenüber was?

> Mein persönliches Fazit: Es bringt etwas, häufig genutzen Code dahin zu
> verfrachten.
Wohin zu verfrachten?

[./. (Gast)]

> Vorteil gegenüber was?
> Wohin zu verfrachten?

Ich hab den Post von Michael verstanden.
Allerdings hatte ich auch schon STM32 die ein CCM hatten in den Fingern.

[Diode (Gast)]

Dann mache doch nicht so spannend: Es geht darum, Code aus dem Flash ins 
interne RAM zu verlagern und den Code-Fetch dadurch zu beschleunigen.

[Uwe Bonnes (Gast)]

_C_ore _C_oupled _M_emory:
Extra RAM Bereich, der nur von der CPU angesprochen werden kann.

[Stefan (Gast)]

Das CCM hängt soweit ich weiß am D-Bus. Wenn da Code liegt ist der 
Zugriff darauf etwas umständlich bzw. der "Havard Vorteil" des 
simultanen Zugriffs auf Code und Daten geht verloren. Die STM32F7 haben 
noch zusätzlich 8kB die am I-Bus hängen. Die STM32F3 haben aber keinen 
Cache Controller. Daher ist der "CCM Code" wohl dennoch schneller.

Ich hatte mal Versuche mit Funktionen im RAM auf einem STM32F405 
gemacht. Da war die Ausführung einer Funktion aus dem Flash bei 168MHz 
etwas schneller als aus dem CCM. Das war übrigens keine Schleife sondern 
eine (Timer) ISR in der am Anfang und am Ende eine LED getoggelt wurde. 
Die CPU hat in der Zwischenzeit anderen Code ausgeführt.

Aber klar, es kommt immer auf die konkrete Anwendung an.

[Michael H. (Gast)]

Samuel C. schrieb:
> Ich würde deinen Post gerne verstehen, weil es an sich ein
> interessantes Thema ist. Leider finde ich deine Sätze ziemlich
> unverständlich.
Ich arbeite gerade am Literaturnobelpreis. :P
>
> der STM32F334 hat 64MHz, aber der Flash kommt nicht bei häufigen
> Sprüngen nicht nach und braucht daher 2 Waitstates wenn er springt. Bei
> 72MHz zugar 3.
>
> Vor'm abschicken bitte selbst noch durchlesen.
> Definiere häufig.
Code schaun? Unten? Im Prinzip bei jeder interation.
>
> Jetzt habe ich mal nachgemessen wieviel Vorteil es bei einer iterativen
> Routine gibt: 1.09ms mit CCM und 1.57ms ohne CCM für max=10000
>
> Vorteil gegenüber was?
Core coupled memory vs. Flash
>
> Mein persönliches Fazit: Es bringt etwas, häufig genutzen Code dahin zu
> verfrachten.
>
> Wohin zu verfrachten?

Ccm. Geht über den Befehl section in dem function prototype. Allerdings 
muss der Startupcode modifiziert werden.

[Michael H. (Gast)]

Danke  Stefan für die gute Erklärungen!

[Michael H. (overthere)]

Ich habe gerade nochmal nachrecheriert, daher ein kleine Ergänzung zu 
Stefans Posts:

Stefan schrieb:
> Das CCM hängt soweit ich weiß am D-Bus. Wenn da Code liegt ist der
> Zugriff darauf etwas umständlich bzw. der "Havard Vorteil" des
> simultanen Zugriffs auf Code und Daten geht verloren. Die STM32F7 haben
> noch zusätzlich 8kB die am I-Bus hängen. Die STM32F3 haben aber keinen
> Cache Controller. Daher ist der "CCM Code" wohl dennoch schneller.
Der CCM ist am gleichen Bus wie der Flash. Siehe Anhang. Also dadurch 
entsteht keine Verzögerung.

>
> Ich hatte mal Versuche mit Funktionen im RAM auf einem STM32F405
> gemacht. Da war die Ausführung einer Funktion aus dem Flash bei 168MHz
> etwas schneller als aus dem CCM. Das war übrigens keine Schleife sondern
> eine (Timer) ISR in der am Anfang und am Ende eine LED getoggelt wurde.
> Die CPU hat in der Zwischenzeit anderen Code ausgeführt.

Wenn man nicht springen muss im Flash (ganz böse Zungen sagen 
"Spagetticode"), dann kann der MCU soweit ich weiß ja die Daten 
vorladen. Und da muss er keine Waitstates einlegen. [Bin mir hier aber 
nicht 100% sicher.]

[Irgendwer (Gast)]

Michael H. schrieb:
> Wenn man nicht springen muss im Flash, dann kann der MCU soweit ich weiß ja die 
Daten vorladen.

Dafür ist ab dem Cortex-M3 sowas hier vorhanden um euch bei Sprüngen die 
Daten vorzuladen:
http://en.wikipedia.org/wiki/Branch_predictor
Nur manchmal wird halt "falsch geraten" und dann dauert es einige Takte 
bis die Pipeline wieder gefüllt ist.

[Stefan (Gast)]

> Stefan schrieb:
>> Das CCM hängt soweit ich weiß am D-Bus. Wenn da Code liegt ist der
>> Zugriff darauf etwas umständlich bzw. der "Havard Vorteil" des
>> simultanen Zugriffs auf Code und Daten geht verloren. Die STM32F7 haben
>> noch zusätzlich 8kB die am I-Bus hängen. Die STM32F3 haben aber keinen
>> Cache Controller. Daher ist der "CCM Code" wohl dennoch schneller.
> Der CCM ist am gleichen Bus wie der Flash. Siehe Anhang. Also dadurch
> entsteht keine Verzögerung.

Ist dieses "CCM-SRAM" nicht der neue Block im STM32F7? Im Refman vom 
STM32F40x/41x/42x/43x nennt sich das "CCM data RAM" und hängt laut 
Skizze nur am D-Bus.

[asdf (Gast)]

Stefan schrieb:
> Ist dieses "CCM-SRAM" nicht der neue Block im STM32F7?

Nö, CCM gibts schon länger z.B. im STM32F4 u.a.