Publicaciones de la categoría: Uncategorized

Instalar Quartus 13 en Ubuntu de 64 bits (Ubuntu 16.04)

Quartus 13 es la versión que hace falta para trabajar con MiST pero hay partes del paquete que requieren librerías de 32 bits y hoy en día lo normal es tener instalada la versión de 64 bits del sistema operativo. En mi caso uso Ubuntu Mate 16.04. Para añadir las librerías de 32 bits adecuadas hay que ejecutar el comando:

apt install make:i386 libxdmcp6:i386 libxau6:i386 libxext6:i386 libxft-dev:i386 libxft2:i386 libxrender1:i386 libxt6:i386 libfontconfig1-dev:i386 libxtst6:i386 libx11-6:i386 unixodbc:i386 ncurses-base:i386 libzmq3-dev:i386 libxext6:i386 libxi6:i386

como root.

Ahí están casi todas las librerias. Falta alguna de las que la guía de instalación lista para ejecutar el simulador ModelSim, pero yo como habitualmente no lo uso no lo tengo puesto. De hecho, para usarlo es casi mejor preparar una máquina virtual con CentOS 6 en 32 bits pues ahí la instalación es más sencilla.

Anuncios

Entrevista en Retromaniac

Esta semana me han hecho una entrevista en Retromaniac enfocada a las FPGA y su papel en el mundo retro. Ha sido muy interesante poder explicar mi punto de vista de la escena en una publicación de calado. Aquí os dejo el enlace.

El ancho de banda y por qué las recreativas eran mejores que los ordenadores

En los 80 y 90 se entendía la informática como algo bipolar: o tenías 8 bits o tenías 16 bits. Y esas palabras parecían contener toda la enjundia posible. Sólo con ese número se resumía por completo la capacidad de un equipo, ya fuera ordenador o consola. Sin embargo, esa no era toda la historia. Lo que todos ignorábamos era que esas máquinas de los bares y salones a menudo tenían una CPU de 8 bits y menos RAM que nuestros ordenadores… Incluso la Megadrive, consola de 16 bits, no estaba a la altura de las máquinas recreativas. ¿Qué pasaba?

Ghosts’n Goblins en máquina (8 bits), Atari ST (16 bits) y Amstrad CPC (8 bits)

Lo que pasaba se llama ancho de banda de memoría. Y consiste en que los ordenadores compartían la memoria entre los distintos componentes. Habitualmente dos: el procesador general (Z80 o motorola 68000) y el circuito de vídeo. Y si el procesador además llevaba la gestión de la música, podemos decir también que el chip de sonido entraba a compartir también el acceso a memoria.

Imaginaos: el procesador tenía que leer de la memoria lo que tenía que pintar, pintarlo en otra posición de memoria, leer también la siguiente nota a ejecutar y pasarla al chip de sonido y por supuesto tenía que leer el programa a ejecutar y escribir en memoria lo que estaba pasando con los personajes. Para más INRI, a veces el procesador iba a acceder a memoria y no podía, porque el circuito de vídeo le bloqueaba el acceso y tenía que pararse y esperar.

En las consolas el panorama era similar: todo (gráfico, juego y música) estaba grabado en un cartucho que tenía una conexión con la consola que formaba un cuello de botella porque cada componente de la consola competía por acceder al cartucho.

¿Pero y en los arcades? Bueno, pues estás máquinas alucinantes tenían desde el principio buses dedicados para cada función. El procesador del juego tenía su propia memoria que no compartía y a cuyo acceso no iba a verse bloqueado. Había otro procesador para la música con su propia memoria y además los circuitos gráficos accedían a las memorías ROM donde estaban los dibujos por buses independientes. Así que todo podía funcionar sin interferirse y a mucha más velocidad a pesar de que los componentes individuales fueran de 8 bits… y si encima eran de 16 bits, ni te cuento.

Esta historia viene a cuento del panorama FPGA actual. Los sistemas más activos actualmente son el ZX-UNO y el MiST y los dos se pensaron para replicar ordenadores domésticos así que sólo cuentan con una memoria y los componentes que se repliquen dentro de la FPGA han de compartir el acceso. ZX-UNO tiene una memoria de 8 bits y MiST tiene una de 16 bits. Los dos sistemas han demostrado que pueden hacer con éxito lo que nacieron para hacer: un ZX Spectrum y un Atari ST. Sin embargo, tienen en su diseño el cuello de botella de la memoria. Como estas memorias son más modernas es posible compartir su uso y aun así tener un rendimiento muy superior al de equipos de los años 80 y 90. Sin embargo, puede que recreativas de 8 bits como Gryzor, no puedan realizarse de forma fidedigna. Olvidaos ya de ver un Shinobi y una NeoGeo… ni te cuento.

