Warum kann ein Cortex M3 nur 120 Mhz während ein Cortex A8 1 Ghz erreicht? Woran liegt das? Flash zu langsam? Gruß Newbie
* Flash zu langsam für Prozessor ohne Cache. * Völlig anderer interner Aufbau, Pipelinetiefe M3:3, A8:13 * Herstellungsprozess M3: 130-180nm, A8: 45nm. Ist ausserdem eine völlig andere Zielgruppe. Der M3 ist nicht auf hohe Performance optimiert, sondern auf geringen Aufwand bei für die Zielgruppe akzeptabler Performance.
Zwischen dieser Frage und einer tiefgreifenden Antwort liegen viele Stunden in Grundlagen und anderen Vorlesungen. A.K. hat schon ein paar wichtige Punkte genannt. Generell haben hoehere Taktraten tiefere Pipelines zur Folge. d.h. die einzelnen Befehle werde in mehr kleine Haeppchen aufgeteilt. Das ist schoe und gut, hat aber bei jeder Verzweigung den NAchteil, dass die Pipeline weggeworfen werden muss, die hat "falsche" Folgebefehle reingeholt. Flash ist eigentlich keine Option fuer einen A8 zur direkten Befehlsausfuehrung, er koennte im Endeffekt langsamer sein als ein M3, weil so viel von der Pipeline immer floeten geht bei Verzweigungen. Befehle werden bei hohen Taktrate (>> 100 MHz) fast immer aus RAM-Zellen ausgefuehrt. Wenn es viele RAM Zellen sind, spricht man meistens von einem Cache. Viele MHz ohne Cache sind im Allgemeinen nicht viel wert. Cache und determinitisches Verhalten sind Erzfeinde. Im M3 Bereich wird aber sehr oft determinitisches Verhalten gefordert........ Es gaebe noch vieles, ich wuerde ein Grundlagenstudium Prozessortechnik dazu empfehlen :-) Gruss, Robert
Robert Teufel schrieb: > Cache und determinitisches Verhalten sind Erzfeinde Hmmm... warum? Wenn ich sage dass die Reaktionszeit im Bereich von 1-10us liegt, dann ist das auch deterministisch oder nicht? Ich muss dann in meiner Anwednung eben mit dem worst case rechnen und leben können.
Fragensteller schrieb: > Wenn ich sage dass die Reaktionszeit im Bereich von > 1-10us liegt, dann ist das auch deterministisch oder nicht? Ich muss > dann in meiner Anwednung eben mit dem worst case rechnen und leben > können. Manchmal ist es aber notwendig, dass die Reaktionszeit genau ist. Der Jitter zwischen best- und worst-case muss in diesen Fällen minimiert werden. -- Marcus
Fragensteller schrieb: > Hmmm... warum? Wenn ich sage dass die Reaktionszeit im Bereich von > 1-10us liegt, dann ist das auch deterministisch oder nicht? Ich muss > dann in meiner Anwednung eben mit dem worst case rechnen und leben > können. Wieder eine Frage der Zielgruppe, vereinfacht ausgedrückt. Wer mit Linux arbeitet (A8), dem sind exakte Reaktionszeiten im einstelligen Mikrosekundenbereich und genau reproduzierbares Laufzeitverhalten von I/O-Aktionen meist nicht allzu wichtig. Bei Controllern ohne Betriebssystem (M3) sind härtere Anforderungen jedoch häufiger anzutreffen. Bei Controllern mit Cache ist es ziemlich schwer, den schlimmsten Fall auch nur herauszufinden, geschweige denn zu testen. So kann sich das Laufzeitverhalten von Caches drastisch ändern, wenn ein grosser selten voll genutzer Datenpuffer ab und zu mit ganz anderem Füllstand (anderer Speicheradresse) verwendet wird als sonst. Die bei neueren CM3 auftrenden Variationen durch den dort vorhandenen Flash-Cache (LPC1700, 120MHz STM32) lassen sich einerseits einigermassen abschätzen und testen, andererseits durch Code im RAM reproduzierbar gestalten. Mitunter kann man solche Probleme mit entsprechender manueller Cache-Konfiguration (festnageln bestimmter Bereiche) in den Griff kriegen, aber sowas ist wirklich kein Vergnügen. Der Extremfall dieser Sichtweise sind Controller wie Propeller oder XMOS, bei denen Reaktionszeiten auf externe Ereignisse von 50ns bzw. 10ns und exakte Ablaufzeiten gewährleistet werden können. In beiden Fällen laufen die Programme daher in internem verzögerungs- und kollisionsfreiem RAM.
Ja und nein, alle oder keiner, denn Echtzeit != Echtzeit. Da musst du bei den Anforderungen konkret werden. Eine garantierte Reaktionszeit von 10s kriegst du mit allem zustande was Pins hat, eine von 10ns wird schon schwieriger.
Eine Kleinigekti zur Nomenklatur: Cortex-M = Mikrocontrolleranwendung (Kleine MSR Aufgaben) Cortex-R = RealTime (zusätzlich DSP Befehle) für konplexere MSR Aufgaben Cortex-A = Application (Betriebssystem, z.B. Linux. Hat eine MMU) Cortex-M0 ist eine LowCost Ausführung vgl. mit M3. Dann gab es noch eine für FPGA als Softcore. Glaub die M1 Variante. Soweit mal zu dem ARM Controllern.
A. K. schrieb: > Ja und nein, alle oder keiner, denn Echtzeit != Echtzeit. Da musst du > bei den Anforderungen konkret werden. Eine garantierte Reaktionszeit von > 10s kriegst du mit allem zustande was Pins hat, eine von 10ns wird schon > schwieriger. Andersherum: Gibt es spezielle ARM CPUs, für welche man die maximalen Ausführungszeit für jede Instruktion bestimmen kann?
Das geht bei wohl jedem der üblichen ARM7er von NXP/ST/Atmel, wenn man Programm und Daten konsequent im RAM hält und auf DMA verzichtet. Denn dann kann man direkt nach dem Timing der Core-Doku vorgehen. Ein alter Atmel ARM7 (AT91RM3400) war dementsprechend gebaut, mit 96KB RAM, ohne Flash, aber Urlader aus externem EEPROM.
Newbie schrieb: > Gibt es spezielle ARM CPUs für Echtzeitaufgaben? Sozusagen. Cortex-M1 als Softcore im FPGA. Das FPGA für die Echtzeit, den Prozessor für den Rest ;-).
Die maximale Ausführungszeit eines Befehls kann man für jede CPU bestimmen; bei Verwendung von DMA, Caches und Flash ist dieser Wert nur u.U. unerfreulich lang.
Andreas Schwarz schrieb: > Die maximale Ausführungszeit eines Befehls kann man für jede CPU > bestimmen; bei Verwendung von DMA, Caches und Flash ist dieser Wert nur > u.U. unerfreulich lang. Das Problem ist zunehmend autarke Peripherie. Führt der Prozessor einen Speicherzugriff aus, während beispielsweise ein DMA Controller gerade den Bus reserviert hat, dann kann man die Dauer dieses Befehls eben nicht genau angeben. Der Write Buffer ist ja auch irgendwann mal voll. -- Marcus
Matthias schrieb: > Eine Kleinigekti zur Nomenklatur: > > Cortex-M = Mikrocontrolleranwendung (Kleine MSR Aufgaben) > Cortex-R = RealTime (zusätzlich DSP Befehle) für konplexere MSR Aufgaben > Cortex-A = Application (Betriebssystem, z.B. Linux. Hat eine MMU) > > Cortex-M0 ist eine LowCost Ausführung vgl. mit M3. > Dann gab es noch eine für FPGA als Softcore. Glaub die M1 Variante. > > Soweit mal zu dem ARM Controllern. Versuchs doch mal so herum, ist mehr im Sinne der Erfinder Cortex-A = Application Cortex-R = RealTime Cortex-M = Microcontroller Faellt jetzt was auf mit der Nomenklatur? It's all about A R M :-) Robert
Die Zeit die der DMA-Controller den Bus belegen kann ist aber doch nach oben begrenzt, oder? Spätestens auf Applikationsebene weiß man ja auch wie man den DMA-Controller verwendet und welche maximalen Verzögerungen sich dadurch ergeben können.
>Die Zeit die der DMA-Controller den Bus belegen kann ist aber doch nach >oben begrenzt, oder? Spätestens auf Applikationsebene weiß man ja auch >wie man den DMA-Controller verwendet und welche maximalen Verzögerungen >sich dadurch ergeben können. Dafür gibt es auch eine "Multi Level Busmatrix". Damit könenn sich mehrere Peripherien, oder Peripherie, RAM und CPU "gleichzeitig" unterhalten. Deshalb hat Atmel auch in einigen Controllern zwei RAM Blöcke drin. Dann kann sich eine Peripherie mit dem RAM unterhalten und gleichzeitig die CPU auf den anderen RAM Blo9ck zugreifen. Allerdings glaub ich, dass der Programmierer die verteilung des RAMs selber organisieren muss, dass dieses Feature auch wirklich so funktioniert, wie es gedacht ist ;-)
Andreas Schwarz schrieb: > Die Zeit die der DMA-Controller den Bus belegen kann ist aber doch nach > oben begrenzt, oder? Spätestens auf Applikationsebene weiß man ja auch > wie man den DMA-Controller verwendet und welche maximalen Verzögerungen > sich dadurch ergeben können. Meines Wissens nach liegt die Begrenzung der DMA-Zeit darin, dass es nur eine begrenzte Buffer-Groesse gibt. Wenn jetzt z.B. mem-mem Transfers stattfinden in ein sehr langsames Memory und die max. Buffergroesse genommen wurde, dann ist das zwar nicht sehr intelligent aber es bewegt sich in Richtung worst case. Es kommen einfach soviele Faktoren rein in eine Latenzzeit und beim Cahce wird es noch viel schwieriger den worst case zu berechnen. Bei der Behauptung, dass Cache der Erzfeind der (harten) Echtzeit ist bleibe ich und DMA ist auch ein potentieller Verursacher extremen Jitters. Bitte nicht falsch verstehen, DMA und Cache erhoehen die Durchschnittsleistung eines komplexeren Systems enorm, doch die Zyklenzaehlerei hoert da irgendwann auf. (Fast) jeder Benchmark wird bessere Werte mit einem Cache liefern als ohne, doch worst case Betrachtungen von Antwortzeiten sind normalerweise ohne Cache deutlich besser. Robert
Sowohl DMA wie Caches verkomplizieren die Situation. Aber bei DMA ist das einigermassen kalkulierbar. Man kennt die Datenrate und die Übertragungscharakteristik und kann den dadurch erzeugten Bandbreitenverlust einrechnen. Sehr kleinräumig betrachtet, d.h. auf wenige Befehle bezogen, tritt ein deutlicher Jitter auf, aber sobald man etwas mehr betrachtet kann man über die Bandbreitenrechnung gehen. Den Effekt von DMA kann man auch recht gut über künstlich hoch gehaltene DMA-Aktivität testen. Bei Caches ist die Situation komplexer. Statistisch sind sie ein riesiger Gewinn, aber es ist sehr schwer, die worst cases der Nebeneffekte sinnvoll zu quantifizieren und zu testen. Sowohl kleinräumig wie grossräumig. Testweises Abschalten von grösseren Caches ist keine Option, weil die damit ausgestatteten Prozessoren dann langsamer sind als die CM3/ARM7-Klasse. Und die Nebeneffekte können bereits bei einfachen Modifikationen eines Programms (oder der oben erwähnten ungewöhnlichen Pufferfüllrate) ganz anders ausfallen als bislang betrachtet, wenn man dadurch in Assoziativitätskonflikte gerät, die vorher aufgrund geringfügig unterschiedlicher Adresslage der Komponenten nicht auftraten. Und so kann man das Verhalten von Caches zwar statistisch gut erfassen, aber Statistik sagt bekanntlich nichts über den Einzelfall aus. Wenn sie in 99,99% vorteilhaft sind, dann nützt das in harter Echtzeitsituation dennoch nichts, wenn diese 0,01% zum Versagen führen.
A. K. schrieb: > Aber bei DMA ist das einigermassen kalkulierbar. Man kennt die > Datenrate und die Übertragungscharakteristik und kann den dadurch > erzeugten Bandbreitenverlust einrechnen. Aber es ging ja hier nicht um den Bandbreitenverlust, sondern um die Frage, ob ich die maximale Ausführungszeit bestimmen kann. DMA, von mir lediglich als hinreichend bekanntes Beispiel für einen weiteren Busmaster angeführt, erhöht den worst-case der Ausführungszeit unter Umständen nicht unerheblich. Daneben kommt bei Applikationsprozessoren natürlich noch die Zeit für die Adressübersetzung durch die MMU hinzu, die im schlimmsten Fall, für den einen oder anderen durchaus überraschend, auch beim cache hit auftreten kann. -- Marcus
Marcus Harnisch schrieb: > Aber es ging ja hier nicht um den Bandbreitenverlust, sondern um die > Frage, ob ich die maximale Ausführungszeit bestimmen kann. Wenn das DMA nicht in Bursts, sondern regelmässig als Einzelzyklen auftritt, dann kann man kalkulieren, dass beispielsweise alle 20 Takte ein solcher Zyklus auftritt und somit auf einen dadurch abgebremsten Befehl ~10 weitere ungebremste Befehle folgen. Auf diese Weise lässt sich eine Folge von Befehlen in einer kritischen Sequenz trotz DMA-Einflusses weit genauer kalkulieren, als sich aus der Summe der Einzelbefehle im worst case ergibt. Dieser Ansatz ist letztlich schon eine Art Bandbreitenrechnung, zumindest kann man über die Bandbreitenrechnung die maximale Auswirkung auf nicht allzu kurze Sequenzen abschätzen. > mir lediglich als hinreichend bekanntes Beispiel für einen weiteren > Busmaster angeführt, erhöht den worst-case der Ausführungszeit unter > Umständen nicht unerheblich. Es kommt natürlich auf die Art des DMA an. Wenn das in längeren Bursts auftritt, dann ist die Situation ganz anders als wenn es beispielsweise ein SPI-Kanal ist, der alle Mikrosekunde je ein Byte loswerden will. Wenn man mit Burst-DMA arbeitet und die Dauer des Bursts die gewünschte Echtzeiteigenschaft in Frage stellt, dann hat man sowieso schon verloren und muss nicht erst lange rechnen ;-). > Daneben kommt bei Applikationsprozessoren natürlich noch die Zeit für > die Adressübersetzung durch die MMU hinzu, die im schlimmsten Fall, > für den einen oder anderen durchaus überraschend, auch beim cache hit > auftreten kann. Yep, das auch noch.
Marcus Harnisch schrieb: > Daneben kommt bei Applikationsprozessoren natürlich noch die Zeit für > die Adressübersetzung durch die MMU hinzu, die im schlimmsten Fall, > für den einen oder anderen durchaus überraschend, auch beim cache hit > auftreten kann. Handhaben diese Applikationsprozessoren den TLB miss eigentlich in Hardware oder als ganz klassische RISC per Exception?
A. K. schrieb: > Handhaben diese Applikationsprozessoren den TLB miss eigentlich in > Hardware oder als ganz klassische RISC per Exception? Hardware. Zuviel RISC ist ja auch nicht gesund ;-) -- Marcus
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.