ARM 926EJ-S MMU Test nach SIL

Hallo Sascha,

was soll denn der Funktionstest am Ende aussagen? Ja, der ICache 
funktioniert generell oder aber der komplette Speicher vom ICache z.B. 
16kB funktioniert einwandfrei?

Gruß Microman

Hallo Microman,
der Test muss sicherstellen, das jede Speicherstelle in dem 16K Cache 
funktionstüchtig ist. Das Genaue Bit oder wo der Fehler genau ist, ist 
nicht wichtig. Ist ja etwas mehr wie nur Speicher beteiligt.

Es geht darum, wenn ich den I-Cache verwende und er hat einen Fehler, 
wird ein Befehl nicht richtig ausgeführt und mein Programm hat ein 
anderes Verhalten. Somit würde bei einer Überwachungselektronik unter 
Umständen ein Menschenleben gefährdet, weil ein Alarm oder ein Notaus 
usw. nicht kommt.

Wird der Fehler aber festgestellt, kann die Steuerung in einen 
definierten Zustand gebracht werden (Störung).

Also muss als Testergebniss nur herauskommen, dass der I-Cache 
einwandfrei funktioniert.

Gruß Sascha

http://stackoverflow.com/questions/1006981/read-cpu-cache-contents

darf man fragen, welcher baustein?

ggf kann man den cach auch als sram ansprechen, wenn dieser nicht für 
den cach verwendet wird. (hab das mal irgendwo so gesehen)

Der Baustein ist ein Atmel AT91SAM9G10.
Aber als SRAM zum direkten anspechen würde nur die hälfte des Tests 
erbracht.
Auserdem kann ich mir das von der Struktur des Speichers nicht 
vorstellen.

Gruß Sascha

Hallo,
so habe gerade den Link mal nachgelesen, ich vermute nur es handelt sich 
hier um einen 920er Kern und ich habe einen 926EJ-S. Die MMU ist leider 
nicht die gleiche. Aber dort würde es ohne Probleme gehen.

Gruß Sascha

Hallo Sascha,

mich würde sehr interessieren, warum Du unbedingt die Caches so intensiv 
testen mußt? Was für einen Anspruch an den Sicherheitslevel besteht 
denn, bzw. welcher soll am Ende erreicht werden?

Gruß Stranger

Hallo Stranger,
also Cache ist auch ein Speicher durch den Fehler entstehen können. Oder 
man benutzt ihn nicht. Dann bleibt es nur noch an den BUS Strukturen 
intern hängen, die werden aber bei einem normalen Memory Test sowieso 
getestet.
Also der Cache kann eine sehr komplexe Sache sein. Bin da nun auch schon 
sehr weit gekommen. Uff ist aber wenn man ins Detail geht etwas 
aufwendiger.

So, mein Programm muss Menschenleben retten, dabei brauche ich auch noch 
einiges an Rechenleistung alleine für die Grafik (SVGA). Keine Sorge ich 
mache keine automotive Entwicklung. Erreicht soll SIL 2 Anforderungen, 
die auch real eingeschätzt zu schaffen sind.

Das Programm läuft mit meinen optimierten Cache Einstellungen ca. 23 mal 
schneller als ohne Verwendung des Cache.
Aber der I-Cache,D-Cache und Write Buffer muss dann natürlich fehlerfrei 
sein. Woher willst du ohne zu testen wissen, ob dein Baustein 100% O.K. 
ist?
Bitte kein Gedanke daran zu verschwenden, "habe ich doch erst neu 
gekauft".

Dann kommt hinzu das mein Prozessor Strahlungen ausgesetzt ist und auch 
einen Schaden nehmen kann. Also muss auch im fortlaufenden Betrieb 
periodisch getestet werden.
Auche alle Register, die im Prozessor die Funktion des Programms 
beeinträchtigen, müssen permanent überbrüft werden.

Gruß Sascha

Hallo Sascha,

einen I-cache zyklisch zu testen ob er noch fehlerfrei ist um SIL2 zu 
erreichen stelle ich mir äußerst spannend vor da ja die Instruktionen 
zum test nicht gecached werden dürfen (könnten ja das Testergebnis 
selbst verfälschen). Dankbar wäre es, den Test in eine Phase des Ablaufs 
zu legen in dem der cache nicht gebraucht wird, diesen dann abzuschalten 
da sonst Dein Test gecached wird. Und jetzt brauchst Du einen 
intelligenten Algorithmus um einige wenige Zellen trotzden zugreifen zu 
können und diese zu testen. Danach Cache wieder an, Programm normal 
ausführen bis zum nächsten Mal. Das nächste Mal dann wieder ein Stück, 
.. Sowas wie Galpat auf den Speicher in kleinen Schritten nur auf den 
I-Cache. Kniffelig ist nur wie Du die Pattern in den I-Cache 
reinkriegst, aber vielleicht gibt es da ein Hintertürchen zum Cache?

