Space Age 2 der 32Bit MIPS Rechner in TTL

Der chaotische Hauptfaden

Moderatoren: Sven, TDI, Heaterman, Finger, duese

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Fr 22. Feb 2019, 22:50

Das Oszi hing auch immer dranne :lol:
Aber ja es gibt ab und zu die geilsten Effekte.

Nunja, die Baustelle des ordentlichen Debuggens per GDB auf dem MIPS TTL hab ich jetzt erstmal angegangen.
Mit dem Emulator lässt sich ja schon per GDB debuggen.
Somit sind die Funktionen des GDB Servers vorhanden.

Ich muss also "nurnoch" die Register/Speicher lesen/schreiben Funktionen auf den Debugbus der echten Hardware umbauen.
Allerdings fliegt dazu der alte USB Programmer raus, weil man einpennt wenn jedes Debugbus Paket auch über USB fliegen muss.
Der GDB Server kommt also vor Ort auf einen STM32.
Der quasselt dann per USB CDC (Virtueller ComPort) oder LAN mit dem PC.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Mi 21. Aug 2019, 15:47

Hier gabs jetz schon ne Weile kein Update mehr, also änder ich das mal.

Bisher sind wir auf einer Suche nach einem Bug und der ist wohl in der Hardware.
Dieser tritt erst seit dem Einbau der MulDiv Karte auf.
Der Bug äußert sich so, dass der Rechner seinen Speicherinhalt auf dem Terminal auskotzt.
Das aber nur wenn IRQs aktiv sind und eine Zahl ausgegeben wird.

Auf dem FPGA tritt dieser Fehler nicht auf!

Daher habe ich ersteinmal eine Platine für den Debugbus des MIPS TTL Rechners erstellt.
Darauf ist ein STM32F4, auf dem läuft der MIPS Emulator und der guckt der echten HW jetzt beim Rechnen auf die Finger :mrgreen:
Somit geht das direkt und nicht mehr übern sacklahmes USB Protokoll.
Hier klemmt das Teil noch am FPGA um die Software für das Teil fertigzustellen/zutesten:
Bild

Der "Debugemulator" hatte auch direkt einen Fehler gefunden, das HI und LO Register der Punktrechenarten wurde im IRQ Handler falsch wiederhergestellt.
Weiterhin war das Timing im Mikrocode falsch.
Das Schreiben nach HI/LO aus einem Register braucht 2 Takte und nicht nur einen!

