Warum sehe ich für einige logische Einsen eine seltsame "Kerbe" in der Datenleitung?

Ich versuche, einen Z80 Homebrew-Computer zu bauen, um Spaß am Retrocomputing zu haben und mir die Grundlagen des elektronischen Designs beizubringen. Zum Proof-of-Concept habe ich in den vergangenen Wochen bereits erfolgreich ein Basissystem auf Steckbrettern aufgebaut.

Der aktuelle Prototyp ist extrem einfach. Ich verwendete einen 4-MHz-Quarz, der von einem 74HCT04-Pierce-Oszillator als Systemtakt angesteuert wurde, zwei 74HCT573-Latches im transparenten Modus ( LEhoch) als Puffer für den 16-Bit-Adressbus und zwei 74HCT573 in entgegengesetzten Richtungen, die von RDund NOT RDals bidirektionale Daten gesteuert wurden Buspuffer. Ich habe ein 100-ns- AT28C256-EEPROM (nur 16 KiB werden decodiert) und zwei 150-ns- 8-KiB-SRAM-Chips an den Systembus angeschlossen. Ich habe einen 74HCT42 verwendet, um das CSSignal zu erzeugen , und OEden EEPROM auf niedrig, WEauf hoch festverdrahtet , wobei nur ein CS-Signal zur Steuerung des EEPROM übrig blieb.

Alles auf den Steckbrettern ist laut, aber das System schien voll funktionsfähig zu sein, nachdem ich alle Stufen abgeschlossen hatte. Nun kann es holen Anweisungen von dem EEPROM lesen und Schreiben von Daten von / zu dem SRAM, und es hat ein seriell aus einem anderen Latch 74HCT573 hergestellt Port D0angeschlossen ist D0, LEwird (NOT (IOREQ NAND WR)), kommt den Ausgang OUT aus Q1, in anderen Worten, nur ein Ausgangstor ohne Adressdecodierungslogik. Ich habe ein CPU / RAM-intensives Benchmark-Programm geschrieben und mein Computer kann das erwartete Ergebnis ausgeben. Memdumps zeigten auch, dass der Z80 alle Bytes aus dem EEPROM korrekt lesen kann, sodass alles funktioniert.

Aber als ich versuchte, den D0Pin des Datenbusses zu prüfen, sah ich einige merkwürdige "Kerben" für einige logische 1-Ausgänge.

und sie scheinen immer für einige logische Einsen zu erscheinen, kurz nachdem das CSSignal des EEPROM aktiv wird. Hier ist zum Beispiel eine Erfassung der seltsamen Kerbe, die dem blauen EEPROM-CS-Signal überlagert ist.

Ich habe versucht, das Problem einzugrenzen, also habe ich alle CS-Pins des SRAM auf HIGH festverdrahtet und sie effektiv aus dem System entfernt. Außerdem habe ich ein einfaches Testprogramm geschrieben, das keinen Speicherzugriff hat.

.org 0x00
    di

    xor a
loop:
    out (0x00), a
    inc a

    jp loop

Aber das Problem bleibt unverändert, seltsame "Kerben" erscheinen immer noch für einige logische Einsen, kurz nachdem MEMRQund / oder (da es sich im Wesentlichen um einen Chip handelt) CS(blau) niedrig wird.

Alle CS-Pins des SRAM sind HIGH, so dass das System so gut wie nur einen AT28C256-EEPROM-Chip als Speicher und einen Latch als Ausgangsport hat. Das System verfügt auch über einen In-System-Programmierer, der aus einem Atmega328p gefertigt ist, um das EEPROM während einer DMA-Anforderung im laufenden Betrieb neu zu programmieren Ich habe Kerben gesehen, noch bevor ich den Programmierer hinzugefügt habe.

Die "Kerben" müssen also während eines Opcode-Abrufzyklus erzeugt werden. Was sind Sie?

Ich habe einige Hypothesen:

1. Es gibt nichts auszusetzen, es liegt nur an der schlechten Signalintegrität der Steckplatinen und es verschwindet automatisch in einer gut gestalteten und entkoppelten Platine . Das Steckbrett weist alle möglichen Probleme mit der Signalintegrität auf: Impedanzfehlanpassungen, Reflexionen, parasitäre Kapazität, Übersprechen, EMI / RFI. Die langen Busleitungen, die über die Platinen verlaufen, verschlimmern das Problem wahrscheinlich um ein gewisses Maß.

   Wenn es wahr ist, können Sie die Art der "Kerben" erklären? Hat dieses Phänomen einen Namen in EE? Ich habe schon viele Überschwinger und Klingeltöne gesehen, aber noch nie die "Kerben". Und warum sehe ich es nur für einige logische Ebenen?

