Mientras busco el resto de componentes que me faltan para montar la placa, he tomado otro camino para poder echar una mano en los fallos que puedan aparecer, y es coger y meter todo el circuito como.... sí, ¡una descripción en Verilog!
Gracias a eso puedo poner "sondas" de analizador lógico donde quiera, y ver cualquier señal cómodamente. Así, me he encontrado con esto:
- glitch_hc.png (6.17 KiB) Visto 6878 veces
HC es el contador horizontal, de 0 a 447. Se incrementa en 1 cada 142ns aproximadamente. Puede observarse que las transiciones de una cuenta a la siguiente no son limpias, sino que hay pequeños glitches, siendo el más acusado el que ocurre cuando la cuenta pasa de 255 a 256. Una ampliación pone de manifiesto qué ocurre realmente con los valores de HC durante esa transición:
- glitch_hc_ampliado.png (8.77 KiB) Visto 6878 veces
NOTA: Para ver esto en el circuito real, con un analizador lógico "de verdad" pinchado en el circuito, dicho analizador tendría que ser suficientemente rápido como para tomar muestras en la mitad del período de la señal que cambia más rapidamente, en este caso, ese periodo es de 8ns, lo que significa que el analizador debe ser capaz de capturar a 250MHz.
Estos glitches ocurren porque en este diseño se ha cambiado el contador original formado por 3 chips 74HC161 por un único 74HC4040. Lo malo del 4040 es que es un contador asíncrono (ripple counter), es decir, un contador en cascada. Los 74HC161 formaban entre los tres un contador síncrono.
Los contadores en cascada tienen el grave inconveniente de que las salidas del contador no se actualizan a la vez, sino que hay retrasos, y estos retrasos son más largos cuanto más significativo sea el bit a actualizar.
NOTA2: De hecho, en la ULA original el contador horizontal está formado por una mezcla de contadores síncronos y asíncronos. Según cuenta Chris Smith, el diseño original contemplaba un contador horizontal síncrono, pero al no haber celdas suficientes para implementar el "look ahead carry" que se requiere para estos contadores, parte del mismo tuvo que diseñarse en forma asíncrona, y eso origina que en pantalla, en determinados casos es posible ver una especie de sombra al lado de un carácter, consecuencia de un glitch en este contador.
Así, en la hoja de datos del 4040 dice que desde que hay un flanco de reloj hasta que se actualiza el bit menos significativo (que en nuestro caso sería HCa) pasan 16ns. El retraso de un bit respecto del anterior es de 8ns. Esto significa que HC0 se actualiza 24ns después del flanco de reloj, HC1 después de 32ns, y así hasta llegar a HC8 (el último bit usado en este contador), que se actualiza al cabo de 88ns.
Estos son datos suponiendo que la temperatura de trabajo sea de 25 grados, y la capacidad (en picofaradios) de los circuitos a los que se conecten las salidas del contador sea de 15pF. Una carga CMOS tiene unos 3,5pF de capacidad asociada, con lo que si una salida se conecta a más de 15/3.5=4 circuitos, la capacidad vista por esa salida será mayor. Cuanto mayor sea la temperatura o la capacidad, más lentas serán las transiciones.
Según cuál sea el valor actual en el contador, y cuál sea el siguiente, estos retrasos generarán valores falsos esporádicos (glitches) entre dos valores correctos. El caso más exagerado sería el paso del valor 255 al 256, ya que en binario esto significa pasar de 011111111 a 100000000. Con lo que acabo de decir, la secuencia sería así:
Partimos de 011111111 (255)
Ocurre un flanco de reloj. Al cabo de 24ns, se propaga el cambio al bit HC0: 011111110 (254)
Al cabo de 32ns, 011111100 (252)
Al cabo de 40ns, 011111000 (248)
Al cabo de 48ns, 011110000 (240)
Al cabo de 56ns, 011100000 (224)
Al cabo de 64ns, 011000000 (192)
Al cabo de 72ns, 010000000 (128)
Al cabo de 80ns, 000000000 (0)
Al cabo de 88ns, 100000000 (256)
Que son ni más ni menos que los valores que se ven en la versión ampliada del glitch.
En el primer cronograma se ve que en condiciones normales (transición limpia de una cuenta a la siguiente, por ejemplo al pasar de 256 a 257), para cuando la señal HCa (el reloj de 7MHz que se usa como reloj para otras partes del circuito) tiene un flanco positivo, el valor del contador es estable y conocido, pero un poco antes, cuando hemos pasado de 255 a 256, el valor del contador aún no es estable, y eso.... sólo puede acarrear problemas.
Aún no he escrito el circuito completo, pero me sospecho que por ejemplo, la parte que genera el valor para OutLatch y Vout puede verse afectada, ya que se emplean varios bits del contador horizontal, entre ellos HC8 que es el que más lento progresa. Este circuito genera dos señales bastante importantes: OutLatch y VOut. Ambas se usan como cerrojos para permitir el paso de los valores de bitmap y atributos desde la memoria al primer registro, y del primer registro al segundo (imaginaos una esclusa con dos compuertas, y mientras un barco pasa del primer al segundo compartimento, otro barco entra desde el exterior al primer compartimento). Si el baile de señales OutLatch y VOut no se realiza de forma sincrónica, puedes encontrarte con que el dato recién ingresado en memoria (controlado por VOut) machaca al que estaba a punto de marchar al siguiente registro, pero que no ha podido porque OutLatch aún no ha cambiado.
- generador_outlatch.png (28.68 KiB) Visto 6878 veces
Quizás merezca la pena hacer lo siguiente: enfriar todo lo posible a U39. Cuanto más frío esté, menor será el tiempo de propagación de las señales en su interior y por tanto, menores los retrasos. Si al enfriarlo, el retraso disminuye y realmente ese retraso estaba fastidiando la señal de video, deberá verse cada vez menos "basura" en pantalla, hasta ver muy poca o ninguna. El efecto es similar al que me encontré hace ya tiempo, con la ULA original, y que también se arreglaba enfriando a la ULA (aunque en aquel caso, y dadas las temperatura habituales de la ULA de Ferranti, para enfriarla bastaba usar el dedo como disipador):
http://www.zxprojects.com/index.php/sim ... la-cooling En este caso quizás haya que recurrir a un trozo de hielo envuelto herméticamente (para que no gotee) en papel de aluminio o algo por el estilo y ponerlo encima de U39.
Con todo, yo recomendaría volver a la configuración de contador completamente síncrono. No sé si habrá alguno de 9 bits o más (9 es lo que necesitamos). Hay más 4040 repartidos por el circuito, pero es que los demás no tienen un reloj tan rápido como U39, así que aun cuando también en ellos se producen los mismos glitches que en U39, la lentitud de las transicione de reloj hace que este efecto tenga menores consecuencias. Es más: si U40 fuera un contador síncrono, seguramente la señal VCrst actuaría antes de la cuenta y en lugar de contar hasta 312 (en PAL) contaría hasta 255 (como de hecho pasó en mi simulación al principio, cuando modelé U39 y U40 como contadores síncronos sin retardos)