rgds

Hallo Marcus und 6A66,
ja ich gebe euch recht, das ist in der Tad nicht ganz einfach, aber 
nehmen wir mal folgendes an: Ich schreibe ein Programm das von A nach B 
ableuft und mir in den Registern Ergebnisse bringt. Das Programm ist so 
groß das es genau in den Cache passt. Es greift auf keine Daten zu nur 
auf Literale.
Das Programm leuft einmal mit und einmal ohne Cache ab. Das Ergebniss 
ist sozusagen bekannt. Nun lässt sich das Ergebniss prüfen.
(wird natürlich noch etwas aufwendiger gemacht...)

Der Daten Cache ist einfacher zu testen, in dem man so groß wie der 
Daten Cache ist einfach über Read Modify Write einen Memory Test 
ablaufen lässt.
Auch der Galpad muss nicht sein oder Walking Bit, es gibt auch 
einfachere Testmethoden, die auch sicher genug sind.
Invalidiert man nun den Cache, so darf keine Veränderung im RAM sein, 
und nach Test und Clean muss der Richtige Inhalt ins RAM übertragen 
werden.
Auch die TLB Flags muss man dazu lesen und überprüfen.

Auch die TLB muss natürlich bezüglich der Speicherzuordnung überprüft 
werden.

Lockdown ist ein eigener Bereich im Cache, den ich nicht benutze und 
somit nur gestreift prüfe. So viel ich weiß ist der Lockdown Bereich 
aber nur dazu da um permanent Code oder Daten für schnelle repetirende 
Aufrufe bereit zu stellen.

Mein Problem mit dem Memory Test ist nur, ich habe 32Mbyte 
Arbeitsspeicher in meinem Chip zu 4 Bänke (SDRAM 32Bit) da wirds mit 
einem Galpad oder Walking Bit schon Zeitaufwendig.

So viel ich weiß sind aber keine speziellen Memory Tests für SIL 2 
vorgeschrieben. Einige sind hingegen empfholen und es ist auch immer von 
der Struktur des Speichers abhängig. Also mechanischer Aufbau Row/Column 
usw. Ich habe natürlich auch gelesen das SRAM bevorugt ist, aber SDRAM 
ist prinzipiell nicht verboten, man muss nur die Refresh Zeiten straffer 
einstellen. Ist aber alles gar kein Problem.

Das Problem, dass der Prozessor irgendwo hinleuft ist bei einem ARM9 
System, wenn es noch halbwegs geht abfangbar. Gerade deshalb auch die 
MMU.

Das System hat auch noch einen zweiten Prozessor, der die Taskabfolge 
des ARM9 überprüft. Ein Worst Case Zenario muss definiert sein, dass ist 
klar.

Gruß Sascha

Hallo Marcus,
danke deine Antwort bringt mich ein Stück nach vorne.
In der Tat muss ich zugeben, dass ich vermutlich das mit den TLBs noch 
nicht ganz verstanden habe. Aber die Doku von ARM ist nicht besonders 
hilfreich, oder wo gibts mehr Infos?
Bitte die MMU aber nicht mit der des ARM920 verwechseln. Diese ist 
einfacher in dem Punkt.

Das mit dem SDRAM Row/Column ist sicherlich eine gute Frage, ob es noch 
reale Angaben von den Herstellern gibt.
Wie dem, das ist auch momentan das etwas kleinere Problem.

Die zweite CPU überprüft keine Laufzeiten, das ist natürlich unsinnig 
bei dem Speed was der ARM9 hat.
Also egal was für ein Code beim Abflug des ARM9 irgendwo steht, er 
bringt keine richtige Sequenz mehr zum zeiten Prozessor, somit kann das 
System in einen definierten Zustand übergehen. Da sehe ich auch einmal 
das kleinere Problem drin.


Gruß Sascha

Literatur ???

Sascha schrieb:
> ja ich gebe euch recht, das ist in der Tad nicht ganz einfach, aber
> nehmen wir mal folgendes an: Ich schreibe ein Programm das von A nach B
> ableuft und mir in den Registern Ergebnisse bringt. Das Programm ist so
> groß das es genau in den Cache passt. Es greift auf keine Daten zu nur
> auf Literale.
> Das Programm leuft einmal mit und einmal ohne Cache ab. Das Ergebniss
> ist sozusagen bekannt. Nun lässt sich das Ergebniss prüfen.
> (wird natürlich noch etwas aufwendiger gemacht...)