Seitdem stürzt er nicht mehr Zeichenkotzend ab, sondern bleibt manchmal einfach stehen bei der Zahlenausgabe.
Auch sieht man manchmal einen verunglückten VT100 Steuercode und die hochzählende Zahl kommt weiter.
(Manchmal
Das sieht dann so aus:
Bild
Alles im und nach dem Cursor in der Zeile ist unerwünschter Text.

Das Problem?
Der Fehler tritt vllt 1 mal pro Stunde auf, debug das mal!
Das schreit doch förmlich danach, dass es nur kracht wenn ein IRQ in ein enges Zeitfenster feuert und damit was zerschießt.

So sieht die Ausgabe vom Debugemulator aus:
Bild

Eigentlich sollten ja die Netzwerkkarte sowie die IDE + Multi I/O Karte schon fertig sein und laufen.
Aber neee, da nervt jetz son Bug! :evil:

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Do 19. Dez 2019, 19:59

So wies aussieht möchte Henry in seinem Urlaub nach Weihnachten ein paar Layouts machen.

Da war ja noch die nicht passende CRC in der Lankarte.
Ansonsten funktioniert in der VHDL Simulation schon alles.
WIe Paketwörter und Bytes per Speicherinterface reinschreiben, die Wörter werden zu Bytes gesplitet und mit der passenden endianess in die TX FIFO gepackt.
Gleichzeitig bekommt der CRC die Bytes.
Der TX Teil hat dann eine Statemachine für Preambel, SFD, Datennibbles, Interpacketgab und IRQ werfen.

Beim Empfangen funktioniert auch schon alles, Preambel rausfiltern bis zum SFD, MAC wird nicht gecheckt (zu viel HW Aufwand), alle in die RX FIFO schieben und die Bytes zählen.
Ist das Paket fertig in der FIFO gelandet so gibts einen IRQ.
Beim Auslesen aus der RX FIFO über das Speicherinterface wird dann auch wieder die CRC gefüttert und Bytes werden zu Wörtern zusammengefasst.

Die Netzwerk CRC32 startet mit 0xFFFFFFFF und invertiert auch wieder das Ergebnis wenn alle Bytes berechnet wurden.
Zusätzlich dazu werden eingehende Bytes und das Ergebnis Reflected.
Was ist das? Ganz einfach, die Bitreihenfolge wird reflektiert.
Das bedeutet, dass das MSB zum LSB wird, also die Bitreihenfolge wird einmal gedreht. (nicht die Bytereihenfolge!)
Da hatte ich mir eine LUT rausgesucht, welche das Reflect eigentlich schon drinne hatt, aber das hat ja offensichtlich nicht funktioniert.

Also wird jetzt eine "normale" LUT genommen, diese enthält nur das Polynom 0x04C11DB7 und keine weiteren Tricks.
Solch ein Reflect des Eingangsbytes ist ja nur eine Vertauschen der Bits in Hardware.
Das Gleiche gilt auch für das Ergebnis.

Für CRC Implementierungen gibt es ein Checkvalue, das ist der Wert der rauskommt wenn der CRC über den String 123456789 berechnet wird.
Also mal diesen String als Paket übers Netzwerk senden:
Bild
Dort ist zu sehen wie der CRC die Bytes des Strings bekommt und am Ende liegt die passende Checkvalue auf dem Datenbus an (0xCBF43926).
Die CRC muss am Ende das pakets von der CPU ausgelesen und auch wie Daten in die TX FIFO geschrieben werden.
Das Macht die Lankarte dann nicht in HW.

Die Lankarte empfängt sich nun selbst und dann wird es aus der RX FIFO ausglesen.
Dabei wird dann die CRC über die Payload und die vorher bestimmte CRC gerehcnet.
Dann kommt da ein Magic Word von 0xC704DD7B raus, laut Theorie:
Wikipedia hat geschrieben: Running the CRC algorithm over the received frame data including the CRC code will always result in a zero value for error-free received data, because the CRC is a remainder of the data divided by the polynomial. However, this technique can fail to detect errors, in which data with trailing zeroes will also result in the same zero remainder. To avoid this scenario, the FCS is complemented (each bit is negated) by the sender before it is attached to the end of the payload data.[3]:section 3.2.9 This way, the algorithm result will always be a CRC32 residue of 0xC704DD7B when data has been received correctly. This allows for receiving a frame and validating the FCS without knowing where the FCS field actually starts
Also mal gucken:
Bild

Also da ist offensichtlich ein 0xC704DD7B zu sehen, aber auf dem crc_bus, also da wo es noch nicht Reflected wurde.
Nunja da schweigt sich der Wikiartikele etwas aus wo das stehen muss, bzw "CRC32 residue" ist dann wohl vor dem Reflect gemeint.

Da hab ich ja noch ein Wireshark Mitschnitt mit Checksummen im Frame, das in ein VHDL Simulator verstänliches Format gepackt und mal reingepustet:
Bild
Da ist auch ein 0xC704DD7B zu sehen, läuft also!

Was jetzt noch aussteht ist eine FPGA Implementierung und ein Test mit etwas C Code auf der CPU.
Natürlich mit einem echten PHY am FPGA angeschlossen 8-)
ARP und ICMP (Ping) sollten ersteinmal reichen um die Funktionalität nachzuweisen.

So, warum wird die CRC jetzt in HW berechnet?
Weil das auf der CPU zu lange dauert, die hat nur 4MHz und braucht 6 Takte für einen ALU Befehl.
1500 Byte Paket bei 10 Befehlen pro CRC Zyklus und 6 Takte pro ALU Befehl:
1500*10*6 = 90000 Takte.
Bei 4MHz sind das 0,0225s -> 22,5ms!
Bei vielen Paketen spart das schon ordentlich Rechenzeit.

Zum Vergleich wie lange das Paketkopieren dauert:
Das Wortlesen statt Bytelesen ist eine Beschleunigung um den Faktor 4.
Jedes LOAD braucht 8 Takte, speichern sind 6 Takte.
Pro Wort sind das also 8+6 Takte + etwas Schleifenabfrage des memcpy.
(1500/4)*(8+6) = 5250 Takte.
Das sind 1,3ms.

Die Nutzung der Lankarte wäre also 17mal langsamer ohne HW CRC!
Selbst jetzt gehen auf Dauervollgas nur 1MBit raus, also wenn das UDP paket vorher schon im Speicher steht und nicht neu berechnet werden muss.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » So 22. Dez 2019, 20:36

