Z80 20 MHz DRAM Ansteuerung

  • Angefangen mit dem DRAM-Tester wollte ich jetzt auch DRAM-Module mit maximaler Geschwindigkeit ansteuern und eine Art Super CP/M Kiste basteln. Da kam mir mein Z80 aus der Bastelkiste mit 20 MHz sehr gelegen. Das kleine Teil kommt schon ziemlich nah an die Grenzen des SIMM DRAM Timings.

    Als Backup habe ich noch einen Z180 mit 33MHz im Auge. Wenn das auch funktionieren würde wäre das die Kür. Die andere Frage wäre was man wohl mit 16 MB RAM anfängt. Ein RAM-Test da ist schon ein legaler Anwendungsfall.


    Die minimale Zugriffszeit ist beim M1-Zyklus mit 1.5 Takten 75ns. Wenn das nicht passt kann man immer noch den M1 Zyklus um 1 Waitstate verlängern.

    Die minimale Zykluszeit Read/Write sind 3 Takte also 150 ns. Zugriffszeit sind hier 2.5 Takte also 125 ns.


    Das entspricht ziemlich genau dem Timing eines 70ns Moduls.



    Die Flash Ansteuerung ging problemlos. Ich hatte zuerst nach einem schnellen Flash gesucht und SST27SF020-70, aber nach etwas probieren gesehen, dass das Timing recht unkritisch ist.

    Von /OE nach Valid-Data vergehen 16 ns (<35 nach Datenblatt). Selbst langsamere Flash-Typen können verwendet werden.


    Jetzt startet der Rechner schon mal und ich bin begeistert von der Geschwindigkeit. Mit der DRAM Ansteuerung habe ich allerdings (bis auf meinen Atmel Tester) keine Erfahrung.

    Nach Datenblatt bleiben zwischen 20...50 ns von RAS-Adresse bis CAS-Adresse.


    Als /RAS Signal kann ich beim Z80 wohl /MREQ direkt verwenden, sowohl beim Normalen Lesen, als auch beim REFRESH. Eine Herausforderung schein "nur" das CAS-Timing zu werden. Da hänge ich gerade. Mein Versuch 1. wird wohl sein mit einen Multiplexer 10ns nach /RAS umzuschalten.

  • Dabei habe ich noch eine Frage. Um das Timing besser zu kontrollieren, möchte ich eine Verzögerungleitung ggf mit HC04 bauen für >10ns und >20ns.

    Einfachste Variante wäre 4 Inverter hintereinander zu schalten. damit käme man auf 16..32ns je nach Typ (also bei 4 Invertern). Variante 2 wäre einen 74LS04 zu probieren zu verwenden. Letztendlich muss ich wohl hier ein wenig experiementieren, bis alles passt.

  • Die Verzögerung per Gatter ist nicht wirlich reproduzierbar und auch temperaturabhängig. Besser wäre es, eine richtige Verzögerungsleitung zu nehmen (so haben wir das früher[tm] gemacht). 74LS31 oder LC basierte Leitungen mit Anzapfungen.

    Da Du aber 80 MHz hast, wäre ein schnelles Schieberegister, welches das /MREQ durchschiebt eine sehr gute Lösung.

    • Official Post

    Als Backup habe ich noch einen Z180 mit 33MHz im Auge.


    Wenn du auch mit 1MB SRAM zufrieden bist, hab ich da eine Loesung.



    • Official Post

    nicht wirlich reproduzierbar und auch temperaturabhängig. Besser wäre es, eine richtige Verzögerungsleitung zu nehmen (so haben wir das früher[tm] gemacht). 74LS31

    Ganz ehrlich, das ist doch auch nicht reproduzierbar.



    Ich nehm mal tPLH: Soll=32ns, min=22ns, max=65ns

    Das sind -31% bis +100%

    Deshalb mag ich diese Delay Lines gar nicht.



    Dein Vorschlag mit dem 80MHz Schieberegister ist da Gold wert.

    Und reproduzierbar!

  • http://dl5uy.de/scratch/PROTEUS-Z80/128kByte%20DRAM.JPG

    Findest Du hier die "reproduzierbare" Delay Line?

    OMG - was ich damals[tm] gemacht habe.. Hat aber funktioniert :)

    • Official Post

    Ich habe nicht gesagt, das funktioniert nicht.

    Ich weiss, damals hat man oefters mit DelayLines gearbeitet. Aber ich finde, schoen ist anders.


    Aber die o.g. Toleranzen sind m.E. weit weg von reproduzierbar.

    Ok, es haengt natuerlich auch von den Frequenzen ab.


    Mit welcher Frequenz wurde deine Speicherkarte angesteuert?

    Und wenn Hobi mit 20MHz arbeiten will, kommen die o.a. Delays in den Bereich einer Periode.


    Ich sag mal so: Wenn sich jemand heute die Muehe macht ein DRAM einzusetzen, dann bitte anstaendig. (Stichwort Schieberegister)


    BTW: Die DRAM Ansteuerung mit Schieberegister wurde auch schon beim TRS-80 benutzt.

    Wenigstens im Grundgeraet, im Expansion Interface war's schon wieder vorbei.

  • Weiss ich nicht... Ich habe von damals noch sehr viel Papier im Lager, aber in keinster Weise geordnet. Ich würde aber im Zweifelsfalle das schnell reverse Engineered bekommen.

    Das Delay für CAS kommt über die Ferritperle und den Kondensator...

    • Official Post

    nur aus Neugierde. Gibt es die Schaltung dazu?

    Ja klar. Ist ja keine Lochrasterplatine. ;)

    Das ist eine verbesserte Version der Z180 Karte.


    Nachtrag: Das habe ich wohl missverstanden. Sorry.

  • Der Z80 lief/läuft mit 4 MHz.

    Heute würde ich einfach und banal ein 512kByte SRAM nehmen. Bzw. habe ich, auf meiner Multicomp-Platine.

  • Weiter gehts.


    Die Idee mit dem Schieberegister ist physikalisch schon recht grenzwertig. Ich habe ein 74HC299 gefunden (lt. Datenblatt max. 50 MHz)

    Erstmal, es funktioniert und das wahrscheinlich auch reproduzierbar. Nur leider muss man das Register wirklich mit 80 MHz antreiben. Dank Propagation Delay kommt das erste Bit erst nach 26 ns wieder raus (15ns wären besser). Das zweite nach 39 ns usw. Timing wise passt das noch recht gut. Mir widerstrebt es aber, nur um das Schieberegister zu betreiben 80 MHz quer über die Platine zu ziehen. Das scheint was am Konzept falsch zu laufen. Die Schieberegistervariante funktioniert wohl mit 10 MHz,ganz bestimmt nicht mehr mit 33 MHz.


    Eventuell werde ich jetzt dich versuchen eine Delay Line auszuprobieren. Dort kann ich direkt 12 oder 15ns nehmen.

    • Official Post

    Ein Schieberegister mit 80MHz ist eine Hausnummer, gar keine Frage.

    Würde ich mit einem schnellen CPLD oder GAL machen.

    Mit HC Bausteinen geht das nicht.


    Wieso musst du 80 MHz quer ueber die Platine ziehen?

    Die 80 MHz brauchts du "nur" für das Schieberegister, alle anderen Signale werden runtergeteilt.


    Aber warum willst du DRAMs einsetzen?

  • Quote

    Ein Schieberegister mit 80MHz ist eine Hausnummer, gar keine Frage.

    Würde ich mit einem schnellen CPLD oder GAL machen.

    Mit HC Bausteinen geht das nicht.

    Geht. Zumindest heute beim Test.

    Quote

    Aber warum willst du DRAMs einsetzen?

    Der DRAM war der Anlass mich mit etwas schnelleren Prozessoren auseinanderzusetzen. Bisher habe ich mit maximal 4 MHz gearbeitet.

    Ich wollte einfach meinenDRAM-Tester RAM Module mit der maximalen Bandbreite beschreiben und mich so mit eben diesen Problem stellen.

  • Nun, wenn man die entsprechende schnelle Logik einsetzt ist das realisierbar.

    Vorschlag: 74F164


    Typisch 100MHz, minimal 80MHz. Der Baustein lässt sich auftreiben.

  • Dank der Antworten bin ich jetzt einen Schritt weiter. Die Lösung war eine Delay Line DS1100Z. Leider ist in meinen Beispiel die Verzögerung etwa höher als erwartet 14 (statt 12ns), aber die Chips kann man mit verschiedenen Einstellungen anfordern. Ein Hoch auf dem Maxim Sample Service. Interessanterweise passen sechs von den acht Beinchen in meine DIP Fassung rein, so dass ich die Platine nicht abändern abändern musste.


    Das Schieberegister hebe ich mir auf, sobald ich an die Bildschirmsteuerung komme.


    Nächster Schritt, EARLY WRITE, READ, REFRESH .

  • Mittlerweile ist es mehr als eine kleine Hardwarebastelei. Dadurch bin auch gezwungen worden, auf GAL's umzusteigen. Dadurch ist es möglich verschiedene Produktterme mit vertretbarem Aufwand durchzutesten und gleichzeitig bekommt man mit der Logik die Gatterlaufzeiten in den Griff.

    Letztendlich haette ich wohl sogar auf die Delay Line verzichten können, da das GAL ohne weiteres Zutun ebenfalls 15ns Verzögerung pro Ausgang verursacht. Die haette man auch als Delay Line verwenden können.


    Ich hab meinen aktuellen Stand hier mal mit angehängt. Ich muss noch etwas ROM/RAM Umschaltung dahingehend anpassen, dass ich 23 K ROM und 32K RAM gleichzeitig ansprechen kann. Dann geht es an den ersten Test.


    Ein bisschen UART habe ich zum debuggen auch implementiert. Ist schon genial bei 9600 Baud, hat man 2080 Taktzyklen Zeit pro Bit oder anders herum bei 46 Takten pro bit käme man auf 400 kBaud Übertragungsrate.

    • Official Post

    WAIT Erzeugung

    Ich hab's mir noch nicht genau angeschaut/aufgemalt.

    Mich stoert das nur das MREQ fuer WAIT verantwortlich ist.

    Das MREQ kommt auch beim Refresh Zyklus. Ich weiss nicht, ob das stoert.

  • Wider erwarten hat der Test auf anhieb geklappt. Einen kleinen Wermutstropfen gibt es noch. Bei 10 MHz gibt es keine Probleme.


    Bei 20 MHz, funktionieren leider nicht mehr alle SIMM Module. An der Zugriffszeit liegt es nicht, ob 60 oder 70ns war egal.


    Ich habe keine Idee mehr wo ich suchen könnte. Ein Teil, aber wohl nicht alles, ist spannungsabhängig, wenn ich die Spannung auf 4.8 V absenke funktioniert der Zugriff etwas stabiler. Kondensatoren zwischen 100uF und 2000uF nahe am Modul hatten keinen großen Effekt.

  • Ich würde VERMUTEN, dass einfach zuviel Ground Bounce stattfindet.

    Es geht nichts über eine solide Masselage in einer Multiplayer Leiterplatte...

    Ein Prototypen-Aufbau kommt dem nicht annähernd nahe :)

  • Der der Begriff ist für mich neu. Bis heute hätte ich das für VooDo gehalten. gibt es eine Möglichkeit wie ich das verbessern kann, für meinen Prototypenaufbau?


    Ein bisschen hatte ich schon das richtige Gefühl. Statt die Masseverbindungen als Baum zu organisieren, habe ich die Masse und 5 Volt Leitungen noch mal quer verbunden und somit Ringe gebaut. Danach hatte sich das etwas verbessert.

  • das ist immer schwierig bei solch einem Aufbau. Ich habe da früher doppelseitige Laborkarten (etwas teuer) genommen, bei denen eine Seite flächig Masse ist: z.B. BICC vero 40945

    Google findet nichts dazu, deshalb hier mal Photos:

    Das ist jetzt natürlich kein DRAM, aber es geht ja um die Leiterplatte. Nicht vergessen: ein 100n bei jedem Versorgungspin an die Massefläche.