Hi Leute ! Hab eine kurze Verständnissfrage: In den Datenblättern steht zB max Frequenz 96 MHz 1.25DMIPS/MHz bei 0 Waitestates! Wie weiß ich den wieviele waitstaits ich den benötige? Bzw wovon ist das abhängig bei einem Controller?
>Bzw wovon ist das abhängig bei einem Controller?
Der Taktfrequenz mit dem Flash-Zugriffe ausgeführt werden
Sowas findet man raus bei innigem Studium des Datasheet oder User Manuals oder Reference Manuals oder Flash Programming Manuals oder wie immer das Ding beim jeweiligen Controller heisst. Allerdings sind 0 Waitstates bei 96MHz "etwas unüblich" und soll wohl heissen, dass der Code im RAM läuft oder der Controller einen Cache hat und der besseren Zahlen wegen von 100% Hitrate ausgegangen wird. Aus dem Flash sind bei solchen Frequenzen 3-5 Waitstates üblich.
danke für die antworten! was bedeutet aus dem RAM? Wird der Code vom Flash ins Ram kopiert und von dort aus exekutiert?
Hi Leute! Danke für eure Infos! Nur irgendwie komm ich nicht weiter .... zB der STR9 von ST .... wo finde ich bitte wieviele Waitsates ich wo benötige? Oder beim STR32? Bin die DOCs durchgegangen, jedoch werd ich einfach nicht schlau daraus! Hat jemand vl noch einen Tipp?
Wenn ich mich recht erinnere findet man das beim STR9 nicht im Manual zum Controller, sondern im separaten Manual zum Flash - ist ja auch ein separater Die, insofern logisch. Flash Programming Manual oder so ähnlich. Beim STM32 steht das in der Reference.
Hallo Gast1, sieht aus, als hättest Du da einen ARM Cortex, vielleicht Cortex-M3. Die "Übersetzung" wird etwa heißen: "Bis zu einer maximalen Frequenz von 96MHz wird ein Programm aus dem Flash ohne Wartezyklen ausgeführt und der Prozessor erreicht 1.25DMIPS/MHz." Es gibt Prozessoren, die "nur" bis ca. 72MHz aus dem Flash ohne Waitstates ausführen können, so weit ich weiß viele von ST. Es gibt aber auch einige die bis 100MHz ohne waitstates auskommen, z.B. Toshiba. Das ändert sich aber ständig. Bei höheren Frequenzen werden mindestens ein Waitstate benötigt bzw. Ausführung aus RAM notwendig. Ab wann waitstates notwendig werden und wieviele hängt vom implementierten Flash ab und ob noch Besonderheiten eingebauten wurden. Gruß
Michael Leusink schrieb: > sieht aus, als hättest Du da einen ARM Cortex, vielleicht Cortex-M3. > Die "Übersetzung" wird etwa heißen: Ich kenne keine ARM-Controller im Bereich 60-100MHz Fetch-Zyklus, die beim Flashzugriff keine Waitstates haben - jedenfalls nicht von NXP, ST, Atmel. Sowas wie 1.25 DMIPS/MHz sind Werbezahlen von ARM, die der Hersteller des Controller direkt durchreicht. Demzufolge erreicht der von ARM eingekaufte Core theoretisch eine Performance von 1.25DMIPS/MHz, wenn keine Waitstates auftreten. Das heisst durchaus nicht, dass aus dem Flash keine Waitstates auftreten, zumal in dieser(!) Aussage auch kein Flash erwähnt wird. > Es gibt Prozessoren, die "nur" bis ca. 72MHz aus dem Flash ohne > Waitstates ausführen können, so weit ich weiß viele von ST. Der STM32 benötigt bei 72MHz sehr wohl Waitstates. Der STR9 bei den üblichen 96MHz ebenfalls, und nicht zu knapp. Flash-Waitstates bedeuten jedoch aber nicht automatisch, dass damit der Befehlsablauf entsprechend abgebremst wird. Pufferung, Prefetching und Caches können helfen, Wartezeiten zu vermeiden. Der STR9 hat beispielsweise eine Art Branch-Target-Cache und das Pendant beim LPC1700 hat recht viel Ähnlichkeit mit einem normalen kleinen Cache für's Flash.
@A.K. Bitte gib mir doch Hinweise, wo ich die von Dir besagten Informationen finde, z.B. Waitzyklen bei ARM Prozessoren zwischen 60 und 100MHz. Bis dahin empfehle ich folgende Informationen http://www.st.com/stonline/stappl/cms/press/news/year2010/t2477.htm http://www.toshiba-microcontroller.com/sites/CortexM3FamilyIntro.htm Du kannst, richtiger weise, argumentieren, dass dies Herstellerseiten sind und alles nur Marketinggefasel. Dhrystone Daten waren immerschon ein Grund für Diskussionen und Zweifel. Gruß
Man muss präziserweise unterscheiden zwischen - den Waitstates beim Flash-Zugriff, - der Auswirkung auf den Programmablauf. Eine Aussage wie "To release the processor’s full 150 DMIPS performance at this frequency the accelerator implements an instruction pre-fetch queue and branch cache, enabling program execution from Flash at up to 120MHz with zero wait states." besagt wie ich schon skizzierte nur, dass es Mechanismen gibt, die den Einfluss der Zugriffszeit auf den Flash-Speicher für laufende Programme im Idealfall auf 0 reduzieren können. Die Begriffswahl von ST ist dabei allerdings technisch betrachtet etwas unglücklich, denn Waitstates treten durchaus auf, werden explizit auch als solche abhängig von der Taktfrequenz konfiguriert. Nur wirken sie sich dank des erwähnen Prefetchings und der Caches nicht so stark aus.
Konkret findet man das zu den bisherigen(!) STM32 beispielsweise im PM0042 Flash Programming Manual auf Seite 25, mit 2 obligatorischen Waitstates bei 72MHz. Bei sequentiellem Zugriff spielt das keine Rolle, bei Sprüngen mangels Branch Target Cache sehr wohl, ebenfalls bei Datenzugriffen auf das Flash (die bei CM3 weniger wichtig sind als bei ARM7/9). Die neuen schnelleren STM32 (s.o.) existieren m.W. bisher nur als Ankündigung, Daten habe ich noch keine gesehen. Die LPC1700 erkaufen sich ihre 100MHz mit 4 Waitstates. Kompensiert durch einen kleinen 8x16 Byte Cache für das Flash, der vor allem Sprünge beschleunigt, aber auch bei Datenzugriffen wirksam ist. Beim STR9 ist das etwas komplizierter, weil dessen Flash-Memory auf einem separaten Die liegt und aus dessen offiziellen 2 Waitstates (ab 75MHz, siehe Flash Programming Manual) aus Sicht der CPU erfahrungsgemäss mehr werden (d.h. die Zugriffszeit ist grösser als diese 2 Takte suggerieren). Kompensiert wird das durch einen 16x32 Byte Branch Cache. Die bei ARM-Cores vor Thumb2 typischerweise sehr häufigen Datenzugriffe auf das Flash werden allerdings nicht beschleunigt, was die effektive Performance dieses Controllers stark negativ beeinflusst.
@A.K. Vielen Dank für die konkreten Hinweise. Jetzt können wir über Fakten sprechen ! Wenn ich's richtig verstanden habe, haben die STM32 einen doppelten 64Bit Puffer vorm Flash. Das Flash selbst hat eine Zugriffszeit von 35ns. Die "Marketing Figures" von 0 Waitstates bei 72MHz beziehen sich demnach ausschließlich auf den linearen Programmablauf im Thumb-2 Modus. Wie Du schon richtig sagst, gilt dies scheinbar nicht für Daten und auch nicht mehr bei Sprüngen, trotz Prefetch. Ähnliches gilt vermutlich auch für die 96MHz oder 120MHz, nur das hier zusätzliche oder andere Methoden der Optimierung benutzt werden. Sind wir uns soweit einig ? Gruß Um doch nochmal kurz auf die Ausgangsfrage zurückzukommen. Ich denke, das bezieht sich auf die Sicht des Programmierers, der sich weniger für die HW Implementierung, sondern mehr für die, für ihn sichtbare Geschwindigkeit interessiert.
Michael Leusink schrieb: > Die "Marketing Figures" von 0 Waitstates bei 72MHz beziehen sich > demnach ausschließlich auf den linearen Programmablauf im Thumb-2 Modus. Sowie annähernd auch auf Code, der im RAM läuft (daraus entstehende I/D-Konflikte mal aussen vor gelassen). Geltend für die bisherigen STM32, die bis 72MHz. > Wie Du schon richtig sagst, gilt dies scheinbar nicht für Daten und auch > nicht mehr bei Sprüngen, trotz Prefetch. Der Prefetch ist sequentiell, beim Sprung bringt er nichts. Der CM3 Core hat freundlicherweise ein bischen Branch-Spekulation drin um Sprünge etwas zu beschleunigen. Bei Datenzugriffen hilft nur ein Cache oder mindestens ein Puffer - letzteres findet sich beispielsweise bereits bei den LPC2000. > Ähnliches gilt vermutlich auch für die 96MHz oder 120MHz, nur das hier > zusätzliche oder andere Methoden der Optimierung benutzt werden. Sind > wir uns soweit einig ? Wenn du mit Optimierung erweiterte Hardware-Mechanismen wie einen Branch Cache meinst, ja.
Michael Leusink schrieb: > Um doch nochmal kurz auf die Ausgangsfrage zurückzukommen. > Ich denke, das bezieht sich auf die Sicht des Programmierers, der sich > weniger für die HW Implementierung, sondern mehr für die, für ihn > sichtbare Geschwindigkeit interessiert. Je komplexer die Cores werden, desto schwieriger ist es, aus irgendwelchen Taktangaben und Architektur- oder Implementierungsdetails auf reale Performance zu schliessen. Da hilft irgendwann nur noch das Nachmessen am konkreten Programm. Das gilt letztlich auch hier. Eine DMIPS Angabe ist nicht mehr als eine grobe Daumenpeilung und hilft sonst nur beim Primzahlensuchen. Wieviel zusätzliche Flash-Waitstates ausmachen kann auch stark vom Compiler abhängen, beispielsweise wieviel Mühe er sich gibt, die beim STR9 ganz üblen Datenzugriffe auf das Flash zu vermeiden. Die klassische ARM/Thumb1-Architektur kommt ihm da nicht wirklich entgegen. Allerdings bezog ich den Anfang des Threads auch auf die Eigenheit von ST, die Information über die notwendige(!) Einstellung von Waitstates im separaten Flash Programming Manual zu verstecken, was anfangs wohl jeder als Manual für's Selberbrennen vom Flash-Inhalt missversteht und folglich ignoriert. Und sich dann wundert, warum er dazu in Datasheet und Reference nichts findet.
Hallo! Sorry das ich den alten Thread ausgrabe, aber ich habe eine Frage: STM32: Flash Access @72Mhz benötigt 2 waitstates STR9: Sind das "alle" Waitstates die auftreten, bzw wo find ich diese Infos für den STR9? Ich hab keine Hinweise gefunden wie das hier bei 96MHz aussehen soll. Habt ihr einen Tipp? Ich hab das Flash Programming Manual und das Reference Manual durchgesehen und sogar nach "wait" und "96" gesucht ;) - leider erfolglos. Vl. hat ja hjemand noch Infos! Lg
Im Flash Programming Manual steht das definitiv drin. Nur kann es sein, dass die Suchfunktion bei Dingen scheitert, die das Auge noch findet ;-).
Michael Leusink schrieb: > Dhrystone Daten waren immerschon ein Grund für Diskussionen und Zweifel. Ich hätte gedacht, dass über die Aussagefähigkeit der Dhrystone Ergebnisse inzwischen keine Zweifel mehr bestehen :-) A. K. schrieb: > Die bei ARM-Cores vor Thumb2 typischerweise sehr häufigen > Datenzugriffe auf das Flash werden allerdings nicht beschleunigt Was hat sich denn da mit Thumb-2 fundamental geändert? ARM's DMIPS Angaben beziehen sich meines Wissen nach immer auf idealen 0 Waitstate Speicher. Was sollten sie sonst auch annehmen? Gruß Marcus
Marcus Harnisch schrieb: >> Die bei ARM-Cores vor Thumb2 typischerweise sehr häufigen >> Datenzugriffe auf das Flash werden allerdings nicht beschleunigt > > Was hat sich denn da mit Thumb-2 fundamental geändert? ARM und Thumb können nur sehr kleine Konstanten direkt im Befehl laden. Für alles jenseits dieser Formate, insbesondere Adresskonstanten deren Wert erst der Linker kennt, ist es üblich, sie PC-relativ zu laden. Folglich aus dem Flash. Die LPC2000 besitzen dazu immerhin bereits einen 16-Byte Puffer, der sich aufgrund der hohen Lokalität dieser Daten durchaus lohnt. Thumb2 besitzt wie wohl alle anderen RISCs mit 32-Bit Befehlswort die Möglichkeit, 32-Bit Konstanten in 2 Befehlen als 2 16-Bit Konstanten zu laden. Das geht folglich sequentiell im Befehlsfluss ungebremst ab. Da dies mit 8 Bytes etwas länger ist die PC-relative Variante mit 6 Bytes wird es aber ggf. bei Optimierung auf Platz nicht verwendet. Bei ARM (nativ) kann man an sich 32-Bit Konstanten auch aus mehreren Befehlen zusammensetzen. Mit insgesamt 4 Befehlen (den load/store ggf. eingeschlossen) geht das - benötigt aber viel Platz. GCC scheint das nicht zu tun, anderswo meine ich das aber schon einmal gesehen zu haben. Beim STR9 dürfte sich das auch lohnen.
A. K. schrieb: > Thumb2 besitzt wie wohl alle anderen RISCs mit 32-Bit Befehlswort die > Möglichkeit, 32-Bit Konstanten in 2 Befehlen als 2 16-Bit Konstanten zu > laden. MOV32, aka (MOV/MOVT) -- theoretisch schon. > Das geht folglich sequentiell im Befehlsfluss ungebremst ab. Da > dies mit 8 Bytes etwas länger ist die PC-relative Variante mit 6 Bytes > wird es aber ggf. bei Optimierung auf Platz nicht verwendet. Ich habe überhaupt noch nie gesehen, dass diese Konstruktion vom Compiler erzeugt wurde. Ich bin mir auch nicht sicher, ob sich das beizeiten ändern wird. Bei Sprungadressen muss der Linker die Platzhalter letztlich mit echten Adressen ausfüllen. Mit literal pools ist das relativ einfach. Beim MOVT/MOV hingegen muss der Linker sich mit dem Opcodeformat auseinandersetzen und anschließend zwei Instrutionen modifizieren. Alles möglich, wird aber meiner Erfahrung nach aber nicht gemacht. Mit "normalen" Konstanten habe ich da bisher auch keine Bewegung in diese Richtung erkennen können. Vor langer Zeit habe ich deswegen auch mal einen Support Case bei ARM aufgemacht. -- Marcus
Marcus Harnisch schrieb: > Ich habe überhaupt noch nie gesehen, dass diese Konstruktion vom > Compiler erzeugt wurde. GCC erzeugt mit -Os die PC-relative Variante, ansonsten bei eingeschalteter Optimierung oft MOV32. > beizeiten ändern wird. Bei Sprungadressen muss der Linker die > Platzhalter letztlich mit echten Adressen ausfüllen. Es geht hauptsächlich um die Datenadressen. Codeadressen sind üblicherweise kein Problem - mit Ausnahmen, vor allem bei manchen C++-Konstrukten und bei RAM-Funktionen, bei denen der Compiler keine Annahme über die Codeplatzierung treffen kann und die vollen 32 Bits frei wählbar lassen muss. > Mit literal pools ist das relativ einfach. Ja, nur dass man dann nichtsequentielle Datenzugriffe in Flash an der Backe hat. Und die sind vergleichsweise teuer, wenn das Flash-Interface keine entsprechenden Massnahmen trifft. > Beim MOVT/MOV hingegen muss der Linker sich mit > dem Opcodeformat auseinandersetzen und anschließend zwei Instrutionen > modifizieren. Ja und? Klar, das Format muss in die relocations rein, aber da ist je nach Architektur sowieso jede Menge derartiger Häckselkram drin. Routine. Beispiel: 16-Bit Adresskonstanten aufgeteilt auf zwei AVR-Befehle sind auch ziemlich schräg verteilt. Einerseits auf die Befehle, andererseits in zwei 4-Bit Stücken. Und mal als Byte- mal als Wortadresse.
A. K. schrieb: > Ja, nur dass man dann nichtsequentielle Datenzugriffe in Flash an der > Backe hat. Und die sind vergleichsweise teuer, wenn das Flash-Interface > keine entsprechenden Massnahmen trifft. Schon klar. Ich sage ja nur, dass ich das im Zusammenhang mit ARM noch nicht gesehen habe. [später] Du hast recht. Ein kurzes grep über alle erzeugten assembler Dateien hat in der Tat ein paar Treffer hervorgebracht. Allerdings nur bei GCC-erzeugten Dateien. Keine einzige RVCT-erzeugte Assembler Datei enthält MOV/MOVT. Wie groß die tatsächliche Ersparnis ist müsste man mal mit praxisrelevanten Tests untersuchen. Womit wir wieder beim Thema Dhrystone wären :-) -- Marcus
>Du kannst, richtiger weise, argumentieren, dass dies Herstellerseiten >sind und alles nur Marketinggefasel. Ja. Aus STR91 -DS : "– Up to 96 MIPS directly from Flash memory" !!!!!!!!!!!!!!!!
Marcus Harnisch schrieb: > Wie groß die tatsächliche Ersparnis ist müsste man mal mit > praxisrelevanten Tests untersuchen. Womit wir wieder beim Thema > Dhrystone wären :-) Der (Kommerz-) Compiler, der beim Dhrystone diese Konstanten nicht schon vor der Schleife ins Register läd, der hat seinen Zweck verfehlt.
A. K. schrieb: > Die LPC1700 erkaufen sich ihre 100MHz mit 4 Waitstates. Kompensiert > durch einen kleinen 8x16 Byte Cache für das Flash, der vor allem Sprünge > beschleunigt, aber auch bei Datenzugriffen wirksam ist. Auch wenn der Beitrag schon etwas älter ist, hoffe ich, dass mir hier noch jemand antwortet. Wie heißt das zugehörige Dokument von LPC für die 1700-Reihe bzw. genauer gesagt für den LPC1788/LPC1768 in dem ich das nachlesen kann? Im User Manual von NXP habe ich leider nichts dazu gefunden (nur für den EMC (External Memory Controller) ). Habe ich es dort überlesen bzw. nach den falschen Begriff gesucht ("wait state") oder steht dies in einem anderen Dokument?
Zum Bleistift im UM10360.pdf, Kapitel 5.4: "Flash Accelerator Configuration register". Und ja, "wait state" kommt da tatsächlich als solches nicht vor.
ST, NXP, Freescale, Atmel, MS (und viele weitere) haben (wie schon mehrfach erwähnt) Std-Flash von nur ca 33MHz! Auch wenn die dollsten MHz-Zahlen am Controller stehen! Wenn der Hersteller nicht explizit eine höhere Flash-Geschwindigkeit oben erwähnt, kann man getrost von diesen (ca) 33MHz ausgehen, (die er ja verstecken will). Einige Japaner haben Flash bis zu 120MHz.
Schade, dass es die Hersteller meistens nicht mal im Kleingedruckten erwähnen.
>Schade, dass es die Hersteller meistens nicht mal im Kleingedruckten >erwähnen. In den Flash-Characteristics bzw Waitstate-konfig uä steht es schon drin (man muss es gezielt suchen, werben tun man für dieses Gurken-Flash nicht), Selbst manche Hersteller auf Messen geben es nicht preis, bzw plappern das (Falsche!) was im DB ganz oben steht. (warum erwähnt M.M. das nicht in seinem Artikel?)
Um wieder das Beispiel von NXP ausführen: Existiert für einen LPC1768/LPC1788 ein deartiges Dokument? (Flash-Characteristcs/Waitstate-Config...)
MCUA schrieb: > (...) > höhere Flash-Geschwindigkeit oben erwähnt, kann man getrost von diesen > (ca) 33MHz ausgehen, (die er ja verstecken will). > Einige Japaner haben Flash bis zu 120MHz. Interessant, welche uCs wären dies?
@bko: Zum Beispiel die RX200 oder RX600-Serie von Renesas... Siehe hier: http://am.renesas.com/products/mpumcu/rx/rx600/index.jsp
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.