Bevor es die volle Dröhnung Reallife Famillie gibt wird sich noch schnell um die TTL Familie gekümmert.

Der Bug ist von:
"oh noes er stürzt ab und zu mal ab"
zu
"ab und zu schlägt der Load Word Befehl fehl"
umgewandelt.
Das wurde alles mit dem oben genannten Debugemulator in den letzten Monaten rausgefunden.
Die Software von dem wurde immer mehr angepasst um das spezifische Problem einzugrenzen.
Aber damit lässt sich nicht rausfinden wieso der auftritt und ab wann das Byte verfälscht wird.
Ja Byte beim Load Word, e gibt nur ein Muster und das ist, dass immer das Byte 1 (Bits 8 bis 15) falsch ist.
Aber Speicheradresse und Register variieren.

Im Endeffekt waren es aber mehrere Bugs und von denen sind jetzt wohl alle bis auf den einen hier debuggt.
F1: mit dem MULDIV ist der MIPS TTL so schnell, dass das Terminal überrannt wurde. Schließlich ist die Zahl -> String Umwandung jetzt viel schneller.
(da muss aber noch XON/XOFF aktiviert werden wenn F5 weg ist)
F2: HI/LO Register im IRQ Handler und Mikrocode vertauscht und somit in IRQs falsch wiederhergestellt
F3: Zugriffszeit nach HI/LO (write) zu kurz (1 Takt statt 2) obwohl der Pfad so lang ist wie eine ALU Berechnung
F4: irgendwas in der UART FIFO, daher gegen eine alte bekannte und fehlerfreie ersetzt (brachte auch Besserung)
F5: (ungelöst!):
Bei langen push/pop Sequenzen wird auf einmal eines der 4 Byte nicht richtig aus dem RAM geladen beim LDR.
Im Register ist 1 Byte falsch, aber im RAM ist alles richtig:
(Ein Beispiel aus der Konsole des Debugemulators)

Code: Alles auswählen

------------------------------------------------------------
EMUFAIL writeregister! (16)
               EMU          TTL
$16 (s0): 0x004fee4d <-> 0x004f124d DIFFERS!

> ram -r 64 -a 0x4FED48 --width 4
Offset(h) 00 01 02 03  Decoded Text
004fed60  00 4f ee 4d  .O.M
Die 0x12 gehört nicht ins Register und müsste 0xee sein! :evil:
Im RAM stimmt der Wert, aber im Register ist er falsch. Der Emulator hat auch richtig geladen.
Also gibt es einen Fehler im RAM lesen Schaltkreis oder Register schreiben Schaltkreis, der aber nur sporadisch Auftritt.
(Vielen Dank aber auch an Murphy!)

Also heute mal die schweren Geschütze aufgefahren, ein 32 Kanal 250MS/s Logic Analyzer!
Damit wurde dann direkt mal die Registerkarte angezapft:
Bild
Über die Signale schreib ich mal nix, das wird sonst unverständlich :lol:
Dann in die CPU gehangen:
Bild

Die Debugsessions arten so langsam aus:
Bild
Das sind so fast 5m an Tischbreite dies braucht und 2 Rechner an 3 Bildschirmen.

Der Fehler hat sich in anbetracht des dicken Geschützes direkt ergeben, also den ganzen Tag nicht gezeigt.
Mist! :evil:

Also den LA zur Gegenprobe mal wieder abgezogen und laufen lassen -> Absturz.

Aber wenn durch den Anschluss des LA an der Platine der Fehler verschwindet, dann ist das schonmal die richtige Stelle!
Denn durch das Anzapfen der Signale wird die Lastkapazität erhöht/verändert.
In der FPGA Implementierung tritt der Fehler zudem nicht auf, also ist das ein Timing- und/oder Signalqualitätsproblem.
Das Timing der Signale wurde mit dem LA natürlich überprüft und sieht im nicht Fehlerfall exakt so aus wie erwartet.

Daher gucken wir uns morgen die Signale auf dem Oszi an, denn das haben wir bisher noch nicht gemacht.

Mit Heißluftföhn und Kältespray wurde auch schon rumhantiert und währenddessen gibts keinen Absturz.
Also ist es leider nicht sowas simples wie ein abgerissener Bonddraht oder ein Kontaktproblem.
Bild

