Por que estou vendo um “entalhe” estranho na linha de dados para alguns 1s lógicos?

Estou tentando construir um computador homebrew Z80 para me divertir com a retrocomputação e me ensinar as bases do design eletrônico. Para prova de conceito, eu já montei um sistema básico em placas de ensaio com sucesso nas semanas anteriores.

O protótipo atual é extremamente simples. Usei um cristal de 4 MHz acionado por um oscilador 74HCT04 Pierce como relógio do sistema, duas travas 74HCT573 em modo transparente ( LEalto) como buffer para o barramento de endereço de 16 bits, outras duas 74HCT573 em direções opostas controladas por RDe NOT RDcomo dados bidirecionais buffer de barramento. I anexa um 100 ns AT28C256 EEPROM (apenas 16-KiB é descodificados) e duas de 150 ns 8-KiB pastilhas SRAM para o enlace comum do sistema. Usei um 74HCT42 para gerar o CSsinal e liguei OEo EEPROM de baixo WEa alto, deixando apenas um sinal CS para controlar o EEPROM.

Tudo nas tábuas de pão é barulhento, mas o sistema parecia estar totalmente operacional depois que eu concluí todas as etapas. Agora ele pode buscar instruções da EEPROM, ler e gravar dados de / para a SRAM, e possui uma porta serial feita com outra trava 74HCT573, D0está conectada a D0, ou LEseja (NOT (IOREQ NAND WR)), a saída sai de Q1, em outras palavras, apenas uma porta de saída sem lógica de decodificação de endereço. Eu escrevi um programa de benchmark com uso intenso de CPU / RAM e meu computador pode gerar o resultado esperado. Memdumps também mostraram que o Z80 pode ler todos os bytes da EEPROM corretamente, para que tudo esteja funcionando.

Mas quando tentei verificar o D0pino do barramento de dados, estava vendo alguns "entalhes" estranhos para algumas saídas lógicas 1 aparentes.

e eles parecem sempre aparecer para alguns 1s lógicos logo após o CSsinal da EEPROM ficar ativo, por exemplo, aqui está uma captura do entalhe estranho sobreposto ao sinal azul da EEPROM CS.

Tentei isolar o problema, por isso conectei todos os pinos CS da SRAM a HIGH, removendo-os efetivamente do sistema e escrevi um programa de teste simples que não tem acesso à memória.

.org 0x00
    di

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

    jp loop

Mas o problema é inalterado, "entalhes" estranhos ainda sempre aparecem para alguns 1s lógicos, logo após MEMRQe / ou (já que é essencialmente um chip agora) CS(azul) fica baixo.

Todos os pinos CS da SRAM são ALTOS, portanto, o sistema possui praticamente apenas um chip AT28C256 EEPROM como memória e uma trava como porta de saída. O sistema também possui um programador no sistema feito de um Atmega328p para reprogramar a EEPROM on-the-fly durante uma solicitação de DMA, mas não acho que seja o culpado, pois tristi todos os dados e endereço do programador e Eu já vi marcas antes mesmo de adicionar o programador.

Portanto, os "entalhes" devem ser criados durante um ciclo de busca do código de operação. O que eles são?

Eu tenho algumas hipóteses:

1. Não há nada errado, é apenas causado pela integridade do sinal ruim das placas de pão e ele desaparecerá automaticamente em uma PCB bem projetada e dissociada . A placa de ensaio apresenta todos os tipos de problemas de integridade do sinal: incompatibilidades de impedância, reflexões, capacitância parasita, diafonia, EMI / RFI. Os longos fios de barramento que atravessam as placas provavelmente pioram o problema em um grau de magnitude.

   Se for verdade, você pode explicar a natureza dos "entalhes"? Esse fenômeno tem um nome em EE? Eu já vi muitas ultrapassagens e toques antes, mas nunca vi os "entalhes". E por que eu estou vendo isso apenas para alguns níveis lógicos?

2. Cronometragem. É possível que um curto "tempo de acomodação" da saída EEPROM ou de outros circuitos lógicos esteja causando esse efeito estranho no barramento?

3. Espalham. Talvez o barramento longo consiga muita corrente e tenha alta capacitância, de modo que a saída da EEPROM estava tendo dificuldades para dirigir alto o barramento? E provavelmente a sonda do osciloscópio também está carregando o barramento?

4. Contenção de barramento ou outros erros lógicos que fizeram com que algo puxasse o barramento de dados. Improvável eu acho? Outros componentes no barramento estão isolados e não consegui ver como uma única EEPROM AT28C256 ou uma trava pode fazer isso. Mas acho que ainda é possível devido a um erro de fiação ou um curto interno oculto nas tábuas de pão.

Atualização: Eu já usei capacitores de desacoplamento e filtragem na placa desde o início. Eu usei alguns capacitores de desacoplamento de 0,1 uF nas placas, e a CPU possui até capacitores de 0,1 uF e 0,01 uF para desacoplamento. O sistema atual possui 8 placas, cada placa de ensaio possui dois capacitores de alumínio de 4,7 uF nos dois trilhos para filtragem local. Além disso, a energia obtida da placa de programação possui um capacitor de tântalo de 200 uF. Mas como eu disse, o problema está aqui.

Não tenho certeza se é adequado, especialmente considerando a dificuldade de colocar 104 capacitores perto dos chips em uma placa de ensaio. Talvez adicionar mais possa corrigi-lo?