Hallo Sascha,

damit ist die Funktion des Caches noch nicht geprüft. Wie stellst Du 
fest, ob nicht durch mehrere unabhängig voneinander existierende Fehler 
das Literal falsch geladen wird und oder der Prozessor eine Sprung an's 
Ende macht und dann "Fertig" signalisiert? Ich denke dass einzig die 
Möglichkeit besteht, mit einem Cache-externen Test einzelne Zellen im 
rollierenden Verfahren zu testen - also ein Speichertest. Schwierig wird 
des auf den Cache zu kommen. Und der test muss ja nicht zwangsläufig in 
1s durch sein (Siehe Speichertests). Was sagt eigentlich die 
zertifizierende Behörde (TÜV?) dazu, haben die Vorschläge?

rgds

Hallo,
ja was sagt der TÜV dazu? Das ist sowieso das nächste Problem.
Eine SIL 2 ist auch wie CE eine Hersteller Selbsterklärung.
Ich will damit jetzt aber auf gar keinen Fall sagen, dass ich 
irgendetwas vernachlässigen will. Natürlich kann man eine Zertifizierung 
machen und dadurch wird es auch Sinnig. Bei Atex wird auch SIL2 als 
voraussetzung gebraucht und muss von der BAM abgenommen werden.
Kommt halt immer darauf an, in Welche Bereiche man mit der Zulassung 
rein will. Eigentlich brauche ich im Moment keine SIL 2 für mein 
Produkt, habe aber schon gehört es könnte verlangt werden.

So aber nun zurück zur Technik. Hat jemand eine Idee wie man den I-Cache 
testen könnte? Es geht mehr darum wie lese ich die Daten aus dem I-Cache 
aus?

Gruß Sascha

PS. mein core Test geht schon und ich habe einige Fehler bei Keil und 
IAR im Simulator gefunden. Die Compiler Software ist weit aus mit mehr 
Fehler behaftet als mir lieb ist. Zum Glück programmiere ich die ernsten 
Dinge mit Assembler.
Gibt es Zertifizierte Software Tools ???
Sind die dann auch Fehlerfrei ???

Hallo Marcus,
das mit dem C können wir definitiv ausklammern, da ich alle low level 
Routinen bis jetzt nur in Assembler schreibe. Würde in C auch gar keinen 
Sinn machen. Würde eh nur die C Anweisung ASM überall stehen.....

Und der Code muss zur Kontrolle vor und zurück übersetzt werden können, 
so steht das bei SIL 2. Also was ist dann einfacher C oder Assembler?
Aber bitte keine Grundsatzdiskusion über C oder Assembler das kann ich 
nicht mehr hören. Ich programmiere den ARM9 in Assembler im Schlaf, ist 
doch ein sehr einfacher und super durchdachter Befehlsatz.
Habe meine ganze Grafik GUI bis hin zu Bresenham Linie,Kreis,Fontausgabe 
und Bildausgabe alles super schnell in Assembler programmiert.
Wobei ich eigentlich eher von der CISC Schiene komme, als von der RISC.

Also z.B. zu einem Fehler des Simulator bei IAR QDADD und QDSUB stimmt 
das Ergebnis nicht wenn die Quelle negativ in Sättigung ist und man 
addiert man eine kleine positive Zahl drauf. Bei QDSUB ist das in 
entsprechender Richtung auch so.

Gruß Sascha

Hallo Marcus,
ich habe den Coretest auf dem echten Prozessor geschrieben, und wollte 
die Routine nur geschwind wegen einer CRC32 selbstüberprüfung auf dem 
Simulator testen dann kam das zum Vorschein. Ich war auch etwas 
verwundert ist aber so. Ich wundere mich da aber schon lange nicht mehr 
wirklich. Ich melde auch keine Fehler mehr, denn das entgegenkommen war 
all die Jahre super mittelmäßig. Es gibt da noch viel brutalere Fehler, 
die ich aber hier im Forum nicht rauslasse. Sonst könnten mir noch 
juristische Schritte drohen.
Wenn z.B. eine Firma XXX ein automotive Produkt damit entwickelt und die 
Floating Point Routine hat einen Fehler ist das echt schockierend. Auf 
der Messe habe ich dieses Problem angesprochen und bin dabei noch 
angeraunzt worden. Was soll ich da noch dazu sagen, man passt nicht ins 
Bild. Wer unbequem ist wird Heute aus dem System entfernt oder 
ignoriert. Deshalb mache ich meine Soße nur noch für mich alleine.

