¿Por qué veo una "muesca" extraña en la línea de datos para algunos 1 lógicos?

Estoy tratando de construir una computadora homebrew Z80 para divertirme en la retrocomputación y aprender las bases del diseño electrónico. Como prueba de concepto, ya he ensamblado un sistema básico en placas de prueba con éxito en las semanas anteriores.

El prototipo actual es extremadamente simple. Utilicé un cristal de 4 MHz impulsado por un oscilador Pierce 74HCT04 como reloj del sistema, dos pestillos 74HCT573 en modo transparente ( LEalto) como búfer para el bus de direcciones de 16 bits, otros dos 74HCT573 en direcciones opuestas controlados por RDy NOT RDcomo datos bidireccionales búfer de bus. I adjunto un 100 ns (se descodifica sólo el 16-KiB) AT28C256 EEPROM y dos 150 ns 8-KiB chips de SRAM al bus del sistema. Utilicé un 74HCT42 para generar la CSseñal y cableé OEla EEPROM a baja, WEa alta, dejando solo una señal CS para controlar la EEPROM.

Todo en las placas de pruebas es ruidoso, pero el sistema parecía estar completamente operativo después de completar todas las etapas. Ahora puede obtener instrucciones de la EEPROM, leer y escribir datos desde / hacia la SRAM, y tiene un puerto serie hecho desde otro pestillo 74HCT573, D0está conectado D0, LEes decir (NOT (IOREQ NAND WR)), la salida sale Q1, en otras palabras, solo un puerto de salida sin lógica de decodificación de dirección. He escrito un programa de referencia de uso intensivo de CPU / RAM y mi computadora puede generar el resultado esperado. Memdumps también mostró que el Z80 puede leer todos los bytes de la EEPROM correctamente, por lo que todo está funcionando.

Pero cuando intenté sondear el D0pin del bus de datos, estaba viendo algunas "muescas" extrañas para algunas salidas lógicas 1 aparentes.

y parece que siempre aparece durante algunos 1 lógicos poco después de que la CSseñal de EEPROM se active, por ejemplo, aquí hay una captura de la muesca extraña superpuesta en la señal azul de EEPROM CS.

Traté de aislar el problema, así que conecté todos los pines CS de la SRAM a ALTA, eliminándolos efectivamente del sistema, y ​​escribí un programa de prueba simple que no tiene acceso a la memoria.

.org 0x00
    di

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

    jp loop

Pero el problema no se ha modificado, extraño "muescas" sigue siempre aparecen para algunos 1s lógicas, justo después MEMRQy / o (ya que es esencialmente un chip ahora) CS(azul) pasa a nivel bajo.

Todos los pines CS de la SRAM son ALTOS, por lo que el sistema es prácticamente solo tiene un chip EE28 de AT28C256 como memoria y un pestillo como puerto de salida. El sistema también tiene un programador en el sistema hecho de un Atmega328p para reprogramar la EEPROM sobre la marcha durante una solicitud de DMA, pero no creo que sea el culpable ya que confié en todos los datos y la salida de direcciones del programador, y He visto muescas incluso antes de agregar el programador.

Por lo tanto, las "muescas" deben crearse durante un ciclo de búsqueda de código de operación. ¿Qué son?

Tengo algunas hipótesis:

1. No hay nada malo, solo es causado por la mala integridad de la señal de las placas de prueba, y desaparecerá automáticamente en una PCB bien diseñada y desacoplada . La placa de pruebas tiene todo tipo de problemas de integridad de la señal: desajustes de impedancia, reflexiones, capacitancia parásita, diafonía, EMI / RFI. Los largos cables del bus que atraviesan los tableros probablemente empeorarán el problema en un grado de magnitud.

   Si es verdad, ¿puedes explicar la naturaleza de las "muescas"? ¿Este fenómeno tiene un nombre en EE? He visto muchos excesos y timbres antes, pero nunca he visto las "muescas". ¿Y por qué lo veo solo para algunos niveles lógicos?

2. Sincronización. ¿Es posible que un corto "tiempo de asentamiento" de la salida EEPROM u otros circuitos lógicos esté causando este efecto extraño en el bus?

3. Desplegarse. ¿Quizás el bus largo consume mucha corriente y tiene una alta capacitancia, por lo que la salida EEPROM estaba teniendo dificultades para conducir el bus alto? ¿Y probablemente la sonda del osciloscopio también está cargando el bus?

4. La contención del bus u otros errores lógicos que causaron que algo tirara del bus de datos. Improbable, creo? Otros componentes en el bus están aislados, y no pude ver cómo una EEPROM AT28C256 o un pestillo pueden hacer esto. Pero supongo que todavía es posible debido a un error de cableado o un corto interno oculto en las placas de pruebas.

Actualización: ya usé condensadores de desacoplamiento y filtrado en el tablero desde el principio. He usado bastantes condensadores de desacoplamiento de 0.1 uF en todas las placas, y la CPU incluso tiene condensadores de 0.1 uF y 0.01 uF para desacoplar. El sistema actual tiene 8 placas, cada placa tiene dos condensadores de aluminio de 4.7 uF en ambos rieles para el filtrado local. Además, la potencia obtenida de la placa de desarrollo tiene un condensador de tantalio de 200 uF. Pero como dije, el problema está aquí.

Sin embargo, no estoy seguro de si es adecuado, especialmente teniendo en cuenta la dificultad de colocar 104 condensadores cerca de los chips en una placa de pruebas. ¿Quizás agregar más puede arreglarlo?

