Tutorial de VHDL centrado en crear un clon

[mike_01]

Hola @antoniovillena. Sí que tengo la placa MOD-VGA, pero mi versión es la que lleva SDRAM de 32MB, lo que complica un poco las cosas. Ya me indicó en su momento @mcleod_ideafix una referencia para implementar un controlador de este tipo de memoria.

Conozco algo de Electrónica Digital y también de VHDL porque tenía algunas asignaturas en las que se daba, pero hace ya mucho tiempo de esto y no me acuerdo de muchas cosas. Así que el tutorial que estás haciendo me viene muy bien. Lo que me falta todavía es el programador JTAG, pero creo que pediré uno de esos por USB de 30 €.

Pues nada, te iré siguiendo en el tutorial y trataré de aportar en lo que pueda.

[mcleod_ideafix]

o sea, que sí o sí, tienes que mezclar, con el "kakao" mental que eso produce.

En su momento tuve que decidir con qué lenguaje quería comenzar con esto del diseño HDL. Mis compañeros de departamento usan VHDL, pero a mi el VHDL me ha parecido siempre muy "verboso" (tienes que escribir un montón de palabras para casi cualquier cosa) y el Verilog es mucho más compacto. Me recordó a la diferencia entre programar en COBOL y hacerlo en C (aunque para ser exactos, debería hacer la comparación entre el ADA, del cuál deriva VHDL, y el C, del cuál deriva Verilog). Como vengo del C, la curva de aprendizaje de Verilog me resultó más suave.

Lo que no quiere decir que Verilog me parezca mejor lenguaje que VHDL. VHDL tiene dos cosas que echo de menos en Verilog: el tipado estricto (lo que evita errores que en Verilog es fácil que ocurran, igual que pasa con el C), y el concepto de varias arquitecturas para una misma entidad, o lo que es lo mismo: poder implementar una entidad de varias formas diferentes, y poder elegir en tu diseño qué implementación es la que quieres (puedes tener una implementación al nivel RTL o de comportamiento, fácilmente sintetizable, y otra orientada a la simulación, no sintetizable)

[antoniovillena]

Ya tengo publicada la segunda lección.

@mike_01 si tienes la MOD-VGA genial. No te preocupes que se pueden hacer muchas cosas sin RAM externa, hasta la lección 4 no la usaré. Aunque si eres capaz también puedes hacer los cambios para que funcione con la SDRAM, o esperar a que alguien los haga. A las malas puedes desoldar el chip y soldarle uno SRAM. Pero desde luego tener la MOD-VGA no te servirá de nada hasta que no tengas el cable.

@mcleod_ideafix Supongo que cada lenguaje tendrá sus pros y sus contras, yo por ahora me voy apañando con VHDL. Como he dicho antes la curva de aprendizaje (desde mi punto de vista) tiene más que ver con los conocimientos previos que tengas de electrónica digital que con el parecido con lenguajes de programación. Por mucho que domines el C o el ADA, si no tienes ni idea de lo que es una puerta lógica, te van a resultar igual de complicados ambos lenguajes de descripción hardware.

[antoniovillena]

Estoy algo atascado en el código de la lección 3. Por alguna razón el Z80 no funciona, y estoy intentando depurar con iSIM para ver el problema y no consigo ver las señales, hay muchas que son indeterminadas. Normalmente cuando he depurado en anteriores lecciones no he tenido ningún problema: le doy a restart, pincho con el botón derecho en clk y le doy a Force Clock... con los parámetros que me interesan y lanzo la ejecución de 1us.

Adjunto el archivo actual por si alguien me puede echar una mano, o al menos darme una pista de cómo se depura correctamente.

[mcleod_ideafix]

En VHDL ya digo que no estoy puesto, pero viendo así tu código por encima, veo que mezclas entidades dependientes de arquitectura con otras que no lo son. Eso es un lío. También veo que aplicas en simulación relojes generados con el DCM. Eso, aunque funcione, es una mala idea (es posible que este sea un caso en el que eso no funcione).

En VHDL, aprovéchate de que puedes asociar más de una arquitectura a una entidad. Así por ejemplo, clock7 puede tener la arquitectura actual, que es adecuada para síntesis (pero sólo para un tipo específico de chip), pero además puedes añadir otra arquitectura, en la que a base de delays dentro de un process crees el reloj de 7MHz tal cual. No sé cómo sería en VHDL, pero un reloj así en Verilog sería algo como esto:

Código: Seleccionar todo

module clock7 (
    input wire clkin_in,
    output wire clkfx_out
    );

    reg ffclk = 0;
    assign clkfx_out = ffclk;
    always begin  // repetir para siempre (el process de VHDL)
      clk = #71.428 ~clk;  // cada 71ns, hay un cambio en el reloj
    end
