Eclipse
Eclipse es un entorno de desarrollo integrado (IDE) desarrollado por la comunidad de código libre. Es un entorno muy común utilizado tanto por desarrolladores de software en proyectos de C/C++ y Java para la arquitectura x86 como en sistemas embebidos destinados a la programación de microcontroladores y microprocesadores de bajo consumo y menor rendimiento, como aquellos que comparten la arquitectura ARMv7, o algunos más simples como los microcontroladores PIC o ATMEL de 8 bits.
En el caso del diseño digital, existen plugins que utilizan Eclipse como IDE para la edición de código en lenguajes de descripción de hardware, con el fin de disponer de un entorno unificado de trabajo tanto para programación de microcontroladores como para el diseño de circuitos digitales.
Dado que Eclipse no proporciona soporte directo para lenguajes de descripción de hardware, se ha instalado el plug-in veditor para Eclipse, que permite la edición interactiva, con características el resaltado de la sintaxis de los lenguajes de descripción de hardware más habituales, Verilog y VHDL.
Para poder simular los diseños efectuados, sin embargo, no se utiliza un plug-in adicional, sino que se utiliza la herramienta de síntesis y simulación Icarus Verilog. Esta herramienta está pensada para su uso en la terminal de comandos de Linux, y por tanto, se requiere de una correcta invocación de la misma desde Eclipse cada vez que se pretende simular.
En base a la necesidad de invocar Icarus Verilog desde Eclipse, se ha desarrollado un pequeño script escrito en Bash para invocarlo desde Eclipse como una herramienta externa y que este se encargue de la correcta manipulación de los ficheros para conseguir simular el circuito, detectando los ficheros con extensión “.v” y dándoselos como entrada a Icarus Verilog. El script se ha llamado vlog y se encuentra localizado en:
/usr/local/bin/vlog
El contenido del script se puede observar en las siguientes líneas de código fuente:
find -name "*.v" > sources.txt iverilog -f sources.txt vvp a.out #gtkwave test.vcd &
El script se encarga de encontrar los archivos Verilog existentes en el directorio del proyecto, y los almacena en un archivo de texto plano denominado sources.txt. Posteriormente se invoca Icarus Verilog utilizando como entrada los ficheros previamente almacenados en sources.txt. Icarus Verilog producirá un archivo ejecutable a.out con la síntesis y será procesado por la herramienta vvp para proporcionar un fichero “<proj_name>.vcd”.
El archivo con extensión “.vcd” se puede abrir directamente utilizando el visor de formas de onda GTKWave, donde se podrán observar las señales que se hayan pasado a través de la tarea $dumpvars() en el testbench del diseño concreto.
Ejemplo de uso
veditor
Pantalla de inicio de Eclipse:
El navegador de proyectos sirve para desplazarse entre cada uno de los proyectos que se están desarrollando. A la derecha pueden encontrarse distintas perspectivas, que configuran la distribución de ventanas y de las herramientas que se muestran. Para el diseño digital trabajaremos con la vista Verilog/VHDL que nos elimina aquellos elementos correspondientes a la compilación y el testeo de aplicaciones escritas en C.
Seleccionemos un nuevo proyecto en la barra de herramientas, y escogemos un proyecto Verilog/VHDL.
Introducimos un nuevo nombre para el proyecto, por ejemplo ALU, y hacemos click en Finish. El nuevo proyecto deberá aparecer en el navegador de proyectos. A continuación, en el menú file, creamos un archivo Verilog, y lo llamamos ALU.v.
El código fuente del ejemplo correspondiente al módulo ALU se encuentra a continuación:
- ALU.v
/************************************** * Module: alu * Date:2015-11-14 * Author: usuario * * Description: ***************************************/ module alu(A,B,op,result,C,Z); // Definción de parámetros parameter n_bits = 8; // Entradas y salidas input [n_bits-1:0] A, B; output [n_bits-1:0] result; input [1:0] op; output C,Z; // Operaciones parameter add_op = 2'b00; // Suma parameter and_op = 2'b01; // And parameter or_op = 2'b10; // Or parameter com_op = 2'b11; // Complementar A reg [n_bits-1:0] result; reg C; always@(A or B or op) case(op) add_op: {C, result} = A + B; and_op: {C, result} = {1'b0, A & B}; or_op: {C, result} = {1'b0, A | B}; com_op: {C, result} = {1'b0 , ~A}; default {C, result} = {n_bits+1{1'b0}}; endcase reg Z; always@(result) if (result == 0) Z <= 1'b1; else Z <= 1'b0; endmodule
Creamos un segundo módulo y lo llamamos ALU_tb.v. Este módulo nos servirá para testar la ALU que corresponde al módulo anterior. Para ello utilizaremos el comando de volcado de variables en un archivo, mediante $dumpfile() y $dumpvars(). El testbench contendrá el siguiente código:
- ALU_tb.v
/************************************** * Module: alu_tb * Date:2015-11-14 * Author: usuario * * Description: ***************************************/ `timescale 1ns / 100ps module alu_tb; reg [15:0] A, B; reg [1:0] op; wire [15:0] result; wire C, Z; alu #(.n_bits(16)) uut ( .A(A), .B(B), .op(op), .result(result), .C(C), .Z(Z) ); integer i; initial begin $dumpfile("alu_tb.vcd"); $dumpvars(0,alu_tb); $monitor("At time %t \n\t A = 0x%h, \n\t B = 0x%h, \n\t op = %b, \n\t result = 0x%h, \n\t C = %b, \n\t Z = %b", $time, A, B, op, result, C, Z); B = 34000; A = 35000; for (i = 0; i < 4; i = i + 1) begin op = i[1:0]; #5; end B = 16'h23; A = 16'hC4; for (i = 0; i < 4; i = i + 1) begin op = i[1:0]; #5; end $finish; end endmodule
El testbench debe encargarse siempre de llamar a la tarea $finish para finalizar la simulación. Esto es muy importante, puesto que de no hacerlo, el simulador seguirá recolectando muestras hasta quedar sin memoria el disco de la máquina.
La implementación de la ALU se ha realizado de forma genérica, para demostrar cómo puede desarrollarse un diseño parametrizable junto Eclipse. Al instanciar el módulo en el testbench, se ha optado por darle un ancho de bits de 16 bits.
La vista del módulo de la ALU se muestra a en la siguiente figura. Se puede observar el resaltado de la sintaxis que realiza el plugin de Eclipse veditor, así como la ventana derecha donde se muestran los puertos de entrada y salida, las nets internas y parámetros del módulo.
Simulación con Icarus Verilog
Para proceder a la simulación, simplemente se debe correr el script vlog desde Eclipse. Para ello, debemos irnos al menú Run→ External Tools → External Tools Configuration. Una vez en el menú, creamos una herramienta externa y la configuramos para que llame al script tal y como se muestra en la siguiente imagen.
De este modo, cada vez que ejecutemos esa herramienta externa, se llamará al script utilizando como directorio de trabajo de la terminal la carpeta del proyecto.
Ejecutamos el script y la salida de la consola se muestra en Eclipse, gracias al uso de la tarea $monitor(). La salida de terminal para esta simulación en concreto es:
VCD info: dumpfile alu_tb.vcd opened for output.
At time 0
A = 0x88b8,
B = 0x84d0,
op = 00,
result = 0x0d88,
C = 1,
Z = 0
At time 50
A = 0x88b8,
B = 0x84d0,
op = 01,
result = 0x8090,
C = 0,
Z = 0
...
Este mismo proceso podría haberse llevado a cabo desde la propia terminal de comandos, navegando hasta el directorio del proyecto e invocando a iverilog desde allí. A continuación se muestra un ejemplo.
cd workspace/ALU iverilog -s alu_tb alu_tb.v alu.v # Crea un archivo de simulación a.out vvp a.out # Simula el archivo generado por iverilog.
Al ejecutar el código, se muestra por la terminal la salida de consola anterior. La orden $monitor funciona tanto dentro como fuera de Eclipse, como es de esperar, puesto que la consola de Eclipse precisamente se encarga de recoger los mensajes que se verían por el terminal.
Icarus verilog permite no sólo la simulación de módulos verilog, sino también otras opciones como síntesis de la netlist o comprobación de sintaxis, o incluso traducción a vhdl. Para más información sobre el programa puede visitarse el manual a través de la terminal:
man iverilog # Muestra el manual y ayuda de Icarus Verilog.
GTKWave
Además de utilizar la salida por terminal, el programa hace un volcado de los cambios de variables en un archivo .vcd. De este modo, podremos abrir la simulación y visualizar las señales en el visor GTKWave. Como nos informa el script a través de la consola, el archivo generado se llama alu_tb.vcd.
Para poder acceder al archivo, lo más sencillo es hacer click derecho sobre la carpeta del proyecto y refrescar el árbol de archivos. De este modo, los nuevos archivos generados (sources.txt, a.out y alu_tb.vcd) ya son accesibles desde el navegador de proyectos. Hacemos doble click sobre el archivo alu_tb.vcd, y se abre la aplicación GTKWave para visualizar los resultados. La ventana de la aplicación tiene el siguiente aspecto:
Podemos ver las señales disponibles en la zona inferior izquierda de la imagen. Estas corresponden al módulo ALU_tb, pero también podemos acceder a aquellas contenidas en los módulos instanciados, a través de Arbol de la zona superior izquierda. Seleccionamos el módulo deseado y nos muestra las señales que contiene el mismo. Por ejemplo, para el caso de las señales del testbench tenemos:
De este modo hemos comprobado el funcionamiento de la ALU, así como los resultados, tanto utilizando una aplicación gráfica como es GTKWave como utilizando el comando $monitor, contando con las ventajas y desventajas de ambos.