Eine neue Programmiersprache: Verilog

Nun habe ich also ein CPLD-Experimentiersystem, aber absolut noch keine Idee, wie ich damit etwas anfangen soll. Nach kurzem Googlen weiß ich nun, dass es drei Wege gibt, dem CPLD beizubringen, wie er sich zu verhalten hat: Zum einen kann man einen Schaltplan aus TTL-Bausteinen zeichnen und das ganze beliebig kompliziert verschalten. Zum anderen kann man in entweder Verilog oder VHDL die Struktur und die Arbeitsweise des Chips beschreiben.
In allen Publikationen habe ich gelesen, dass die programmierte Variante wohl auch die übersichtlichste sei, da man hier auch einfacher Module und Baugruppen definieren könne. Zwischen VHDL und Verilog gibt es funktional keinen großen Unterschied. VHDL ist wohl eher die europäische Sprache der Wahl, während man über'm Teich eher Verilog den Vorzug gibt. Ich hatte mich vor Jahren schon mal mit VHDL bemüht, aber das war irgendwie nicht meine Welt. Nun habe ich mich ein wenig mit Verilog beschäftigt und muss sagen, dass mir das alles irgendwie logischer und einfacher erscheint.
Zum Probieren und Zusammenstöpseln von kleinen Beispielen muss man nun auch keine Gigabytes auf die Platte schaufeln, denn es gibt einen kleinen Mini-Simulator mit Namen "Icarus Verilog" oder auch "IVerilog". Er erzeugt ein Präcompilat, welches wiederum einen Interpreter bedarf. Dieser kann die Test-Ausgaben dann entweder per Print-Ausgabe tabellarisch darstellen oder aber, was mir sehr gut gefällt, die Daten auf die Platte schreiben, um sie mit GtkWave darzustellen.
Hier habe ich mal ein Beispiel eines Vergleichers, also ein Gatter mit zwei Eingängen und einem Ausgang. Der Ausgang soll genau dann 1 sein, wenn beide Eingänge 1 oder beide 0 sind. Das ganze sieht dann in Verilog so aus:

module comparator(

    input x,

    input y,

    output z

    );

assign z = (~x & ~y) |(x & y);

endmodule

Alles in Verilog spielt sich in Modulen ab. Sie haben Parameter, die über eine externe Datei später den physikalischen Pins des CPLD (oder auch des FPGA) zugeordnet werden. Dann haben sie natürlich eine Anweisung, was denn alles so passieren soll, wenn sich die Signale ändern, hier die Assign-Anweisung. Das war's auch schon. Mit einem weiteren Test-Modul, dass periodisch die Eingänge ändert, sieht das dann in GtkWave so aus:

Es gibt übrigens eine interessante Internetseite mit dem Namen opencores.org. Dort findet man hunderte fix und fertige Verilog- oder VHDL-Module. Da gibt es (hauptsächlich für FPGAs, weil die viel mächtiger als CPLDs sind) Gigabit-Ethernetcontroller, CRC32 Rechner, Video-Chips, 200 MHz RISC CPUs, Nachbauten von 6502, Z80, 68000, usw., ja, sogar ganze Rechner wie z. B. ein C64 zum Herunterladen in einen FPGA findet man dort.
Interessant. Ich frage mich gerade, warum ich einen Z8 mit einem CPLD erweitere, anstatt einen FPGA zu nehmen und dort ein CP/M-Plus System mit 200 MHz aufzubauen... :-)
Nun, immer erst einmal einen Schritt nach dem anderen. Jetzt lerne ich erst mal Verilog und versuche darin meinen SD-Karten Treiber zu entwickeln.

CPLD? Wassen das nu wieder fürn Schweinkrams?

Nachdem ich neulich meine Ideen zu einem CPLD geäußert habe, der die Kommunikation zwischen Z8 und SD-Karten übernehmen sollte, habe ich mich derweil etwas schlauer gemacht, und zwar hinsichtlich SD-Karten-Ansteuerung und der CPLDs.

Erkenntnis 1: SD-Karten sind bei weitem nicht so einfach handzuhaben, wie man das gerne glauben möchte. Das beginnt beim Einstecken einer SD-Karte in ein laufendes System, bei dem Ströme fließen können, welche einen Spannungsdrop verursachen, die den ganzen Rechner zum Absturz bringen können. Des weiteren muss man sich bei mehreren parallelen SD-Karten darauf verlassen können, dass inaktive Karten "die Klappe halten". Auch das ist nicht so einfach: Nimmt man das CardSelect Signal einer Karte weg, bedeutet das noch lange nicht, dass die Karte dann auch Ruhe gibt. Nein, sie möchte noch ein paar Clock-Impulse hinterher haben, um sich langsam hochohmig schalten zu können. Aber da gibt es glücklicherweise im Netz genug Seiten, die sich damit detailliert befassen.