endmodule

Por supuesto, en este caso, el pin clkin_in no serviría de nada.

En general, cuando hagas un diseño en HDL deja siempre los detalles dependientes de arquitectura fuera del diseño real, y ponlos en los que es el TLD (top level design). El TLD es un "wrapper" que se conecta a tu diseño y le da las señales de reset, clock, etc, que necesita, tomando los recursos del chip para el que implementes. Las salidas que genere tu diseño las rutará a pines reales del chip. En simulación no te hará falta ese TLD, sino otro llamado "test bench" en el que es el mismo fichero contiene los procesos que generan las señales que necesitas (usando delays y esas cosas).

Así, portar tu diseño a una FPGA u otra sólo es cuestión de cambiar el TLD.

Lo mismo se aplica para las entidades que modelan la RAM y la ROM de tu dispositivo. Estás usando entidades propias de Xilinx, que aunque sean simulables, hacen tu código no portable a otro entorno. Para simular modela una ROM y una RAM genérica añadiendo otra arquitectura a tu entidad, y elige cuál de ellas usarás para simulación y cuál para síntesis.

En simulación, el fichero UCF no lo necesitas. Eso sólo es para implementarlo.

PD: y unos comentarios en el código ayudan a quien quiera ayudarte a depurarlo Entiendo que estás modelando algo parecido a un Spectrum con su ULA y demás, ¿no?

-- Actualizado 11 Jun 2013, 18:17 --

Otro ejemplo: debo confesar que mis primeros diseños también eran muy caóticos y no respetaba esto de la jerarquía, pero éste en concreto es bastante maduro: es el diseño del microordenador de Radastan. El TLD para implementación en una Spartan 3 me quedó así:

Código: Seleccionar todo

module tld(
    input clk50,
    input reset,
    output csync,
    output r,
    output g,
    output b,
    output i
    );

// Generación de los relojes
wire clk56;
reg [3:0] clkdiv = 4'b0000;
wire clk35 = clkdiv[3];
wire clk7 = clkdiv[2];
wire clk14 = clkdiv[1];
wire clk28 = clkdiv[0];
always @(posedge clk56)
   clkdiv <= clkdiv + 1;

reloj clk_maestro (
    .CLKIN_IN(clk50),
    .CLKFX_OUT(clk56),
    .CLKIN_IBUFG_OUT(),
    .CLK0_OUT()
    );
   
