Da noch einige Tage Zeit ist bis die Platinen für die Bausätze in Auftrag gehen habe ich noch einige Tests durchgeführt für die bisher keine Zeit war. Eigentlich sind sie vielleicht auch nicht unbedingt nötig, aber einmal mehr getestet kann ja nicht schaden. Also habe ich das testprogramm für den externen Ram etwas erweitert. Bei meiner Platine ist soweit alles ok, aber man kann ja nie ausschließen das bei einer Platine mal eine Durchkontaktierung reißt. Auch die Lötkünste der künftigen Hiveerbauer kann man ja nicht vorhersehen, also ist es vielleicht klug mit Kurzschlüssen oder kalten Lötstellen auf dem Daten- bzw. Adressbus zu rechnen. Wie kann man diese Fehler also sinnvoll automatisch mit einem Test erkennen, das war die Frage. Folgende Tests sind momentan integriert:
[A] 1:1, Random: Hierbei werden gleichzeitig beide RAM-Bänke mit den gleichen Zufallszahlen beschrieben und danach verglichen.
1:1, Negierte Bänke: Dieser Test gleicht Test A bis auf den Unterschied, daß die zweite Bank mit den negierten Werten von Bank 1 beschrieben wird.
[C] Adresskontinuität: Um zu vermeiden der Adressraum durch fehlenden Kontakt oder Kurzschluss auf einer oder mehrerer Adresseitungen nicht linear ist, wird bei diesem Test die Adresse als 32 Bit Wert fortlaufend in den RAM geschrieben und danach verglichen.
[D] Testmuster: Hier wird jede Zelle mit den Mustern $00, $FF, $AA, $55 geprüft.
Der Test läuft endlos, gibt Fehler akustisch (durch den Hertbeatsound) und per Statistik aus. Ich habe bei meinen beiden Prototypen das Programm 24 Stunden ohne Fehler laufen lassen und denke es könnte eine Hilfe beim Aufbau sein.
Nebenher experimentiere ich etwas mit PASM und habe mir gleich überlegt wie man damit diesen Test etwas beschleunigen könnte. Inzwischen habe ich mir eine kleine Shell gebastelt mit welcher ich fast ein wenig interaktiv mit einer Cog experimentieren kann. Zwei kleine Routine um den externen Speicher mit Werten zu füllen und diesen zu überprüfen machen dabei wirklich sehr viel Lust auf mehr:
512 K mit den IOS-Spin-Routinen füllen dauert ca. 60 Sekunden
512 K in PASM mit einem Wert füllen dauert ca. 0,5 Sekunden
Das sind natürlich tolle Werte und man kann durch einige wenige geschickt gewählte PASM-Routinen, die man dann komfortabel in SPIN einbindet, das Testprogramm um den Faktor 100 beschleunigen. Da ich erst anfange die RISC-Kerne per Assembler zu ergründen ist da mit Sicherheit noch einiges Potential da meine Routine wahrscheinlich nicht wirklich optimal ist. Interessant dabei aber folgender Effekt: Eine Routine die einen definierten Wert suchen sollte, lieferte mir immer statt der korrekten Adresse die Folgeadresse. Erst dachte ich an einen Programmierfehler, da ich bei der Füllroutine bewußt immer die Folgeadresse in den Parametervariablen rückgeliefert habe um durch Mehrfachaufruf aufeinander folgende Blöcke zu füllen und ich die Suchroutine aus dieser gebildet habe. Aber alle Sucherei nach dem Fehler brachte keinen Erfolg. Der Code war in seiner logischen Struktur völlig korrekt aber lieferte einen definiert falschen Wert. Erst eine kühles Bier und ein talaxianischer Kaffee brachte mir die Idee, mal zu betrachten ob da in der Hardware etwas nicht so läuft, wie ich es mir ausgedacht hatte. Ein kurzer Überschlag der Zeiten erbrachte folgende Werte: Eine normale RISC-Operation braucht bei 80 MHz zur Ausführung 50 ns. Wenn ich also die Adresse anlege und im folgenden Befehl das Datum der Speicherzelle auf dem Datenbus einlese, hat der RAM 50 ns Zeit diesen Wert bereitzustellen. Der RAM hat aber eine Zugriffszeit von 55 ns
weshalb ich also mit der Routine immer den Wert des vorigen Schleifendurchlaufs bekomme --> also auch eine Adresse der Fundstelle +1. Gemäß meiner Erwartung brachte das einschieben eines NOP's die korrekten Werte. Den NOP habe ich natürlich wieder entfernt und ersetzt durch eine andere eh erforderliche Operation um keinen unnötigen Overhead zu erzeugen.Bei den Experimenten mit PASM ist mir noch eine ander Idee gekommen wie man den Hive verbessern könnte: Ich habe für die Selektionssignale und das Schreibsignal je einen Pullup-Widerstand eingebaut, der diese Signale hardwäremäßig auf Inaktivitätspotential hält. Bisher war da nicht nötig, da immer eine COG die volle Kontrolle über diese Signalpegel hatte, aber es könnte das Handling der Bussignale per Software in bestimmten Fällen deutlich erleichtern: Wenn in Regnatix eine COG den Bus für eine bestimmte Zeit an eine andere COG übergibt, kann das ohne großen Softwareaufwand geschehen, ohne das die Signale irgendwie in einen undefinierten Aktivitätszustand gelangen. Zur Übergabe schaltet sich COG A einfach vom Bus indem sie die Portdirection auf Eingabe setzt und gibt COG B ein Startsignal. Die kurze Pause in welcher dabei keine COG die Kontrolle über den Bus hat, kann so nicht mehr zu Problemen führen. Diese Widerstände habe ich in der neuen Platine schon eingearbeitet.
