Mahlzeit! In einem 2 semestrigen Kurs (mit Drittmitteln) an der TU-Berlin entstand da ein kleines "Projektchen". Die Planungs- und Bauzeit (also vom Anfang des Schaltplanentwurf bis zum fertigen Gerät+Software) vergingen dann 10 Monate. Im Endeffekt sind das nun 496TTL Bausteine auf 4 oder 6 Lagen Platinen die im Betrieb 17A bei 5V fressen. Dabei verstehen diese dann den MIPS1 Befehlssatz (keine Coprozessorbefehle). Daher auch ganz normal mit dem MIPS GCC programmierbar das Teil. Das erste Programm ist ein wissenschaftlicher Taschenrechner (Vorbild Casio fx80). Da bisher am IO gespart wurde, es ging ersteinmal um einen funktionsfähigen Rechenkern. IO Karten kommen aber noch in nachfolgenden Semestern, aber mit anderen Studententeams. Alles weitere hier: http://www.fritzler-avr.de/spaceage2/
Angehängte Dateien:
-
2015-09-20_sp2_gesamt_2.jpg
230 KB
Martin W. schrieb: > Mahlzeit! > In einem 2 semestrigen Kurs (mit Drittmitteln) an der TU-Berlin entstand > da ein kleines "Projektchen". > Die Planungs- und Bauzeit (also vom Anfang des Schaltplanentwurf bis zum > fertigen Gerät+Software) vergingen dann 10 Monate. > > Im Endeffekt sind das nun 496TTL Bausteine auf 4 oder 6 Lagen Platinen > die im Betrieb 17A bei 5V fressen. > Dabei verstehen diese dann den MIPS1 Befehlssatz (keine > Coprozessorbefehle). > Daher auch ganz normal mit dem MIPS GCC programmierbar das Teil. > > Das erste Programm ist ein wissenschaftlicher Taschenrechner (Vorbild > Casio fx80). > Da bisher am IO gespart wurde, es ging ersteinmal um einen > funktionsfähigen Rechenkern. > IO Karten kommen aber noch in nachfolgenden Semestern, aber mit anderen > Studententeams. > > Alles weitere hier: > http://www.fritzler-avr.de/spaceage2/ TTL mit IC's? Weicheier! Richtige Männer nehmen einzelne Transistoren! ;) (Troll) Trotzdem eine beachtliche Leistung, und sehr sauber aufgebaut, was man so sieht. Hut ab! Sind das auf der zweiten Karte Relais? Wofür sind die?
:
Bearbeitet durch User
Mike B. schrieb: > Sind das auf der zweiten Karte Relais? Wofür sind die? Das dürften batteriegepufferte RAMs mit eingebauter Batterie sein, à la MK48T08.
Mike B. schrieb: > Richtige Männer nehmen einzelne Transistoren! Klick bei ihm auf der Seite mal auf den Link zu Spaceage: http://www.fritzler-avr.de/spaceage2/!Bilder/sp1.jpg http://www.lndw.tu-berlin.de/lndw13/programm/haus-der-elektrotechnik-und-informatik/#722
:
Bearbeitet durch User
Jo das Ding heißt Spaceage 2, ist somit der Nachfolger des Spaceage aus Einzeltransistoren. Sind die TTL ICs jetzt erlaubt? =P Ne Webseite zum Ersten müsst ich mal machen, aber an dem v1 hab ich nicht mitgearbeitet, nur am Spaceage 2. Das sind, wie schon erwähnt, SRAM mit Batterie. Der Mikrocode sollte ja einenn Powercycle überleben, aber trotzdem noch gefundenne Bugs shcnell überspielt werden können. Das werden noch ROMs später.
Un wie schnell läuft es ? Die NVSRAMs sind 70ns, geht es bis 12 MHz ? oder läuft noch langsamer ? Welche Kritische pfade gibt es ? Ich finde es super, einfach Klasse ! Und so schön dokumentiert :).
Erinnert mich schwer an den MOPPEL in den 80ern. Sowas baut man doch heute komplett in VHDL :-) Allerdings hat man andererseits mit so einem Projekt eine Menge an Wissen beisammen, dass einen überhaupt erst in die Lage versetzt, sowas sinnvoll in VHDL zu machen ... Ich frage mich, ob man das nicht einfach generell einführen sollte, Neulinge wieder reale Hardware machen zu lassen, statt sie über Prozesse und virtuelle Welten loslegen zu lassen. Ich denke, da würden sich viele Themen im FPGA-Bereich des Forums erledigen ... Gratulation jedenfalls. Eine Frage noch: Auf der Webseite lese ich einen Hinweis auf Xilinx-Synthese. Was hat ihr da drin?
:
Bearbeitet durch User
Das Projekt finde ich sehr beeindruckend, auch wenn mir der Nachbau etwas zu aufwendig wäre die 496TTL ICs auf zu löten. Wenn ich mich recht erinnere gab es hier im Forum mal einen Link auf eine 4Bit CPU die auf eine Platine gepasst hat, den kann ich aber leider nicht mehr finden. Auf jeden Fall bekommt man beim Anschauen eurer CPU Lust auch eine zu haben. gibt es eigentlich einen PC-Simulator?
chris_ schrieb: > gibt es eigentlich einen PC-Simulator? Warum willst du auf dem Teil einen PC simulieren?
>Warum willst du auf dem Teil einen PC simulieren?
Du weist ja, was ich meine..
Da es eine überschaubare Anzahl TTL ICs ist dachte ich mir, es müsste
relativ einfach sein, eine CPU-Simulation zu programmieren.
Was mir zum Projekt eingefallen ist: Wenn man schon eine 32bit CPU baut,
sollte man vielleicht auch eine einfache VGA-Karte dazu machen, damit
man die Leistung der CPU "auf den Schirm bringen kann".
Da kommt ja noch einiges mehr an Laufzeiten zusammen, im Endeffekt sind 6,7MHz möglich. Momentan ist ein 4MHz Quarz eingebaut. Die Rechenleistung liegt also bei 0,8 MIPS (wegen Multicycle). Mit dem richtigen Takt haben wir also einen MIPS mit 1MIPS. Der langsamste Pfad ist das Lesen aus dem RAM, da hängen ja vor allem 2 RAMs hintereinander, die Lookuptable des Microcodes und der eigentliche RAM am Adressbus. Dazu das Steuerwerk, der Adressdekoder, der Datenmultiplexer und und und. Die Timinganalyse liegt jetzt komischerweise nicht im SVN, muss ich mal gucken wo das hin is. Der gesamte Space Age 2 liegt als VHDL Code vor, schließlich wurde zuerst alles simuliert um vorzeitig Bugs zu finden. Allerdings mit weniger Speicher. Die Bugs sind in der Simulation einfach leichter zu finden und in Hardware würden diese richtig Geld kosten und Zeit, man finde mal einen sporadischen Bug in einem 32Bit Prozessor mit nem Logikanalyzer. Noch aufwendiger als die TTL ICs zu löten war das Layouten der Platinen, war aber nicht meine Aufgabe. Einen Simulator gibt es nicht. bzw nicht von uns, denn MIPS ist ja eine Standardarchitektur, also wirds dazu nen QEMU geben. Der Space Age 2 ist ja noch nicht fertig, nur der CPU Kern. Natürlich gibts noch mehr IO, dazu aber erst weiteres wenn es fertig ist.
:
Bearbeitet durch User
chris_ schrieb: > Wenn ich mich recht erinnere gab es hier im Forum mal einen Link auf > eine 4Bit CPU die auf eine Platine gepasst hat, den kann ich aber leider > nicht mehr finden. Nibbler 4 Bit CPU ? http://www.bigmessowires.com/nibbler/
Der Nibbler ist super weil einfach ist. Es hat alles was man braucht: Registers, memory i/o, ports und Microcode !.
Martin W. schrieb: > Der gesamte Space Age 2 liegt als VHDL Code vor, schließlich wurde > zuerst alles simuliert um vorzeitig Bugs zu finden. In VHDL simuliert und dann aufgelötet? Das ist echtes Retro :-)
Martin W. schrieb: > 496TTL Bausteine auf 4 oder 6 Lagen Platinen > die im Betrieb 17A bei 5V fressen. > ... > Das erste Programm ist ein wissenschaftlicher Taschenrechner (Vorbild > Casio fx80). Also 85W... schicke Heizung =) Wieviel braucht der fx80 so zum Vergleich? Dürfte wohl im mW oder gar µW Bereich liegen ;-) ;-P
Das hier ist mal ein richtig schöner Computer zum Nachbauen: http://hackaday.com/2015/10/29/400-transistors-and-1800-resistors-form-this-1967-personal-computer/#more-175168
Die Nibbler 4 Bit CPU ist so ziemlich das Gegenteil vom Space Age 2. Dort sollte mit so wenig TTL Bausteinen wie möglich ausgekommen werden. Der Spaceage 2 ist von vornherein ein 32Bit Monster, kostet eben mehr TTL ICs. Auch wenn die ALU ICs gleich sind, der 74181. Ja das VHDL war wichtig, es wurden noch ~120Bugs gefunden. Also insgesamt in Hardware und Mikrocode, aber auch Mikrocode Bugs waren in der VHDL Simulation leichter zu sehen. Wenn ein ERgebnis falsch ist so lässt sich das zurückverfolgen bis der Fehler direkt zu sehen ist (mach das mal mit nem Logikanalyzer...) Aber somit auch hut ab vor den TTL CPU Pionieren, die hatten sowas ja nicht. Was der fx80 zieht weis ich nicht, jedenfalls rechnet er 69! um einiges langsamer aus als der Space Age 2.
>Die Nibbler 4 Bit CPU ist so ziemlich das Gegenteil vom Space Age 2. Klar ist der Space Age 2 eine andere Kategorie. Allerdings ist der Bauteilaufwand relative groß, so dass es nur wenige davon geben dürfte. Den Nibbler kann man auf eine Europakarte bauen: http://www.bigmessowires.com/category/nibbler/ Interessant sind die Assemblercodebeispiele. Wenn man sich das Programm Frogger anschaut, fragt man sich, wie so was ohne call und return programmiert wird. Das Ergebnis ist ziemlich interessant und ich denke, die Studenten könnten da viel über Assemblerbefehlarchitektur lernen.
chris_ schrieb: > Wenn man sich das Programm > Frogger anschaut, fragt man sich, wie so was ohne call und return > programmiert wird. Wir haben in den 80ern alle Telespiele auf dem VC20 und dem VC64 in linearem Assembler geschrieben. War aufwändig, aber des Effektivste was machbar ist. Man muss eben die schnellen "tasks" jedesmal anfahren und die weniger wichtigen seltener und das auf die Ausführungszeiten anpassen -> task-time-balancing.
Angehängte Dateien:
-
ubersicht.png
17 KB -
muldiv.png
100 KB
Es geht weiter! Der MIPS Kern kann ja immer Punktrechnung im Gegensatz zum ARM. Daher gibts auch keine Compilerflags damit der GCC eigene Routinen einbindet. Deswegen wird bisher in eine Exception gesprungen wenn der MIPS Punktrechnen soll, das wird dann in Assembler gemacht. Blöderweise sind dadurch Punktrechnungen im zB Interrupt nicht möglich, da keine nested Exceptions vorgesehen sind. Das braucht zudem mehr als 2000 CPU Takte. Also muss das nun in Hardware her, in 32Bit. In der ersten Ausbaustufe wurde eine solche Schaltung schon berücksichtigt, es muss nur eine Karte getauscht und etwas Fädeldraht zum Steuerwerk verlegt werden. Es wird kein parallel Multiplizierer, das wäre zu groß und teuer. Es wird so gebaut wie beim echten MIPS1 Kern, addieren/subtrahieren und schieben, also ein serieller Multiplizierer/Dividierer. Ist trotzdem um mehr als Faktor 25 schneller als die Softwareemulation und umschifft das Verbot von Punktrechnungen in Interrupts/Exceptions. Kurzfassung: unsigned mul -> addieren und rechts schieben signed mul -> addieren/subtrahieren und rechts schieben unsigned div -> links schieben und subtrahieren signed div -> absolute Hölle Vorbetrachtungen, dann links schieben und addieren/subtrahieren, daanach Nachbetrachtungen und nen Sonderfall der 2x32Bit auf 0 Vergleichen muss... Daraus ergibt sich dann ubersicht.png im Anhang. Der Schaltplan auf Regsterbene ist dann eeetwas größer.
Vielleicht von Interesse: http://www.computerhistory.org/semiconductor/timeline.html#1970s mfg. Gerhard
Ist dann quasi eine R3000 CPU ? Dann müsste auch theoretisch ein Linux kern drauf laufen oder ein kleines BSD :O Krasses Projekt jedenfalls, beindruckend :)
Matthias W. schrieb: > Dann müsste auch theoretisch ein Linux kern drauf laufen oder ein > kleines BSD :O Nö, es fehlt ja das komplette IO-Subsystem, wahrscheinlich auch eine MMU das sollen ja zukünftige Studentengeneration herbeizaubern. > Krasses Projekt jedenfalls, beindruckend :) Nichts für ungut aber hinsichtlich der Hardware verschwendende Jugend. Den Ansatz eine CPU from the scratch mit Studenten zu entwickeln finde ich auch gut, aber mit einer FPGA Realisierung per schematic entry hat man den selben lerneffekt ohne sich mit Löt-/Steckfehlern herumzuschlagen. Und lernt nebenher wie man die Lehren der Computergeschochte auch moderne Technologien überträgt.
@Gerhard O.: Schöne Chronik! Erinnert mich daran, dass ich im Internet mal einen TTL IC gefunden hatte der 32x32Bit multipliziert. War irgendwas aus der 74er Serie, hatte sogar schon das Datenblatt davon gesehen. Allerdings wieder aus dem Sichtfeld verloren, da nicht mehr beschaffbar. Inzwischen weis ich nichtmal mehr die Nummer. Zu einem R3000 fehlt da noch einiges, wie eben MMU und FPU. Ohne MMU kein Unix, bei den 4MHz ist das eh zu viel Software. MMU wird aber nicht kommen, so eine MMU kann größer sein als der CPU Kern selbst. Das Teil in TTL bauen hat aber auch seinen Reiz! MIPS(single/multi Cycle, pipelined) und ARM9 wurden schon im Bachelor Grundstudium in VHDL entworfen.
Angehängte Dateien:
-
k_datf_ctrl.png
110 KB -
muldivvhdl.png
44 KB
Dass es keine FPU braucht ist ja klar. uclinux, welches keine MMU braucht, klingt ja schonmal interessant. Hat auch einen Port auf Microblaze, was ja eigentlich nen MIPS ist. Ansonsten gehts weiter mit dem Hauptthema. Ersteinmal wurde das in 4Bit getestet, da kann man noch alle Zahlenkombinationen reinwerfen und somit alle Fälle abdecken. Auch Grenzfälle wo noch Fehler gefunden wurden, sind jetzt im neuen Schaltplan ausgemerzt. Wer will kann ja die Unterschiede suchen ;) Danach nochmal in 8Bit getestet, weil dann der Addierer mit einem Carry Lookahead IC arbeitet und 2 Schieberegister verkettet sind. Ein Aufblasen auf 16/32/64 oder sonstwas Bits ist somit nurnoch ein Erweitern der Schieberegisterkette und der ALU aus 74181/74182. Der nächste Schritt war dann das Erweitern auf 32Bit sowie der Einbau in den MIPS TTL CPU Kern, zumindest in VHDL. Um zu testen ob die Variablenübergaben funktionieren. In dem Sinne, dass der MIPS kern und die PUnktrechnungseinheit jeweils ein eigenes Steuerwerk haben. So hält eine laufende Punktrechnung den MIPS Kern an bis die Berechnung fertig ist. In dem VHLD Simulatorbild ist dann zu sehen: Bei instr[] ist 0022001a der div Befehl. Gut zu sehen wie der Punktrechner die CPU anhält. Dann rasselt er eine Berechnung durch und lässt die CPU wieder laufen. In hi und lo steht dann das Ergebnis. In diesem Falle 7/(-4) = -1 Rest 3
Angehängte Dateien:
-
SAM_2408k.jpg
230 KB -
SAM_2382k.jpg
140 KB
Die Videokarte ist fertig und gibt fröhlich Text über FBAS aus. Wenn die Doku dazu fertig ist post ich das noch rein. Ist ansonsten auf der VCFB 2016 in Berlin zu sehen.
:
Bearbeitet durch User
Mw E. schrieb: > Die Videokarte ist fertig und gibt fröhlich Text über FBAS aus. > > Wenn die Doku dazu fertig ist post ich das noch rein. > > Ist ansonsten auf der VCFB 2016 in Berlin zu sehen. Wahnsinn, dieser Fortschritt.
Mw E. schrieb: > 496TTL Bausteine auf 4 oder 6 Lagen Platinen > die im Betrieb 17A bei 5V fressen warum TTL? schon 1984 hatte ich im apple2+ fast alle TTL (LS TTL) soweit möglich durch HC(HCT) ersetzt, die brauchen wesentlich weniger Strom und sind auch bessere Treiber, das FAN out ist deutlich höher.
Joachim B. schrieb: > Mw E. schrieb: >> 496TTL Bausteine auf 4 oder 6 Lagen Platinen >> die im Betrieb 17A bei 5V fressen > > warum TTL? > > schon 1984 hatte ich im apple2+ fast alle TTL (LS TTL) soweit möglich > durch HC(HCT) ersetzt, die brauchen wesentlich weniger Strom und sind > auch bessere Treiber, das FAN out ist deutlich höher. Das ist die TU-Berlin, da muss man Abstriche machen. Man denke dein Argument konsequent zu Ende, wo wäre man denn da?
Bowd schrieb: > Man denke dein > Argument konsequent zu Ende, wo wäre man denn da? bei nem Smartphone...
Bowd schrieb: > Das ist die TU-Berlin, da muss man Abstriche machen. OK, trotzdem kommt es mir vor wie ein (Design)Fehler. Bowd schrieb: > Man denke dein > Argument konsequent zu Ende, wo wäre man denn da? beim aktiven stromsparen? Mit weniger thermischen Problemen?
:
Bearbeitet durch User
Na dann zeig mir mal nen lieferbaren 74HC181, 74HC182, 74HC825 sowie 74HC870. Zudem ist HC langsamer als F/S/AS, erst AC ist dann wieder shcnell genug. In AC bekommt man die "fancy" Schaltkreise aber auch nicht mehr. Der 74S181 rechnet zusammen mit S182er Carry Lookahead nen 32Bit Integer in 28ns durch. bei einem 74HC181 ist das Propagatian Delay vom Operator Eingang zum Carry Lookahead Ausgang schön höher und das für einen IC! Und was will man bei dem Projekt bitte Strom sparen?
bei der TU Berlin dürfte da der so oft gefordete Aspekt der Ausbildung durch Verstehen der Grundlagen im Vordergrund stehen und nicht das lego-mäßige Zusammenstöpseln fertiger Komponenten
Mw E. schrieb: > Na dann zeig mir mal nen lieferbaren 74HC181, 74HC182, 74HC825 sowie > 74HC870. > > Zudem ist HC langsamer als F/S/AS OK OK, das ist eine verständliche Antwort, ich bekomme ja auch nicht mehr alle benötigen F AC AHCT Steine aber ich bekomme auch nicht mehr alle (LS)TTL Steine und mit SN75162 in DIL siehts auch mies aus.
Wenn man mal in die andere Richtung denkt, hätte man ECL nehmen können, dass wäre schneller, aber würde noch viel mehr Strom schlucken. Dafür ist die Verfügbarkeit erstaunlich gut. Linux darauf zum laufen zu bringen wäre schon cool, mit 8Mb Ram wäre sogar X11 möglich (zumindest damals auf nem 486 war es das).
:
Bearbeitet durch User
Lukas S. schrieb: > hätte man ECL nehmen können, > dass wäre schneller, aber würde noch viel mehr Strom schlucken. Dafür > ist die Verfügbarkeit erstaunlich gut. ja aber leider auch nicht für alles, hier liegen noch jede Menge kaputte Geräte wo man die benötigten ECL nicht mehr zu angemessenden Preisen bekommt. Das einzige was ich noch in ECL habe sind Röhren :) aber wie deren Zustand ist müsste geprüft werden.
:
Bearbeitet durch User
Ooooch, LS/S/AS/F kann man noch stangenweise als NOS kaufen, zB ebay. Die gibts aber nur jenseits des großen Teichs, weil damals noch dort drüben hergestellt. War ja zu der Zeit Hightech. ECL klingt ist schon interessant, ist aber nur marginal schneller als F. Wobei es da auch mal eine ECL Subgruppe gab, die 1GHz schaffte. Das Problem ist aber, dass es nurnoch Einzelgatter zu kaufen gibt (sogar von TI), aber höhere Logikfunktionen nicht mehr. Nun könnt man sich ne ALU auch selber bauen, die MIPS ALU kann ja nicht sonderbar viel. Dann ist der Geschwindigkeitsvorteil aber komplett weg. Eine RAM Erweiterung ist irgendwann geplant, dann geht da noch mehr. Vllt sogar eine billig MMU, die so 16 Speicherbereiche mappen kann.
Wenn es nicht unbedingt der 74181 sein muss .. AMD brachte 1975 die AM2900 BIT-Slice Prozessoren auf den Markt. Es gab später dann komplette 16Bit Rechenwerke in 64poligen Dip Gehäusen wie den CY7C9101. Oder gleich eine PDP-11 ;-))
Der CY7C9101 sieht interessant aus, der hat quasi die gesamte Hardware für das serielle Multiplizieren/Dividieren eingebaut. Wenn das geplante TTL Grab für diese Operationen die 6,7MHz nicht schafft, dann ist das eine Überlegung wert!
Das Netzteil mit 5V 40A wäre dann fertig. Sowie der Monitor mit Ansteuerung und HV Teil. Bilder hier: http://www.fritzler-avr.de/spaceage2/gallery/main.php?cmd=album&var1=Zusatzger%E4te/ Doku hier: http://www.fritzler-avr.de/spaceage2/down_doku.htm
Angehängte Dateien:
-
mipsemu.png
8,6 KB
Es ist dann doch etwas nervig nach der Arbeit/Studientag zum Ort zu fahren wo der MIPS TTL steht. Also habe ich mal einen MIPS Emulator geschrieben, der auch das veränderte Exception/Interruptsystem hat. Bisher sind der MIPS Kern fertig und der 16C550 UART. Der UART öffnet einen virtuellen tty (pty) auf den dann ein xterm geöffnet wird. Durch einen Austausch des Filedescriptors könnte dann auch auf ein ttyUSB zugegriffen werden um ein relles Terminal wie das VT100 anzuschließen. Im Bild läuft Eliza (eines der Programme zur VCFB 2016) über dem UART. Das Programm musste nicht angepasst werden.
:
Bearbeitet durch User
Mw E. schrieb: > Na dann zeig mir mal nen lieferbaren 74HC181, 74HC182, 74HC825 sowie > 74HC870. Wie schön, dass ich davon noch eine Menge rumliegen habe
Angehängte Dateien:
-
spemugdp.png
27 KB -
spemu3.png
2,3 KB -
spemu2.png
1,5 KB -
spemu1.png
12 KB
Na dann schnapp dir etwas Lochraster und bau nen MIPS Prozessor draus ;) Asonsten noch ein paar Bilder des Emulators, jetzt auch mit GDB Anbindung! Zudem ist jetzt auch die Videokarte emuliert, daher noch ein Bild von Game Of Life und einmal Soviet Snake.
:
Bearbeitet durch User
Mw E. schrieb: > Zudem ist jetzt auch die Videokarte emuliert, daher noch ein Bild von > Game Of Life und einmal Soviet Snake. ein Linpack/LaPack wäre interessanter Aber schon extrem beeindruckend deine Arbeit!
Mit Linpack/LaPack wird villeicht getestet wenn die Multiplikationskarte fertig ist. Irgendwie muss man ja den Speedup in harten Zahlen sehen. Die Emulation der Punktrechnung in der Exception hat noch nichtmal alle Register gesichert bevor die Hardwarekarte fertig ist mit rechnen.
Uiui, erinnert mich an meine Anfangszeit in der Computertechnik -)
Mw E. schrieb: > Na dann zeig mir mal nen lieferbaren 74HC181, 74HC182, 74HC825 sowie > 74HC870. > > Zudem ist HC langsamer als F/S/AS, erst AC ist dann wieder shcnell > genug. > In AC bekommt man die "fancy" Schaltkreise aber auch nicht mehr. > > Der 74S181 rechnet zusammen mit S182er Carry Lookahead nen 32Bit Integer > in 28ns durch. bei einem 74HC181 ist das Propagatian Delay vom Operator > Eingang zum Carry Lookahead Ausgang schön höher und das für einen IC! > > Und was will man bei dem Projekt bitte Strom sparen? Warum zum Teufel reiten immer Alle auf dem 74181 herum, die Industrie hat damals AM2901 und Konsorten verwendet. Der AM2901C ist intern IMHO ECL mit TTL IO, der AM29C01 die CMOS Ausführung. Gruß, Holm
Dann guck mal über deinen Tellerrand hinaus. Den 74F181 bekommt man günstig stangenweise als NOS über ebay. Den AM2901 als Einzelstücke zu horrenden Preisen. Weiterhin ist der 74F181 schnell genug, die ALU bremst unseren MIPS TTL nicht aus, sondern die langsamen SRAM Bausteine im Steuerwerk. Andere Logikpfade sind auch langsamer als die ALU.
Mw E. schrieb: > Dann guck mal über deinen Tellerrand hinaus. > Den 74F181 bekommt man günstig stangenweise als NOS über ebay. > Den AM2901 als Einzelstücke zu horrenden Preisen. Weswegen ich in den USA eine Stange NOS AM2901DC für $20 kaufen konnte und die Russen werfen einem die K1804xxxx auch nach, die Frage ist halt ob man sich auf die Angebote für die Vitrinenfreaks mit weiß/goldenem Gehäuse einschießt oder wirklich nur die Funktionalität haben möchte. > > Weiterhin ist der 74F181 schnell genug, die ALU bremst unseren MIPS TTL > nicht aus, sondern die langsamen SRAM Bausteine im Steuerwerk. > Andere Logikpfade sind auch langsamer als die ALU. Die AM290x sparen einen Haufen Gemüse im Datapath.. die 74181 ist nur die ALU, die 290x sind RALU ..enthalten also auch die schnellen Register, die AM2910 ist ein dazu passendes Steuerwerk.. Die Firma IDT hat mit den 49C402 höher integrierte Bausteine auf den Markt gebracht, 16 Bit auf einem Chip, erweiterte Steuerwerke gibts auch 49C410..nur Beispiele. [Mod: Sinnloses Geplänkel gelöscht, da nicht zur Diskussion beitragend] Gruß, Holm
:
Bearbeitet durch Moderator
[Mod: Sinnloses Geplänkel gelöscht, da nicht zur Diskussion beitragend] MIPS hat 32 Register und der AM2901 stellt nur 16 bereit (A [0...3]) -> zu wenig. Das Steuerwerk könne wir nicht nutzen, weil es nicht auf MIPS ummünzbar ist. Der AM2901 hat keinen barrelshifter, also kann pro Takt nur um 1 Byte schieben, MIPS kann aber pro Takt um bis zu 32 Bitpositionen schieben. Der AM2901 hat zwar viel OnChip, aber das schränkt auch wieder seine Nutzbarkeit ein. [Mod: Sinnloses Geplänkel gelöscht, da nicht zur Diskussion beitragend]
:
Bearbeitet durch Moderator
Joachim B. schrieb: > warum TTL? Warum überhaupt? Wenn du einen schnellen und stromsparenden Rechner willst, wirst du ganz bestimmt nicht so ein Projekt starten. Egal ob in TTL oder CMOS. Weshalb in Retro-Projekten die Entscheidung für eine bestimmte Technik nicht unbedingt mit Effizienz zu tun haben muss.
:
Bearbeitet durch User
[Mod: Sinnloses Geplänkel gelöscht, da nicht zur Diskussion beitragend] > > MIPS hat 32 Register und der AM2901 stellt nur 16 bereit (A [0...3]) -> > zu wenig. AM29705, AM29707. > Das Steuerwerk könne wir nicht nutzen, weil es nicht auf MIPS ummünzbar > ist. Das erklärst Du mir bitte genauer. > Der AM2901 hat keinen barrelshifter, also kann pro Takt nur um 1 Byte > schieben, MIPS kann aber pro Takt um bis zu 32 Bitpositionen schieben. > Die 74181 hat einen Barrel Shifter? Da wäre noch die AM2903, AM29203...und die von denen ich bereits vorher schrieb. > Der AM2901 hat zwar viel OnChip, aber das schränkt auch wieder seine > Nutzbarkeit ein. > Achwas. Dann nimm den 2903, 29c101, 29C116 oder 49Cxxx. Du hast oben die Cy7C9101 interessant gefunden, das ist im Wesentlichen die AM29C101..die natürlich völlig unbrauchbar ist. Mann kommt das flach.. > Sonst noch was? > Du hast nicht drüber nachgedacht, legst aber Wert darauf mich "abzubügeln". Ich weiß nicht was das soll..aber wenns schee macht.. Du kannst mit 74181 nichts machen was mit der 2901 nicht geht. >>Weswegen ich in den USA eine Stange NOS AM2901DC für $20 kaufen konnte > Nicht jeder fährt mal eben so in die USA bzw. das Schnäppchen ist dann > greifbar wenn man es braucht. > Welch durchschlagendes Argument! Ich war aber noch nie da un so lange sich die Verhältnisse mit den Einreisekontrollen da nicht ändern werde ich da auch nicht auftauchen. Gastfreundschaft ist was Anderes. ..Demotronic aus dem zitierten Text gleich verschwunden, kein Gegenargument? [Mod: Sinnloses Geplänkel gelöscht, da nicht zur Diskussion beitragend] Gruß, Holm
:
Bearbeitet durch Moderator
[Mod: Sinnloses Geplänkel gelöscht, da nicht zur Diskussion beitragend] Holm T. schrieb: >> MIPS hat 32 Register und der AM2901 stellt nur 16 bereit (A [0...3]) -> >> zu wenig. > > AM29705, AM29707. Bist du lustig... Erst verweist du auf den Vorteil des AM2901, dass dieser interne Register hat und ich sage das sind zu wenige. Jetzt schlägste mir 2 Dualport SRAMs vor ohne ALU drann. Wo ist da jetzt der Unterschied zur bisherigen Lösung mit 74181 und 74870? Kann die internen Register ja imemrnoch nicht nutzen. Dazu wirds ja nun langsam richtig exotisch. Holm T. schrieb: >> Das Steuerwerk könne wir nicht nutzen, weil es nicht auf MIPS ummünzbar >> ist. > > Das erklärst Du mir bitte genauer. Guck dir den MIPS Befehlsatz und seine Coderung an, danach was der Sequenzer kann. Sag MIR doch lieber wieso gehen sollte. Holm T. schrieb: >> Der AM2901 hat keinen barrelshifter, also kann pro Takt nur um 1 Byte >> schieben, MIPS kann aber pro Takt um bis zu 32 Bitpositionen schieben. >> > > Die 74181 hat einen Barrel Shifter? > Da wäre noch die AM2903, AM29203...und die von denen ich bereits vorher > schrieb. Nein hat er nicht, aber das ist wieder auf die von DIR betonte integrierung des AM2901 ICs bezogen, also les mal genauer. 74181 und Barrelshifter liegen beim Projekt einfach parallel im Datenpfad. Beim Am2901 müsst man den jetzt irgendwie ranfrickeln, abgesehen von der zu geringen Registeranzahl. Weiterhin scheinste ja nichtmal die DB deiner vorgeschlagenen ICs zu lesen, diese ICs haben auch keine Barrelshifter und könne somit auch nur eine Bitposition pro Takt schieben. Der AM29203 versprvht aber schonmal, dass man bei dem die Registerbank vergrößern kann (dann wird der aber langsamer beim rechnen). Man kanns aber auch schöner haben und es von anfang an trennen, das ist nachvollziehbarer. Holm T. schrieb: > Achwas. > Dann nimm den 2903, 29c101, 29C116 oder 49Cxxx. > Du hast oben die Cy7C9101 interessant gefunden, das ist im Wesentlichen > die AM29C101..die natürlich völlig unbrauchbar ist. Mann kommt das > flach.. Bitte genauer lesen warum ich weiter oben den Cy7C9101 interessant fand! Für den Multiplizierer, weil da die closed Loop alles hat was ich brauche. [Mod: Sinnloses Geplänkel gelöscht, da nicht zur Diskussion beitragend]
:
Bearbeitet durch Moderator
Mw E. schrieb: > Holm T. schrieb: >> Ich muß angesichts Deiner Antworten meine bisherige Meinung über Dich >> noch mal überdenken lieber Henry. > Ich bin nicht Henry! Ok, dann nicht. Dann steigt meine Meinung über Henry wieder. > > Sinnlos bashen ist allerdings weiter drauf rumzureiten obwohls dem Thema > nix bringt, hatte weiter oben schon gesagt wieso der AM nicht genutzt > wurde und dann tippste wild weiter. "Der AM" ist eine ganze Serie. Welche Begründung zu genau welchem davon hast Du geschrieben? > > Holm T. schrieb: >>> MIPS hat 32 Register und der AM2901 stellt nur 16 bereit (A [0...3]) -> >>> zu wenig. >> >> AM29705, AM29707. > Bist du lustig... > Erst verweist du auf den Vorteil des AM2901, dass dieser interne > Register hat und ich sage das sind zu wenige. > Jetzt schlägste mir 2 Dualport SRAMs vor ohne ALU drann. Die passen exakt an die RALU Chips, dazu sind sie nämlich da, als Erweiterung des internen Registersatzes. Bei IDT und Cypress gibts die Serie mit mehr internen Registern und es gibt auch keinen direkten Zusammenhang zwischen den CPU Registern die man auf Assembler Ebene sieht und den in der Mikroprogramm Architektur. Das weißt Du und ich weiß das auch. > Wo ist da jetzt der Unterschied zur bisherigen Lösung mit 74181 und > 74870? > Kann die internen Register ja imemrnoch nicht nutzen. > Dazu wirds ja nun langsam richtig exotisch. Die 2901 Serie besteht nicht nur aus 74181 und Registern. > > Holm T. schrieb: >>> Das Steuerwerk könne wir nicht nutzen, weil es nicht auf MIPS ummünzbar >>> ist. >> >> Das erklärst Du mir bitte genauer. > Guck dir den MIPS Befehlsatz und seine Coderung an, danach was der > Sequenzer kann. Sag MIR doch lieber wieso gehen sollte. Sagt Dir der Begriff Mapping Rom irgend Etwas oder ist Dir da auch ne Masche runter gefallen? > > Holm T. schrieb: >>> Der AM2901 hat keinen barrelshifter, also kann pro Takt nur um 1 Byte >>> schieben, MIPS kann aber pro Takt um bis zu 32 Bitpositionen schieben. >>> >> >> Die 74181 hat einen Barrel Shifter? >> Da wäre noch die AM2903, AM29203...und die von denen ich bereits vorher >> schrieb. > Nein hat er nicht, aber das ist wieder auf die von DIR betonte > integrierung des AM2901 ICs bezogen, also les mal genauer. Ich kann hier schreiben was ich will, Du wirst jedes Mal ein anderes Argument an den Haaren herbei ziehen. > 74181 und Barrelshifter liegen beim Projekt einfach parallel im > Datenpfad. > Beim Am2901 müsst man den jetzt irgendwie ranfrickeln, abgesehen von der > zu geringen Registeranzahl. Dann nimm doch nicht den 2901! Der 2901 war als Erster seiner Serie angeführt, es gibt da wesentlich mehr, auch 16 Bit Slices mit Shiftern, mit mehr internen Registern usw., das hatte ich Alles schon angemerkt. > Weiterhin scheinste ja nichtmal die DB deiner vorgeschlagenen ICs zu > lesen, diese ICs haben auch keine Barrelshifter und könne somit auch nur > eine Bitposition pro Takt schieben. Es gibt nicht nur Barrelshifter > Der AM29203 versprvht aber schonmal, dass man bei dem die Registerbank > vergrößern kann (dann wird der aber langsamer beim rechnen). Man kanns > aber auch schöner haben und es von anfang an trennen, das ist > nachvollziehbarer. Nochmal, IDT, Cypress und Andere, schneller, mehr Register intern, Shifter und Multiplizierer/Addierer.... > > Holm T. schrieb: >> Achwas. >> Dann nimm den 2903, 29c101, 29C116 oder 49Cxxx. >> Du hast oben die Cy7C9101 interessant gefunden, das ist im Wesentlichen >> die AM29C101..die natürlich völlig unbrauchbar ist. Mann kommt das >> flach.. > Bitte genauer lesen warum ich weiter oben den Cy7C9101 interessant fand! > Für den Multiplizierer, weil da die closed Loop alles hat was ich > brauche. Ach! Du bist ja auch der Einzige von uns Beiden der nun konsequent auf dem 2901, dem einfachsten aus seiner Familie herumreitet. Vergleiche mal den Cy7C9101 mit dem IDT49C401 oder auch dem AM29C101, evtl. fällt Dir ja irgendwas auf... > > Holm T. schrieb: >> Du hast nicht drüber nachgedacht, legst aber Wert darauf mich >> "abzubügeln". >> Ich weiß nicht was das soll..aber wenns schee macht.. >> Du kannst mit 74181 nichts machen was mit der 2901 nicht geht. > Jetz hör hier mal wirklich mit seinem sinnlosen blabla auf! ..Moooment. Warst das nicht gerade eben Du noch der hier mit sinnlosem Blabla kam und mir Bashing unterstellte? > Abbügeln geht eher in die andere Richtung, du versuchst hier unser > Projekt als undurchdacht abzuhaken und schlägst sinnfrei irgendwelche > ICs vor OHNE vorher mal zu gucken ob die überhaupt passend wären. Was > diese nicht sind. Beschäftige dirch erstmal genauer mit dem Aufbau des > Projekts anstatt wie ein Rottweiler auf das Stichwort 74181 > anzubeißen... Das gebe ich Dir gerne zurück! Was genau geht mit der 74181 was mit der 2901 nicht geht oder aufwändiger währe? Lies Dir Donamaie E White durch und/oder Mick & Brick, danach reden wir weiter was geht und was nicht. Ihr habt eine Bit Slice CPU mit einem niedrigen Integrationsgrad aufgebaut, auch der Barrelshifter hängt da "irgendie rangebastelt" dran, aber bei den von mir genannten Alternativen muß wohl ein fertiger Mikroprozessor in einem Chip sein...nimm doch eine Mips! Gruß, Holm
> Nein, eigentlich nicht, denn Du hast kein einziges "warum" stichhaltig > begründen können sondern meine Fragen und Gegenargumente jedes Mal unter > den Tisch fallen lassen, dafür kam aber auch jedes Mal eine neue Idee > warum es nicht geht. Er hat gesagt warum die Am290x nicht gehen: Registerfile ist zu klein, dann muss du z.B. extra Registern einbauen. Die ALU (Am290x) muss auch diese Registern lesen und schreiben können: mehr muxes, mehr FFs, Glue-logic, usw. am Ende des Tages hast du wahrscheinlich nicht viel gewonnen :(. Ich hab gedacht daß klar war warum (Habe auch selbe den MIPS Prozessor als Verilog Module entworfen wollen und habe es mir genau angeschaut). Es gibt ein Paperbei AMD wo sie ein 8080 mit diesen Bit-Sclice ALUs entwerfen, eine Platine Voll !... Sehr interessant.
R.A. P. schrieb: >> Nein, eigentlich nicht, denn Du hast kein einziges "warum" stichhaltig >> begründen können sondern meine Fragen und Gegenargumente jedes Mal unter >> den Tisch fallen lassen, dafür kam aber auch jedes Mal eine neue Idee >> warum es nicht geht. > > Er hat gesagt warum die Am290x nicht gehen: Registerfile ist zu klein, > dann muss du z.B. extra Registern einbauen. Die ALU (Am290x) muss auch > diese Registern lesen und schreiben können: mehr muxes, mehr FFs, > Glue-logic, usw. am Ende des Tages hast du wahrscheinlich nicht viel > gewonnen :(. Guten Morgen. > Ich hab gedacht daß klar war warum (Habe auch selbe den MIPS Prozessor > als Verilog Module entworfen wollen und habe es mir genau angeschaut). > Es gibt ein Paperbei AMD wo sie ein 8080 mit diesen Bit-Sclice ALUs > entwerfen, eine Platine Voll !... Sehr interessant. [Mod: persönliche Angriffe gelöscht] Das von Dir angeführte Problem wurde weiter oben diskutiert und ich habe auch auf AM29705/707 hingewiesen die nahtlos als Erweiterung des Registerfiles an ICs > AM2901 passen. Das sind keine Universal Dualport RAM sondern Registererweiterungen für die AM29xx Serie. Keine Muxes, keine Glue Logic, keine FFs sondern nur die zusätzlichen Adreßbits um die Register adressieren zu können. [Mod: persönliche Angriffe gelöscht] Gruß, Holm
:
Bearbeitet durch Moderator
Holm T. schrieb: > Das sind keine Universal Dualport RAM sondern Registererweiterungen für > die AM29xx Serie. > Keine Muxes, keine Glue Logic, keine FFs sondern nur die zusätzlichen > Adreßbits um die Register adressieren zu können. [Mod: persönliche Angriffe gelöscht] Guck mal in das Datenblatt deiner geliebten ICs.
:
Bearbeitet durch Moderator
Ja Du hast Recht ich bin ein Lügner (oder?), gemessen hier dran: http://www.fritzler-avr.de/spaceage2/!Files/Schaltplan/Schaltplan_register.pdf und dem hier http://www.fritzler-avr.de/spaceage2/!Files/Schaltplan/Schaltplan_registermultiplex.pdf ist das mit dem AM29705/707 natürlich ein exorbitant hoher Aufwand. Ihr habt ja quasi nicht mal ein einziges Gatter verwendet, geschweige denn einen Multiplexer oder Decoder :-).. Das Datenblatt zeigt eine Variante der Beschaltung, man muß das nicht so machen. Überlege mal was nach meiner Aussage "nur zuätzliche Bits zur Adressierung" noch von der Schaltung übrig bleibt. Du willst von mir Antworten? Wie wäre es denn wenn Du mal eine meiner Fragen weiter oben beantwortest und diese nicht einfach unter den Teppich kehrst? Ein Beispiel wäre mal die aussehende Erklärung warum ein CY7C9101 "interessant aussieht" ein AM29C101 aber nicht geeignet ist wo doch das Cypress Datenblatt (hallo Datenblatt!!!) erzählt: "The CY7C9101 is a pin-compatible, functional equivalent for the Am29C101 with improved Performance" [Mod: persönliche Angriffe gelöscht]
:
Bearbeitet durch Moderator
[Mod: persönliche Angriffe gelöscht] Holm T. schrieb: > Das Datenblatt zeigt eine Variante der Beschaltung, man muß das nicht so > machen. Überlege mal was nach meiner Aussage "nur zuätzliche Bits zur > Adressierung" noch von der Schaltung übrig bleibt. Das Datenblatt zeigt das Minimalbeispiel, da ist jetzt nichts was wegfallen könnte außer das PROM. Irgendwie muss man die "zusätzlichen Bits" ja anschließen und und decodieren. Diese Logik ist eben nicht in den ICs vorhanden sondern erfolgt extern. Außerdem erzähl mir mal wie man mit dieser Kombination das Register 0 in Hardware auf 0x00000000 legen kann. Bei MIPS Ist Register 0 immer 0 und nicht beschreibbar. -> schon kommt da noch mehr Logik rein. Da du ja nichtmal Schaltpläne lesen kannst hier eine Erklärung zu diesem: http://www.fritzler-avr.de/spaceage2/!Files/Schaltplan/Schaltplan_register.pdf Die Eigentlichen Register sind nur die rechte Hälfte des Plans (Spalte 3 und 2). Das ist in etwa das was auch in der pdf zum Minimalbeispiel der AMxxx im Anhang von mir zu sehen ist, zwar ohne ALU, aber schon in 32 Registern zu 32Bit. Dafür ist das echt wenig. Die linke Seite (Spalte 5, 4, 3) sind die Ansteuerlogik um aus einer Instruction die Adressbits für die Register zu generieren. Diese Logik würde 1zu1 auch benötigt beim AMxxx, im Minimalbeispiel kommen ja so schön die Adressbereich A, B und C an. Irgendwie müssen die ja auchnoch erzeugt werden. Zusätzlich dazu ist da auchnoch eine Menge Logik für den Debugger vorhanden. Der Debugger muss ja lesend/schreibend auf die Register zugreifen können. Fast vergessen: Adressbits merken für den Branch Delay Slot des MIPS. [Mod: persönliche Angriffe gelöscht] Holm T. schrieb: > Ein Beispiel wäre mal die aussehende Erklärung warum ein > CY7C9101 > "interessant aussieht" ein AM29C101 aber nicht geeignet ist wo doch das > Cypress Datenblatt (hallo Datenblatt!!!) erzählt: "The CY7C9101 is a > pin-compatible, functional equivalent for the Am29C101 with improved > Performance" Jetzt vermischte hier schonwieder Dinge, arbeite mal an deiner Argumentationsfähigkeit. Dieser IC sieht interessant aus für den Hardware Multiplizierer. Dort bildet die integrierte Schleife mit ALU und Shifter genau das ab was man für einen seriellen Multiplizierer (und auch dividierer) braucht. Für die eigentliche TTL MIPS CPU wieder uninteressant. Beim MUL werden aber auch erstmal 181er verwendet, die haben wir jetzt stangenweise und die BOM muss man ja nicht hochtreiben bei nicht mehr hergestellten ICs. [Mod: persönliche Angriffe gelöscht]
:
Bearbeitet durch Moderator
Mw E. schrieb im Beitrag #4794106: > ab Beitrag "Re: Space Age 2 der 32Bit MIPS Rechner in TTL" darf gerne > alles ausradiert werden ;) Ich fand die technische Diskussion (wenn man die emotionalen Teile ausblendet) gar nicht so uninteressant.
Hui da gings jetzt aber hoch her, macht doch beide erst einmal ein Reise: https://de.wikipedia.org/wiki/Gullivers_Reisen#Teil_1:_Reise_nach_Liliput
Habe dann mal den MIPS Emulator auf die Webseite gepackt falls es mal wer ausprobieren will. Habe auch das Binary der momentanen Software beigepackt. http://www.fritzler-avr.de/spaceage2/down_software.htm
WSI WS59032 ..wird angeblich immer noch produziert. Ein CMOS Highspeed Chip aus 8fach AM2901 4 Bit Slice mit 32x32 Bit internem Register RAM und weniger als 3% der Stromaufnahme des equivalenten Bipolar Systems. Gruß, Holm
Nein, ich habe nicht danach gesucht, aber Leute die den Loswerden wollen (IA59032) gibts durchaus: http://marketron.co.uk/obsolete.php http://proactivecomponents.com/products/ia59032-cpga101c-00 Gruß, Holm
Ich bin ganz fasziniert beim lesen des Threads. Was mich aber überrascht hat, ist das die Slices von AMD z.B. der Am2901 hier zum Thema gemacht werden. Ich wusste garnicht, dass es die noch gibt. Ich meine vor ein paar Jahren mal danach gesucht zu haben und nur Informationen aber keine konkreten Angebote gefunden zu haben. Mag mir da mal jemand ein paar Hinweise geben wo man sowas (also nicht unbedingt von AMD aber eben "Slices" heute noch zu kaufen kriegt)? Was würde mich sehr interessieren. Mir ist schon klar, das man sowas heute ökonomischer mit FPGAs macht. Aber ich würde das dennoch gerne wissen.
Bitraspler schrieb: > Ich bin ganz fasziniert beim lesen des Threads. > > Was mich aber überrascht hat, ist das die Slices von AMD z.B. der Am2901 > hier zum Thema gemacht werden. > > Ich wusste garnicht, dass es die noch gibt. Ich meine vor ein paar > Jahren mal danach gesucht zu haben und nur Informationen aber keine > konkreten Angebote gefunden zu haben. > > Mag mir da mal jemand ein paar Hinweise geben wo man sowas (also nicht > unbedingt von AMD aber eben "Slices" heute noch zu kaufen kriegt)? Was > würde mich sehr interessieren. > > Mir ist schon klar, das man sowas heute ökonomischer mit FPGAs macht. > Aber ich würde das dennoch gerne wissen. evita.lt (K1804VS1, VS2 [cyrillisch К1804ВС1 ]) oder demotronic.de (IDT,AMD, Cypress). Gruß, Holm
Negative Bewertung dafür das ich Jemandem auf Nachfrage Bezugsquellen heraussuche? OMG...das muß ja richtig weh tun.. BTW: der К1804ВС1 (AM2901) kostet bei evita.lt 30 Eurocent. Versand nach D war als ich letztens bestellt hatte was über 8 Euro..und .lt ist Europäische Union. Gruß, Holm
>Search - K1804VS1 > >Search: K1804VS1 > Search in product descriptions >Search >Products meeting the search criteria >There is no product that matches the search criteria. Dead end :( Weder K1804 noch AM2901 :( AM2901 gibt es noch bei Aliexpress. Evtl. kann man es in einem CPLD rein packen.
Alex schrieb: >>Search - K1804VS1 >> >>Search: K1804VS1 > > >> Search in product descriptions >>Search >>Products meeting the search criteria > >>There is no product that matches the search criteria. > > Dead end :( > > Weder K1804 noch AM2901 :( > > AM2901 gibt es noch bei Aliexpress. Evtl. kann man es in einem CPLD rein > packen. Sieh mal zu wie Du Dein totes Ende wieder auf die Beine bekommst: http://www.evita.lt/index.php?route=product/search&search=1804 http://www.evita.lt/en/m-1804vs1-kr-mikroschema-kr1804vs1?search=1804 K vs. KR ist eine Gehäusevariante.. 1804 ist die Serie, die hatten mal mehr davon. Irgendwie scheine ich hie verpflichtet zu sein für die Leute die nicht selber suchen können den Kram zu finden. Sowas mache ich auch kommerziell, dann bekomme ich das aber üblicherweise bezahlt. 1804VS1 im Plastik Dil Gehäuse kann ich Dir aber auch ein paar vermachen. Die im weißen Keramikgehäuse mit goldenen Pins behalte ich aber selbst. Gruß, Holm
Angehängte Dateien:
-
spemu5.png
6,1 KB
Mike B. schrieb: > Mw E. schrieb: > >> Zudem ist jetzt auch die Videokarte emuliert, daher noch ein Bild von >> Game Of Life und einmal Soviet Snake. > > ein Linpack/LaPack wäre interessanter Linpack war dann doch einfacher als gedacht. Musste nur die Funktion zum Zeit einlesen abändern. Der Code ist von hier: http://www.netlib.org/benchmark/linpackc Habs aber ersteinmal nur auf dem Emulator getestet, die Hardware ist seit der Messe noch gut verpackt. Das FPGA Board hat leider zu wenig BlockRAM für die 32k große Matritze für die Berechnungen. Da es keine FPU gibt, wird natürlich die lib des gcc genutzt und da kommen selbst im Emulator ernüchternde Zahlen raus: 22kFLOPS. Is ja mal ganix ;) Integer Benchmarks wären auchnoch interessant, wenn Zeit is.
holm und fritzler: bitte bei der Sache bleiben. Streiten könnt ihr per PN.
Mw E. schrieb: > Da es keine FPU gibt, wird natürlich die lib des gcc genutzt und da > kommen selbst im Emulator ernüchternde Zahlen raus: 22kFLOPS. > Is ja mal ganix ;) Sei stolz auf Dich! Einen Linpack auf einer Eigenentwicklung zum Laufen zu bringen ist aller Ehren wert! 22kFlops, besser als nix. Bei welcher Taktrate lief der Emulator? Ich hatte ja damals einen beowulf-Cluster mit einem Server und drei Stück PentiumM 1.6GHz Nodes und hatte auch nur ~250MFlops im Verbund gesamt, obwohl schon ein einzelner Prozzi was bei 400MFlops bringen müsste, genaue Werte wiess ich nich mehr. http://www.roylongbottom.org.uk/linpack%20results.htm (double precision 32bit)
Mike B. schrieb: > Sei stolz auf Dich! > Einen Linpack auf einer Eigenentwicklung zum Laufen zu bringen ist aller > Ehren wert! Das war doch nur kopierter C Code von dem Link. Mike B. schrieb: > 22kFlops, besser als nix. Bei welcher Taktrate lief der Emulator? Der Emulator läuft in einer Linux VM auf einem Win7 Host auf einem i5-2500k. Zudem ist der Emulator nicht optimiert, einfach nur an einem Wochenende runtergeschriebener Code (für den MIPS Kern).
mal eine Zusatzfrage: wieso heisst das Teil eigentlich "Space Age"? Hab ich das überlesen?
Rate mal. Schätze mal als Anlehnung an die Bordrechner der ersten unbemannten Weltraum Missionen.
Huch, da hab ich sträflicherweise vergessen zu Antworten... Matthias W. hats aber schon aufgelöst. Die Namensgebung kommt von Henry und ist eben an diese Bordrechner engelehnt. Wobei es da eher um das Zeitalter selbst ging, also Space Missinen und die Rechner entwickelten sich um die Berechnungen durchführen zu können. Den Space Age 1 gibts übrigens auch, der hat 4Bit und besteht aus Einzeltransistoren. Eine Webseite wirds dazu auch mal geben, aber erstmal keine Zeit dafür. https://www.lndw.tu-berlin.de/uploads/tx_mulflndwprojects/_Teilansicht1.jpg https://www.eecs.tu-berlin.de/fileadmin/f4/fkIVbilder/LaNa2012/SPACE_AGE2.JPG https://www.youtube.com/watch?v=H-Ui5wxCzvU edit: Der SP1 ist im Heinz Nixdorf Museum in Paderborn ausgestellt (wenn ich mich richtig erinner)
:
Bearbeitet durch User
Hey Martin, ich bin echt begeistert, wie weit das Projekt verfolgt wurde! Im Nachhinein betrachtet war das Space Age 2 Projekt eines der besten Projekte, bei dem ich von Anfang bis Ende mitgewirkt habe! Hinsichtlich Qualität der Arbeit, Dokumentation und Fehlermanagement wurde sehr akribisch gearbeitet. Das war einerseits nervig, andererseits der richtige Weg! Die dicke technische Akte (Doku-Ordner) sprach schon damals Bände, wenn sie während der VCFB verwendet wurde, um Fragen anschaulich zu beantworten! So muss das sein! Ich erinnere hierbei nur an Henry's Dokumentationskette bei Layoutfehlern! Dank der VHDL Simulation konnten die meisten Fehler noch während der Layoutphase behoben werden - ein sehr gutes Beispiel dafür, wie wichtig (Software-)Tests sind - eine Tätigkeit, die gerne vernachlässigt wird. Ich weiß noch, wie stolz Henry darauf war, dass die erste realisierte Hardware-Revision der ALU Platine fehlerfrei lief.. Dieses Projekt konnte das im Buch "Die Seele einer neuen Maschine" beschriebene Gefühl ansatzweise, aber intensiv wiedergeben! Dies wäre ohne Henry's nervenzerrenden Einsatz nicht möglich gewesen. ;] @Henry: danke! Ich möchte mich außerdem bei allen Beitragenden zu diesem Thread für die gute Diskussion bedanken. Viele Grüße, Martin Schürer Ps: melde dich mal bei mir, falls du Interesse an einer Stelle als HW-Entwickler im Medizinbereich hast - wir suchen zur Zeit ;)
Martin Schuerer schrieb: > Dieses Projekt konnte das im Buch "Die Seele einer neuen Maschine" > beschriebene Gefühl ansatzweise, aber intensiv wiedergeben! > Ps: melde dich mal bei mir, falls du Interesse an einer Stelle als > HW-Entwickler im Medizinbereich hast - wir suchen zur Zeit ;) Ist die Aufwärmung einer thread-Leiche jetzt als versteckte Werbung für ein Buch oder als Hilferuf beim Stichwort "Fachkräftemangel" gedacht gewesen? In der Tat schade das dieser thread vorübergehend (?) eingeschlafen ist. Echt spannende Arbeit dies.
Angehängte Dateien:
-
muldiv_vorn.jpg
400 KB -
muldiv_hinten.jpg
390 KB -
muldiv_einbau.jpg
270 KB -
muldiv_fehler_sreg.jpg
90 KB -
muldiv_fehler_sreg1.jpg
140 KB -
muldiv_fehler_sreg2.jpg
12 KB
plöpp Es leeeebt! Also die Karte für Hardware Multiplikation und Division. Die CPU läuft damit merklich schneller, aber der Linpack will auf der echten Hardware nicht laufen und schmiert mit nem Stackoverflow ab. Das tut er auch mit der vorherigen Emulation der Punktrechnarten. Woran das liegt sehe ich wohl erst wenn der Debugger des CPU Kerns dann auch mal mit dem GDB spricht und nicht nur der Emulator. Allerdings hatte sich die Karte anfänglich bei manchen Multiplikationen verrechnet. Die Fehler lagen alle im oberen Bereich (siehe muldiv_fehler_sreg). Im Endeffekt hatte sich da der Massepin beim Sockeln verbogen. (muldiv_fehler_sreg1) TTL hat eben keine Clampdioden und läuft somit nicht ohne GND :> Beim Taschenrechnerprogramm ergab 5x5=25,00001 Der rechnet intern in double, aber 0,00001 ist dafür zu viel Fehler. Vor allem wenn mit der MulDiv Emulation genau 25 rauskam (durch ein snprintf geschönt natürlich). Nun ruft die softfloat Lib mehrmals die Punktrechenarten auf. Da sieht man den Fehler nicht so einfach. Also musste der Debugger dahin erweitert werden, dass er automatisiert sämtliche Inputs und Outputs der MulDiv Karte abschnorchelt. Das sah dann so aus: -------------------------MulDiv------------------------------- MULTU: 2279119104 * 390561520 10000111|11011000|10011001|00000000 * 00010111|01000111|01111110|11110000 HI_ist: 207250990; LO_ist: 1700622336 HI_soll: 207250989; LO_soll: 1700622336 HI_ist: 00001100|01011010|01100110|00101110; LO_ist: 01100101|01011101|01110000|00000000 HI_diff: 00000000|00000000|00000000|00000011; LO_diff: 00000000|00000000|00000000|00000000 HI_soll: 00001100|01011010|01100110|00101101; LO_soll: 01100101|01011101|01110000|00000000 Die Fehler sind alle in den LSB des HI Schieberegisters, d.h. am Anfang der Berechnung wird was falsches reingeschoben. Zudem: die Fehler waren alle bei unsigned mul, also ausgerechnet der einfachsten Rechenvorschrift! Am Ende wars nen kleiner Fehler im Mikrocode der MulDiv Schaltung, der Carryout der 74181 war 1 Takt zu früh freigeschaltet. Somit wurde eine 1 in das Rechenschieberegister geschrieben, die da nicht hingehört.
Da hab ich doch glatt den Schaltplan vergessen. Ist im Anhang.
Mw E. schrieb: > Die Doku zur MulDiv Karte wär jetzt auch fertig. sehr schön, +1 Aber welches A******** vergibt für diese Arbeit eine negative Bewertung? Bannen!
Solche Kleingeister gibts eben, da muss man drüber stehen ¯\_(ツ)_/¯
:
Bearbeitet durch User
@Mike B, das war kein versteckter Hilferuf. Manchmal gehen Menschen in Rente =) @Martin: gute Arbeit! Bin auf die nächsten Updates gespannt! Steht die Gdb Verbindung schon? Grüße und bis demnächst an der EN, Martin
Bevor der GDB auf die Hardware losgelassen wird muss die FT2232H Platine ersetzt werden. Die USB Paketlaufzeiten sind einfach zu hoch wenn nur was kleines Übertragen werden muss. Bei dem MulDiv Bugsuchen konnte man zugucken beim Registerauslesen. Durch das Schreiben deines Debugegrs auf ASM Ebene haste das ja auch bemerkt. Der CmdLineProgrammer (du solltest noch SVN Zugriff haben?) schaffts zwar nen 120kByte Programm in 5sek in den SRAM zu prügeln, aber eben nur unter Zuhilfename von vollen USB Paketen zum FT2232H. Sobald es nen PingPong braucht hat man verloren :/ Originalgeschwindigkeit! im Video: https://www.youtube.com/watch?v=68j4Y1E-bhk Daher kommt da wohl nen STM32 auf den DebugSteckplatz (oha mal eben die Rechenleistung verhundertfacht?) und darauf läuft dann der GDB Server. Dann muss Henry auch nicht mehr mit der VM rumfummeln, sondern kann per USB Stick "flashen".
Angehängte Dateien:
-
linpack_fpga.png
23 KB -
eliza.png
19 KB
So, ich habs jetzt mal geschafft die VHDL Implementation des Space Age 2 auf den aktuellen Stand zu ziehen. Also mit Terminal Videokarte und UART. Der Linpack braucht 1,5h zum Durchlaufen und spuckt dan sagenhafte 3kflops aus! Der Emulator in C hat 22kflops, denn er nutzt die MulDiv Routinen des Host Prozessors. Der Hardware MulDiv des Space Age 2 braucht 70 bis 100 Takte.
Sehr beeindruckend, ein Linpack der auf einem selbstgebauten Rechner ohne Problem durchläuft. Hut ab! Das Ergebnis ist: läuft!!! Die Zahl die da steht ist erstmal völlig wumpe.
Angehängte Dateien:
-
sam_3462.jpg
210 KB -
ds2_quickprint54.png
10 KB -
ds2_quickprint55.png
9,1 KB
Zwischen Weihnachten und Silvester ist jetzt etwas Zeit für ein Update. Das ist durchaus so viel, dass das jetzt mehrere Posts werden könnten wegen den Bildern. Zur VCFB 2018 wurde ja die MulDiv Karte fertig und der MIPS TTL wurde vor der VCFB ausgiebig getestet. Allerdings wohl nicht lang genug, nach mehreren Stunden Laufzeit stürzte die Kiste immermal ab. Das is ja mal doof! Um gegen zu checken ob wir da jetzt einen logischen Fehler haben musste der VHDL Teil nachgezogen, denn die Videokarte gabs noch nicht in VHDL. Wenn der Fehler dann im FPGA auftritt lässt sich in VHDL etwas Logik basteln welche verdächtige Signale traced und dann ausgibt. Zudem ist der jetzige FPGA zu klein von seinen BlockRAMs her um das gesamte programm zu speichern. Ein externer SRAM hing auch nicht dranne für den benutzten RAM des Programms. Daher musste zuerst einmal die Videokarte nachgezogen werden, denn das Programm nutzt diese und die Karte erzeugt zyklische IRQs welche den Programmfluss beeinflussen. Ein FPGA Board mit externem SRAM und genug BlockRAM belam ich von der Uni geliehen und ich musste noch ein VHDL Modul schreiben um den 2Takt pipelined SRAM an den MIPS TTL Speicherbus anzuschließen. (Warum auch immer der um 2 Takte gepiped ist) Im FPGA lief alles tagelang ohne Abstürze durch, so ein Mist aber auch. Dahin ist die gemütliche Fehlersuche. In den Bildern ist das FPGA Board zu sehen sowie die analoge Videokartenausgangsstufe und die Videosignale auf dem Oszi.
Da sich der Fehler im FPGA nicht zeigte wurde ersteinmal klassisch debuggt. Ein Absturz passierte ab und zu wenn nach einem Spiel der Highscore angezeigt wird. Bei der Ausgabe des Highscores wird das ganze Terminal vollgeschrieben mit Namen, Zeilentrennern und er Punktzahl. Das Terminal ist dabei ein VT101 auf 9600Baud. Der Absturz äußerte sich darin, dass nur der halbe Bildschirm geschrieben wurde und dann kam nurnoch Salat mit Speicherauskotzung des MIPS TTL. Was war der Fehler? Durch die neue MulDiv Platine ist die Zahlenumrechnung so schnell, dass das Terminal trotz 9600Baud überrannt wurde (aber eben nicht immer). Eigentlich sollte dies das XON/XOFF Handshaking verhindern, aber das hatte einen Bug. Bug 1 war, dass das XOFF vom Terminal nicht richtig gehandelt wurde und daher sich die FIFO implementierung abschießen lies (Bug2). Dann wurde dauergesendet und zwar der Speicherinhalt nach dem FIFO Pointer. Also waren es im Endeffekt 2 Fehler. Diese sind nun gefixt, aber diese beiden Fehler erklären nicht wieso die Zahlen manchmal einfach falsch umgerechnet wurden. zB wurde manchmal -1 angezeigt als Punktzahl, was nun wirklich nicht sein kann. Beim nächsten Anzeigen stimmte die Zahl dann wieder. Da wird doch nicht doch noch ein böser Fehler in der MulDiv Karte lauern? Zudem gab es immernoch sporadische Bstürze nach langer Laufzeit.
Angehängte Dateien:
-
debugger.jpg
210 KB -
debugger_fpga.jpg
110 KB -
debugemu_disasm.png
22 KB -
debugsim.png
68 KB -
deb16funz1.png
47 KB
Da die MulDiv Karte verdächtigt wird, soll dieser nun auf die Finger geschaut werden! Aber mit dem jetzigen USB Debugger per FT2232H ist dies VIEL zu langsam! Siehe diesen Post: Beitrag "Re: Space Age 2 der 32Bit MIPS Rechner in TTL" Vor allem das Video, das ist Echtzeit. Aber! Dieser FT2232H sollte eh mal rausfliegen und gegen einen "lokalen" Debugger ersetzt werden. Dieser bespielt dann direkt den Debugbus des MIPS TTL. Da dies nur die Testversion werden soll wurde die daher auf einem übrigen Platz eines Nutzens gepackt (daher so klein und unförmig). Bild: debugger.jpg Dieser Debugger wurde dann auf der FPGA Impleentierung getestet ob Register RW, Speicher RW und sonstige Debugzugriffe wie anhalten, Single STep und weiterlaufen lassen funktionieren. Bild: debugger_fpga.jpg Dies allein reicht nicht um rauszufinden ob die MulDiv Kartenergebnisse stimmen. Ein MIPS Emulator muss parallel mitrechnen und gucken ob die Ergebnisse stimmen. Also noch mal eben den Eigenbau MIPS Simulator auf den STM32 gezogen. Der Debugger hält also die echte CPU nach jedem Befehlszyklus an und guckt ob der Register- oder Speicherzugriff korrekt war. Bild: debugsim.png Es lässt sich anhand des Disassemblys sehr gut nachvollziehen woe die CPU sich grade im Code befindet. Bild: debugemu_disasm.png Auch dieses Vorgehen verlangsamt den CPU kern, aber nicht mehr so stark wie die reine USB Lösung. Aber es wird durchaus noch so langsam, dass die Zeichen in Zeitlupe auf dem VT101 erscheinen. (Wieso hab ich das eigentlich nicht gefilmt?) Bevor der Debugger mit der Simulation begnnt muss erst der Programmspeicher überprüft werden und der RAM Inhalt ausgelesen werden um den IST Zustand zu erkennen. Bild: deb16funz1.png
Dieser, nennen wir ihn "Debugemulator", hat dann auch direkt was gefunden. Im IRQ Handler war die Wiederherstellung der HI und LO Register vertauscht. In diesen Registern befindet sich das Ergebnis der letzten Punktrechnung der MulDiv Karte. Wenn nun also im Zeitfenster zwischen der Punktrechnung und der Auslesung des Ergebnisses ein IRQ kommt, dann rappelt das. BINGO! Dies fiel schon bei einem ersten Test des Debugemulators am FPGA auf. Warum fiel das nicht schon so auf im FPGA? Die VHDL Implementierung des 16C550 UART IC von opencores läuft leider nicht asynchrn zum Systemtakt. Also wurde dieses Zeitfenster wohl nie getroffen. In der echten hardware hat der 16C550 ein eigenes Baudratenquarz. Jedenfalls habe ich Henry dann das neue programm gesendet für einenr Dauertest. Es stürzt immernoch ab, wiebitte? Also musste ich mit dem Debugemulator zu Henry fahren und am echten Objekt Debugemulieren. Nach einer gewissen Laufzeit meckerte der Debugemulator, dass schonwieder die HI/LO Register nicht stimmten. Diesmal aber gabs kein problem beim Wiederherstellen, beim nächsten IRQ wurde beim Schreiben auf den Stack der Inhalt moniert. Also stimmten die Werte im Register nach einem Schreibvorgang nicht, Da stellte sich nach der Sichtung des Mikrocodes und der Timinganalyse heraus, dass das Timing zu knapp war. Es wurde daher nicht immer richtig geschrieben. Die Lösung ist es im Mikrocode 1 Takt mehr zeit zu lassen und seitdem läuft das. Wieso ist das im FPGA nicht aufgefallen? Der ist einfach viel schneller als die TTL Gatter.
Angehängte Dateien:
-
sp2_la2.jpg
120 KB -
sp2_la1.jpg
91 KB -
sp2_la_platz.jpg
85 KB -
sp2_ks.jpg
210 KB
Leider hat auch das nicht alles behoben, aber das Fehlerbild hat sich radikal geändert. Es gibt keine falschen Zahlen mehr auf dem VT101 Bildschirm und er kotzt auch nicht mehr seinen Speicher aus. Sondern der MIPS TTL bleibt manchmal einfach stehen oder gibt mal zu viel Zeichen aus und fängt sich dann wieder. Also mal weiter mit dem Debugemulator laufen lassen. Ab und zu kommt dann mal ein Fehler wie dieser hier:
1 | ------------------------------------------------------------ |
2 | EMUFAIL writeregister! (16) |
3 | EMU TTL |
4 | $16 (s0): 0x004fee4d <-> 0x004f124d DIFFERS! |
5 | |
6 | > ram -r 64 -a 0x4FED48 --width 4 |
7 | Offset(h) 00 01 02 03 Decoded Text |
8 | 004fed60 00 4f ee 4d .O.M |
Ab und zu schlägt der lw (Load Word) Befehl fehl. Dabei ist es egal in welches Register geschrieben wird, aber immer Byte 1 ist korrumpiert. Das ist Byteoffset 02, weil Big Endian. Wie zu sehen ist, ist das byte im RAM noch richtig. Jetzt müsst man "nurnoch" rausfinden wieso. Aber fassen wir mal zusammen, denn bisher gab es 5 Fehler zusammen von denen 4 gelöst sind: 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. 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 wenn XOFF kommt, daher gegen eine alte bekannte und fehlerfreie ersetzt F5: (ungelöst!) 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!) Daher wurde sich am Wochenende vor Weihnachten um die TTL Familie gekümmert bevor es die volle Dröhnung Reallife Familie gibt. Dazu wurden auch die schweren Geschütze aufgefahren, ein 32 Kanal 250MS/s Logic Analyzer! (Den ich mir ausleihen drfte) Damit wurde dann direkt mal die Registerkarte angezapft. Bild: sp2_la2.jpg Über die Signale schreib ich mal nix, das wird sonst unverständlich. Dann das Gerfallen in die CPU gehangen. Bild: sp2_la1.jpg Im Bild sp2_la_platz.jpg ist zu sehen wie die Debugsessions langsam ausarten. 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! 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. 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 (oder doch?). Bild: sp2_ks.jpg Der MIPS TTL Rechner lief dann auch eine Nacht lang 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.
Angehängte Dateien:
-
sp2_anoszi.jpg
22 KB -
sp2_wackel.jpg
6,4 KB -
sp2_pullups.jpg
42 KB -
sp2_lockericplan.png
37 KB -
sp2_fneualt.jpg
21 KB
Weil die großen Geschütze nichts halfen, weil der Fehler verschwand haben wir uns dann mal alle Signalformen angesehen. Offensichtlich ist die richtige Karte im Visier. 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: sp2_anoszi.jpg Der kleine Glitch in der Bildmitte ist übrigens völlig in Ordnung, Da sieht man den EPROM des Steuerwerk Mikrocodes beim Adresse dekodieren, dann glitcht eben auch mal der Ausgang. 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: sp2_wackel.jpg Daher noch ein paar Pullups an die passende Stelle im Datenmultiplexer angelötet. Bild: sp2_pullups.jpg 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: sp2_lockericplan.png 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" Der sitzt bombenfest! Mal die IC Beine angesehen, die neuen von TI sind nicht mehr verzinnt! Bild: sp2_fneualt.jpg 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. "Lange genug" sollte wohl erfüllt sein wenn der Rechner über Weihnachten läuft. Genau das haben wir auch getan und heute Morgen angekommen lief er immernoch! Fehler gelöst würd ich da ma sagen!
Große Klasse was ihr da macht! Hut ab!
Diese Fehlerkombintion war jetzt auch wirklich sehr ... äh ... nervig. Vor allem hatte der letzte Fehler mit der MulDiv Karte garnichts mehr zu tun. Da hat sich der IC wohl mit der Zeit genug gelockert, sodass das Schreibsignal des Registerbytes ab und zu mal nicht stimmte. Die ersten 4 Fehler wurden recht zeitnah gefunden, also in wenigen Monaten. Schließlich hocken wir nicht 24/7 am MIPS TTL rum, sondern Treffen uns imemr mal am Wochenende wenn Zeit ist. Wenn ich der MulDiv Karte kein programmierbares Steuerwerk in Form einer Mikrocodeengine verpasst hätte, sondern eine feste Statemachine, dann hätten wir die Karte wohl neubauen können bei den 2 Fehlern. Der letzte Fehler kostete dann so richtig Zeit beim Eingrenzen. Daher haben wir auch nicht auf der VCFB 2019 ausgestellt und die Netzwerkkarte ist noch nicht fertig. Die einzelnen Teile der Netzwerkkarte funktionieren bereits in der VHDL Simulation und der CRC generator wird grade ausgebaut zu einem General Purpose CRC. Denn der HW CRC beschleunigt die CRC Berechnung mal eben um den Faktor 17. Dafür sind nur ein paar ICs mehr nötig und das passt schon wenn danach nicht nur die Netzwerk CRC32 berechnet werden kann. Die Polynome stecken eh in einer LUT und da sind noch Adresspins frei für mehr LUTs. Für CRC16/8 muss nur die Schiebeweite des Eingangsbytes verändert werden. Das ReflectIn muss auch abschaltbar sein. Danach alle CRCs von dieser Webseuite hier durchtesten: https://crccalc.com/ Kennt noch wer Polynome die dort nicht aufgeführt sind, aber Verwendung finden?
Sind das diese https://shop.psf-technik.de/bauelemente/bauteile-mechanische/steckverbinder/fine-pitch-1-27mm/1946/psv30-paar-platinen-steckverbinder-ml/wl-30pol.-gerade-rm1-27mm-elco-5061?c=100 Platinenverbinder, die ihr da benutzt? Oder überall die 3-reihigen Pfostenstecker?
:
Bearbeitet durch User
Wir haben die alten DIN Stecker und Buchsen genomen: https://www.mouser.de/ProductDetail/649-860939673765E1LF Die sitzen bombenfest!
Angehängte Dateien:
-
sam_3959kk.jpg
130 KB -
lancard_firstping.PNG
2,3 KB
Es gibt einen Fortschritt bei der Netzwerkkarte. Diese ist nun in VHDL komplett simuliert und im FPGA implementiert. Am FPGA hängt eine PHY Breakoutplatine aus einem alten Projekt. Jedenfalls funktioniert es. Mein Rechner kann nun den MIPS TTL Rechner im FPGA über die Netzwerkkarte anpingen und bekommt auch einen Pong zurück. Dazu habe ich dann mal noch die Vordoku und den Schaltplan angehangen.
Angehängte Dateien:
-
lancard_simu_ping.PNG
120 KB -
lwip_httpserver_emu.PNG
37 KB
Die Tage hab ich dann die Netzwerkkarte noch dem MIPS Emulator hinzugefügt. Inklusive automatischer Erstellung des TAP Interface am Kernel und der Netzwerkbrücke. Nur muss der Emulator jetzt immer als root laufen deswegen :/ Als das lief dann mal den LWIP eingebaut und nach dem Vergessen der Codezeile des LinkUp läuft jetzt auch das Webserverbeispiel. Im Emulator läuft das dufte, auf dem FPGA stürtzt es ab wenn ich zu schnell auf F5 (reload) hämmer. Aber da hab ich schon eine Idee.
Angehängte Dateien:
-
card.jpg
240 KB -
test_mail_inbox.jpg
57 KB -
test_mail_view.jpg
43 KB -
test_rxing.jpg
54 KB -
test_loop_success.jpg
44 KB -
test_loop_fail.jpg
54 KB -
test_crc.jpg
36 KB -
RigolDS10.png
69 KB -
RigolDS12.png
61 KB
Es geht weiter! Heute war der Testtermin der TTL Lankarte. Die Hardware lag ja schon 2 Jahre lang rum und wollte jetzt mal getestet werden. Dementsprechend musste ich letzte Woche nurnoch die Verschiedenen Teststages der Software aus dem GIT kratzen und nochmal auf dem FPGA Board zwischentesten: CRC -> der CRC Generator muss zeigen, dass beim Teststring "123456789" auch die passende Summe rauskommt loop -> der PHY wird gegen ein oszillator und 5 Drähte ersetzt -> was gesendet wird, das wird auch empfangen passive RX -> einfach passiv alle Broadcasts im Netzwerk einfangen und anzeigen ping/webserver -> der lwip läuft und lässt sich pingen, der lwip Webserver zeigt die Defaultseite an mail -> email lesen über POP3 geht Der CRC Test war schnell erfolgreich durch [test_crc.jpg] Der loopbacktest lief nicht durch, beim Empfang overflow und Datenpakete stimmen nicht. [test_loop_fail.jpg] Also mal mit dem Oszi+LA drinne rumstochern wie die FIFO ausgelesen wird. HUCH?! Wie sieht denn bitte das gelbe Signal aus? Das kommt nicht nach GND. Zudem müsste das ein schöner 50:50 DC sein mit halbem TX Takt von D5. Das ist einfach nur ein 74F74 (D-FF) mit nQ->D loopback, das DARF so nicht aussehen. [RigolDS10.png] IC getauscht und es sieht aus wie es soll! [RigolDS12.png] Schon läuft der Test durch. [test_loop_success.jpg] Nächster Test, einfach nur Pakete empfangen und gucken ob die CRC stimmt, manche werden auch angezeigt (ARP). [test_rxing.jpg] Nächster Test, Pingen. Da gibts jetzt kein "Screenshot". Die Ping Zeit ist 3ms, garnicht mal so schlecht! Der Webserver läuft auch, aber das wurd aufm Firefox im Laptop angezeigt, das wär auchn langweiliger Screenshot. Bzw das Bild gibts schon in einem vorherigen Post. Aber da läuftn Webserver auf einem Rechner aus TTL Bausteinen mit der Lankarte aus aus TTL Bausteinen. Letzter Test: Auf dem Laptop lief nen Mailserver (weil unverschlüsselter POP3 Zugang) und der MIPS TTL hat sich da nen paar Mails abgeholt. [test_mail_inbox.jpg] Hier wird ne Mail angezeigt. [test_mail_view.jpg] Jetzt müssen noch Mails gesendet werden können. Dabei gibts aber ein Problem beim Text editieren. Es heißt zwar immer "VT100 Emulation", aber diese können mehr als ein echtes VT101. Leider ist da ein wichtiges Feature bei, nämlich das scrollen (bzw nach links rücken) der Zeichen innerhalb der Zeile wenn man ein Zeichen entfernt. Eine chtes VT101 packt dort dann nur ein Leerzeichen hin und die Zeichen dahinter bleiben unverändert stehen. Die muss ich dann mit 9600Baud neuschreiben, was natürlich dauert. Eigentlich müssten ja auch alle Zeilen darunter dann 1 nach links wandern (so wie in Word zB). Das werd ich aber erst dann nachrücken lassen wenn eine Zeile leer ist und ich das Zeilenscrollen nutzen kann. Nach jedem Zeichenlöschen den Bildschirm aufbaun dauert ja ewig. Ab dem VT220 ist das Feature übrigens eingebaut.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.