// Señal de video de 2bpp
wire [1:0] video;
wire analogvideo;
assign r = analogvideo;
assign g = analogvideo;
assign b = analogvideo;
assign i = 1'b1;
videodac senal_video (analogvideo, video, clk56, 1'b0);
      
// Conexión del ordenador al TLD de la Spartan
radastan the_computer (
      .clkvideo(clk7),
      .clkvideo2x(clk14),
      .clkcpu(clk14),
      .clkmem(clk28),
      .reset_n(!reset),
      .csync(csync),
      .video(video)
      );

endmodule


El diseño de ese microordenador es basicamente la entidad "radastan" que aparece instanciada casi al final del fichero. Ahí se ve que el diseño tiene tres relojes: uno para video, otro que debe ser el doble del reloj que pongamos para video, y un tercero que es el reloj de la CPU. El cómo se generan esos relojes es algo que a "radastan" no le compete, ya que si este módulo se implementa en una Spartan, pues se usará el DCM (como es de hecho este caso). Si se implementa en una FPGA de Altera, será el PLL. Si se implementa en una CPLD, pues será lógica discreta externa a esa CPLD, etc.

Otra cosa de la que "radastan" no debe preocuparse es cómo se envía la señal de video al dispositivo que vaya a presentarla. "radastan" genera una señal de video de dos bits más sincronismos. El monitor que tengo es RGB analógico, así que fuera de "radastan" hago la conversión digital-analógico (un conversor sigma-delta que instancio mediante el módulo "videodac") y replico la señal en los tres canales RGB para verla en tonos de grises.

Lamento no poder darte ejemplos en VHDL, pero como ya comenté en este mismo hilo, con ese lenguaje me pierdo con tanta palabra

[Joss]

Yo voy a intentar seguidos, a ver si aprendo algo .....

[antoniovillena]

Muchas gracias McLeod. Bueno he avanzado algo pero sigo sin poder arrancar el spectrum. Los fallos en la simulación los arreglé inicializando algunas variables a cero (contadores hcount, vcount y flash) y poniendo algunos parámetros más en la bram (di y dip). Lo malo es que en la simulación no funciona bien la BRAM, y estoy seguro que es culpa de la simulación porque en la ejecución (en hardware real) se ve bien.

Ahora tengo otros problemas, no sé si es por culpa de la contención pero tengo problemas al escribir en vram. Por ejemplo si utilizo LD (HL), 0 puedo borrar bien la zona de atributos, sin embargo falla cuando lo hago con LDIR.

Como comentas el diseño es muy dependiente de la arquitectura. Se emplean tanto los DCMs como BRAMs que sólo existen en XILINX, pero al menos los he separado en módulos. Sería cuestión de que más adelante genere módulos alternativos para clock7, vram y rom que no dependan de la arquitectura. Más o menos sé como se hace, porque el core T80 hace lo mismo. Existen 2 implementaciones distintas para los registros, T80_Reg.vhd y T80_RegX.vhd, la última dependiente de la arquitectura. Dependiendo de cual de los 2 archivos incluyas el diseño funcionará en una Altera (caso 1) o será más eficiente en recursos (caso 2).

Mas o menos entiendo lo que me dices, lo que tu llamas TLD yo lo he llamado main, y sería el módulo al que le afecta el archivo .UCF y el que tiene pines "tangibles" físicamentes.

Respecto a test_bench, sé que VHDL tiene instrucciones específicas para simulación, pero todavía no le he metido mano a eso. Lo que hago es forzar las señales, con "Force clock" para el reloj y "Force constant" para el reset tengo lo suficiente para las simulaciones que estoy haciendo, aunque seguro que me quedaré corto para más adelante.

En cuanto al ejemplo de radastán, aunque esté en Verilog creo que se como va. Lo que haces es "aislar" el ordenador completo en un módulo, dejando la TLD con muy poco código. En los ejemplos del tutorial cargo bastante el main (lo que sería la TLD), pero con vistas a que en un futuro meta toda la funcionalidad de la ULA en un archivo ula.vhd.

[jotego]

a mi el VHDL me ha parecido siempre muy "verboso"

Según la RAE: "verboso: Abundante y copioso de palabras.", aunque parezca mentira, antes de la opción "-v" de la línea de comandos ¡ya existía la palabra verboso!

Yo uso verilog porque en la empresa sólo se uso ese. Me sumo además a @McLeod: VHDL tiene mucha verborrea.

[mcleod_ideafix]

a mi el VHDL me ha parecido siempre muy "verboso"

Según la RAE: "verboso: Abundante y copioso de palabras.", aunque parezca mentira, antes de la opción "-v" de la línea de comandos ¡ya existía la palabra verboso!

Yo uso verilog porque en la empresa sólo se uso ese. Me sumo además a @McLeod: VHDL tiene mucha verborrea.

Gracias! Con esa información, dejaré de ponerlo entre comillas

-- Actualizado 11 Jun 2013, 20:02 --

Ahora tengo otros problemas, no sé si es por culpa de la contención pero tengo problemas al escribir en vram. Por ejemplo si utilizo LD (HL), 0 puedo borrar bien la zona de atributos, sin embargo falla cuando lo hago con LDIR.

Curiosamente, mi primera implementación del Jupiter ACE tenía un error y no conseguía dar con él, que impedía que arrancara la máquina. Depurando la ejecución del código de la ROM en el iSim me di cuenta de que LDIR... ¡funcionaba mal! Resultó que me había bajado no la versión estable, sino una más avanzada, completamente inestable, del core del T80, en donde precisamente LDIR no funcionaba No digo que sea eso lo que te ha pasado a ti, porque es que además lo de la contención es muy tema muy puñetero, y probablemente sea eso y no nada del T80, pero sí significa que tendrás que depurar la ejecución del código a ver qué está pasando con LDIR.

Otra idea: elimina la contención y deja que el Z80 siempre tenga su reloj estable y dándole la prioridad a él sobre la "ULA", aunque eso signifique que la pantalla tenga basura (sólo la verás cuando haya accesos a la memoria de video mientras se está representando el area activa en pantalla). Con eso podrás descartar que el fallo no venga de otro sitio que no sea el circuito de contención.

[antoniovillena]

Pues no sé si será la misma que la tuya, pero uso la versíon 303 del T80, que la he encontrado por otro sitio. En opencores está disponible una versión más antigua a esta. Y de entre todas las posibilidades he escogido la opción asíncrona (el archivo Z80A).

Por lo que veo la depuración en estos casos es un coñazo. En el diseño que tengo no sé porqué pero la simulación me falla cuando se accede a BRAM, sin embargo en la mod-vga se lee bien de la BRAM. Así que voy a tener que ir probando diferentes cosas. De momento seguiré tu idea de meterle un reloj continuo a la CPU y priorizarla sobre la ULA.

Si no, me tendré que poner a depurar con iSIM, aunque antes tendré que buscar una implementación alternativa los bloques BRAM que no me dé problemas.