ZONA DE PRUEBAS

Hago esta pregunta al aire porque cada vez estoy más convencido de ello.

Verilog es un lenguaje de descripción de hardware, es decir, puede llegar a describir un ordenador/videoconsola/recreativa fielmente al 100% y permitir una réplica exacta de su funcionamiento. ¿Por qué no usarlo en emuladores también y así avanzar en dos frentes a la vez?

Comprendo que emular Verilog es algo jodido a nivel de recursos, pero creo que ya sería posible usarlo para los sistemas más antiguos. Bastaría emular una salida a TV y otra para mandos/teclados, pero se podría usar el mismo código Verilog que se está usando para los clones en FPGA.

¿Es una locura o voy bien encaminado?

radastan escribió:Verilog es un lenguaje de descripción de hardware, es decir, puede llegar a describir un ordenador/videoconsola/recreativa fielmente al 100% y permitir una réplica exacta de su funcionamiento. ¿Por qué no usarlo en emuladores también y así avanzar en dos frentes a la vez?

¿Puedes elaborar un poco más esto? Quiero decir... ¿qué entiendes tú por emular con Verilog? ¿Quieres decir quizás usarlo como cualquier otro lenguaje de programación para crear software, en este caso, un emulador?

mcleod_ideafix escribió:

radastan escribió:Verilog es un lenguaje de descripción de hardware, es decir, puede llegar a describir un ordenador/videoconsola/recreativa fielmente al 100% y permitir una réplica exacta de su funcionamiento. ¿Por qué no usarlo en emuladores también y así avanzar en dos frentes a la vez?

¿Puedes elaborar un poco más esto? Quiero decir... ¿qué entiendes tú por emular con Verilog? ¿Quieres decir quizás usarlo como cualquier otro lenguaje de programación para crear software, en este caso, un emulador?

Efectivamente, usar el propio código de Verilog para emular un sistema. Sólo habría que asignar a los pines de e/s del código verilog la emulación de lo externo (un televisor, un mando, etc). Evidentemente habría que usar una precompilación antes de ejecutar el emulador, pero se usaría el mismo código.

Es más, rizando el rizo se podría hacer varias emulaciones a la vez para emular hasta el hardware de periféricos. Podríamos tener perfectamente emulados un ZX Spectrum con su Interfaz 1.

Un ejemplo: podríamos coger el código Verilog del ZX Uno y emularlo directamente con sólo asignar pines de e/s a lo que se deba (el conector de vídeo compuesto se vería reflejado en pantalla como si fuera un televisor CRT).

radastan escribió:Efectivamente, usar el propio código de Verilog para emular un sistema. Sólo habría que asignar a los pines de e/s del código verilog la emulación de lo externo (un televisor, un mando, etc). Evidentemente habría que usar una precompilación antes de ejecutar el emulador, pero se usaría el mismo código.

Y... ¿qué diferencia hay entre eso y convertir la descripción en un circuito para metérselo en una FPGA?

Porque si lo que estás insinuando es que exista algún tipo de compilador que traduzca Verilog al código máquina de un procesador, ya te cuento que hay varios escollos:
- Verilog es un lenguaje que de forma natural procesa en paralelo. Esto no es posible en un procesador, ni siquiera en uno con varios nucleos, dado que el procesamiento en paralelo de Verilog es a nivel de ciclo de reloj. Muchísimo más fino que el procesamiento paralelo a nivel de cores de un multicore. Un ejemplo: para intercambiar el contenido de dos variables a,b en cada ciclo de reloj, en Verilog, se usa esto:

Esto funciona porque ambas asignaciones se realizan al mismo tiempo, por lo que no hay condiciones de carrera que sí habría en un multicore.
- Hay procesos y cálculos, incluso, que se ejecutan ideamente en 0ns de tiempo (y que en la realidad, según la FPGA usada, pueden tardar del orden de 2-3ns). Un ejemplo: un trozo de código que según el valor de su entrada, un número de 4 bits en formato BCD, genera el patrón de bits para encender un display LED de 7 segmentos:

- El sistema en que se implementa un diseño en Verilog "habla" con otros dispositivos (un teclado, un monitor) que van a una cierta velocidad. Pongamos el monitor, que tiene que poder pintar 352 píxeles en 64 microsegundos. Esto significa que Verilog tiene que poder darle a la salida de video un dato nuevo cada 140 nanosegundos aproximadamente. Y debe hacerlo independientemente del resto de cosas que se estén "ejecutando" en el interior del dispositivo en el que use el diseño en Verilog.

Todos estos escollos lo que vienen a sugerir es que la traducción de Verilog a código máquina nunca (o practicamente nunca, salvo para casos excepcionalmente triviales) va a producir un código máquina capaz de leer y generar datos a la misma cadencia que se haría con una FPGA. El microprocesador que usara una "compilación" de Verilog estaría ejecutando secuencialmente lo que en origen es paralelo.

El primer entorno de diseño con FPGA que usé era el DK de Celoxica (luego Mentor Designs). En él podíamos simular el código Verilog, apareciendo en pantalla una representación gráfica de la placa actual para la que se había diseñado ese código. Si como parte del diseño habíamos hecho un controlador VGA, podíamos ver cómo ese controlador VGA iba pintando la pantalla. Obviamente no lo veíamos en tiempo real, sino a cámara lenta, y no porque el PC fuera muy lento.... es que para poder hacer esa simulación en tiempo real el PC debería ser como 1000 veces más rápido de lo que lo es ahora.