(Leider nur Handybilder, die Kamera passte nicht mehr in den Rucksack)

Benutzeravatar
Kuddel
Beiträge: 3571
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Kuddel » So 22. Dez 2019, 20:42

Tolles Projekt.
Was ist das für ein Rechner ganz rechts?

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » So 22. Dez 2019, 20:46

Das ganz rechts ist kein Rechner, sondern ein originales VT101.
https://de.wikipedia.org/wiki/VT100

Ein TTL Grab braucht doch eine passende Konsole. 8-)

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Mo 23. Dez 2019, 17:09

Der MIPS TTL Rechner lief von gestern Nachmittag bis heute früh durch.
Natürlich mit angeschlossenem Debugemulator und Logic Analyzer um vllt doch den Fehler noch zu erwischen.
Blöderweise lief das Ding fehlerfrei durch.
Wenigstens bestätigt das, dass meine Debugzugriffe in den CPU Kern keine Fehler auslösen.

Daher wurden heute die Signalformen und Qualitäten mit einem Analogoszi bestaunt.
Ob da villeicht etwas zu knapp kommt oder das Signal Pegel verletzt.
Hier zB das Schreibfreigabesignal für das Register direkt aus dem Steuerwerk.
Denn die Signale verfolgt man von der Quelle zum Ziel.
Bild
Der kleine Glitch in der Bildmitte ist übrigens völlig in Ordnung,
Da sieht man den EPROM beim Adresse dekodieren, dann glitcht eben auch mal der Ausgang.
Mit einem Digitaloszi hätte man den auch nicht gesehen!

Jedenfalls waren alle Signale auf der Registerkarte perfekt.
Von der Signalqualität her und vom Timing.
Alles sah so aus wie erwünscht.

Also haben wir uns vom RAM zum Register vorgetastet.
Leider hab ich kein Bild vom Oszi gemacht, aber da sah dann so richtig unschön aus!
Auf dem Speicherbus (Datenbusabteilung) gabs Pegel im verbotenen Bereich wenn der Bus völlig tristate sein sollte.
Eigentlich pullen sich TTL ICs selber hoch, aber das ist hier nicht der Fall.
Denn es sind auch 74ACT Bustreiber verbaut, upps.
Eindeutig ein Designfehler der gefixt werden möchte.

Das Signal habe ich mal nachgezeichnet.
Links direkt auf dem Bus.
Es wird zuerst eine 1 ausgegeben, dann eine 0 und dann solls in den Tristate.
Aber anstatt einer RC Glied Ladekurve gibts einen linearen Anstieg, aber nur bis in den verbotenen Bereich rein.
Am Schluss liegt dann noch eine getriebene 0 an, diese getriebene 0 soll ins Register.
Das mochte der 74F245 im Datenmultiplexer am Eingang garnicht und produzierte zu der zeit wilde Schwingungen (rechtes Bild).
Eigentlich! hört die Schwingung lange genug vor der Datenübernahme auf, aber vllt hats je nach Temperatur und Mondschein in Sibirien mal länger geschwungen?
Jedenfalls musste dieser Fehler so oder so behoben werden.
Bild

Daher noch ein paar Pullups an die passende Stelle im Datenmultiplexer angelötet.
Bild
Schon sind wunderschöne RC Ladekurven auf dem Datenbus zu sehen und keine Schwinger mehr im Datenmultiplexer.

Dann gabs noch etwas das VILLEICHT der wirkliche Fehler war.
Zum Anzapfen der Signale konnten wir nicht die mitgelieferten Klemmen des LA nutzen, denn diese waren zu klein für den dicken Teil der IC Pins.
Schließlich gucken ja nur die noch aus dem Sockel raus.
Daher haben wir die ICs herausgenommen und kleine Pinöpel aus 2,54mm Pinleisten rangelötet um den LA direkt anzustecken.
Dabei viel auf, dass einer der ICs nicht so fest saß wie alle Anderen, aber doch eigentlich fest genug.
Aber der Rechner lief ja ab dem Zeitpunkt Fehlerfrei.
Heute musste der Pinöpel aber wieder abgelötet werden vom IC, denn sonst hätte die Karte nicht mehr reingepasst ohne die Riserkarte.
Und weeste wat? Der saß wieder etwas lockerer als die anderen ICs trotz ordentlich reindrücken.
Was macht der IC laut Schaltplan? Die Schreibpulsfreigabe für die einzelnen Bytes in der Registerkarte!
Es ist U2252 A-D, also die ganze Spalte unter dem Pfeil:
Bild

