Perché vedo una strana "tacca" sulla linea dati per alcuni 1 logici?


15

Sto cercando di costruire un computer homebrew Z80 per un po 'di divertimento retrocomputer e di insegnarmi le basi del design elettronico. Come prova di concetto, ho già assemblato con successo un sistema di base su breadboard nelle settimane precedenti.

L'attuale prototipo è estremamente semplice. Ho usato un cristallo a 4 MHz pilotato da un oscillatore Pierce 74HCT04 come orologio di sistema, due fermi 74HCT573 in modalità trasparente ( LEalta) come buffer per il bus di indirizzo a 16 bit, altri due 74HCT573 in direzioni opposte controllate da RDe NOT RDcome dati bidirezionali buffer del bus. Ho collegato una EEPROM AT28C256 da 100 ns (viene decodificato solo 16 KiB) e due chip SRAM da 8 KiB da 150 ns sul bus di sistema. Ho usato un 74HCT42 per generare il CSsegnale e ho cablato la OEEEPROM su bassa, WEalta, lasciando solo un segnale CS per controllare la EEPROM.

Tutto sulle breadboard è rumoroso, ma il sistema sembrava essere pienamente operativo dopo aver completato tutte le fasi. Ora può recuperare istruzioni dalla EEPROM, leggere e scrivere dati da / verso la SRAM, e ha una porta seriale ricavata da un altro latch 74HCT573, a cui D0è collegata D0,LE è (NOT (IOREQ NAND WR)), l'uscita esce Q1, in altre parole, solo una porta di uscita senza logica di decodifica dell'indirizzo. Ho scritto un programma di benchmark ad alta intensità di CPU / RAM e il mio computer può produrre il risultato atteso. Memdumps ha anche mostrato che lo Z80 può leggere correttamente tutti i byte dalla EEPROM, quindi tutto funziona.

Ma quando ho provato a sondare il D0pin del bus dati, stavo vedendo alcune strane "tacche" per alcune uscite logiche apparenti 1.

Un esempio di Weird Notches su D0

e sembrano apparire sempre per alcuni 1 logici poco dopo che il CSsegnale dell'EEPROM diventa attivo, ad esempio, ecco una cattura della strana tacca sovrapposta al segnale CS EEPROM blu.

Una strana tacca sovrapposta al segnale CS

Ho provato a isolare il problema, quindi ho cablato tutti i pin CS della SRAM su HIGH, rimuovendoli efficacemente dal sistema e ho scritto un semplice programma di test che non ha accesso alla memoria.

.org 0x00
    di

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

    jp loop

Ma il problema è invariato, strane "tacche" appaiono sempre per alcuni 1 logici, subito dopo MEMRQe / o (dato che ora è essenzialmente un chip) CS(blu) diventa basso.

Tutti i pin CS della SRAM sono ALTI, quindi il sistema ha praticamente un chip EEPROM AT28C256 come memoria e un latch come porta di uscita. Il sistema ha anche un programmatore interno al sistema fatto da un Atmega328p per riprogrammare la EEPROM al volo durante una richiesta DMA, ma non credo che sia il colpevole da quando ho provato tutti i dati e l'indirizzo del programmatore, e Ho visto tacche anche prima di aggiungere il programmatore.

Un altro esempio di "Notches"

Quindi le "tacche" devono essere create durante un ciclo di recupero del codice operativo. Quali sono?

Ho alcune ipotesi:

  1. Non c'è niente di sbagliato, è solo causato dalla cattiva integrità del segnale delle breadboard e scomparirà automaticamente in un PCB ben progettato e ben disaccoppiato . La breadboard presenta ogni sorta di problemi di integrità del segnale: discrepanze di impedenza, riflessioni, capacità parassita, diafonia, EMI / RFI. I lunghi fili del bus che attraversano le schede probabilmente peggiorano il problema di un grado di grandezza.

    Se è vero, puoi spiegare la natura delle "tacche"? Questo fenomeno ha un nome in EE? Ho visto molti overshoots e squilli prima, ma non ho mai visto le "tacche". E perché lo vedo solo per alcuni livelli logici?

  2. Timing. È possibile che un breve "tempo di assestamento" dell'uscita EEPROM o di altri circuiti logici stia causando questo strano effetto sul bus?

  3. Fan-out. Forse il bus lungo assorbe molta corrente e ha un'alta capacità, quindi l'uscita EEPROM ha avuto difficoltà a guidare il bus in alto? E probabilmente anche la sonda dell'oscilloscopio sta caricando il bus?

  4. Contesa del bus o altri errori logici che hanno causato l'estrazione del bus dati. Improbabile, penso? Altri componenti sul bus sono isolati e non sono riuscito a vedere come una singola EEPROM AT28C256 o un fermo possano farlo. Ma immagino che sia ancora possibile a causa di un errore di cablaggio o di un cortocircuito interno nascosto nelle breadboard.

