Forum: Projekte & Code Space Age 2 der 32Bit MIPS Rechner in TTL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
25 lesenswert
nicht lesenswert
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/

von Mike B. (mike_b97) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Ale (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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 :).

von Jürgen S. (engineer) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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
von chris_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
chris_ schrieb:
> gibt es eigentlich einen PC-Simulator?

Warum willst du auf dem Teil einen PC simulieren?

von chris_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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".

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
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
von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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/

von Ale (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Nibbler ist super weil einfach ist. Es hat alles was man braucht: 
Registers, memory i/o, ports und Microcode !.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Der Gilb (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von chris_ (Gast)


Bewertung
1 lesenswert
nicht lesenswert

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
3 lesenswert
nicht lesenswert
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.

von chris_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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.

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert

von Matthias W. (matthias_w40)


Bewertung
2 lesenswert
nicht lesenswert
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 :)

von Wahrheit tut weh (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
@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.

von Matthias W. (matthias_w40)


Bewertung
0 lesenswert
nicht lesenswert
Naja uclinux läuft ja auch ohne MMU und FPU :)

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
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
von Bowd (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Bowd (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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?

von Marc H. (marchorby)


Bewertung
0 lesenswert
nicht lesenswert
Bowd schrieb:
> Man denke dein
> Argument konsequent zu Ende, wo wäre man denn da?

bei nem Smartphone...

von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
4 lesenswert
nicht lesenswert
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?

von Mike B. (mike_b97) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
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

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lukey S. (lukey3332)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Hans-Georg L. (h-g-l)


Bewertung
1 lesenswert
nicht lesenswert
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 ;-))

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
von OSILayer8 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
von Mike B. (mike_b97) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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!

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Uiui, erinnert mich an meine Anfangszeit in der Computertechnik -)

von Holm T. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Holm T. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
3 lesenswert
nicht lesenswert
[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
von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
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
von Holm T. (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
[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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
5 lesenswert
nicht lesenswert
[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
von Holm T. (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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

von Alex P. (ra_p)


Bewertung
2 lesenswert
nicht lesenswert
> 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.

von Holm T. (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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
von Holm T. (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
[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
von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von bko (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
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

von Holm T. (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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

von Alex (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hast du irgendwo stock davon gesehen ?

von Holm T. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Bitraspler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Holm T. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Holm T. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Alex (Gast)


Bewertung
2 lesenswert
nicht lesenswert
>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.

von Holm T. (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
holm und fritzler: bitte bei der Sache bleiben. Streiten könnt ihr per 
PN.

von Mike B. (mike_b97) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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)

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Mike B. (mike_b97) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
mal eine Zusatzfrage: wieso heisst das Teil eigentlich "Space Age"?
Hab ich das überlesen?

von Matthias W. (matthias_w40)


Bewertung
0 lesenswert
nicht lesenswert
Rate mal.
Schätze mal als Anlehnung an die Bordrechner der ersten unbemannten 
Weltraum Missionen.

: Bearbeitet durch User
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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
Youtube-Video "Henry Westphal: "Der SPACE AGE, ein Tischrechner in diskreter Transistortechnik""

edit:
Der SP1 ist im Heinz Nixdorf Museum in Paderborn ausgestellt (wenn ich 
mich richtig erinner)

: Bearbeitet durch User
von Martin Schuerer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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 ;)

von Mike B. (mike_b97) Benutzerseite


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Da hab ich doch glatt den Schaltplan vergessen.
Ist im Anhang.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Die Doku zur MulDiv Karte wär jetzt auch fertig.

von Mike B. (mike_b97) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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!

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
Solche Kleingeister gibts eben, da muss man drüber stehen
¯\_(ツ)_/¯

: Bearbeitet durch User
von Martin Schürer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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: 
Youtube-Video "Spaceage 2 MulDiv Debugger"

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".

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
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.

von Mike B. (mike_b97) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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:
------------------------------------------------------------
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

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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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!

von Mike B. (mike_b97) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Große Klasse was ihr da macht!
Hut ab!

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
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?

von Mike B. (mike_b97) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
Wir haben die alten DIN Stecker und Buchsen genomen:
https://www.mouser.de/ProductDetail/649-860939673765E1LF

Die sitzen bombenfest!

von Mike B. (mike_b97) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info!

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.