gryzor

Gryzor (arcade, 8 bits)

Compilar iVerilog 10 en Ubuntu 16.04

Ubuntu viene con la version 0.9 de iVerilog. Para acceder a la última version hay que descargarla de aquí. Compilarla es sencillo: ejecutar ./configure y luego make. Pero la sorpresa puede venir cuando al ir a grabar en formato LXT iVerilog da un error:

LXT2 support disabled since zlib not available

En ese caso tenemos que instalar estas librerias:

sudo apt install libbz2-dev zlib1g-dev

y repetir la compilación: ./configure otra vez y luego make. Si os fijais en la salida del configure habrá unas líneas así:

checking for gzwrite in -lz... yes
checking for gzwrite in -lz... (cached) yes
checking for BZ2_bzdopen in -lbz2... yes
checking for BZ2_bzdopen in -lbz2... (cached) yes

Comprueba que tengas un yes en todas ellas. Entonces la compilación producirá un iverilog capaz de generar LXT. Al final haz:

sudo make install

Y listo.

Entrevista en AmigaWave

El equipo de AmigaWave me entrevistó para su podcast/canal de youtube. Fue una charla interesante donde traté temas poco conocidos, como el esfuerzo que se está desarrollando para abrir chips antiguos y extraer el circuito original.

Os dejo aquí la entrevista en youtube, marcada ya en el minuto donde empieza.

Sistemas retro en FPGA ¿Por qué?

Con todo el entusiasmo generado por el ZX Uno, un proyecto español originado en el foro Zona de pruebas, que recrea un ZX Spectrum (entre otros) en una pequeña placa con una FPGA, muchos se están preguntando… ¿qué es una FPGA? ¿Por qué es mejor que emular?

Hay un vídeo en youtube que trata de explicar esto en relación a otro gran proyecto abierto de recreación en FPGA, el Mist. Sin embargo, creo que la explicación no satisfará a muchos con ansias de entender mejor la ventaja. Así que me he animado a escribir esta entrada.

Supongo que sabes que un ordenador, clásico o no, se compone de básicamente de estos elementos:

  1. Procesador (CPU)
  2. Memoria
  3. Sistema de E/S (Entrada/Salida), incluye teclado, vídeo, sonido, cinta, disco…

En la imagen tenemos la placa del ZX Spectrum con estos componentes marcados. Hay memoria que contiene el sistema (el BASIC en un ordenador de 8 bits). A esta memoria la llamamos ROM, porque no puede borrarse. Hay otra memoria que se usa para guardar los datos con los que el procesador trabaja, que llamamos RAM. Por supuesto está la CPU y un chip bastante grande marcado como FERRANTI ULA que contiene los sistemas de entrada y salida. A su lado hay dos piezas metálicas que contienen cuarzo y se usan para generar el reloj del sistema. El número 4.4336 que puede leerse es la frecuencia en MHz para la que está diseñado ese cristal, usado en el circuito de vídeo.

ZXspectrum_mb2

Un emulador es un programa que recrea la función de todos estos elementos: uno a uno y dentro de las restricciones temporales, de sonido e imagen que plantea el sistema sobre el que corre el emulador. Sin embargo, en el equipo real estos chips funcionan todos a la vez. Es más, en su interior hay miles de componentes que también funcionan a la vez. El emulador trata de recrear lo que el programa original está haciendo. Si el programa original decía: coge dos números de memoria y súmalos. El emulador hará eso. Pero… la placa original no hacía exactamente eso.

Bueno, sumaba los dos números pero pasaban más cosas. Esos números eran transportados hasta el interior de la CPU. Almacenados en una memoria especial llamado “registro” del procesador y pasados a través de otra etapa dentro del procesador encargada de hacer sumas. Cada uno de estos elementos estaba fabricado con transistores y cada uno de estos transistores tenía su propia actividad que ocurría al ritmo marcado por el reloj: 3,5MHz en un Spectrum. Y mientras tanto el chip de vídeo seguía con su actividad, y el altavoz seguía funcionando y la cinta moviéndose… Todo ocurría a la vez (en paralelo).

