Pourquoi est-ce que je vois une étrange «encoche» sur la ligne de données pour certains 1 logiques?

J'essaie de construire un ordinateur homebrew Z80 pour le plaisir de la rétro-informatique et de m'enseigner les bases de la conception électronique. Pour preuve de concept, j'ai déjà assemblé avec succès un système de base sur des planches à pain au cours des semaines précédentes.

Le prototype actuel est extrêmement simple. J'ai utilisé un cristal de 4 MHz piloté par un oscillateur Pierce 74HCT04 comme horloge système, deux verrous 74HCT573 en mode transparent ( LEhaut) comme tampon pour le bus d'adresse 16 bits, deux autres 74HCT573 dans des directions opposées contrôlées par RDet NOT RDcomme données bidirectionnelles tampon de bus. J'ai attaché une EEPROM AT28C256 de 100 ns (seulement 16 Ko est décodée) et deux puces SRAM de 8 kiB de 150 ns au bus système. J'ai utilisé un 74HCT42 pour générer le CSsignal et câblé le OEde l'EEPROM à bas, WEà haut, ne laissant qu'un seul signal CS pour contrôler l'EEPROM.

Tout sur les platines est bruyant, mais le système semblait être pleinement opérationnel après avoir terminé toutes les étapes. Maintenant, il peut récupérer des instructions de l'EEPROM, lire et écrire des données de / vers la SRAM, et il a un port série fabriqué à partir d'un autre verrou 74HCT573, D0est connecté à D0, LEest (NOT (IOREQ NAND WR)), la sortie sort Q1, en d'autres termes, un seul port de sortie sans logique de décodage d'adresse. J'ai écrit un programme de test intensif CPU / RAM et mon ordinateur peut produire le résultat attendu. Memdumps a également montré que le Z80 peut lire correctement tous les octets de l'EEPROM, donc tout fonctionne.

Mais quand j'ai essayé de sonder la D0broche du bus de données, je voyais d'étranges "encoches" pour certaines sorties logiques 1 apparentes.

et ils semblent toujours apparaître pour certains 1 logiques peu de temps après l' CSactivation du signal de l'EEPROM, par exemple, voici une capture de l'encoche étrange superposée au signal bleu de l'EEPROM CS.

J'ai essayé d'isoler le problème, j'ai donc câblé toutes les broches CS de la SRAM à HIGH, les supprimant efficacement du système, et j'ai écrit un programme de test simple qui n'a pas d'accès à la mémoire.

.org 0x00
    di

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

    jp loop