Erkenntnis 2: Ich habe keine (oder zumindest, nicht ausreichend) Ahnung von CPLDs. Abhilfe kam heute in Form eines kleines Päckchens von Pollin: Ein CPLD Experimentiersystem mit eingebauten Programmer für den Druckerport, einem Xilinx XC95144 (der eigentliche CPLD), 128 kB RAM, 4 Tastern und 8 LEDs.

Das ganze Set hat als Bausatz € 24,95 gekostet, liegt also durchaus noch im Bastler-Budget. Die SMD-Bauteile (wie u.a. der 100-Pin CPLD) sind bereits vorbestückt, wie angenehm. Muss man also nur noch das übliche Kleinzeug, wie Buchsen, große ICs, LEDs, Taster, etc. montieren. Zum Wochenende soll das Wetter eh bescheiden sein, na also.

Alles, was man nun noch braucht ist ein Druckerport-Kabel, einen Druckerport (Ähmm..) und eine spezielle Software. Mit dem Druckerport beginnt bereits das Verzweifeln: Keiner meiner Rechner hat noch einen Druckerport. Alles, was ich habe, ist ein USB->Centronics Kabel. Ich hoffe, dass es damit auch funktioniert.
Ein weiterer Schockmoment war, als ich auf die Seite von Xilinx ging und mir die ISE Software für Linux in der neuesten Version 14.7 herunterladen wollte: SECHS-KOMMA-NULL-NEUN-GIGABYTE?? Ja, seid ihr denn völlig bescheuert???
Nachdem ich ein wenig recherchierte stellte ich fest, dass die XC-Reihe schon relativ alt ist. Auch die Verwendung des Druckerports zur Kommunikation ist nichts neues. Also muss es ja auch nicht notwendiger Weise die neueste Version sein. Im Archiv gibt es da auch erheblich ältere Versionen, z.B. die 7.1 SP 4 für 64 Bit Linux in der Größe von 336 MB. Na, also. Geht doch.
Während der Download also läuft, verschwinde ich mal im Keller und schraube das Board zusammen.

Detailkram