Also mal einen anderen IC reinstecken.
Immernoch recht locker.
Also den Sockel tauschen.
Immernoch recht locker.
Wie jetz?

-> Mal nen IC aus ner anderen Charge nehmen wegen Toleranzen.
Dieser 74F32 war ein Neukauf, die gabs bis vor kurzem noch bei Mouser von TI.
Die andere Charge war dann ein Fairchild produziert in "W Germany" :mrgreen:
Der sitzt bombenfest!

Mal die IC Beine angesehen, die neuen von TI sind nicht mehr verzinnt!
Bild

Jedenfalls ist das ja leider ein statistischer Fehler.
Der MIPS TTL muss jetzt erstmal eine Weile fehlerfrei laufen um den Nachweis zu erbringen.
Ist eben nur die Frage wie lange lange genug ist.

Benutzeravatar
ferdimh
Beiträge: 7029
Registriert: Fr 16. Aug 2013, 15:19

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von ferdimh » Mo 23. Dez 2019, 17:22

Ich sehe hier mal wieder die unsäglichen extra teuren "Präzisionssockel", die mir schon öfter durch mangelnde Federwirkung aufgefallen sind... Bisher aber ohne definitiv dadurch verursachte Ausfälle auf meinem Tisch.
Ein "billiger" Sockel hat deutlich mehr Federweg und kann solche Maßdifferenzen ausgleichen.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Mo 23. Dez 2019, 17:35

Der Sockel is ja präzise, nur der IC nich :lol:
Aber ja, persönlich nutze ich ich auch die Federsockel.
Henry wollte diese haben.

Nun muss aber auch gesagt werden, dass die anderen ICs alle richtig fest sitzen.
Fester als ich das von den Federsockeln bei den heimischen Projekten her kenne.

Ob der Fehler jetzt definitiv dieses Anpressproblem war oder die Schwingung werden wir wohl nie erfahren?
(Oder ob der Fehler sich demnächst wieder zeigen wird)

Benutzeravatar
ferdimh
Beiträge: 7029
Registriert: Fr 16. Aug 2013, 15:19

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von ferdimh » Mo 23. Dez 2019, 18:25

Das Problem mit dem festen Sitz ist halt auch, dass da sehr gerne Pins abbrechen...
Ist halt auch (meiner Meinung nach) nicht das Problem vom IC, wenn die Sockel zickig sind, was die Pintoleranzen angeht.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Sa 28. Dez 2019, 20:32

LÄUFT!!!!!!!!!!!!!!!!!!!!!
Fritzler hat geschrieben:
Mo 23. Dez 2019, 17:09
Jedenfalls ist das ja leider ein statistischer Fehler.
Der MIPS TTL muss jetzt erstmal eine Weile fehlerfrei laufen um den Nachweis zu erbringen.
Ist eben nur die Frage wie lange lange genug ist.
Henry hat das Ding einfach mal eiskalt über Weihnachten laufen lassen und heute Morgen angekommen lief das Teil immernoch fehlerfrei.
Die Platine war nicht mehr auf der Riserkarte und der LA abgesteckt.
Damit sollte "lang genug testen" wohl erfüllt sein.

@ferdimh:
Wenn der Pin abreißt, dann wars sicher fest genug :lol:
Jedenfalls hat Henry jetzt einen neuen Arbeitsschritt zur Inbetriebnahme neuer Teile vorgesehen:
Am IC etwas hebeln um zu gucken wie fest der sitzt.
Einlöten will er nicht.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Fr 3. Jan 2020, 20:57

Die Lankarte wäre dann in VHDL schonmal fertig und in VHDL Simulationen verifiziert.

Den CRC Generator habe ich noch ausgebaut, sodass dieser auch CRC8 und CRC16 zusätzlich zur CRC32 kann.
Bei DEM Speedup konnte ich einfach nicht widerstehen!
Dazu noch mit allen möglichen Polynomen, welche noch in die LUT passen.

Da ich 16Bit OTP ROMs genommen habe sind das ne Menge (7 Adressbits sind frei), denn die haben auch 16 Adressbits.
(Weniger gabs nicht)

Es sind jetzt alle CRCs von der Seite hier implementiert: https://crccalc.com/
Kennt noch wer weitere CRC Polynome ;) ?

