Come posso implementare un controller DRAM asincrono molto semplice?

Mi piacerebbe sapere come costruire un controller DRAM asincrono a ossa nude. Ho alcuni moduli SIMM 70ns DRAM a 30 pin 1Mx9 (1Mx9 con parità) che mi piacerebbe usare in un progetto di computer retrò homebrew. Sfortunatamente non esiste un foglio dati per loro, quindi vado dal Siemens HYM 91000S-70 e da "Capire il funzionamento della DRAM" di IBM.

L'interfaccia di base con cui vorrei finire è

• / CS: in, selezione chip
• R / W: in, leggi / non scrivere
• RDY: out, HIGH quando i dati sono pronti
• D: bus dati in / out, 8 bit
• A: in, bus indirizzo a 20 bit

Aggiornamento sembra piuttosto semplice con diversi modi per farlo bene. Dovrei essere in grado di eseguire un aggiornamento distribuito (interleaved) solo RAS (ROR) durante il clock della CPU BASSO (dove non viene effettuato l'accesso alla memoria in questo particolare chip) utilizzando qualsiasi vecchio contatore per il tracciamento dell'indirizzo di riga. Credo che tutte le righe debbano essere aggiornate almeno ogni 64ms secondo JEDEC (512 per 8ms secondo la scheda tecnica Seimens, ovvero aggiornamento standard del ciclo / 15.6us), quindi questo dovrebbe funzionare bene e se rimango bloccato, invierò semplicemente un'altra domanda. Sono più interessato a leggere e scrivere in modo semplice, corretto e determinando cosa dovrei aspettarmi per quanto riguarda la velocità.

Per prima cosa descriverò rapidamente come penso che funzioni e le potenziali soluzioni che ho escogitato finora.

Fondamentalmente, hai diviso un indirizzo a 20 bit a metà, usando metà per la colonna e l'altra per la riga. Stroboscopicamente l'indirizzo della riga, quindi l'indirizzo della colonna, se / W è ALTO quando / CAS diventa BASSO, allora è una lettura, altrimenti è una scrittura. Se si tratta di una scrittura, i dati devono essere già sul bus dati a quel punto. Dopo un periodo di tempo, se si tratta di una lettura, i dati sono disponibili o se si tratta di una scrittura, i dati saranno sicuramente scritti. Quindi / RAS e / CAS devono essere portati nuovamente ALTO nel periodo di "precarica" ​​contro intuitivamente. Questo completa il ciclo.

Quindi, sostanzialmente è una transizione attraverso diversi stati con ritardi specifici non uniformi tra ogni transizione. L'ho elencato come una "tabella" indicizzata dalla durata di ogni fase della transazione in ordine:

1. t (ASR) = 0ns
   • /ERUZIONE CUTANEA
   • /CONTANTI
   • A0-9: RA
   • / W: H
2. t (RAH) = 10ns
   • / RAS: L
   • /CONTANTI
   • A0-9: RA
   • / W: H
3. t (ASC) = 0ns
   • / RAS: L
   • /CONTANTI
   • A0-9: CA
   • / W: H
4. t (CAH) = 15 ns
   • / RAS: L
   • / CAS: L
   • A0-9: CA
   • / W: H
5. t (CAC) - t (CAH) =?
   • / RAS: L
   • / CAS: L
   • A0-9: X
   • / W: H (dati disponibili)
6. t (RP) = 40 ns
   • /ERUZIONE CUTANEA
   • / CAS: L
   • A0-9: X
   • / W: X
7. t (CP) = 10ns
   • /ERUZIONE CUTANEA
   • /CONTANTI
   • A0-9: X
   • / W: X

I tempi a cui mi riferisco sono nel diagramma seguente.

(CA = indirizzo colonna, RA = indirizzo riga, X = non importa)

Anche se non è esattamente così, è qualcosa del genere e penso che lo stesso tipo di soluzione funzionerà. Quindi ho trovato un paio di idee finora, ma penso che solo l'ultimo abbia un potenziale e sto cercando idee migliori. Sto ignorando rinfrescante, Fast Page e controllo di parità / generazione qui.

La soluzione più semplice consiste solo nell'utilizzare un contatore e una ROM in cui l'uscita del contatore è l'ingresso dell'indirizzo ROM e ogni byte ha l'uscita di stato appropriata per il periodo di tempo a cui l'indirizzo corrisponde. Questo non funzionerà perché le ROM sono lente. Anche una SRAM precaricata sembra che sarebbe troppo lenta per valerne la pena.

La seconda idea era quella di utilizzare un GAL16V8 o qualcosa del genere, ma non credo di capirli abbastanza bene, i programmatori sono molto costosi e il software di programmazione è chiuso e Windows solo per quanto ne so.

La mia ultima idea è l'unica che penso possa funzionare davvero. La famiglia logica 74ACT ha bassi ritardi di propagazione e accetta alte frequenze di clock. Penso che leggere e scrivere potrebbe essere fatto con un registro a scorrimento CD74ACT164E e SN74ACT573N .

Fondamentalmente, ogni stato unico ottiene il proprio fermo programmato staticamente usando binari 5V e GND. Ogni uscita del registro a scorrimento va a un pin di Latch / OE. Se capisco bene le schede tecniche, il ritardo tra ogni stato potrebbe essere solo 1 / SCLK ma è molto meglio di una soluzione PROM o 74HC.

Quindi, è probabile che l'ultimo approccio funzioni? Esiste un modo più veloce, più piccolo o generalmente migliore per farlo? Penso di aver visto che l'IBM PC / XT utilizzava 7400 chip per qualcosa legato alla DRAM ma ho visto solo foto di fascia alta, quindi non sono sicuro di come funzionasse.

ps Vorrei che questo fosse fattibile in DIP e non "imbrogliare" usando un FPGA o un moderno uC.

pps Forse usare gate delay direttamente con lo stesso approccio latch è un'idea migliore. Mi rendo conto che sia il registro a scorrimento che i metodi di ritardo di gate / propagazione diretti variano con la temperatura, ma accetto questo.

Per chiunque lo trovi in ​​futuro, questa discussione tra Bil Herd e André Fachat copre molti dei progetti citati in questo thread e discute di altri problemi tra cui i test DRAM.

Ci sono schemi completi per IBM PC / XT nel manuale di riferimento tecnico IBM Personal Computer XT (Appendice D), che potresti trovare online.

Il problema qui è che, data una linea stroboscopica che viene attivata su una memoria in lettura o scrittura, si desidera generare RAS, CAS e una linea di controllo (chiamarla MUX) per il multiplexer di indirizzi. Per semplicità, supporrò irrealisticamente che lo strobo, il RAS e il CAS siano tutti attivi.

Osservando lo schema PC / XT e gli schemi di alcuni altri computer in questo periodo, vedo tre strategie di base, che sono all'incirca le seguenti:

• Usa lo strobo per RAS. Utilizzare una linea di ritardo (una parte il cui output è una versione ritardata del suo ingresso) su RAS per generare MUX e utilizzare un'altra linea di ritardo per generare una versione ancora successiva di RAS, utilizzata per CAS. Questa strategia è utilizzata dal PC / XT e dal TRS-80 Modello II.
  
  Un esempio (moderno) di linea di ritardo è il Maxim DS1100.

• Utilizzare lo strobo per RAS e ritardarlo per MUX e CAS, ma farlo utilizzando un registro a scorrimento ad alta velocità anziché una linea di ritardo. Questa strategia è utilizzata dal modello I TRS-80 e dall'Apple II.

• Usa circuiti integrati personalizzati. Questa è la strategia del Commodore 64.

La tua domanda è abbastanza complicata che non sono nemmeno sicuro di quale sia il tuo vero problema, ma ci proverò!

Il design DRAM basato su 6502 "più pulito" che ho potuto trovare è dal PET Commodore 2001-N . Ha un 6502 che funziona a 1 MHz, ma la logica DRAM è sincronizzata a 16 MHz, probabilmente per generare tutti i tempi.

Non ho analizzato i dettagli, ma l'azione principale sembra accadere con un contatore 74191 a 4 bit collegato a un registro a scorrimento 74164. Questo emette 8 linee separate che entrano in un MUX 74157 che è controllato dalla linea R / W. L'uscita dal MUX entra in un flip-flop 7474 e in una logica discreta per generare i segnali RAS / CAS finali. Ecco un estratto che rimanda alla pagina pertinente nello schema di riferimento.

L'aggiornamento viene gestito con un contatore separato e ogni riga dell'indirizzo è collegata a un multiplexer che seleziona l'indirizzo "reale" o l'indirizzo di aggiornamento.

Parti di questa logica sembrano anche generare tempi per il sottosistema video. Sono sicuro che può essere semplificato per le tue esigenze particolari, ma penso che qualcosa di simile possa essere utile: un contatore ad alta frequenza, registro a scorrimento e multiplexer.

ps Vorrei che questo fosse fattibile in DIP e non "imbrogliare" usando un FPGA o un moderno uC.

Mentre comprendo completamente lo spirito del tuo progetto e il tuo desiderio di utilizzare parti non elaborate, andrei sicuramente nel modo FPGA se fossi in te .

Diverse ragioni:

1. È un'opportunità di apprendimento perfetta. La progettazione di un controller DRAM non è un progetto "ciao-mondo" e dopo puoi dire con sicurezza che "puoi fare" FPGA;
2. Potresti spremere ogni bit di prestazioni da questa memoria, specialmente se si tratta di un vecchio chip DRAM. Non solo avresti il ​​tuo PC basato su 6502 costruito in casa, è possibile che tu abbia il PC basato su 6502 più veloce ;
3. Può essere molto più semplice eseguire il debug dei problemi o effettuare statistiche sulle operazioni di memoria emesse dalla CPU. Puoi usare gli analizzatori logici su bus paralleli, ma non è mai divertente (un mio amico fa qualcosa del genere: vuole scrivere una simulazione esatta del ciclo di 8088 e per questo motivo ha bisogno di raccogliere quelle statistiche sugli accessi alla memoria e sui tempi usa il chip set originale (8288, 8280, 8237) e usa un analizzatore logico con molti canali, ma dalla sua esperienza posso dirti che è un trascinamento).