O que me interessa é a causa raiz do problema. Se for possível confirmar que são simplesmente os problemas inerentes à dissociação inadequada ou à integridade do sinal ruim na placa de ensaio, posso parar de tentar perder tempo para solucionar problemas ou me preocupar com isso, pois o design final seria um PCB. Mas eu não tenho certeza.

Obrigado.

Update2: Na minha opinião, acredito que o comentário de Bruce Abbott deu a resposta correta e o problema foi resolvido! Embora eu não possa testá-lo até amanhã. O culpado é a atualização DRAM do Z80, veja minha própria resposta para obter detalhes. Atualmente, nenhuma nova resposta é necessária, e eu aceitarei minha própria resposta quando confirmar a solução. Se não der certo, atualizarei a pergunta. Obrigado pela ajuda de todos.

Obrigado pela ajuda de todos. Acredito que Bruce Abbott deu a resposta correta.Estou postando da minha cama e ainda não posso testá-lo até amanhã, masA análise abaixo é confirmada, quando ele mencionou a palavra "atualizar", acho que o problema já está resolvido. Eu sabia como o Z80 atualiza a memória, mas esqueci completamente dela nos dias anteriores.

... outros dois 74HCT573 em direções opostas controladas por RD e NOT RD como um buffer de barramento de dados bidirecional. "- talvez isso? Por favor, forneça um diagrama de circuito mostrando os sinais de controle.

Suspeito que seja causado pela atualização no final de cada ciclo M1 (busca do código de operação). Precisa ver exatamente como você está gerando o CS e o buffer do barramento de dados.

- Bruce Abbott

O buffer de dados bidirecional é controlado RDe, NOT RDse RDestiver ativo baixo, o buffer direciona os dados para a CPU; caso contrário, se RDestiver alto, significa gravação / saída, o buffer aciona o barramento.

No entanto, o Z80 executa uma leitura de memória para atualização de DRAM imediatamente após a busca do opcode. Desta vez, RDé HIGHapesar de que é uma operação de leitura, fazendo com que o tampão para inverter a sua direcção e dirigir o ônibus, o resultado é uma contenção de barramento. Tão estranhos "entalhes" sempre apareciam durante o ciclo de atualização da DRAM, mas não as leituras / gravações comuns de memória ou E / S. Isso explica por que o "entalhe" sempre aparece, mas apenas para alguns e nem todos os 1s lógicos.

Além disso, a SRAM não precisa ser atualizada, portanto a atualização DRAM é completamente inútil no meu sistema, e essa contenção de barramento não corromperá nenhuma instrução ou dado, fazendo com que o sistema pareça estar totalmente funcional.

Solução: implementar (RD AND REFRESH)e (NOT (RD AND REFRESH). Na próxima revisão, também devo testar BUSACKpara garantir que o buffer de dados não esteja dirigindo o barramento também durante uma operação de DMA.

Atualização: posso confirmar o problema e a solução. Usando WRe NOT WRcorrigindo o problema, conforme mostrado nos novos esquemas ( não faça isso! Isso também está errado, consulte a Atualização 2 ).

A forma de onda parece normal agora!

Update2: Os esquemas acima também estão corrompidos; se você é um leitor desta resposta, não a use! Se assumindo que o ônibus estáWR quando o RDsinal está inativo é ruim o suficiente, assumir que o barramento está RDquando WRestá inativo é ainda pior. Eu usei o programa anterior para os testes iniciais, para que o sistema parecesse funcionar, mas faltou um problema crítico.

Durante um ciclo de gravação de memória, a CPU do Z80 começaria a dirigir o barramento antes de WR ficar baixa, nesse momento, o buffer de dados ainda estava direcionando os dados para a CPU, oops, criando uma contenção de barramento.

Bruce Abbott está correto: é melhor usar sempre RD e WRsinalizar independentemente para controlar cada buffer, em vez de inverter um único.

Por exemplo,

Funciona perfeitamente agora.

E, finalmente, novamente, os esquemas acima são uma simplificação, é preciso testar também BUSACKpara garantir que o buffer de dados não esteja dirigindo o barramento também durante uma operação de DMA.

Verifique se você possui capacitores de desacoplamento adequados em todos os seus CIs. Uma cerâmica de 100nF da potência ao terra em cada IC, mantendo suas derivações o mais curtas possível, e um eletrolítico de baixo ESR diz 100uF na placa de ensaio, através dos trilhos de força.

Eu vejo duas possibilidades aqui:

1) D0 é tristado

O que quer que esteja dirigindo D0 passa a tristate (modo de alta impedância) e, em seguida, um pull-down em algum lugar na rede D0 diminui a tensão lentamente (constante de tempo definida pela resistência ao pull-down e pelas capacitâncias parasitas dos CIs e traços). A natureza exponencial da forma de onda é uma forte indicação de que a linha não está sendo movida por algo forte, mas sim por um pull-down relativamente fraco.

Tente adicionar outro resistor pull-down à linha e verifique se a forma de onda exponencial chega a zero mais rapidamente.

Lembre-se de que isso não é necessariamente um problema e seu ônibus pode funcionar perfeitamente bem com isso.

2) Contenção

Sua hipótese # 4. Também é possível que D0 esteja em curto para outra linha lógica. Acho isso improvável, pois nesse caso você não veria uma forma de onda exponencial com um tempo relativamente longo constante como você vê agora. Você pode pesquisar outras redes em seu circuito em busca de outra forma de onda idêntica, indicando que você tem um curto.

Boa sorte!

PS - este não é um problema de integridade do sinal, a largura do pulso é muito longa para esse