Der Schaltplan mit einer kurzen predoku schlummert für Neugierige im Anhang.
Dateianhänge
Lan Karte Doku.pdf
(228.89 KiB) 12-mal heruntergeladen
Lankarte_nicht_zum_layouten.pdf
(137.77 KiB) 11-mal heruntergeladen

Benutzeravatar
ferdimh
Beiträge: 7029
Registriert: Fr 16. Aug 2013, 15:19

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von ferdimh » Fr 3. Jan 2020, 21:32

CRC16 -VÖV gibts noch, z.B. hier
Die habe ich gerade erst implementieren dürfen (und mich echt gewundert, warum zum Henker man sich da echt IMMER was neues ausdenken muss).

Zu Ethernet allgemein:
Müsste es nicht möglich sein, ein Paket zu konstruieren, das man nicht übertragen kann, weil irgendwo die CRC an dem Punkt drin steckt, so dass das Ding dann "Paketende" vorzeitig erkennt?

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Fr 3. Jan 2020, 21:59

Da ich bei sonem CRC ja grade völlig durchgestiegen bin (behaupte ich jetz ma so).
Kann ich dir sagen, dass CRCs nur eine Kombination sind aus:
- Polynom
- Breite (32/16/8) <- bestimmt die Schiebeweite
- Initwert
- XOR Out
- Reflect In
- Reflect Out

Also ein C Algo, der ein struct dieser Parameter vernascht kann dann alle CRCs.
Nur eben nicht so performant wie ein angepasster CRC.
Kannst dir ja den C Code aus dem Schaltplan reverse engineeren :mrgreen:

Aus dem Polynom kannste dir eine LUT bauen, dann wirds schneller.
Genau das hatte ich vergessen oben zu schreiben:
Ein C Programm zum LUT erstellen aus den Polys habe ich auch geschrieben.
Das exportiert als .mif für die VHDL Simulation und als bin/hex für den PROMer.
Bei einem 16Bit OTP ROM haste dann aber direkt ein Endianessproblem.
Also hab ich etwas gefummelt bis es im PROMer Programm richtig aussah.
(Und direkt noch rausbekommen, dass das Chinesending die Checksumme ignoriert...)
Bild

Zum CRC-16 VÖV sehe ich jetz nur das Poly, aber keine der anderen Einstellungen.
Mal gucken, das Poly kommt aber schonmal rein.
Nachbrennen wird schwierig.
(warum die Polys auch fast imemr als x^y geschreben werden anstatt einfach als Zahl)
ferdimh hat geschrieben:
Fr 3. Jan 2020, 21:32
Müsste es nicht möglich sein, ein Paket zu konstruieren, das man nicht übertragen kann, weil irgendwo die CRC an dem Punkt drin steckt, so dass das Ding dann "Paketende" vorzeitig erkennt?
Das sollte nicht gehen.
Beim Senden wird die Paketlänge dem MAC Layer extra übergeben.
Der PHY bekommt dann vom MAC ein "DataValid" Signal und moduliert dann erst auf dem TwistedPair rum (siehe deine hervorragenden Oszibilder dazu).
(Dann gibts noch so extra Pulse auf der Bitschicht zum offen halten des Links und Speed auskaspern)
Der empfangende PHY erkennt dieses Signal (da ist ncht umsonst eine preambel und SFD dabei) und setzt dann selber ein DataValid Signal zum empfangenden MAC.
Jetzt wird gezählt für wieviele Takte (=Nibbles) das Signal valide ist. Das ist dann die Paketlänge.
Der höherligende IP/UDP/TCP guckt dann eh noch getrennt in die Längenfelder der Header.
Bedenke, die Mindestlänge eines Pakets ist 64Byte, ein Ping/ICMP Paket ist kürzer.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Fr 3. Jan 2020, 22:08

Hier noch ein Bild zur Verdeutlichung:
Bild

Benutzeravatar
Chefbastler
Beiträge: 1951
Registriert: Mo 12. Aug 2013, 20:21
Wohnort: Südbayern

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Chefbastler » Fr 3. Jan 2020, 22:21

ferdimh hat geschrieben:
Mo 23. Dez 2019, 17:22
Ich sehe hier mal wieder die unsäglichen extra teuren "Präzisionssockel", die mir schon öfter durch mangelnde Federwirkung aufgefallen sind... Bisher aber ohne definitiv dadurch verursachte Ausfälle auf meinem Tisch.
Ein "billiger" Sockel hat deutlich mehr Federweg und kann solche Maßdifferenzen ausgleichen.
Ich hatte hier schon welche die defintiv auch Wackelkontakt gemacht haben.