Mais le problème est inchangé, des "encoches" étranges apparaissent toujours pour certains 1 logiques, juste après MEMRQet / ou (puisqu'il s'agit essentiellement d'une seule puce maintenant) CS(bleu) devient faible.

Toutes les broches CS de la SRAM sont ÉLEVÉES, donc le système a à peu près seulement une puce EEPROM AT28C256 comme mémoire et un verrou comme port de sortie. Le système dispose également d'un programmateur intégré à un Atmega328p pour reprogrammer l'EEPROM à la volée lors d'une demande DMA, mais je ne pense pas que ce soit le coupable puisque j'ai tristé toutes les données et la sortie d'adresse du programmeur, et J'ai vu des encoches avant même d'ajouter le programmeur.

Les "encoches" doivent donc être créées pendant un cycle de récupération d'opcode. Que sont-ils?

J'ai quelques hypothèses:

1. Il n'y a rien de mal, c'est juste causé par la mauvaise intégrité du signal des platines d'essais, et il disparaîtra automatiquement dans un PCB bien conçu et bien découplé . La maquette a toutes sortes de problèmes d'intégrité du signal: asymétries d'impédance, réflexions, capacité parasite, diaphonie, EMI / RFI. Les longs fils de bus qui traversent les cartes aggravent probablement le problème d'un certain degré.

   Si c'est vrai, pouvez-vous expliquer la nature des "encoches"? Ce phénomène a-t-il un nom en EE? J'ai déjà vu de nombreux dépassements et sonneries, mais je n'ai jamais vu les "crans". Et pourquoi je ne le vois que pour certains niveaux logiques?

2. Horaire. Est-il possible qu'un court "temps de stabilisation" de la sortie EEPROM ou d'autres circuits logiques provoque cet effet étrange sur le bus?

3. Fan-out. Peut-être que le long bus consomme beaucoup de courant et a une capacité élevée, de sorte que la sortie EEPROM a eu du mal à conduire le bus haut? Et probablement la sonde de l'oscilloscope charge également le bus?

4. Conflit de bus ou autres erreurs logiques qui ont provoqué un problème de traction du bus de données. Peu probable, je pense? Les autres composants du bus sont isolés et je n'ai pas pu voir comment une seule EEPROM AT28C256 ou un verrou peut faire cela. Mais je suppose que c'est toujours possible en raison d'une erreur de câblage ou d'un court-circuit interne caché dans les platines.

Mise à jour: J'ai déjà utilisé des condensateurs de découplage et de filtrage sur la carte depuis le début. J'ai utilisé pas mal de condensateurs de découplage de 0,1 uF à travers les cartes, et le CPU a même des condensateurs de 0,1 uF et 0,01 uF pour le découplage. Le système actuel a 8 cartes, chaque planche à pain a deux condensateurs en aluminium de 4,7 uF sur les deux rails pour le filtrage local. De plus, la puissance obtenue du devboard a un condensateur au tantale de 200 uF. Mais comme je l'ai dit, le problème est là.

Je ne sais pas si c'est suffisant cependant, surtout compte tenu de la difficulté de placer 104 condensateurs près des puces sur une planche à pain. Peut-être que l'ajout de plus peut le réparer?

Ce qui m'intéresse, c'est la cause profonde du problème, s'il peut être confirmé qu'il s'agit simplement de problèmes inhérents de découplage inadéquat ou d'une mauvaise intégrité du signal sur la maquette, je peux arrêter de perdre du temps à dépanner ou à m'inquiéter depuis le la conception finale serait un PCB. Mais je ne suis pas sur.

Merci.

Update2: Dans mon esprit, je crois que le commentaire de Bruce Abbott a donné la bonne réponse et le problème est résolu! Bien que je ne puisse pas le tester avant demain. Le coupable est le rafraîchissement de la DRAM du Z80, voir ma propre réponse pour plus de détails. Actuellement, aucune nouvelle réponse n'est nécessaire et j'accepterai ma propre réponse lorsque j'aurai confirmé la solution. Si cela ne fonctionne pas, je mettrai à jour la question. Merci pour l'aide de tout le monde.

Merci pour l'aide de tout le monde. Je crois que Bruce Abbott a donné la bonne réponse.Je poste depuis mon lit et je ne peux pas encore le tester avant demain, maisL'analyse ci-dessous est confirmée, quand il a mentionné le mot "rafraîchir", je pense que le problème est déjà résolu. Je savais comment le Z80 rafraîchit la mémoire, mais je l'ai complètement oublié les jours précédents.

... deux autres 74HCT573 dans des directions opposées contrôlées par RD et NON RD comme tampon de bus de données bidirectionnel. "- peut-être cela? Veuillez fournir un schéma de circuit montrant les signaux de commande.

Je soupçonne qu'elle est causée par le rafraîchissement à la fin de chaque cycle M1 (extraction de code d'opération). Besoin de voir exactement comment vous générez le CS et le tampon de bus de données.

- Bruce Abbott

Le tampon de données bidirectionnel est contrôlé par RDet NOT RDs'il RDest actif bas, le tampon conduit les données vers le CPU, sinon, s'il RDest élevé, cela signifie écriture / sortie, le tampon pilote le bus.