Aggiornamento: ho già usato i condensatori di disaccoppiamento e filtro sulla scheda sin dall'inizio. Ho usato parecchi condensatori di disaccoppiamento da 0,1 uF su tutte le schede e la CPU ha persino condensatori da 0,1 uF e 0,01 uF per il disaccoppiamento. L'attuale sistema ha 8 schede, ciascuna breadboard ha due condensatori in alluminio da 4,7 uF su entrambe le guide per il filtraggio locale. Inoltre, la potenza ottenuta dalla devboard ha un condensatore al tantalio 200 uF. Ma come ho detto, il problema è qui.

Non sono sicuro che sia adeguato, soprattutto considerando la difficoltà di posizionare 104 condensatori vicino ai chip su una breadboard. Forse l'aggiunta di più può risolverlo?

Quello che mi interessa è la causa principale del problema, se si può confermare che sono semplicemente i problemi intrinseci del disaccoppiamento inadeguato o della scarsa integrità del segnale sulla breadboard, posso smettere di tentare di perdere tempo per risolvere i problemi o preoccuparmi dal il progetto finale sarebbe un PCB. Ma non sono sicuro.

Grazie.

Update2: Secondo me, il commento di Bruce Abbott ha dato la risposta corretta e il problema è stato risolto! Anche se non posso provarlo fino a domani. Il colpevole è l'aggiornamento DRAM di Z80, vedere la mia risposta per i dettagli. Al momento non è necessaria una nuova risposta e accetterò la mia risposta quando confermerò la soluzione. Se non funziona, aggiornerò la domanda. Grazie per l'aiuto di tutti.


Ho appena visto la tua modifica. Credo che sarebbe l'ideale se si osservano le specifiche e le note / applicazioni di progettazione per le parti che si stanno utilizzando. Potrebbero esserci componenti che ti mancano oltre ai condensatori di disaccoppiamento per il dispositivo. Sei sicuro di aver seguito tutte le specifiche? È un buon esercizio per la causa principale. A partire da ora, la tua domanda è senza risposta senza uno schema elettrico.
KingDuken,

6
Un modo per aiutare a separare i problemi di EMI / alimentazione dai problemi di orologio / logici è provare a utilizzare un orologio a frequenza più lenta, ad esempio 0,5 MHz o 1 MHz. Se lo strano problema tecnico va da 250 ns a 1us, si basa sul funzionamento del processore. Se rimane circa 250 ns, potrebbe trattarsi di un problema EMI / alimentazione. Hai resistenze pull-up / down sul bus (potrebbe essere una risposta a tre stati)?
W5VO,

1
Dai un'occhiata e vedi se la scheda tecnica del processore raccomanda / suggerisce eventuali resistenze di pull-up o pull-down sul bus dati. Ciò contribuirebbe a ridurre la possibilità di glitch da un'operazione a tre stati. Se hai aggiunto un'altra istruzione "inc a" al tuo programma, probabilmente potresti capire quale istruzione stava causando il problema tecnico.
W5VO,

1
"... altri due 74HCT573 in direzioni opposte controllate da RD e NOT RD come buffer del bus dati bidirezionale." - forse questo? Fornire uno schema circuitale che mostri i segnali di controllo.
Bruce Abbott,

5
Sospetto che sia causato dall'aggiornamento alla fine di ogni ciclo M1 (opcode fetch). È necessario vedere esattamente come si stanno generando CS e abilita il buffer del bus dati.
Bruce Abbott,

Risposte:


13

Grazie per l'aiuto di tutti. Credo che Bruce Abbott abbia dato la risposta corretta.Sto postando dal mio letto e non posso ancora provarlo fino a domani, maL'analisi che segue è confermata, quando ha menzionato la parola "aggiorna", penso che il problema sia già risolto. Sapevo come Z80 aggiorna la memoria, ma me ne sono completamente dimenticato nei giorni precedenti.

... altri due 74HCT573 in direzioni opposte controllate da RD e NOT RD come buffer del bus dati bidirezionale. "- Forse questo? Fornire uno schema circuitale che mostri i segnali di controllo.

Sospetto che sia causato dall'aggiornamento alla fine di ogni ciclo M1 (opcode fetch). È necessario vedere esattamente come si stanno generando CS e abilita il buffer del bus dati.

- Bruce Abbott

Il buffer di dati bidirezionale è controllato da RDe NOT RDse RDè attivo basso, il buffer invia i dati alla CPU, altrimenti, se RDè alto, significa scrittura / output, il buffer guida il bus.

buffer di dati bidirezionale

