[Icestudio] Testbenches Hardware

[Juan Gonzalez Gomez]

Hola, 

Llevo un tiempo haciendo pequeños bancos de prueba hardware: circuitos que prueban otros circuitos, todo dentro de la FPGA 

Este sería un ejemplo "hola mundo": Un circuito para probar un biestable D:

El bloque "probador" es el DFF-TB. Envía datos a la entrada del biestable (d) y lee su salida (q), para comprobar que es la que debe ser. Una vez finalizado el test, emite un tic por done y, en este ejemplo, se enciende el LED. Así, el proceso de prueba es así: Se aprieta el pulsador SW1 y si pasa los test se enciende el LED7, de lo contrario se queda apagado

Sin embargo, cuando estás desarrollando, no basta sólo con  saber si pasa la prueba o no, sino que sería interesante ver sus señales internas, para en el caso de no pasarla, saber qué ha fallado. Gracias al proyecto icerok de Charliva, esto es muy fácil. La salida tx del Testbench se comunica con el plugin de icerok para guardar la captura de las señales en un fichero y visualizarlo con Pulse View. Esto es lo que se obtiene cuando el test es correcto:

De un golpe de vista vemos que efectivamente es un biestable D. Sólo hay que fijarse en su señal de entrada: d, y la de salida: q. Vemos que la señal q es igual que d pero retrasada un ciclo: se trata de un biestable D. ¡Todo esto sin necesidad de tener ningún analizar lógico!

Desde el PulseView podemos realizar mediciones, y comprobar cuánto tiempo ha tardado en hacerse la prueba. Medimos desde que la prueba comienzo (señal de busy a 1) hasta que la señal de done se puede leer (instante situado en la derecha del todo). El tiempo que sale es de 1250ps (1.25µs)

Esto mismo lo podríamos haber medido también usando el bloque medidor de ciclos comentado en este hilo . Conectamos a sus entradas las señales start y done. El circuito quedaría así:

Desde el terminal serie de icestudio vemos el resultado:

Ha tardado 15 ciclos. Como el reloj del sistema es de 12Mhz, tenemos que el tiempo que tarda es de: 15 * 1 /12 = 1.25µs, lo que habíamos medido antes con Pulseview

¿Y qué ocurre si metemos un biestable D defectuoso? El Testbench debería detectar que no funciona. Hacemos una prueba rápida sustituyendo el biestable D por una puerta not, a ver qué pasa:

Al apretar el pulsador, ahora el LED no se enciende. Sí veremos el destello del led amarillo que indica que nuestro circuito está transmitiendo algo al PC, pero el LED verde de ok NO se enciende. El testbench ha detectado que eso no funciona como un biestable D

Echemos un vistazo a las señales internas. Aparece un pulso en la salida error

 Mirando d y q vermos qué ha pasado: el testbench a colocado un 0 en la entrada del biestable (d). En el ciclo siguiente comprueba la salida (q), que debería ser 0, pero encuentra un 1: ¡Error!

El tener "circuitos probando circuitos" me parece muy divertido, y me está sirviendo mucho para desarrollar la intuición sobre el pensamiento hardware. También es interesante para la gente que está aprendiedo. Se les pide que diseñen un circuito concreto, y podrán comprobar que lo tienen bien con estos bloques

Típicamente esto se hace en simulación. Pero tiene su gracia el que se pueda hacer físicamente, en hardware real

Ejemplos similares a los que he puesto aquí están disponibles en la colección iceFF: https://github.com/FPGAwars/iceFF

¡Que las FPGAs libres os acompañen!

Saludos, Obijuan

[Democrito]

A mí este enfoque de diseño me abre más la mente, en el sentido de ver posibilidades. Se me ha pasado por la cabeza un zócalo comprobardor de integrados externo e incluso que "adivine" qué integrado es. Y a parte de esto, con un golpe de vista poder ver en la gráfica si algo va como se espera o falla alguna zona de ese chip (familias TTL, CMOS, etc de chips).

Muchísimas gracias por abrirnos nuevos caminos y posibilidades!

[charli va]