Benutzeravatar
Matt
Beiträge: 3633
Registriert: So 24. Aug 2014, 21:22
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Matt » Fr 3. Jan 2020, 22:26

Zu Fassung: alles ist mir egal, solange nicht so ne Texas Instrument Fassung ist. Der bringt dir garantiert zum gewaltsame raushebeln von Fassung zwecks entfernen.

Mit solchere Fassung hat man NUR Ärger.
Bild
Zuletzt geändert von Matt am Sa 4. Jan 2020, 08:16, insgesamt 1-mal geändert.

Benutzeravatar
ferdimh
Beiträge: 7029
Registriert: Fr 16. Aug 2013, 15:19

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von ferdimh » Fr 3. Jan 2020, 23:16

Zur Paketlänge:
Ich gebe zu bedenken, dass eben dieses definierte Paketende mindestens bei Koaxethernet nicht existiert...
Damit muss der MAC AUCH anders erkennen können, dass das empfangene Paket zuende ist.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Fr 3. Jan 2020, 23:58

10BASE2?
Da guck mal ins DB vom DP8392 und DP83910 (die arbeiten zusammen).
Leider gibts keine Direktlinks mehr.

Da fliegt wohl auch nur Manchester drüber und Paketende ist wenns keine Flanken mehr gibt.

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Do 9. Jan 2020, 20:30

Heute kam dann die Brenner Hardware zur Software.
Das Ding fühlt sich recht hochwertig an, für den Batronixbrenner in DIL40 hätt ich 300€ statt 33€ ausgeben müssen :evil:
Also Augen zu und abdrücken, dann den IC versteckbrettet.
-> Endianess stimmt, passt!

Die Lankarte ist in VHDL fertig und in den FPGA implementiert und der Treiber geschrieben.
Nur bleibts beim paketsenden irgendwo hängen inkl der printf Ausgabe, das macht spaß beim debuggen, nicht.
Also immer mal was ändern und Programm übertragen.
Das Proramm ist im FPGA Bitstream und landet dann als Init im BlockRAM, aber eine Synthese dauert 30min.
Mit dem Debugemulator kann ich Daten von einer SD Karte in den RAM schreiben.
Ist aber auch nervig immer mit der SD Karte rumzufummeln.

Aaaaber!
Es ist ja noch die GDB Anbindung geplant, daher habe ich eine USB Buchse auf der Debuggertestplatine vorgesehen.
Der USB Device CDC Stack läuft nach Anfangsschiwierigkeiten: https://fingers-welt.de/phpBB/viewtopic ... 19#p297434
Einen GDB Server habe ich ja schon für den Simulator, also den mal rübergezogen.

Läuft schonmal so halb, also ich kann Programme rüberschieben, steppen geht erstmal noch nicht:

Code: Alles auswählen

root@spaceage2:/home/spacy/MIPS_Software/Games# /home/spacy/mips-elf-gcc/bin/mips-elf-gdb
(gdb) target remote /dev/ttyACM0
Remote debugging using /dev/ttyACM0
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0002da4c in ?? ()
(gdb) file /home/spacy/soft_printf/Games/games
Reading symbols from /home/spacy/soft_printf/Games/games...done.
(gdb) load
Loading section reset, size 0x10 lma 0x0
Loading section divu, size 0x8 lma 0x80
Loading section div, size 0x8 lma 0xa0
Loading section multu, size 0x8 lma 0xc0
Loading section mult, size 0x8 lma 0xe0
Loading section eirq, size 0x8 lma 0x100
Loading section ovw, size 0x4 lma 0x120
Loading section undef, size 0x4 lma 0x140
Loading section sysc, size 0x4 lma 0x160
Loading section break, size 0x4 lma 0x180
Loading section .text, size 0x2d638 lma 0x200
Loading section .rodata, size 0x14740 lma 0x2d838
Loading section .data, size 0x1ad0 lma 0x41f78
Loading section .sdata, size 0x75c lma 0x43a48
Start address 0x0, load size 278508
Transfer rate: 23 KB/sec, 5925 bytes/write.
(gdb) compare-sections
Section reset, range 0x0 -- 0x10: matched.
Section divu, range 0x80 -- 0x88: matched.
Section div, range 0xa0 -- 0xa8: matched.
Section multu, range 0xc0 -- 0xc8: matched.
Section mult, range 0xe0 -- 0xe8: matched.
Section eirq, range 0x100 -- 0x108: matched.
Section ovw, range 0x120 -- 0x124: matched.
Section undef, range 0x140 -- 0x144: matched.
Section sysc, range 0x160 -- 0x164: matched.
Section break, range 0x180 -- 0x184: matched.
Section .text, range 0x200 -- 0x2d838: matched.
Section .rodata, range 0x2d838 -- 0x41f78: matched.
Section .data, range 0x41f78 -- 0x43a48: matched.
Section .sdata, range 0x43a48 -- 0x441a4: matched.

