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

9

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.

chronogramme

(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.

Anthony
la source
1
Quel processeur votre ordinateur rétro va utiliser?
Anonyme
6502, la mémoire sera mise en banque évidemment.
Anthony
Est-il possible de ne pas inventer le vélo pour vous, existe-t-il déjà des conceptions disponibles utilisant des DRAM? Je ne connais pas cette famille de machines, mais C64 doit être un bon match. Cependant, il utilise à l'origine la puce 6567 "VIC" pour contrôler la RAM. Mais encore une fois, je suis sûr que depuis lors, il y avait des projets liés à ce que vous vouliez faire.
Anonyme le
3
Une suggestion légèrement déformée: le Z80 avait suffisamment de contrôleur DRAM intégré pour gérer la logique de rafraîchissement. (Vous aviez encore besoin d'un multiplexeur d'adresses)
Brian Drummond
3
@BrianDrummond S'il vous plaît, ne recommandez pas d'aller du côté obscur. Rien de bon ne peut en sortir.
pipe

Réponses:

6

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.

David Moews
la source
Apparemment, je n'avais trouvé qu'un XT TR sans l'annexe D hier. Je l'ai maintenant, c'est super. Je ne savais pas que ces circuits intégrés de ligne à retard existaient et je me demandais comment ils géraient la température. Merci d'avoir mentionné l'exemple moderne. +1 pour plusieurs solutions également.
Anthony
5

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.

Page de référence PET 2001-N 6

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.

tuyau
la source
C'est à cela que je pensais, mais j'étais assez stupide pour réfléchir à plusieurs verrous au lieu d'un MUX ou deux. L'horloge 16Mhz me fait mal parce que a) elle est beaucoup plus élevée que l'horloge CPU que je viens de trouver bizarre mais elle a du sens et b) Les phases peuvent être au minimum de ~ 62 ns plus les délais de propagation que je pensais lent mais maintenant je voir c'est dans le même ordre que l'IBM PC / XT.
Anthony
L'Apple II est très similaire, utilisant l'horloge vidéo 14,318 MHz pour chronométrer et partager la mémoire entre le processeur et la vidéo sur des demi-cycles alternatifs sans contention. Il n'a même pas besoin d'un compteur de rafraîchissement séparé, car l'activité de rafraîchissement vidéo sert également à garder la mémoire rafraîchie.
Dave Tweed
-2

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).
anrieff
la source
2
Je ne sais pas comment c'est une réponse au lieu d'un commentaire. 1) Il ne dit pas qu'il veut apprendre les FPGA. 2) Les DRAM des années 80 sont déjà suffisamment lentes pour une logique discrète. 3) Le débogage peut être difficile. Pourquoi ne pas tout implémenter dans le FPGA, ou même simplement dans le logiciel? Pourquoi même utiliser la RAM du tout ... :)
pipe
1
@pipes: Oui, exactement. Je ne veux pas passer de temps à apprendre les FPGA pour le moment. J'en ai déjà assez dans mon assiette avec un deuxième projet analogique sans rapport. Les FPGA et les PLD en général ont l'impression de se mettre en travers du chemin à ce stade, même si un jour j'apprendrai à les utiliser.
Anthony
1
@pipe: Le recâblage des cartes est souvent difficile, long et frustrant, surtout si l'on n'est pas particulièrement compétent. L'utilisation de PLD assez simples (par exemple 22V10) pour certaines parties de la conception, il sera plus facile de modifier les choses.
supercat