Comment puis-je implémenter un contrôleur DRAM asynchrone très simple?

Je voudrais savoir comment construire un contrôleur DRAM asynchrone bare bones. J'ai des modules DRAM SIMM 70ns 30 broches 1MB (1Mx9 avec parité) que j'aimerais utiliser dans un projet d'ordinateur rétro homebrew. Malheureusement, il n'y a pas de fiche technique pour eux, donc je vais du Siemens HYM 91000S-70 et "Understanding DRAM Operation" d'IBM.

L'interface de base avec laquelle j'aimerais finir est

• / CS: in, sélection de puce
• R / W: dans, lire / ne pas écrire
• RDY: out, HIGH lorsque les données sont prêtes
• D: entrée / sortie, bus de données 8 bits
• A: bus d'adresse 20 bits

Actualiser semble assez simple avec plusieurs façons de faire les choses. Je devrais être en mesure de faire un rafraîchissement distribué (entrelacé) RAS uniquement (ROR) pendant l'horloge CPU LOW (où aucun accès à la mémoire n'est effectué dans cette puce particulière) en utilisant n'importe quel ancien compteur pour le suivi de l'adresse de ligne. Je crois que toutes les lignes doivent être actualisées au moins toutes les 64 ms selon JEDEC (512 par 8 ms selon la fiche technique Seimens, c'est-à-dire le rafraîchissement standard du cycle / 15,6us), donc cela devrait fonctionner correctement et si je suis coincé, je posterai simplement une autre question. Je suis plus intéressé à obtenir une lecture et une écriture simples, correctes et à déterminer ce à quoi je dois m'attendre en ce qui concerne la vitesse.

Je vais d'abord décrire rapidement comment je pense que cela fonctionne et les solutions potentielles que j'ai trouvées jusqu'à présent.

Fondamentalement, vous divisez une adresse 20 bits en deux, en utilisant une moitié pour la colonne et l'autre pour la ligne. Vous strobez l'adresse de ligne, puis l'adresse de colonne, si / W est HAUT lorsque / CAS devient BAS alors c'est une lecture, sinon c'est une écriture. S'il s'agit d'une écriture, les données doivent déjà être sur le bus de données à ce stade. Après un certain temps, s'il s'agit d'une lecture, les données sont disponibles ou s'il s'agit d'une écriture, les données sont sûrement écrites. Ensuite, / RAS et / CAS doivent être à nouveau HAUT dans la période de "précharge" nommée contre-intuitivement. Ceci termine le cycle.

Donc, fondamentalement, c'est une transition à travers plusieurs états avec des retards spécifiques non uniformes entre chaque transition. Je l'ai répertorié comme une "table" indexée par la durée de chaque phase de la transaction dans l'ordre:

1. t (ASR) = 0ns
   • / RAS: H
   • /EN ESPÈCES
   • A0-9: RA
   • / W: H
2. t (RAH) = 10ns
   • / RAS: L
   • /EN ESPÈCES
   • A0-9: RA
   • / W: H
3. t (ASC) = 0ns
   • / RAS: L
   • /EN ESPÈCES
   • A0-9: CA
   • / W: H
4. t (CAH) = 15ns
   • / RAS: L
   • / CAS: L
   • A0-9: CA
   • / W: H
5. t (CAC) - t (CAH) =?
   • / RAS: L
   • / CAS: L
   • A0-9: X
   • / W: H (données disponibles)
6. t (RP) = 40ns
   • / RAS: H
   • / CAS: L
   • A0-9: X
   • / W: X
7. t (CP) = 10ns
   • / RAS: H
   • /EN ESPÈCES
   • A0-9: X
   • / W: X

Les temps dont je parle sont dans le diagramme suivant.

(CA = adresse de colonne, RA = adresse de ligne, X = peu importe)

Même si ce n'est pas exactement cela, c'est quelque chose comme ça et je pense que le même type de solution fonctionnera. J'ai donc trouvé quelques idées jusqu'à présent, mais je pense que seule la dernière a du potentiel et je cherche de meilleures idées. J'ignore ici l'actualisation, la vérification rapide des pages et la parité / génération.

La solution la plus simple consiste simplement à utiliser un compteur et une ROM où la sortie du compteur est l'entrée d'adresse ROM et chaque octet a la sortie d'état appropriée pour la période de temps à laquelle l'adresse correspond. Cela ne fonctionnera pas car les ROM sont lentes. Même une SRAM préchargée semble être beaucoup trop lente pour en valoir la peine.

La deuxième idée était d'utiliser un GAL16V8 ou quelque chose comme ça, mais je ne pense pas que je les comprenne assez bien, les programmeurs sont très chers et le logiciel de programmation est fermé et Windows uniquement pour autant que je sache.

Ma dernière idée est la seule qui, selon moi, pourrait fonctionner. La famille logique 74ACT présente de faibles délais de propagation et accepte des fréquences d'horloge élevées. Je pense que la lecture et l'écriture pourraient être effectuées avec certains registres à décalage CD74ACT164E et SN74ACT573N .

Fondamentalement, chaque état unique obtient son propre verrou programmé statiquement à l'aide de rails 5V et GND. Chaque sortie du registre à décalage va à une broche du verrou / OE. Si je comprends bien les fiches techniques, le délai entre chaque état ne pourrait être que de 1 / SCLK mais c'est bien mieux qu'une solution PROM ou 74HC.

Alors, la dernière approche est-elle susceptible de fonctionner? Existe-t-il un moyen plus rapide, plus petit ou généralement meilleur de procéder? Je pense avoir vu que l'IBM PC / XT a utilisé 7400 puces pour quelque chose en rapport avec la DRAM, mais je n'ai vu que des photos de la carte supérieure, donc je ne sais pas comment cela a fonctionné.

ps Je voudrais que cela soit faisable en DIP et non "triche" en utilisant un FPGA ou uC moderne.

pps Il est peut-être préférable d'utiliser le retard de porte directement avec la même approche de verrouillage. Je me rends compte que les méthodes de registre à décalage et de retard de porte / propagation varient en fonction de la température, mais je l'accepte.

Pour tous ceux qui trouveront cela à l'avenir, cette discussion entre Bil Herd et André Fachat couvre plusieurs des conceptions mentionnées dans ce fil et discute d'autres problèmes, y compris les tests DRAM.

Il existe des schémas complets pour IBM PC / XT dans le manuel de référence technique IBM Personal Computer XT (annexe D), que vous pourrez peut-être trouver en ligne.

Le problème ici est que, étant donné une ligne stroboscopique qui est activée lors d'une lecture ou d'une écriture en mémoire, vous souhaitez générer RAS, CAS et une ligne de contrôle (appelez-la MUX) pour le multiplexeur d'adresses. Par souci de simplicité, je supposerai de façon irréaliste que le stroboscope, le RAS et le CAS sont tous actifs en haut.

En regardant le schéma PC / XT et les schémas de certains autres ordinateurs à cette époque, je vois trois stratégies de base, qui sont à peu près les suivantes:

• Utilisez le stroboscope pour RAS. Utilisez une ligne à retard (une partie dont la sortie est une version temporisée de son entrée) sur RAS pour générer MUX, et utilisez une autre ligne à retard pour générer une version encore plus récente de RAS, qui est utilisée pour CAS. Cette stratégie est utilisée par le PC / XT et le TRS-80 Model II.
  
  Un exemple (moderne) de ligne à retard est le Maxim DS1100.

• Utilisez le stroboscope pour RAS et retardez-le pour MUX et CAS, mais faites-le en utilisant un registre à décalage à grande vitesse au lieu d'une ligne à retard. Cette stratégie est utilisée par le TRS-80 Model I et l'Apple II.

• Utilisez des circuits intégrés personnalisés. Telle est la stratégie du Commodore 64.

Votre question est suffisamment compliquée pour que je ne sois même pas sûr de votre problème réel, mais je vais essayer!

La conception de DRAM 6502 "la plus propre" que j'ai pu trouver est celle du Commodore PET 2001-N . Il a un 6502 fonctionnant à 1 MHz, mais la logique DRAM est cadencée à 16 MHz, susceptible de générer tous les timings.

Je n'ai pas analysé les détails, mais l'action principale semble se produire avec un compteur 74191 4 bits connecté à un registre à décalage 74164. Cela délivre 8 lignes distinctes entrant dans un 74157 MUX qui est contrôlé par la ligne R / W. La sortie du MUX passe dans une bascule 7474 et une logique discrète pour générer les signaux RAS / CAS finaux. Voici un extrait qui renvoie à la page pertinente du schéma de référence.

L'actualisation est gérée avec un compteur séparé, et chaque ligne d'adresse est connectée à un multiplexeur qui sélectionne soit l'adresse "réelle" soit l'adresse d'actualisation.

Certaines parties de cette logique semblent également générer des temporisations pour le sous-système vidéo. Je suis sûr que cela peut être simplifié pour vos besoins particuliers, mais je pense que quelque chose de similaire peut être utile: un compteur haute fréquence, un registre à décalage et des multiplexeurs.

ps Je voudrais que cela soit faisable en DIP et non "triche" en utilisant un FPGA ou uC moderne.

Bien que je comprenne parfaitement l'esprit de votre projet et votre désir d'utiliser des pièces non fantaisistes, j'irais certainement dans le sens du FPGA si j'étais vous .

Plusieurs raisons:

1. C'est une parfaite opportunité d'apprentissage. La conception d'un contrôleur DRAM n'est pas un projet "bonjour" et après cela, vous pouvez dire en toute confiance que vous "pouvez faire" FPGA;
2. Vous pouvez extraire chaque bit de performances de cette mémoire, surtout s'il s'agit d'une ancienne puce DRAM. Non seulement vous auriez votre PC 6502 maison, mais il est possible que vous ayez le PC 6502 le plus rapide ;
3. Il peut être beaucoup plus facile de déboguer des problèmes ou de faire des statistiques sur les opérations de mémoire émises par votre processeur. Vous pouvez utiliser des analyseurs logiques sur des bus parallèles, mais ce n'est jamais amusant (un de mes amis fait quelque chose dans ce sens - il veut écrire une simulation à cycle exact de 8088 et pour cette raison, il doit collecter ces statistiques sur les accès à la mémoire et le calendrier motifs. il utilise le jeu de puces d' origine (8288, 8280, 8237) et utilise un analyseur logique avec beaucoup de chaînes, mais de son expérience , je peux vous dire qu'il est un frein).