Lo que me interesa es la causa raíz del problema, si se puede confirmar que se trata simplemente de los problemas inherentes de desacoplamiento inadecuado o mala integridad de la señal en el tablero, puedo dejar de intentar perder el tiempo para solucionarlo o preocuparme por ello desde El diseño final sería un PCB. Pero no estoy seguro.

Gracias.

Actualización 2: En mi opinión, ¡creo que el comentario de Bruce Abbott ha dado la respuesta correcta y el problema está resuelto! Aunque no puedo probarlo hasta mañana. El culpable es la actualización DRAM de Z80, vea mi propia respuesta para más detalles. Actualmente, no se necesita una nueva respuesta, y aceptaré mi propia respuesta cuando confirme la solución. Si no funciona, actualizaré la pregunta. Gracias por la ayuda de todos.

Gracias por la ayuda de todos. Creo que Bruce Abbott ha dado la respuesta correcta.Estoy publicando desde mi cama y no puedo probarlo hasta mañana, peroEl análisis a continuación se confirma, cuando mencionó la palabra "actualizar", creo que el problema ya está resuelto. Sabía cómo Z80 refresca la memoria, pero lo olvidé por completo en los días anteriores.

... otros dos 74HCT573 en direcciones opuestas controladas por RD y NO RD como un búfer de bus de datos bidireccional. "- tal vez esto? Proporcione un diagrama de circuito que muestre las señales de control.

Sospecho que es causado por la actualización al final de cada ciclo M1 (búsqueda de código de operación). Necesita ver exactamente cómo está generando CS y habilita el búfer de bus de datos.

- Bruce Abbott

El búfer de datos bidireccional está controlado por RDy NOT RDsi RDestá activo bajo, el búfer dirige los datos a la CPU; de lo contrario, si RDes alto, significa escritura / salida, el búfer controla el bus.

Sin embargo, el Z80 realiza una lectura de memoria para la actualización de DRAM inmediatamente después de la búsqueda del código de operación. Esta vez, RDes HIGHa pesar de que es una operación de lectura, haciendo que la memoria intermedia para voltear su dirección y conducir el autobús, el resultado es un conflicto de bus. Por lo tanto, siempre aparecerían "muescas" extrañas durante el ciclo de actualización de DRAM, pero no lecturas / escrituras de memoria ordinarias o E / S. Esto explica por qué siempre aparece la "muesca", pero solo para algunos, y no todos los 1 lógicos.

Además, SRAM no necesita actualizarse, por lo que la actualización de DRAM es completamente inútil en mi sistema, y ​​esta contención del bus no corrompería ninguna instrucción o dato, haciendo que el sistema parezca ser completamente funcional.

Solución: implementar (RD AND REFRESH)y (NOT (RD AND REFRESH). En la próxima revisión, también debería probar BUSACKpara asegurarme de que el búfer de datos no esté manejando el bus durante una operación DMA también.

Actualización: puedo confirmar el problema y la solución. Usando WRy en su NOT WRlugar solucionó el problema, como se muestra en los nuevos esquemas( ¡no hagas esto! Esto también está mal, consulta la Actualización 2 ).

¡La forma de onda se ve normal ahora!

Actualización 2: Los esquemas anteriores también están rotos, si eres un lector de esta respuesta, ¡no la uses! Si asumir que el bus es WRcuando la RDseñal está inactiva es suficientemente malo, asumir que el bus es RDcuando WRestá inactivo es aún peor. Utilicé el programa anterior para la prueba inicial, por lo que el sistema parecía funcionar, pero falló un problema crítico.

Durante un ciclo de escritura de memoria, la CPU Z80 comenzaría a conducir el bus antes de que WR se active a nivel bajo, en este momento, el búfer de datos todavía estaba conduciendo los datos hacia la CPU, ¡vaya !, creando una contención de bus.

Bruce Abbott tiene razón: es mejor usar siempre RDy WRseñalizar independientemente para controlar cada búfer, en lugar de invertir uno solo.

Por ejemplo,

Funciona perfectamente ahora.

Y finalmente, nuevamente, los esquemas anteriores son una simplificación, también se debe probar BUSACKpara asegurarse de que el búfer de datos no esté impulsando el bus durante una operación DMA.

Asegúrese de tener condensadores de desacoplamiento adecuados en todos sus circuitos integrados. Una cerámica de 100nF de potencia a tierra en cada IC que mantiene sus cables lo más cortos posible y un electrolítico de baja ESR de 100uF en la placa de prueba a través de los rieles de potencia.

Veo dos posibilidades aquí:

1) D0 está tristada

Lo que sea que condujera D0 pasa a tristate (modo de alta impedancia) y luego un pulldown en algún lugar de la red D0 baja el voltaje lentamente (constante de tiempo definida por la resistencia de pull-down y las capacitancias parásitas de circuitos integrados y trazas). La naturaleza exponencial de la forma de onda es una fuerte indicación de que la línea no está siendo impulsada por algo fuerte, sino por un pull-down relativamente débil.

Intente agregar otra resistencia desplegable a la línea y verifique si la forma de onda exponencial llega a cero más rápido.

Tenga en cuenta que esto no es necesariamente un problema y su autobús puede funcionar perfectamente bien con esto.

2) contención

Tu hipótesis # 4. También es posible que D0 esté en corto a otra línea lógica. Creo que esto es poco probable, ya que en este caso no vería una forma de onda exponencial con una constante de tiempo relativamente larga como lo ve ahora. Puede sondear otras redes en su circuito en busca de otra forma de onda idéntica, lo que indica que tiene un corto.

¡Buena suerte!

PD: este no es un problema de integridad de la señal, el ancho de pulso es demasiado largo para eso