Tuttavia, lo Z80 esegue una lettura della memoria per l'aggiornamento della DRAM immediatamente dopo il recupero del codice operativo. Questa volta, RDè HIGHnonostante è un'operazione di lettura, causando il buffer per invertire la sua direzione e guidare il bus, il risultato è una contesa bus. Quindi strane "tacche" appariranno sempre durante il ciclo di aggiornamento della DRAM, ma non le normali letture / scritture di memoria o I / O. Questo spiega perché la "tacca" appare sempre, ma solo per alcuni e non tutti gli 1 logici.

Diagramma dei tempi di recupero del codice operativo Z80

Inoltre, SRAM non ha bisogno di essere aggiornato, quindi l'aggiornamento DRAM è completamente inutile nel mio sistema e questa contesa sul bus non corromperà alcuna istruzione o dato, rendendo il sistema perfettamente funzionante.

Soluzione: implementare (RD AND REFRESH)e (NOT (RD AND REFRESH). Nella prossima revisione, dovrei anche testare BUSACKper assicurarmi che anche il buffer di dati non stia guidando il bus durante un'operazione DMA.

Aggiornamento: posso confermare il problema e la soluzione. Utilizzando WReNOT WR invece risolto il problema, come mostrato nei nuovi schemi( Non farlo! Anche questo è sbagliato, vedi Aggiornamento 2 ).

Nuovi schemi (errato)

La forma d'onda sembra normale ora!

La nuova forma d'onda che mostra il problema è stata corretta.

Aggiornamento2: Anche gli schemi sopra riportati sono rotti, se sei un lettore di questa risposta, non usarla! Se supponendo che il bus sia WRquando il RDsegnale è inattivo è abbastanza male, supporre che il bus sia RDquando WRè inattivo è anche peggio. Ho usato il programma precedente per i test iniziali, quindi il sistema sembrava funzionare, ma mancava un problema critico.

Durante un ciclo di scrittura della memoria, la CPU Z80 avrebbe iniziato a guidare il bus prima di WR diventare attiva, in questo momento il buffer di dati stava ancora guidando i dati verso la CPU, oops, creando una contesa sul bus.

Diagramma dei tempi di lettura / scrittura della memoria Z80

Bruce Abbott ha ragione: è meglio usare RDe WRsegnalare sempre in modo indipendente per controllare ciascun buffer, anziché invertirne uno solo.

Per esempio,

Nuovi schemi (risolti, ma DMA non è gestito, è necessario gestirlo.

Funziona perfettamente ora.

E infine, ancora una volta, i suddetti schemi sono una semplificazione, si dovrebbe anche testare BUSACKper assicurarsi che il buffer di dati non stia guidando il bus anche durante un'operazione DMA.


6
È possibile considerare l'utilizzo di / WR anziché invertito / RD per abilitare il buffer superiore. In questo modo il bus dati sarà inattivo a meno che non sia in corso una lettura o scrittura effettiva.
Bruce Abbott,

8

Assicurarsi di disporre di condensatori di disaccoppiamento adeguati su tutti i circuiti integrati. Una ceramica da 100 nF dall'alimentazione a massa su ciascun circuito integrato mantiene i cavi più corti possibile e un elettrolitico a bassa ESR dice 100 uF sulla breadboard attraverso le barre di alimentazione.


Sembra essere la soluzione per molta instabilità per i circuiti integrati digitali :)
KingDuken,

4
@KingDuken Assolutamente e un po 'un argomento caldo per me, un mio amico è stato licenziato una volta per aver perso uno. Ha causato molta instabilità in una macchina per la gestione del contante, whoops.
RoyC,

2
Il disaccoppiamento è importante, ma non è la risposta a tutto. Dovrebbe essere evidente dalla forma d'onda che è improbabile che sia rilevante qui.
pericynthion,

4

Vedo due possibilità qui:

1) D0 viene tristato

Qualunque cosa stesse guidando D0 va in tristate (modalità ad alta impedenza) e quindi un pull-down da qualche parte nella rete D0 abbassa lentamente la tensione (costante di tempo definita dalla resistenza di pull-down e dalle capacità parassite di circuiti integrati e tracce). La natura esponenziale della forma d'onda è una forte indicazione che la linea non è guidata da qualcosa di forte, ma piuttosto da un pull-down relativamente debole.

Prova ad aggiungere un altro resistore pull-down alla linea e controlla se la forma d'onda esponenziale va a zero più velocemente.

Tieni presente che questo non è necessariamente un problema e il tuo autobus potrebbe funzionare perfettamente con questo.

2) Contesa

La tua ipotesi n. 4. È anche possibile che D0 sia in cortocircuito verso un'altra linea logica. Lo trovo improbabile, poiché in questo caso non vedresti una forma d'onda esponenziale con una costante di tempo relativamente lunga come vedi ora. Puoi sondare altre reti nel tuo circuito alla ricerca di un'altra forma d'onda identica, indicando che hai un corto.

In bocca al lupo!

PS: questo non è un problema di integrità del segnale, l'ampiezza dell'impulso è troppo lunga per quello

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.