DESCUBRIENDO LA PAL16R4 (II)
Jugar, a su favor, con los tiempos de propagación de las puertas.
Desde que una combinación de entradas hace que una salida cambie, pasa un determinado tiempo. Este
tiempo se conoce como tiempo de propagación. En ciertos diseños hay que tener en cuenta estos tiempos porque
puede hacer que un diseño que debería funcionar no lo haga.
Observemos esta capturación del analizador lógico con la PAL16R4-20 original:
Este es el instante en que las salidas rf17-rf14 pasan del estado 1111 a 1011 y
finalmente a 1010.Veamos que sucede exactamente:
Previo al punto 1 se ve que o19 sube momentáneamente a 1.
En el punto 2, rf16 pasa a 0.
En el punto 3, rf14 pasa a 0.
Observemos ahora esta capturación del analizador lógico con una Lattice GAL16V8-12:
Aunque parecidas, hay un par de diferencias que hacían que el CPC se colgase con el diseño hecho en la
GAL16V8.
En el punto 1, o19 es más pequeño y no impide que rf16 pase a 0. Nos hemos comido un ciclo de reloj
En el punto 2, rf14 pasa a 0.
En el punto 3, se dan las condiciones para pasar al estado 0010 cuando no debería hacerlo. Aquí ocurre
que el botón stop sigue pulsado y saltamos al estado 1110.
Porque sube o19.
Si ampliamos la capturación del analizador entenderemos que pasa:
Las ecuaciones que había conseguido sacar en ese momento era la siguiente:
/o19 = i3 * i4 * /i6 * /i7 * rf15
+ /i2 * /i3 * /i6 * /i7 * i8 * /o12 * rf17 * /rf15
+ /i6 * /i7 * /o12 * rf15
Cuando i3 pasa a "0", tenemos que la ecuación de /o19 = i3 * i4 * /i6 * /i7 * rf15 ya no
se cumple y o19 debería pasa a "1". Esto debería ocurrir aprox. 20ns después (dado que es una PAL16R4-20) pero
ocurre a los 30ns.
Poco después, o12 (que es MREQ en realidad) pasa a "0" y esto hace que la ecuación
/o19= /i6 * /i7 * /o12 * rf15 se cumpla, lo que hace que o19 pase a "0". Esto ocurre 50ns después lo que no
concuerda con los tiempos de propagación de la PAL.
En principio pensé que faltaba algo en las ecuaciones de o19 y o12 pero tuve que
desestimar esta teoría. Mis ecuaciones si reflejaban porque cambia o19, las pruebas en la placa de testeo no indicaban
otras ecuaciones (y tampoco se ven en la capturación del analizador) y me preocupaban que los tiempos de propagación fueran más largos de lo debido.
¿Y en el caso de la GAL16V8-12?
La GAL16V8 tiene unos tiempos de propagación de aprox. 12ns. Con estos tiempos tenemos que el tiempo
entre que baja i3 y sube o19 se reduce de 30ns a 12ns pero vuelve a bajar 12ns después de que lo haga o12.Esto nos da un tiempo
aprox. de 20ns lejos de los 40ns de la señal original.
Todo esto, me hizo pensar en la posibilidad que los diseñadores usaron algún método para obtener
esto tiempos de propagación más grandes y así conseguir 2 cosas. Hacer funcionar correctamente el
interface y ocultar su funcionamiento.
Comprobación de la teoría y soluciones al problema
Usar un condensador externo para variar tiempos de propagación
Para comprobar si estaba en lo cierto, usé la técnica de colocar un condensador variable (8-60pf) en la patilla
o12. Con esto se consigue variar levemente los tiempos de propagación (haciéndola más lenta).
Observemos ahora la capturación del analizador lógico con una Lattice GAL16V8-12 y condensador:
El condensador ha conseguido que MREQ tarde un poco más en bajar a "0" y se puede ver como o19 es más grande.
Con este cambio, el Multiface two con la GAL16V8-12 empezó a funcionar correctamente.
Sin embargo esta opción la descarte rápidamente. Con una GAL16V8-12 de Lattice, se necesita un condensador
de unos 20pF. Sin embargo con una ATMEL16V8-15 se necesitaba un valor más alto. No se puede tampoco incrementar mucho más el valor
del condensador porque estamos modificando la señal MREQ del CPC y más allá de 40-50pF el CPC empezaba a fallar.
GAL más lentas
Otra prueba fue probar las ecuaciones con GAL16V8-25 de Lattice (25ns. Más lenta que la
PAL original). El resultado fue positivo aunque también descarte esta opción. No soluciona el problema de
raíz y obligas a buscar un determinado modelo de GAL.
No optimizaciones
Cuando utilizas un programa para compilar las ecuaciones, suele traer opciones para optimizar las
ecuaciones. En el caso del software Opaljr desactivando estas optimizaciones, usando opciones de "mantener productos
redundantes", "JED completos", etc., etc. se consiguió un jed que hace que tanto la GAL16V8-12 de Lattice como la
ATMEL16v8-15 funcionasen bien (pero no 100% igual a la PAL). Es posible que los diseñadores usaran una técnica
de estas para conseguir esos tiempos de propagación más grandes.
Esta opción también la desestimé porque no soluciona el problema de raíz
Solución final. Cambiar las ecuaciones para que no se produzca el fallo
Consiste en una manera distinta de afrontar el problema. Recordemos todo surge porque con la GAL16V8
se salta un ciclo de reloj y tiene tiempo para pasar del estado 1111 > 1011 > 1010 > 0010 cuando
debería parar en 1010. Modificando la ecuación de rf14 encontré la solución buscada:
rf14 := rf17 * rf16 * /rf14 * /i13 * i5
+ rf14 * rf16 * i5
+ rf17 * /rf16 * rf15 * rf14 * /i2 {este le pongo para que no salte cuando no debe}
Esta solución se ha probado en 3 gal distintas , Lattice 16V8-12, Lattice 16V8-25 y ATMEL16v8-15 con buenos resultados, hace que ya
no dependamos de propagaciones y además el interface se comporta incluso un poco mejor que con la PAL (el CPC de pruebas se
resetea alguna vez con la PAL16R4).