MC Leod, evidentemente cuando hablo de compilación no me refiero a código máquina. Es evidente que se debe realizar un ciclo completo de ejecución del código Verilog para ser fiable.

Yo mismo creé en su día un emulador de circuitos digitales, no pasé de puertas lógicas simples, retardos (para los tiempos de propagación), y pérdidas de tensión (para simular la disipación y los niveles reales). La cuestión es que tuve que hacer dos mallas: una para el tiempo previo, y otra para el tiempo siguiente. Tu dabas un tiempo de ciclo de simulación, por ejemplo 1 ns, y ejecutaba la primera malla transfiriendo los datos a la segunda. Usaba un lenguaje parecido al SPICE basado en nudos.

http://redeya.bytemaniacos.com/scd/scd.html

Pues lo mismo pero para Verilog. Es evidente que se necesitará un procesador potente, pero es que al ritmo que vamos empieza a ser factible la emulación de sistemas sencillos a nivel de hardware y no de aproximaciones software.

mcleod_ideafix escribió:Y... ¿qué diferencia hay entre eso y convertir la descripción en un circuito para metérselo en una FPGA?

Ninguna, eso es lo bueno. Los que no quisieran hardware real tendrían un emulador 100% fiel, y los que quisieran hardware real sólo tendrían que "tostar" su FPGA. La ventaja estaría en la fidelidad de la emulación y que todos trabajarían con el mismo código de descripción. Imagina a todos los autores de emuladores del mundo trabajando en Verilog (hablo de un hipotético futuro), pudiendo avanzar todos en la misma dirección.

Cuando hice un curso de hardware reconfigurable lo primero que se me pasó por la cabeza fue emular una FPGA con un microcontrolador...
Evidentemente para cosas sencillas didácticas, podría funcionar.

Como casi todo lo que pienso se quedó en eso; un pensamiento.

radastan escribió:Pues lo mismo pero para Verilog. Es evidente que se necesitará un procesador potente, pero es que al ritmo que vamos empieza a ser factible la emulación de sistemas sencillos a nivel de hardware

Verilog ya permite simular la descripción que tú hayas hecho, y ver qué resultados obtienes. Es de hecho un paso obligatorio antes de meter el código en la FPGA. Cuando Antonio estaba diseñando la placa para el Harlequin 128, como él la estaba haciendo "a ojo" por decirlo de alguna forma, me ofrecí a implementar su placa, tal y como él la estaba diseñando, en Verilog, y simularla, llegando a obtener no una imagen, sino un video completo de la ejecución de un programa. El hilo era éste:
viewtopic.php?f=26&t=3074&p=20974#p20974

Más tarde hice algo parecido, pero con la Shock Megademo, para ver qué tal se vería en la placa real, aun sin existir fisicamente:
viewtopic.php?f=26&t=3074&start=280

No sé si es esto en lo que estabas pensando...

En el primero de los dos hilos comento que en mi PC (un Quad Core), 20 milisegundos de tiempo del circuito descrito tarda del orden de 1,5 segundos en procesarse, así que haciendo las cuentas, resulta que necesitaría un PC 75 veces más potente que el que tengo para poder lanzar la simulación y que ésta funcionara en tiempo real.

Suponiendo que la ley de Moore se siga cumpliendo al mismo ratio que hasta ahora (se dobla la velocidad cada 18 meses), y partiendo de que este test lo hice hace practicamente dos años, en Abril del 2013, no podremos ver nada como lo descrito hasta, como mínimo el 2023.

Quizás mucho antes si en lugar de tomar el lenguaje Verilog completo se toma una parte de él, y se cambia la generación de señal de video por la instanciación de una "caja negra" que lo que haría sería generar una imagen usando DirectX (por poner un ejemplo en Windows) tomando los datos que el circuito escribiera en un framebuffer.

Efectivamente Mc Leod, eso que simulaste en tiempo real y con lo que has comentado es lo que tenía en mente. Evidentemente algo como un clon del ZX Spectrum queda grande ahora mismo, pero seguro que en unos años ya no será ciencia ficción. Tal y como dices es una emulación muy bestia y lo mismo no necesitamos la descripción completa de Verilog.

También parecía ciencia ficción emular una recreativa... y mira.

Tal como lo entiendo, no describes una emulación sino en reimplementar un hardware clásico con un lenguaje de descripción de hardware. Ya existen librerías para ciertas FPGAs (Xilinx Spartan me viene a la cabeza) que describen una CPU z80 o 8086 completa. Pero entonces no hablamos de una emulación, ya que entonces esas FPGAs ejecutan código nativo Z80 o x86.

Dejando al margen la viabilidad de la tarea -que me figuro que con una CPU lo bastante rápida puede ser factible-, no acabo de ver la ventaja que aportaría un simulador a nivel de circuitos digitales en vez de los emuladores funcionales actuales. Ojo, que no me parece para nada una pregunta "tonta", pero no creo que vayan a ir por ahí los tiros. Teniendo en cuenta el enorme consumo de recursos de este tipo de simulación y el dudoso beneficio que se obtendría, no creo que nunca pase de la fase de experimento académico. Al fin y al cabo el objetivo de un emulador es reproducir el comportamiento de un sistema determinado, no su funcionamiento interno (entonces es un simulador).

Un saludo!