2. Zeitliche Koordinierung. Ist es möglich, dass eine kurze "Einschwingzeit" des EEPROM-Ausgangs oder anderer Logikschaltungen diesen seltsamen Effekt auf den Bus verursacht?

3. Ausschwärmen. Vielleicht zieht der lange Bus viel Strom und hat eine hohe Kapazität, sodass der EEPROM-Ausgang Schwierigkeiten hatte, den Bus hoch zu fahren? Und wahrscheinlich lädt der Oszilloskop-Tastkopf auch den Bus?

4. Buskonflikt oder andere logische Fehler, die dazu geführt haben, dass der Datenbus unterbrochen wurde. Unwahrscheinlich ich denke? Andere Komponenten auf dem Bus sind isoliert, und ich habe nicht gesehen, wie ein einzelnes AT28C256-EEPROM oder ein Latch dies tun können. Aber ich denke, es ist immer noch möglich, aufgrund eines Verdrahtungsfehlers oder eines versteckten internen Kurzschlusses in den Steckbrettern.

Update: Ich habe bereits von Anfang an Entkopplungs- und Filterkondensatoren auf der Platine verwendet. Ich habe eine ganze Reihe von 0,1-uF-Entkopplungskondensatoren auf allen Platinen verwendet, und die CPU hat sogar sowohl 0,1-uF- als auch 0,01-uF-Kondensatoren zur Entkopplung. Das derzeitige System verfügt über 8 Platinen. Jedes Steckbrett verfügt über zwei 4,7-uF-Aluminiumkondensatoren auf beiden Schienen für die lokale Filterung. Die vom Devboard erhaltene Leistung hat einen Tantalkondensator von 200 uF. Aber wie gesagt, das Problem ist hier.

Ich bin mir jedoch nicht sicher, ob es angemessen ist, insbesondere angesichts der Schwierigkeit, 104 Kondensatoren in der Nähe der Chips auf einem Steckbrett zu platzieren. Vielleicht kann das Hinzufügen von mehr Abhilfe schaffen?

Was mich interessiert, ist die Grundursache des Problems. Wenn bestätigt werden kann, dass es sich um die inhärenten Probleme einer unzureichenden Entkopplung oder einer schlechten Signalintegrität auf dem Steckbrett handelt, kann ich aufhören, Zeit für die Fehlerbehebung zu verschwenden oder mir darüber Sorgen zu machen endgültiges Design wäre eine Leiterplatte. Aber ich bin mir nicht sicher.

Vielen Dank.

Update2: Meiner Meinung nach hat Bruce Abbotts Kommentar die richtige Antwort gegeben und das Problem ist gelöst! Obwohl ich es erst morgen testen kann. Der Schuldige ist die DRAM-Aktualisierung von Z80, siehe meine eigene Antwort für Details. Derzeit ist keine neue Antwort erforderlich, und ich akzeptiere meine eigene Antwort, wenn ich die Lösung bestätigt habe. Wenn es nicht funktioniert, aktualisiere ich die Frage. Vielen Dank für die Hilfe aller.

Vielen Dank für die Hilfe aller. Ich glaube, Bruce Abbott hat die richtige Antwort gegeben.Ich poste von meinem Bett aus und kann es erst morgen testen, aberDie Analyse unten ist bestätigt, als er das Wort "aktualisieren" erwähnte, denke ich, dass das Problem bereits gelöst ist. Ich wusste, wie Z80 die Erinnerung auffrischt, habe es aber in den vergangenen Tagen völlig vergessen.

... noch zwei 74HCT573 in entgegengesetzter Richtung, die von RD und NICHT RD als bidirektionaler Datenbuspuffer gesteuert werden. "- Vielleicht das? Bitte liefern Sie einen Schaltplan mit den Steuersignalen.

Ich vermute, dass dies durch die Aktualisierung am Ende jedes M1-Zyklus (Opcode-Abruf) verursacht wird. Müssen genau sehen, wie Sie CS generieren und Datenbuspuffer aktivieren.

- Bruce Abbott

Die bidirektionale Datenpuffer wird gesteuert durch RDund NOT RDwenn RDaktiv niedrig, die Puffer treibt die Daten an die CPU, andernfalls , wenn RDhoch ist, bedeutet dies , Schreib / Ausgang, wobei der Puffer steuert den Bus.