En el emulador, todo ocurre en serie: paso a paso. El emulador simula qué hace la CPU durante un tiempo. Se para y mira qué hace el chip de vídeo. Se para y atiende al sonido. Vuelve la mirada hacia el teclado… Así que las cosas no pasan a la vez y normalmente esto no se nota. Los ratitos que el emulador dedica a cada tarea son lo suficientemente cortos como para que no se note… Casi nunca. Cuando un programa necesita, por diseño o por casualidad, una relación de tiempo más precisa entre los componentes pasamos a necesitar equipos mucho más rápidos para poder emular el sistema. Podéis leer aquí el caso de cómo emular una SNES puede llevarse por delante un procesador de 3GHz. Y aun así, será inexacto.

¿Qué es una FPGA?

Una FPGA es un chip en cuyo interior hay muchos componentes electrónicos cuyas conexiones son libres. Estos componentes son desde muy pequeñitos como flip flops (memorias de un solo bit) hasta memorias más grandes o incluso CPUs modernas (modernas sí, pero pequeñas). La mayoría de los componentes de la FPGA son bloques elementales de la electrónica digital. Son piezas muy pequeñas (puertas AND, OR, flip flops, sumadores, algún divisor) que el diseñador electrónico necesita unir para crear circuitos.

Dentro de los chips del ordenador de la imagen también se encuentran estas mismas piezas. La diferencia clave está en que en los chips del ordenador original esas piezas están conectadas con un metal que no se puede cambiar una vez fabricado. Mientras que en la FPGA la conexión es variable. Y aquí viene lo fascinante. Con la FPGA adecuada, es posible reconstruir el circuito electrónico original y por lo tanto tener el mismo sistema, solo que en un solo chip. Así que una FPGA no imita lo que hacía el sistema original. Una FPGA es como el sistema original. Por supuesto, en la recreación del circuito se pueden cometer errores o puede faltar información y ahí surgirán pequeñas diferencias. Pero el potencial de llegar a ser exactamente igual al original con precisión superior al microsegundo está ahí.

¿Cómo se programa una FPGA?

El término programar es confuso. Programar una FPGA realmente se refiere a transferir la información de las conexiones desde el ordenador, donde se ha desarrollado el sistema, hasta el chip de la FPGA. Una vez programada, la FPGA contiene las conexiones que el ingeniero quiere.

¿Cómo decide el ingeniero esas conexiones? Dado que para cada modelo de FPGA hay unos bloques elementales en su interior, el ingeniero puede decidir directamente qué bloque usar y a qué bloque conectarlo. Como quien une los puntos de un dibujo. Sin embargo, este enfoque no es el más práctico. El ingeniero prefiere escribir un código parecido al de un programa de ordenador. Este código describe lo que el circuito tiene que hacer. Aunque parezca un programa, no es realmente un programa porque no existe un procesador que lo ejecute. En vez de eso, el ordenador con el que trabaja el ingeniero transformará ese código (ese fichero de texto) en unas conexiones en la FPGA tales que la FPGA se convierta en un circuito que haga la función que el ingeniero había descrito. Esto, que suena como si el proceso de transformación requiriese mucho ingenio por parte del ordenador, en realidad no lo es tanto. Lo más complicado del proceso no es pasar de la descripción a los bloques electrónicos sino conectarlos de forma que la señal se transmita adecuadamente entre ellos.

Así que, si un ingeniero escribe una descripción de un procesador, por ejemplo un Z80, este procesador podrá realizarse en los circuitos de muchos modelos distintos de FPGA y con el mismo código, también en un chip de verdad. Todos los procesadores y sistemas electrónicos digitales modernos están diseñados utilizando estos lenguajes de descripción (Verilog, principalmente) y el que acaben en un chip dedicado, con conexiones fijas, o en una FPGA, con conexiones variables; depende del tamaño de mercado para el que se fabrican y de su velocidad, fundamentalmente.

Resumiendo: en una FPGA se reconstruye el circuito original y, a efectos electrónicos, nos encontramos ante el mismo sistema que el original. Hasta los detalles más insignificantes y las particularidades más meticulosas de un sistema se pueden recrear en la FPGA y a menudo ocurrirán como consecuencia natural del circuito que se monta en ella. Sin embargo en un emulador el programador necesita elegir qué aspectos de la máquina original va a imitar y de qué manera. Los aspectos que no se noten en la emulación no se replican en un emulador. Sin embargo en la FPGA, por ser el circuito electrónico, es necesario incluir prácticamente todos los elementos que ocurrían en el original.