La verdad que es  super interesante. Me recuerda mucho a las pruebas unitarias software.

Es una pasada plantear todo este nuevo tipo de enfoques, mil gracias!!

El mié., 9 sept. 2020 a las 21:07, Democrito (<spo...@gmail.com>) escribió:

A mí este enfoque de diseño me abre más la mente, en el sentido de ver posibilidades. Se me ha pasado por la cabeza un zócalo comprobardor de integrados externo e incluso que "adivine" qué integrado es. Y a parte de esto, con un golpe de vista poder ver en la gráfica si algo va como se espera o falla alguna zona de ese chip (familias TTL, CMOS, etc de chips).

Muchísimas gracias por abrirnos nuevos caminos y posibilidades!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/722177a5-5011-4016-ba5b-fa62811bf99bo%40googlegroups.com.

[Obijuan]

Gracias a ti Charli por icerok! Esa es la clave! Se abren un montón de posibilidades

Saludos, Obijuan

[Alexandre Dumont]

relacionado con el tema testing, en mi proyecto de HRMCPU, yo hice un sistema para lanzar pruebas unitarias (de instrucciones) y probarlas tanto en simulaciones, como contra el hw real. os cuento como parentesis, por si os puede interesar (aunque no tengo claro si es parecido a eso o no, y perdonad por el off-topic si lo es).

en mi caso, cuando hage el make, genero el bitstream que incluye un programa (rom). En el circuito ya tengo tambien una UART, para poder enviar y recibir datos para que la CPU ejecute el programa y procese esos datos. (esta CPU exotica procesa datos en una FIFO de entrada y los deja en una fifo de salida. ambas FIFOs estan conectadas a UART RX/TX respectivamente).

Lo que he hecho, es un sistema de testing, basado en carpetas, cada carpeta es un test, contiene un programa (que se asembla durante el test), un conjunto de datos de input (los genere de manera aleatoria), y un conjunto de datos esperados.

El test "echo" por ejemplo, seria:

El programa que queremos probar es:

init:
INBOX
OUTBOX
JUMP init  

por ejemplo si el input (fichero test00.in) es:

01

02

la salida esperada (fichero test00.out) es tambien:

01

02

Al ejecutar el test, mi script ensambla el programa, genera la rom, genera el bitstream (con la rom embebida en bram), programa la FPGA y le envia el input por Serial, y recupera la salida. Despues compara ambas. Si esta bien, pasa al sigiente conjunto de input/output esperado (y cuando los acabe, al siguiente test/programa).

Los tests que tengo no son unitarios como tal creo (no soy un experto de testing ni desarrollo), son varios programitas que pruebas varias instrucciones, pero lo cierto que el valor que me ha aportado tener eso ha sido ENORME!!

Como decia, puedo lanzar tests "software" : solo se lanza por simulacion con iverilog, y genera waveforms gtkwave, son los que mas uso, de hecho son los que lanzo en "integracion continua" (en Travis-CI). . Esa modalidad de test hw tambien es muy util y la uso cuando los tests sw pasan. (si fallan los tests sw me centro en encontrar primero donde puede estar ese fallo en la simulacion).

Aqui teneis un ejemplo de salida (tampoco es que muesre mucho, pero en el log se ven todos los tests,...) , esa es la version ejecutada en Travis CI, pero en HW seria parecida. https://travis-ci.com/github/adumont/hrm-cpu/jobs/381632695#L1576

Como apunte, al final cuando ejecutaba los tests hw, se perdia mucho tiempo en mi caso, por 2 cosa:

- Para cada rom (programa) diferente resintetizaba todo el bitstream.: Para eso encontre que se puede cambiar solo la rom dentro del bitstream (con icebram)

- Para probar otro input/output diferente, reprogramaba la FPGA lo que tardaba mucho. Al final consegui una manera para ver que era el mismo bitstream y no reflashearlo, y solo reseteo la FPGA (lo que es mucho mas rapido, con iceprog -t )

[Quilbio Antigua]

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CABqu7xqNdpTqwxw_6S9ffL9Gs6f9JH9E2oJR9yoWHzabin5X5g%40mail.gmail.com.