(gdb) info registers
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 00000001 0000000c 000000ff 0000000c 0003fd80 00000003 00000027 
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   2d617672 2e64652f 00000001 65616765 32202020 20202020 20202020 20202020 
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  00000000 0000000c 00000000 00000000 00040000 0003fd7c 0002e638 00000000 
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 00000000 00000000 00000000 00852884 00520028 00000000 00001348 
            sr       lo       hi      bad    cause       pc
      00000000 00000000 00000000 00000000 00000000 00000000 
           fsr      fir
      00000000 00000000 
23kbyte/s?
Mal gucken ob da noch was zu optimieren geht.

@Matt jetz seh ich die Bilder.
Mit diesen fassungen hatte selbst ich schonmal Ärger.

Benutzeravatar
Matt
Beiträge: 3633
Registriert: So 24. Aug 2014, 21:22
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Matt » Do 9. Jan 2020, 20:49

Hab Bild später eingebaut.
Der TI Fassung ist zum aufregen.


Programmer ist TL866II ?
Ich nutze Vorgänger TL866CS, der ist OK und hat oft meine Arsch gerettet. (denn dank ihm bin ich deutlich mutiger beim Firmware-Update)

Grüss
Matt

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Do 9. Jan 2020, 20:56

TL866II Plus.
Ohne + gibbet wohl nicht mehr.

Komischerweise gabs die 16Ax16B nur als fensterlose EPROM.
Also haste nur einen Versuch.

Benutzeravatar
Chefbastler
Beiträge: 1951
Registriert: Mo 12. Aug 2013, 20:21
Wohnort: Südbayern

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Chefbastler » Do 9. Jan 2020, 21:11

Fritzler hat geschrieben:
Do 9. Jan 2020, 20:56

Komischerweise gabs die 16Ax16B nur als fensterlose EPROM.
Also haste nur einen Versuch.
Genauere Bezeichnung? Wenn du 16Kbit/2Kb EPROM suchst gabs mal 2716 Früher massenhaft, 2816 als EEPROM.

Ich bin froh noch einen alten TL866 zu haben, hab noch einige 21V EPROMs...

Benutzeravatar
Fritzler
Beiträge: 7772
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk
Kontaktdaten:

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Fritzler » Do 9. Jan 2020, 21:27

Das ist ein AT27C1024.
Ich schireb 16Adressbits und 16Datenbits.

Eigentlich brauch ich 32Bit als CRC LUT Ausgabe, aber habe 2IC zu 16Bit genommen.
Jetzt bitte nicht Fragen warum nicht 4ICs zu 8Bit , das weis ich selber nicht.
Aber warscheinlich platzsparen auf dem PCB.

Adressbits:
8 Bit gehen rein als CRC Lookupwert, dann ein Bit als high/low ROM (damit ich nur ein Image brauche)
Dazu dann noch 5 Bit als Auswahl von bis zu 32 Polynomen.

Benutzeravatar
Chefbastler
Beiträge: 1951
Registriert: Mo 12. Aug 2013, 20:21
Wohnort: Südbayern

Re: Space Age 2 der 32Bit MIPS Rechner in TTL

Beitrag von Chefbastler » Do 9. Jan 2020, 22:11

Fritzler hat geschrieben:
Do 9. Jan 2020, 21:27
Das ist ein AT27C1024.
Ich schireb 16Adressbits und 16Datenbits.
Auf Ebay wären noch welche mit Fenster NOS/Gebraucht zu finden im PLCC Gehäuse, du wirst aber wahrscheinlich die DIL Variante haben?

Wenn die nicht so Teuer wären, wäre das auch ein schönes Gehäuse:
https://www.ebay.de/itm/NEW-ATMEL-AT28C ... SwEY1d374E

Antworten