Heute habe ich mich die ganze Zeit damit beschäftigt, KiCAD (das kostenfreie Platinenlayout-System, mit dem ich dieses System entwickele) die ganzen neuen Schaltplansymbole und Footprints beizubringen. Insbesondere die 36poligen SMD Speicher-ICs waren recht aufwändig.
Nun konnte ich aber schon einmal alles auf eine Europlatine (160x100mm) platzieren und schauen, wie weit ich mit dem Platz komme. Resultat: Es ist man gerade die Hälfte der Platine gefüllt. Da ist noch massig Platz für zwei SD-Karten, einige Bus-Treiber und eine 64polige VG-Leiste für einen rückwärtigen Bus. Nach vorne hin (also zur Frontseite des halben 19" Gehäuses) befinden sich die beiden SD-Kartenschächte, einige LEDs zur Statusanzeige, sowie die 9polige RS-232 Schnittstelle zum Hostrechner.
Bei meinen Recherchen bei Reichelt habe ich gerade gesehen, dass man dort auch fertige Bus-Platinen für 64er und 96er Busse hat. Wieder ein Teil, was man nicht selbst machen muss.
Was die Ansteuerung der SD-Karten betrifft, so habe ich mich dazu entschlossen bei diesem ersten Prototypen eine direkte Ansteuerung über den Z8 zu machen. Langsam, aber so brauche ich mir um CPLDs und Co. keine Gedanken zu machen. Schwierig ohnehin ist die Pegelwandlung: Die SD-Karten laufen allesamt mit 3,3 Volt. Und folglich sind auch die Signale auf dem seriellen Bus zur Karte entweder 0 oder 3,3 Volt. Direkte Ansteuerung mit den Signalen der CPU scheidet folglich aus, da man damit die Karte grillen würde. Man braucht also zumindest in Hinrichtung eine Pegelumsetzung.  In Rückrichtung ist diese nicht erforderlich, da die CPU auch mit den Signalpegeln der Karte klar kommen sollte.
Für die Pegelwandlung setzt man klassischerweise ein 74HC244 oder 74LSV244 ein. Diese Chips kommen mit 3,3 Volt Versorgungsspannung klar und nehmen auch höhere (TTL-) Spannungen an den Eingängen nicht krumm. Leider brauchen diese ICs dann auch eine Versorgungsspannung von 3,3 Volt. Und hier spuckt mir das KiCAD wieder in die Suppe, da es keine eigenen Versorgungsleitungen an diese TTL-ICs schreibt. Es verdrahtet diese Versorgungsleitungen intern selbst. Also muss ich mir so ein IC erst einmal wieder selbst in die Bibliothek eintasten, welches ich dann mit einer eigenen Spannungsversorgung beschicken kann. Umstände...
Eine weitere Idee, die mir noch gekommen ist, betrifft eine batteriegepufferte Echtzeituhr. Wobei ich hier mit Schrecken noch meine alte WERSI-Orgel in Erinnerung habe. Dort sind auf einigen Platinen auch Stütz-Akkus eingesetzt gewesen, die sich mit der Zeit geöffnet und ihren Inhalt auf den Platinen verteilt haben. Das wiederum hat gute Teile der Platinen zerfressen. Bis ich das wieder alles gereinigt und die Verbindungen neu gefädelt hatte,... Die neuen Akkus in der Orgel sind nun hinten in kleinen Plexiglas-Schälchen und mit langen Kabeln verbunden. Da muss ich mal schauen, was es da so geben tut.

Massenspeicher

Was mir an den ganzen bereits veröffentlichten Schaltungen nicht gefällt, ist der Einsatz von Floppy-Controllern. Ich meine, gut und schön, wenn der Selbstbaurechner ein Diskettenlaufwerk hat, nur, was soll ich damit dann anfangen? Ich habe keinerlei Rechner mehr, der über ein Diskettenlaufwerk verfügt. Womit sollte ich dann Daten austauschen?

Der einzig sinnvolle Massenspeicher ist daher, zumindest momentan, die SD-Karte. Ein USB-Stick wäre mir fast noch lieber, allerdings dürfte es sehr problematisch sein, dass korrekte Protokoll auszutüfteln. Davon ab sind SD-Karten heute billig zu bekommen und fast jeder Laptop hat auch einen SD-Karten Einschub.

Als internen Festplatten-Ersatz habe ich sowohl echte Festplatten gesehen, wie auch schon CF-Karten. Ich denke, dass auch hier eine einfache SD-Karte das Mittel der Wahl ist.

Zwei SD-Karten als externer und interner Massenspeicher sind somit für mich gesetzt. Nun dreht es sich "nur" noch um die Ansteuerung der Karten. Natürlich könnte ich einfach einen Portbaustein (z. B. Z80-PIO oder 8255) nehmen und den Z8 dies von allein bewerkstelligen lassen. Allerdings habe ich den Eindruck, als wenn dies nicht sonderlich schnell sein wird. Andererseits stellt sich die Frage, welche Geschwindigkeit denn wirklich notwendig ist, für ein System, dessen Hauptspeicher maximal 1MB groß ist.

Dennoch denke ich darüber nach, einen CPLD wie den XC9572 von Xilinx oder andere einzusetzen. Bein Schreiben auf die SD-Karte werden byteweise durch die Z8-interne DMA die Daten in ein 8-Bit Schieberegister im CPLD geschrieben, sowie darin ein Zähler auf 0 gesetzt. Sodann beginnt der CPLD seriell die Daten in die SD-Karte zu schreiben. Nach jedem Bit wird der Inhalt des Schieberegisters um eine Stelle weiter geschoben und der Zähler inkrementiert. Erreicht der Zähler den Wert 8, wird zum einen das Zählen blockiert. Zum anderen wird ein Signal an die DMA gegeben das nächste Byte zu senden.

Beim Lesen werden die Informationen bitweise von der SD-Karte in das Schieberegister eingeschoben und der Zähler bis 8 inkrementiert. Ist dieser Wert erreicht, also ein ganzes Byte empfangen, wird ein Signal an die DMA gegeben, dass ein Wert zur Abholung bereit steht. Nach der Abholung wird der Zähler zurück gesetzt und das nächste Byte eingelesen. Diese Überlegung führt automatisch zu der Erkenntnis, dass hierfür zuvor die Anzahl der einzulesenden Bytes vom Z8 in den CPLD geschrieben werden muss. Zum Schreiben ist diese Information nicht erforderlich.

Erster Entwurf

So sieht derzeit mein erster Entwurf eines Z8S180 Systems mit ATmega32-Bootloader aus:

Alles eine Frage des Timings

Nachdem ich bald einen Schreck bekommen hatte, dass dieser Z80, im Gegensatz zum Original-Z80, den externen Takt nicht etwa durch vier teilt, sondern tatsächlich mit der vollen Taktfrequenz laufen kann, schaute ich nochmals in die Timing-Diagramme im Z8S180-Handbuch. Natürlich will ich, wenn ich denn schon einen 33 MHz Prozessor habe, diesen auch mit der vollen Geschwindigkeit und ohne Wait-States betreiben.
Nach den Timing-Diagrammen ergab sich hieraus eine maximale Antwortzeit des externen Speichers von 1,5 Taktzyklen. Bei 33 MHz ist ein Zyklus 30ns lang. Die maximale Antwortzeit liegt demnach bei 45ns. Nicht viel Zeit.
Nachdem ich in einigen Foren herum fragte, welche Möglichkeiten es zu schnellen Signal-Auswertung es denn gäbe, kam ich auf die folgende Idee: Es gibt keine komplizierte Auswertung, und auch nur zwei schnelle Speicherbausteine á 512 kB RAM. Das wurde dadurch möglich, dass ich komplett auf das EPROM verzichtete.
Meine ersten Ideen gingen davon aus, dass ich ein EPROM, sagen wir mal 32 kB, im untersten Adressbereich liegen habe. Ein Flip-Flop, das bei einem Reset zurück gesetzt wird, entscheidet darüber, ob Lesezugriffe auf die unteren 32 kB auf das EPROM oder das RAM geleitet werden. Nach dem Reset kopiert die CPU das EPROM in das RAM und setzt das Flip-Flop um. Nachfolgende Operationen finden dann komplett im RAM statt.
Das alles hätte aber eine Logik erforderlich gemacht, die viel zu langsam für die geforderten 45ns wäre. Statt dessen sitzt an der Stelle des EPROMs ein ATmega32. Dieser übernimmt nach einem Reset die Kontrolle über den Bus und hält den hält den Z8S180 im Dauer-Reset. Sodann kopiert der ATmega seine Nutzfracht aus seinem Flash in das RAM. Danach macht er seine Leitungen hochohmig (zieht sie quasi aus dem Sockel) und gibt dem Z8S180 den Reset frei. Dieser findet dann direkt im Speicher sein Betriebsystem vor.
Ein weiterer Vorteil dieser Methode ist, dass ich den Inhalt des "EPROM"s quasi beliebig oft in-system umprogrammieren kann. Ich brauche keinen UV-Löscher, keinen EPROMmer, sodern nur einen ATmel-ISP Adapter. Vorhanden!

Es wird Zeit für ein neues Projekt

Nachdem ich eine ganze Menge Spielereien mit ATmel und anderen Mikrocontrollern realisiert habe, fand ich, dass es an der Zeit ist, mal wieder einen richtiges System bestehend aus einer CPU, etwas Speicher, Steuerlogik und Sonstigem zu basteln.

Ich dachte schon immer mal wieder an ein mittleres ECB-System im halben 19" Format. Da gibt's eigentlich schon eine ganze Menge an freien Projekten, allerdings entsprach keines genau dem, was mir vorschwebte. Entweder war es ein schnuckeliges Z80-System, dann aber mit Floppy-Controller und so. Quizfrage: Was soll ich dann mit einer Floppy machen? Klingt ähnlich wie Programmarchiv auf Musikkassette. Wer hat das denn noch? Dann wiederum wurden Bauteile verwendet, wo man allen Ernstes auf eBay nach Restposten Ausschau halten sollte. Na toll.

Was mir bei der Suche nach dem geeigneten Prozessor auffiel, war vor allem eine Lücke zwischen 20 MHz und den Giga-Hertzen. Dazwischen gibt es auf dem freien Markt scheinbar gar nichts mehr, wenn man denn nicht alles selbst in einem FPGA realisieren möchte.

Und dann fand ich eines Tages ein Datenblatt eines Z8S180 im Internet. Das ist quasi ein Z80, der später von Hitachi als HD 64180 auf 1 MB RAM, mit seriellen Schnittstellen und DMA erweitert wurde, um dann zurück lizensiert von Zilog als Z8S180 auf den Markt zu kommen. Also ein Z80 mit 33 MHz und 1MB RAM, damit kann man doch schon mal was anfangen.

Auf eBay wurde ich dann tatsächlich fündig und bestellte dort aus den USA zwei dieser Prozessoren für wenige Euronen. Vier Wochen später trafen sie bei mir ein.