¿Ventajas de una FPGA frente a un emulador?

A estas alturas debería resultar obvio: la FPGA es, básicamente, el sistema original. Así que comparar el emulador con la FPGA es muy similar a compararlo con el original. Eso sí, la FPGA habitualmente puede hacer cosas que el sistema original no puede:

  • Acceso a más RAM
  • Lectura de discos desde una tarjeta SD
  • Incrementar la velocidad de la CPU o de la memoria
  • Otros trucos dado el acceso directo al hardware del que dispone

Y puede hacer algo que los emuladores tienen casi por imposible: conectarse a hardware real de la época, como el caso de los puertos MIDI del Mist o los puertos de cartucho del One Chip MSX.

Y hasta aquí este repaso sobre FPGAs y emulación.

Eliminación del autodisparo en un Quickshot

Hace unos días compré por eBay estos mandos, aun precintados, de Quickshot (ver aquí).

Imagen

El problema de estos mandos es que llevan un autodisparo en los dos botones. Hay muchos juegos en los que el autodisparo es un inconveniente: no permite realizar acciones o estorba. Así que me propuse quitárselo. Los dos botones en realidad son el mismo disparo para el ordenador. El cambio que voy a enseñar consiste en dejar el izquierdo con autodisparo y el derecho sin él. Después de desmontar la caja con mucha facilidad hice un diagrama de la placa:

Imagen

Y de ahí, se saca el esquema del circuito. Consiste en un oscilador conectado a los dos botones. Los botones se conectan entre un diodo LED y la salida del oscilador. La placa está preparada para dar salida individual a cada botón pero el cable carece de la conexión para el 2º botón. Para eliminar el autodisparo en uno de los botones basta con desconectar el lado del botón que va al colector del transistor y conectarlo a masa (cable negro) en su lugar. En el esquema esta conexión está indicada en negro.

Imagen

Para conectar a masa, usé el emisor del transistor más cercano al botón, que ya estaba conectado a masa.

Imagen

Y con eso queda el cambio hecho.

Conexión de la placa Spartan 3A Starter Kit a Linux

Llegó por fin la FPGA y lo primero ha sido intentar programarla desde Linux. Yo gasto Fedora 17 (voy una versión atrasado), con una versión de núclero 3.x. Con la placa viene la versión 13.4 de ISE (la herramienta de Xilinx). Durante la instalación aparece un error acerca del controlador del cable, un tal windrvr. Rebuscando entre los ficheros de C, parece ser que está pensado para la versión 2.6 del núcleo exclusivamente. Buscando por aquí y sobre todo por allá, acabo enterándome de lo que pasa:

Resulta que no hace falta el windrvr, con que esté libusb instalado basta. Pero, al conectar el cable Linux debe instalarle el firmware. Eso se hace con el demonio udev. El programa de instalación de ISE ya lo ha dejado todo casi hecho en el directorio /etc/udev/rules.d pero con una sintáxis incorrecta. Parece ser que a algún iluminado se le ocurrió que había que cambiar BUS por SUBSYSTEM, SYSFS por ATTR, y TEMPNODE a minúsculas: tempnode. A saber la de gente que estará mareada por culpa del tipo ese.

El fichero /etc/udev/rules.d/xusbdfwu.rules corregido para mi cable queda así:

ATTR{idVendor}=="03fd", ATTR{idProduct}=="0008", MODE="666"
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03fd", ATTR{idProduct}=="000d",
RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D $tempnode"

El fichero dice que cuando se conecte al USB el dispositivo 03FD:000D, se ejecute el comando fxload, que es el que carga el firmware. Con el nuevo firmware el dispositivo pasa a ser reconocido como 03FD:0008 y en ese caso se aplica la primera línea, que hace referencia a los permisos. Para que ISE pueda acceder al cable hay que darle permiso a todo el mundo. Eso se hace con la línea acabada en MODE=”666” del fichero. Aun así, si se está usando SELinux no funciona. Seguro que se puede añadir la excepción para SELinux lo acepte pero yo he preferido pasar SELinux al modo permisivo.

Tras hacer todas estas cosas, el cable funciona correctamente con ISE en Linux 3.x.