Néanmoins, le Z80 effectue une lecture de la mémoire pour l'actualisation de la DRAM immédiatement après la récupération de l'opcode. Cette fois -ci , RDest HIGHmalgré c'est une opération de lecture, ce qui provoque le tampon de retourner sa direction et conduire le bus, le résultat est un conflit de bus. Ainsi, des "encoches" étranges apparaissent toujours pendant le cycle de rafraîchissement de la DRAM, mais pas les lectures / écritures de mémoire ordinaires ni les E / S. Ceci explique pourquoi le "notch" apparaîtrait toujours, mais seulement pour certains, et pas tous les 1 logiques.

En outre, SRAM n'a pas besoin d'être actualisé, de sorte que l'actualisation DRAM est complètement inutile dans mon système, et cette contention de bus ne corromprait aucune instruction ou donnée, ce qui rend le système semble être pleinement fonctionnel.

Solution: implémenter (RD AND REFRESH)et (NOT (RD AND REFRESH). Dans la prochaine révision, je devrais également tester BUSACKpour m'assurer que le tampon de données ne pilote pas également le bus pendant une opération DMA.

Mise à jour: je peux confirmer le problème et la solution. Utilisation WRet NOT WRcorrection du problème à la place, comme indiqué dans les nouveaux schémas( ne faites pas ça! C'est faux aussi, voir la mise à jour 2 ).

La forme d'onde semble normale maintenant!

Update2: Le schéma ci-dessus est également cassé, si vous êtes un lecteur de cette réponse, ne l'utilisez pas! Si supposer que le bus est WRlorsque le RDsignal est inactif est suffisamment mauvais, supposer que le bus est RDlorsqu'il WRest inactif est encore pire. J'ai utilisé le programme précédent pour les tests initiaux, donc le système semble fonctionner, mais il a manqué un problème critique.

Pendant un cycle d'écriture en mémoire, le CPU Z80 commencerait à piloter le bus avant de WR devenir actif bas, à ce moment, le tampon de données conduisait toujours les données vers le CPU, oups, créant un conflit de bus.

Bruce Abbott a raison: il vaut mieux toujours utiliser RDet WRsignaler indépendamment pour contrôler chaque tampon, au lieu d'en inverser un seul.

Par exemple,

Cela fonctionne parfaitement maintenant.

Et enfin, encore une fois, les schémas ci-dessus sont une simplification, il faut également tester BUSACKpour s'assurer que le tampon de données ne pilote pas le bus également pendant une opération DMA.

Assurez-vous que vous disposez de condensateurs de découplage adéquats sur tous vos circuits intégrés. Une céramique 100nF de la puissance à la terre sur chaque circuit intégré gardant ses fils aussi courts que possible et un électrolytique à faible ESR, disons 100uF sur la planche à pain à travers les rails d'alimentation.

Je vois ici deux possibilités:

1) D0 est tristate

Tout ce qui conduisait D0 passe à l'état tristate (mode haute impédance), puis un pull-down quelque part dans le réseau D0 abaisse lentement la tension (constante de temps définie par la résistance de pull-down et les capacités parasites des circuits intégrés et des traces). La nature exponentielle de la forme d'onde est une forte indication que la ligne n'est pas entraînée par quelque chose de fort, mais plutôt par un pull-down relativement faible.

Essayez d'ajouter une autre résistance de rappel à la ligne et vérifiez si la forme d'onde exponentielle se met à zéro plus rapidement.

Gardez à l'esprit que ce n'est pas nécessairement un problème et que votre bus peut parfaitement fonctionner avec cela.

2) Contention

Votre hypothèse # 4. Il est également possible que D0 soit court-circuité sur une autre ligne logique. Je trouve cela peu probable, car dans ce cas, vous ne verriez pas une forme d'onde exponentielle avec une constante de temps relativement longue comme vous le voyez maintenant. Vous pouvez sonder d'autres réseaux dans votre circuit à la recherche d'une autre forme d'onde identique, indiquant que vous avez un court-circuit.

Bonne chance!

PS - ce n'est pas un problème d'intégrité du signal, la largeur d'impulsion est beaucoup trop longue pour cela