Trotzdem führt der Z80 unmittelbar nach dem Abrufen des Opcodes ein Speicherlesen für die DRAM-Aktualisierung durch. Dieses Mal RDist HIGHtrotz es eine Leseoperation ist, wodurch der Puffer seine Richtung drehen und mit dem Bus fährt, ist das Ergebnis eine Buskonkurrenzsituation. Während des DRAM-Auffrischungszyklus traten also immer seltsame "Kerben" auf, jedoch keine normalen Speicherlesevorgänge / -schreibvorgänge oder E / A-Vorgänge. Dies erklärt, warum die "Kerbe" immer erscheint, aber nur für einige und nicht alle logischen Einsen.

Darüber hinaus muss SRAM nicht aktualisiert werden, sodass die DRAM-Aktualisierung in meinem System völlig unbrauchbar ist und dieser Buskonflikt keine Anweisungen oder Daten verfälscht, sodass das System anscheinend voll funktionsfähig ist.

Lösung: implementieren (RD AND REFRESH)und (NOT (RD AND REFRESH). In der nächsten Revision sollte ich auch testen BUSACK, ob der Datenpuffer den Bus auch während einer DMA-Operation nicht antreibt.

Update: Ich kann das Problem und die Lösung bestätigen. Verwenden Sie WRund, um NOT WRdas Problem zu beheben, wie in den neuen Schaltplänen gezeigt( Mach das nicht! Das ist auch falsch, siehe Update 2 ).

Die Wellenform sieht jetzt normal aus!

Update2: Die obigen Schaltpläne sind ebenfalls fehlerhaft. Wenn Sie diese Antwort gelesen haben, verwenden Sie sie nicht! Wenn vorausgesetzt , den Bus ist , WRwenn RDSignal inaktiv ist schon schlimm genug ist, ist mit dem Bus unter der Annahme , RDwenn WRinaktiv ist , ist noch schlimmer. Ich habe das vorherige Programm für die ersten Tests verwendet, sodass das System anscheinend funktioniert, aber ein kritisches Problem übersehen wurde.

Während eines Speicherschreibzyklus würde die Z80-CPU den Bus ansteuern, bevor WR er auf Low- Pegel geht. Zu diesem Zeitpunkt wurden die Daten vom Datenpuffer immer noch in Richtung CPU übertragen.

Bruce Abbott hat Recht: Es ist besser, jeden Puffer immer unabhängig zu steuern RDund zu WRsignalisieren, anstatt nur einen zu invertieren.

Beispielsweise,

Es funktioniert jetzt perfekt.

Und schließlich ist das obige Schema wieder eine Vereinfachung. Man sollte auch testen BUSACK, ob der Datenpuffer den Bus auch während einer DMA-Operation nicht antreibt.

Stellen Sie sicher, dass alle ICs über ausreichende Entkopplungskondensatoren verfügen. Eine 100-nF-Keramik von der Stromversorgung bis zur Masse auf jedem IC hält die Zuleitungen so kurz wie möglich und einen niedrigen ESR-Elektrolytwert von 100 uF auf dem Steckbrett über die Stromschienen.

Ich sehe hier zwei Möglichkeiten:

1) D0 ist tristatisiert

Was auch immer D0 angesteuert hat, geht in den Tristate-Zustand (hochohmiger Modus) und dann senkt ein Pulldown irgendwo im D0-Netz die Spannung langsam (Zeitkonstante, die durch den Pulldown-Widerstand und die parasitären Kapazitäten von ICs und Leiterbahnen definiert ist). Die exponentielle Natur der Wellenform ist ein starkes Indiz dafür, dass die Linie nicht von etwas Starkem, sondern von einem relativ schwachen Pulldown gesteuert wird.

Versuchen Sie, der Leitung einen weiteren Pulldown-Widerstand hinzuzufügen, und prüfen Sie, ob die exponentielle Wellenform schneller auf Null geht.

Denken Sie daran, dass dies nicht unbedingt ein Problem ist und Ihr Bus möglicherweise einwandfrei funktioniert.

2) Streit

Ihre Hypothese # 4. Es ist auch möglich, dass D0 zu einer anderen Logikleitung kurzgeschlossen wird. Ich halte dies für unwahrscheinlich, da Sie in diesem Fall keine exponentielle Wellenform mit einer relativ langen Zeitkonstante sehen würden, wie Sie jetzt sehen. Sie können andere Netze in Ihrer Schaltung auf der Suche nach einer anderen identischen Wellenform untersuchen, um anzuzeigen, dass Sie einen Kurzschluss haben.

Viel Glück!

PS - dies ist kein Problem der Signalintegrität, dafür ist die Pulsbreite viel zu lang