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

15

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.

Un exemple d'encoches étranges à J0

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.

Une étrange encoche superposée au signal 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.

Un autre exemple de "crans"

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.

比尔 盖子
la source
Je viens de voir votre montage. Je crois que ce serait idéal si vous regardez les spécifications et les notes de conception / applications pour vos pièces que vous utilisez. Il pourrait y avoir des composants qui vous manquent autres que des condensateurs de découplage pour votre appareil. Êtes-vous certain d'avoir suivi toutes les spécifications? C'est un bon exercice de cause profonde. Pour l'instant, votre question est sans réponse sans schéma de circuit.
KingDuken
6
Une façon d'aider à séparer les problèmes EMI / alimentation des problèmes d'horloge / logique consiste à essayer d'utiliser une horloge à fréquence plus lente, par exemple 0,5 MHz ou 1 MHz. Si le problème étrange passe de 250ns à 1us, il est basé sur le fonctionnement du processeur. S'il reste environ 250 ns, il peut s'agir d'un problème EMI / alimentation. Avez-vous des résistances pull-up / down sur le bus (pourrait-il s'agir d'une réponse à trois états)?
W5VO
1
Jetez un œil et voyez si la fiche technique du processeur recommande / suggère des résistances de pull-up ou pull-down sur le bus de données. Cela aiderait à réduire les risques de pépins dus au fonctionnement à trois états. Si vous avez ajouté une autre instruction "inc a" à votre programme, vous pourriez probablement déterminer quelle instruction était à l'origine du problème.
W5VO
1
"... 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 ça? Veuillez fournir un schéma de circuit montrant les signaux de commande.
Bruce Abbott
5
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

Réponses:

13

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.

tampon de données bidirectionnel

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.

Diagramme temporel de récupération de l'opcode Z80

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

Nouveaux schémas (faux)

La forme d'onde semble normale maintenant!

Nouvelle forme d'onde, montrant que le problème est corrigé.

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.

Diagramme de temps de lecture / écriture de la mémoire Z80

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,

Nouveaux schémas (fixes, mais DMA n'est pas géré, vous devez gérer cela.

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.

比尔 盖子
la source
6
Vous pourriez envisager d'utiliser / WR au lieu de / RD inversé pour activer le tampon supérieur. De cette façon, le bus de données sera inactif à moins qu'une lecture ou une écriture réelle ne soit en cours.
Bruce Abbott
8

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.

RoyC
la source
Semble être la solution à beaucoup d'instabilité pour les circuits intégrés numériques :)
KingDuken
4
@KingDuken Absolument et un peu un sujet brûlant pour moi, un de mes amis a été viré une fois pour en avoir manqué un. Causé beaucoup d'instabilité dans une machine de traitement de l'argent, whoops.
RoyC
2
Le découplage est important, mais ce n'est pas la réponse à tout. Il devrait être évident à partir de la forme d'onde qu'il est peu probable qu'elle soit pertinente ici.
pericynthion
4

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

joribama
la source