Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Publicado: 12 Abr 2022, 22:15
Hoy le ha tocado sufrir a la KM4164B-15 (la #9 de @Gomas48K) y tenemos buenas y malas noticias.
La mala es que hay un error en las tablas lookup que afecta a la parte alta de la tabla lo que deduzco debido a que falla con las 4164 pero va bien con las 4116. Es algo pesado pero revisaré el código que las genera hasta encontrar el gazapo que posiblemente serán dos o más bits intercambiados.
La buena es que los tests (de "relleno") funcionan a la perfección aunque he utilizado el "modo seguro" que es más lento porque fija el bus de direcciones calculándolo bit a bit prescindiendo de las tablas lookup pero así y todo solo se lleva unos 17s para toda la 4164 sin salida a pantalla. A propósito, este "modo seguro" está en el código provisionalmente como alternativa mientras no tengamos todas las tablas en regla.
Otra buena noticia es que como la 4164 al contrario que la 4116 no usa alimentación en el pin 1 del zócalo ZIF, la actualización del firmware del Nano no tiene interferencias lo que ha facilitado sobremanera todos los tests.
Aunque se ha planteado antes me gustaría dejarlo claro en este momento, ¿cuál veis mejor estrategia para comprobar una memoria?
a) escribirla entera con un valor para después verificarla entera hasta encontrar un fallo (o no), o
b) escribir un valor en una dirección e inmediatamente verificarlo.
La primera estrategia tiene la ventaja de que los valores se verifican cuando se termina toda la escritura por lo que, en cierta forma, se está haciendo una verificación de la persistencia de los datos. El inconveniente que tiene es que si la memoria tuviera un error en, por ejemplo, las primeras direcciones tardaría más en detectarlo dado que de cualquier modo siempre completa la escritura de toda la memoria.
La segunda estrategia tiene la ventaja de que tan pronto encuentra un error en una dirección, interrumpe la escritura y lectura. En definitiva, es más rápido al probar memorias con errores. El inconveniente en este caso es que si el error de la memoria es que pasado un milisegundo se olvida de los datos, esto no se comprobaría.
Por último aprovecho el mensaje para recalcar la importancia de que una vez que tengáis la placa a punto, le dediquéis todo el tiempo necesario al test de pines sin tomar atajos. El más mínimo error susceptible de ser detectado durante el test de pines implicaría inevitablemente que los tests con memorias no van a funcionar.
La mala es que hay un error en las tablas lookup que afecta a la parte alta de la tabla lo que deduzco debido a que falla con las 4164 pero va bien con las 4116. Es algo pesado pero revisaré el código que las genera hasta encontrar el gazapo que posiblemente serán dos o más bits intercambiados.
La buena es que los tests (de "relleno") funcionan a la perfección aunque he utilizado el "modo seguro" que es más lento porque fija el bus de direcciones calculándolo bit a bit prescindiendo de las tablas lookup pero así y todo solo se lleva unos 17s para toda la 4164 sin salida a pantalla. A propósito, este "modo seguro" está en el código provisionalmente como alternativa mientras no tengamos todas las tablas en regla.
Otra buena noticia es que como la 4164 al contrario que la 4116 no usa alimentación en el pin 1 del zócalo ZIF, la actualización del firmware del Nano no tiene interferencias lo que ha facilitado sobremanera todos los tests.
Aunque se ha planteado antes me gustaría dejarlo claro en este momento, ¿cuál veis mejor estrategia para comprobar una memoria?
a) escribirla entera con un valor para después verificarla entera hasta encontrar un fallo (o no), o
b) escribir un valor en una dirección e inmediatamente verificarlo.
La primera estrategia tiene la ventaja de que los valores se verifican cuando se termina toda la escritura por lo que, en cierta forma, se está haciendo una verificación de la persistencia de los datos. El inconveniente que tiene es que si la memoria tuviera un error en, por ejemplo, las primeras direcciones tardaría más en detectarlo dado que de cualquier modo siempre completa la escritura de toda la memoria.
La segunda estrategia tiene la ventaja de que tan pronto encuentra un error en una dirección, interrumpe la escritura y lectura. En definitiva, es más rápido al probar memorias con errores. El inconveniente en este caso es que si el error de la memoria es que pasado un milisegundo se olvida de los datos, esto no se comprobaría.
Por último aprovecho el mensaje para recalcar la importancia de que una vez que tengáis la placa a punto, le dediquéis todo el tiempo necesario al test de pines sin tomar atajos. El más mínimo error susceptible de ser detectado durante el test de pines implicaría inevitablemente que los tests con memorias no van a funcionar.