Gruß Sascha

Sascha schrieb:
> vor und zurück übersetzt werden können,
> so steht das bei SIL 2.

Hallo Sascha,

was meinst Du damit?

rgds

Hallo 6A66,
ganz einfach DIN EN 61508-1 bis -7 oder genauer DIN EN 61508-3 der 
Softwareteil lesen. Unter anderem heißt es, die Tools zur Generierung 
des Codes müssen überprüft werden. D.H. es muss jeder Code der erzeugt 
wird auch rückwärts übersetzt werden (Kontrolliert werden) um sicher zu 
stellen, dass das was man haben will (an Code) auch dem entspricht was 
man programmiert hat. Es genügt nicht den Compiler,Assembler und Linker 
zu evaluieren, da die Kombination von aufeinandertreffenden Opcodes 
nicht vorhersehbar ist.
Dem kann ich nur zustimmen, wenn man bedenkt, was manche Produkte 
(Compiler usw.) durch ihre optimierungsphase alles verfälschen.

Was natürlich noch besser ist man arbeitet mit zwei verschiedenen Tools.
Z.B. GNU,Keil,IAR usw. man muss natürlich aufpassen das kein Tool vom 
anderen übernommen/abgeleitet oder weiterentwickelt wurde, sonst können 
ähnliche Fehler enthalten sein.

Gruß Sascha

Sascha schrieb:
> die Tools zur Generierung
> des Codes müssen überprüft werden. D.H. es muss jeder Code der erzeugt
> wird auch rückwärts übersetzt werden (Kontrolliert werden) um sicher zu
> stellen, dass das was man haben will (an Code) auch dem entspricht was
> man programmiert hat. Es genügt nicht den Compiler,Assembler und Linker
> zu evaluieren, da die Kombination von aufeinandertreffenden Opcodes
> nicht vorhersehbar ist.

Hallo Sascha,

das würde ich aber mit den zertifizierenden Stellen mal diskutieren! Bei 
einem Code von 128kB in C müssten 128kB Op-Code von Hand zu Assembler 
und C zurückinterpretiert werden und dann der Erfolg verifiziert werden? 
Das ist nach meinem dafürhalten NICHT die Intention der 61508! Dafür 
sollte es zertifizierte Compiler und Assembler geben!

rgds

Sascha schrieb:
> die Tools zur Generierung
> des Codes müssen überprüft werden.

Da hast Du recht. Aber das kann auch durch den Hersteller der Werkzeuge 
geschehen. Und du musst nicht das Ergebnis der Werkzeuge sondern die 
Werkzeuge selbst prüfen.

rgds

Hallo,

abgesehen davon gibt es auch andere Methoden als das Rückübersetzen, um 
das Ergebnis der Toolkette zu validieren. Richtig angesetzt fällt dann 
der Compiler und Linker häufig in die nicht zu qualifizierenden 
Bereiche. Ich habe schon Beispiele gesehen, bei denen aus einer 
Toolkette mit 40 verschiedenen Tools nur zwei als kritisch angesehen 
wurden. Und das waren Tools zum Verwalten von Requirements und zum 
Validieren der Testergebnisse.

Hinweise zur Toolqualifikation können auch die von der 61508 
abgeleiteten Fachnormen geben z.B. die ISO 26262 (Automotive) oder die 
DO-178C (Luftfahrt).

Zum ursprünglichen Thema: Hast Du den Hersteller Deines µC mal befragt, 
ob es schon fertige Ebene-3-Bibliotheken gibt? Denn das Problem, was Dir 
gerade in Form des I-Cache begegenet, gibt es eine Ebene tiefer noch zu 
Hauf in den Prozessoren: Pipelines, Out-of-Order-Execution, Branch 
Predictions,... die alle dafür sorgen (so sie einen Fehler enthalten), 
dass Dein Ebene-2-Code eventuell nicht mehr so funktioniert, wie 
erwartet.

So richtig beherrschen kann man das entweder nur mit Hilfe des 
µC-Suppliers, oder indem man so viele der laufzeitveränderlichen 
Elemente wie möglich abschaltet (Caches, MMU,...) und dann die 
Ebene-2-Software mit Testdatensätzen als Instruction-Set-Test 
durchrechnen lässt.

Allerdings kommt man damit auch in Bereiche, in denen normalerweise 
redundante Systeme eingesetzt werden. Apropos redundant: Wie stellst Du 
sicher, dass bei einem falsch arbeitenden µC trotzdem immer der sichere 
Zustand angesteuert werden kann? Watchdog oder kleiner Zweit-µC?

Ausserdem erweckt es den Anschein, als ob Du zwar Teile der 61508 
verwendest, um Dein Produkt zu designen, Du allerdings nicht die 61508 
vollständig umgesetzt hast. Als erstes wird nach der Item-Definition 
normalerweise eine Gefahren- und Risikoanalyse für das Zielsystem 
durchgeführt, und daraus dann der maximale SIL bestimmt, nach dem 
entwickelt werden muss. Damit entfällt dann in der Regel das "...habe 
aber schon gehört es könnte verlangt werden".

Ebenso scheinst Du noch nicht ganz sicher in der Interpretation der 
61508 zu sein - diese fordert aber, dass die Mitarbeiter entsprechend 
ihrer Aufgaben kompetent sind (und entsprechend weitergebildet werden). 
Ebenso muss ein entsprechender Sicherheitslebenszyklus aufgesetzt werden 
(siehe Teil 1 der Norm), inkl. unabhängiger Prüfung der erarbeiteten 
Ergebnisse (soviel zur Selbst-Zertifizierung). Ohne dass jedoch die 
ganze Norm abgearbeitet wurde, ist das System nicht IEC61508-konform und 
Du stehst ggf. mit einem Bein im Gefängnis, wenn Du die Verantwortung 
dafür übernimmst.

Insofern kann ich nur empfehlen, mit dem (oder einem möglichen 
zukünftigen) Auftraggeber die Anforderungen durchzusprechen und basieren 
darauf (auch mit den Zulieferern der Teile und Tools) die notwendigen 
Maßnahmen festzulegen (und Disassemblieren gehört dann ziemlich sicher 
nicht dazu...)

Schöne Grüße,
Martin

Hallo Martin,
Ich habe alle Teile der DIN gelesenen, habe aber viele Anwendungen für 
das Gerät. Muss aber alles einbeziehen, damit die Hardwarebasis auch für 
eine SIL 2 Entwicklung hinreicht. Das alles hier im Vorum geschwind zu 
erklären würde den Rahmen sprengen. Ich arbeite schon ca. 16 Jahre in 
dieser Branche und kenne auch Produkte für SIL 1 und SIL 2. Da leider 
nicht nur mein Steuergerät in die Bewertung der gesammten Anlage 
eingeht, ist es unheimlich komplex. Eine SIL 2 wird meistens nicht 
verlangt, weil die Sicherheit an anderer Stelle des Systems erzeugt 
wird. Nur geht meine Weiterentwicklung die kommenden Jahre Richtung ATEX 
mit BAM Zulassung, und da ist SIL 2 verlangt. Ich werde mich in der Tat 
nach einem Berater umschauen müssen, der die SIL2 Geschichte begleitet.
Gruß Sascha

Sascha schrieb:
> Hallo Martin,
> Ich habe alle Teile der DIN gelesenen, habe aber viele Anwendungen für
> das Gerät. Muss aber alles einbeziehen, damit die Hardwarebasis auch für
> eine SIL 2 Entwicklung hinreicht. Das alles hier im Vorum geschwind zu
> erklären würde den Rahmen sprengen. Ich arbeite schon ca. 16 Jahre in
> dieser Branche und kenne auch Produkte für SIL 1 und SIL 2. Da leider
> nicht nur mein Steuergerät in die Bewertung der gesammten Anlage
> eingeht, ist es unheimlich komplex. Eine SIL 2 wird meistens nicht
> verlangt, weil die Sicherheit an anderer Stelle des Systems erzeugt
> wird. Nur geht meine Weiterentwicklung die kommenden Jahre Richtung ATEX
> mit BAM Zulassung, und da ist SIL 2 verlangt. Ich werde mich in der Tat
> nach einem Berater umschauen müssen, der die SIL2 Geschichte begleitet.
> Gruß Sascha

Hallo Sascha,

vielleicht hilft Dir so etwas:
"IAR hat ARM-Workbench nach IEC61508 zertifiziert".
http://marketing.iar.com/acton/rif/1011/s-0478-1304/-/l-sf-rpt-00O30000005pcvK-6988:52e/l-sf-rpt-00O30000005pcvK-6988/showPreparedMessage

rgds

Hallo 6A66,
Ja super, der Link ist klasse, das bringt mich auch mal in die richtige 
Richtung. Die SIL Einstufung und Bewertung kann ich bei meinem Projekt 
nicht alleine bestimmen sondern bekomme die Vorgaben von meinem 
Prüfingeneur (Projektingeneur), der die Systemberwertung macht 
vorgegeben. Ich muss nur alle Maßnahmen dafür ergreifen, das mein Part 
sozusagen conform ist.

Danke,
Gruß Sascha