Para la realización de dicha prueba se conectó a la placa el módulo con el convertidor analógico-digital y la VGA, y se programó. El resultado tras la depuración del fichero .ucf fue el correcto funcionamiento del sistema en modo simulación (podía verse la señal triangular en la pantalla), esto es, utilizando el modelo interno del ADC; sin embargo, hubo problemas con el convertidor externo (la señal que salía por pantalla permanecía a cero). El sistema no pudo depurarse completamente por falta de tiempo, y aunque las causas del fallo barajadas a priori eran problemas con el HW (cable mal conectado…) o problemas con la interfaz al ADC (pero en las simulaciones no se observaron problemas), un repaso de la documentación reveló la causa más probable, repasemos para ello el modelo del ADC (ver apartados interfaz e imperfecciones): http://osciloscopiodigital.wordpress.com/2008/04/20/modelo-del-adcs7476/

En el cronograma proporcionado por el fabricante vemos que la señal CS debe permanecer activa durante toda la adquisición de la muestra, y vemos que aunque habíamos previsto el problema, se diseñó la unidad de control de la unidad de adquisición como si el ADC comenzara la adquisición con el flanco descendente. Las soluciones posibles serían la modificación de la UC de la unidad de adquisición para que mantenga CS activa el tiempo necesario o colocar un bloque que prolongue la duración de la señal CS_OUT; en todo caso el fallo está localizado.

Nos despedimos finalmente de los que hayan podido interesarse por la aplicación comentada aquí, esperamos que haya sido de interés para los lectores.

Los archivos se encuentran comprimidos en ficheros con formato 7z autoextraibles.

INTERFAZ

A continuación se muestra una breve descripción de las señales de entrada y salida de la UC, siendo ésta superficial, aunque en el fichero vhdl pueden verse con detalle las funciones de cada señal:

El bloque diseñado dispone de las entradas típicas de reloj (clk) y de reset síncrono (reset). Una vez aplicada la señal de reset, la UC inicializa todos los circuitos del sistema final mediante dos señales de reset, una global (reset_out) y otra para el divisor de frecuencia (reset_clk_out). Se incluyeron además dos señales de salida para el control de dos leds (led_interfaz y led_funcionando), que indicarán respectivamente que se esperan las modificaciones pertinentes en la interfaz (amplitud: ampli_in; periodo: peri_in; modo simulación: simul_in) y consiguiente activación de la señal de comienzo (empieza), y estado de funcionamiento del osciloscopio. Además se incluye una señal de entrada (cambio) que lleva a la UC al estado “interfaz” (estado 6). Asimismo, la UC incluye salidas de control para todos los bloques (inicio_adq, inicio_pro, inicio_vga; simul_out, peri_out, ampli_out; sel_mux_adc, sel_mux_vga) y entradas de dichos bloques (fin_adq, fin_pro, fin_vga).

SECUENCIA INTERNA DE OPERACIONES

Puede verse a continuación el diagrama de secuencia de operaciones de la UC, aunque se obviaron las activaciones de señales permitiendo una visión de más alto nivel:

Cabe resaltar que los flags a los que se refiere el diagrama son señales que permanecen activas tras la activación de las señales (biestables): cambio, empieza, y fin_vga. Cada una de las citadas señales tiene su flag, y nacen de la necesidad de memorizar la activación de dichas señales ya que ésta podría durar un único ciclo y la comprobación sólo se realiza en determinados estados.

Por ejemplo, la señal fin_vga se activa durante un ciclo de reloj tras la finalización de la representación, y si esto ocurre antes de la activación de la señal fin_adq, la FSM se quedará indefinidamente en el estado 7 esperando la activación de fin_adq, la cual no volverá a producirse. Así, se soluciona este problema introduciendo un biestable que se resetea tras su comprobación.

VERIFICACIÓN DE LA UC

En la siguiente figura pueden verse las simulaciones funcional y temporal de la UC diseñada. Cabe resaltar que para las señales fin_* , se utilizaron las señales inicio_* correspondientes retardadas cierto número de ciclos (no el que tardarían realmente, pero esto es indiferente para la verificación actual) con un retardo “tipo transporte” y no “tipo inercial” (tipo predeterminado), ya que éste último no sigue las variaciones.

Simulación funcional: En la primera gráfica se ve la inicialización y normal funcionamiento, y en la segunda se prueba el cambio en la interfaz.

Simulación temporal: Se incluye también un extracto de la simulación temporal, ya que no sería suficiente con la temporal para concluír un correcto funcionamiento. El estado indeterminado en las señales fin_* se deben como se comentó arriba al modelo transport del retardo utilizado para esas señales.

CAMBIOS EN LA UNIDAD DE ADQUISICIÓN

Inicialmente se había realizado el modelo del ADC para un reloj de 25 MHz, cuando el ADC real trabaja como máximo a 20 MHz. Para la solución de este problema se planteaban dos posibles soluciones: introducir un bloque “gestor de reloj digital” (DCM) que generara una señal de 20 MHz o cambiar el divisor de frecuencia 1/2 por otro 1/10 (la implementación del divisor de frecuencia no aconseja la elección de un divisor 1/5, ya que al ser impar el número de ciclos de 10 ns necesarios para hacer un ciclo de 50 ns, el cambio de nivel alto a bajo debería hacerse por flanco descendente; además entre 5 y 10 MHz no llega a haber un orden de magnitud y al ser ésta una aplicación didáctica podemos permitirnos la consecuente pérdida de calidad del osciloscopio). Finalmente se optó por esta última opción por ser la más sencilla, aunque no se descarta la anterior si una vez terminado el proyecto sobra tiempo. Además se introdujo un contador en la unidad de control de esta unidad para mantener las señales necesarias para controlar el ADC activas durante 10 ciclos, ya que la UC trabaja con el reloj de 50 MHz y el ADC con el de 5 MHz.

En esta imagen puede verse un extracto de la simulación del ADC donde vemos un ciclo de muestreo:

Puede apreciarse además en las gráficas que se muestran a continuación que el tiempo total de operación, comprendido entre las activaciones de las señales “inicio_adq” y “fin_adq” se ve incrementado al hacerlo el período del reloj del ADC. Finalmente el período de muestreo es 4 μs (como es lógico resulta ser 4 veces el obtenido en simulaciones anteriores, dado que la nueva frecuencia de reloj es un cuarto de la anterior) y el tiempo total de operación es 2.564 ms, tiempos que no se ciñen a los estimados al inicio de este proyecto pues los cálculos se habían realizado con el reloj de 20MHz, pero por otra parte no se salen de las restricciones de tiempo real (el tiempo total de operación).

PRUEBA DE LA UNIDAD DE ADQUISICIÓN CON LA BRAM

Para la simulación conjunta de estos dos bloques, se han interconectado dentro de otro bloque. Aunque las simulaciones vistas arriba también se han realizado conjuntamente con la BRAM, ahora comentaremos sus implicaciones:

En la figura, se realiza dos veces la simulación y en la segunda el ADC vuelve a escribir los mismos datos (ya que se reinicializa, no así la BRAM), realizándose lecturas previas al establecer la dirección, pudiendo observarse los resultados esperados.

BLOQUES USADOS EN LAS MEMORIAS

En nuestro sistema usamos dos bloques de memoria:  un bloque está destinado al almacenamiento de las muestras adquiridas por parte de la unidad de adquisición, y un segundo bloque se dedica a almacenar el mapa de la pantalla en formato pixel después de procesar adecuadamente las muestras adquiridas.

El primer bloque ha sido implementado en la propia FPGA usando una memoria Block RAM de 1 K x 16 bits, instanciada según las plantillas de Xilinx. Disponemos de un bus de direcciones de 10 bits, y un bus de datos de 16 bits, con dos bits de paridad.

Esta memoria consume todos los recursos disponibles en la FPGA para este tipo de circuito. En conjunto con el bloque BRAM disponemos de un multiplexor conectado a las unidades de adquisición y procesado. Este multiplexor permite que ambas unidades accedan de manera independiente a la BRAM. La unidad de adquisición solamente efectuará operaciones de escritura en la memoria, mientras que la unidad de procesado efectuará operaciones de lectura. El multiplexor permite seleccionar la dirección de escritura/lectura en la memoria BRAM, mediante una variable de selección de la salida del multiplexor (conteniendo la dirección efectiva a la cual se quiere acceder en la memoria BRAM) que será operada desde la unidad de control principal del sistema.

El segundo bloque se basa en una memoria SRAM externa presente en la placa Digilent S3 Starter Board. La memoria SRAM dispone de dos módulos de 512 Kbytes.

Para está implementación usamos solamente uno de los módulos disponibles. Disponemos de un bus de direcciones de 18 bits y un bus de datos de 18 bits con 2 bits de paridad.

Para el control de esta memoria externa disponemos de dos circuitos: un multiplexor y un buffer intermedio. El multiplexor cumple las mismas funciones que el usado en el bloque destinado a la memoria BRAM. En este caso se permiten operaciones de escritura en la memoria por parte de la unidad de procesado, y operaciones de lectura por parte de la unidad de visualización. El buffer intermedio dispone de tercer estado y permite el envío de datos a la memoria SRAM por parte de la unidad de procesado, y su puesta en tercer estado cuando se realicen operaciones de lectura por parte de la unidad de visualización. Se ha implementado este sistema para evitar que ambas unidades puedan interferirse en su acceso a la memoria SRAM, ya que el puerto de datos de la memoria es de entrada/salida.

A continuación podemos observar la jerarquía de los ficheros vhd que contienen los circuitos diseñados para ambos bloques de memoria.

Veremos ahora la simulación del bloque correspondiente a la memoria BRAM (memoria_adq_pro).

En esta simulación escribimos dos datos consecutivos en la memoria BRAM por parte de la unidad de adquisición (cuando la variable sel_mux es igual a cero y write_enable está habilitado) en la dirección d”0″ y en la dirección d”2″. Después leemos de la posición d”0″ cuando sel_mux es igual a uno (simulando la lectura por parte de la unidad de visualización), para volver a escribir en la posición d”3″, y nuevamente leer de la posición d”2″.  La salida en esos instantes de lectura son los datos que habíamos escrito anteriormente con la unidad de procesado. En el momento que cambiamos la dirección de escritura/lectura, la salida es  cero hasta una nueva orden de escritura o lectura (ya que la memoria esta inicialmente a cero en todas sus posiciones). Nótese que la señal de reset en este caso se denomina ssr (sinchronous set and reset). Los cursores señalan el comienzo de la primera operación de lectura/escritura.

Ahora veremos la simulación del bloque correspondiente a la memoria SRAM

(memoria_pro_VGA) .

En esta simulación escribimos datos desde la unidad de procesado (con sel igual a cero escribimos al estar we_in activo a nivel bajo) y leemos datos consecutivamente desde la unidad de visualización (con sel igual a uno). Cuando efectuamos la operación de lectura el buffer intermedio se pone en tercer estado para evitar que los datos provenientes de la unidad de procesado se escriban mientras estamos leyendo. Puede observarse que el tercer estado se activa cuando la señal sel es igual a uno (operación de lectura). Durante esos instantes la salida dato_VGA_out está en tercer estado. Esto es así debido a que la memoria SRAM nos está incluida en la FPGA, por lo que al hacer una operación de lectura el bus de datos está “al aire”, prevaleciendo la señal de tercer estado proveniente del buffer intermedio, conectada al puerto de entrada/salida de datos de la memoria SRAM. Cuando el circuito se encuentre implementado en la placa, la salida en tercer estado para una operación de lectura será obviamente el dato contenido en la posición de memoria desde la cual se quiere leer (dirección dada por dir_out, que es modificada por las direcciones desde la unidad de procesado para escrituras con sel igual a cero o desde la unidad de visualización con sel igual a uno).

Nótese que al no tener disponible la memoria SRAM real, también se ha obviado la señal de reloj necesaria para esta, pero que estará implementada en el sistema final.

No se ha creído necesario crear un modelo de la memoria SRAM para su simulación, entre otros motivos por la falta de recursos de la FPGA utilizada. No obstante si el tiempo lo permite podría hacerse un modelo usando toda la capacidad disponible de la FPGA en una memoria BRAM interna, para la prueba del presente bloque.

El presente articulo también se ha incluido en la carpeta Skydrive en formato pdf para facilitar su consulta offline.

1.-ESTRUCTURA

Este bloque se compone de dos módulos, uno con la parte operativa (bloque_util_adq) y otro con la de control (uc_adq):

1.a.-UNIDAD DE CONTROL

La unidad de control debe activar las señales pertinentes para la realización de la adquisición. Está implementada mediante una máquina de estados finita, siguiendo el siguiente diagrama de secuencia de operaciones:

Los contadores a los que se hace referencia son dos:

• Contador_de_t: para variar la frecuencia de muestreo.
• Contador_col: para capturar 640 datos.

Cabe destacar que en el diagrama no se explicitan las asignaciones a señales sino que éstas van implícitas en las descripciones de los estados, lo que facilita su comprensión. También que la FSM no se realizó con ningún programa específico, sino que se creó directamente en vhdl, dado que resultó ser así más sencilla su realización por la necesidad de contadores adicionales, decisión que aunque por una parte podría no aprovechar todas las posibilidades en cuanto a rendimiento de la FPGA, sí aumenta la portabilidad del diseño a otros dispositivos de lógica programable e independiza el diseño de programas específicos.

1.b.-UNIDAD OPERATIVA

La unidad operativa está formada por tres bloques: el modelo del ADC, un multiplexor, el receptor del puerto serie, y un bloque divisor de frecuencia de reloj.

• El modelo ADC fue implementado para probar el sistema, y aunque en un principio no pretendía formar parte del sistema final decidió incluírse para evitar la existencia de diferentes versiones de éste, además de permitir la prueba de la parte de procesado y visualización (ya que proporciona una fuente determinista de información) y ayudar a la detección de problemas una vez implementado en la placa. No se profundizará sobre detalles de su implementación ya que esto se hizo anteriormente.
• El multiplexor permite seleccionar como entrada al receptor serie-paralelo la salida del ADC interno o del externo.
• El receptor serie-paralelo recibe la trama y extrae de ella el dato de 12 bits, tarea para la cual necesita tres bloques:

§         Bloque de retardo: registro de desplazamiento de 5 bits si se selecciona la entrada del modelo del adc, 3 si es la externa, con un detector de flancos ascendentes a su entrada para conseguir la señal de inicio de conversión serie-paralelo del dato extraído del adc. La explicación de este retardo se basa en la inclusión al inicio de la trama de 4 ceros, lo que implica 4 registros para su retardo. Como el detector de flancos retarda un ciclo el pulso recibido, se utilizarán 3 registros. Los 2 adicionales para el modelo de ADC surgen de la imperfección del modelo realizado, que genera la trama con dos ciclos de retraso. El pulso retardado en este bloque dispara el siguiente bloque.

§         Bloque de control de desplazamiento: está formado por un contador y un circuito combinacional que genera el pulso de habilitación de los registros de desplazamiento de 12 bits donde se guardan los datos extraídos del ADC, además de indicar la finalización del desplazamiento con la activación de una señal.

§         Bloque de desplazamiento: 2 registros de 12 bits de desplazamiento colocados en serie en los que queda la muestra actual y la previa tras la adquisición de un dato. El almacenado de la muestra previa no provee todavía utilidad alguna, pero será útil en el momento de inclusión de un circuito de disparo para comenzar la adquisición con un cruce por cero, tras un máximo o mínimo…

·         El circuito divisor de frecuencia de reloj tiene por objeto generar la señal de reloj para alimentar al convertidor analógico-digital externo, ya que la frecuencia utilizada por el sistema es lo doble que la máxima que permite.

2.-INTERFAZ

Al inicio del apartado anterior (1.-ESTRUCTURA) pueden observarse las entradas y salidas del bloque diseñado.

• El reloj de entrada será el mismo que el del sistema, 50MHz.
• Se incluyen dos señales diferentes de reset, ya que es necesario inicializar el bloque divisor de frecuencia antes que activar el reset global del sistema. Esto es así porque todos los reset son síncronos, y si se inicializa todo con un único reset los circuitos dependientes del reloj de 25MHz quedan sin inicializar al no tener señal de reloj durante su reseteo. Por tanto, primero debe aplicarse el pulso al terminal de reset_clk (que únicamente va conectado al bloque divisor de frecuencia) y luego el pulso al terminal de  reset global.
• La entrada simul debe permancer a ‘1’ si se utiliza el ADC interno (modelo) y a ‘0’ en caso de utilizar el ADC externo, cuyos terminales conectaremos con los de la unidad de adquisición: sdata->sdata_externo, cs->cs_out, clk->clk25_out.
• Las señales amplitud y frecuencia permiten aplicar una “amplificación digital” a la señal muestreada y variar la frecuencia de muestreo respectivamente, aunque sus funcionalidades no han sido implementadas todavía.
• La unidad de adquisición se conecta con la BRAM por medio de we_ram ( terminal de habilitación de escritura), puntero_ram (dirección) y dato_ram (dato de entrada).
• Una vez configurada la unidad con los parámetros pertinentes mediante la activación de las señales correspondientes, se inicia el proceso de adquisición mediante un pulso en la entrada inicio_adq. Cuando el proceso finalice, quedarán en las primeras 640 posiciones de la BRAM los datos muestreados y se generará en la salida fin_adq un pulso para indicar tal finalización.

2.-FUNCIONAMIENTO

No incluiremos en esta publicación todos los test realizados a todos los subsistemas que forman la unidad operativa, aunque estos han sido realizados y verificados, para no incrementar demasiado la extensión de la misma; pero sí se incluye a continuación la gráfica resultante de la prueba del sistema final (unidad operativa):

En la gráfica puede verse la inicialización, cómo la señal de reloj de 25 MHz no empieza hasta la aplicación de reset_clk, luego se aplica la señal de reset; y posteriormente inicio_adq. Puede observarse cómo dato_ram es igual al puntero más uno: esto es así ya que la inicialización del ADC interno genera la muestra cero, y por tanto la primera vez que se pida una muestra ésta será la siguiente, esto es, x”001”.

En la segunda gráfica podemos ver la finalización con activación de la señal fin_adq. Puede observarse que la frecuencia de muestreo máxima es 1/0.88 us = 1.14MHz.

Y en la tercera podemos ver la duración mínima total del proceso de adqusición: 563.24 us. Puede comprobarse que está dentro de los márgenes estimados si revisamos las especificaciones establecidas al inicio del diseño.

En la próxima publicación incluiremos la simulación temporal y la prueba con la BRAM, con lo daremos por finalizada la implementación de la unidad operativa básica. Intentaremos asimismo realizar las ampliaciones pertinentes para permitir la selección de amplitud y frecuencia, así como la selección del tipo de disparo para la captura tan pronto como nos sea posible.

El diseño de este bloque funcional, que no pertenece al sistema completo a introducir en la FPGA, nace de la necesidad de una caja negra que proporcione en las simulaciones una fuente de muestras, con una interfaz que se corresponda con la del ADC al que controlará el sistema final. Así, buscando un diseño sencillo, se optó por la salida de un contador (de 8 bits, aunque el dato que proporciona el ADC es de 12 bits, se han puesto a ‘0’ los 4 bits más significativos ya que no es objetivo ocupar todo el rango, y en caso de que así fuera, siempre puede sustituírse el contador por otro más “grande”). Se pensó también en una memoria con las muestras, pero repetimos, se buscaba la máxima sencillez posible.

El modelo se compone de:

• Un contador de 8 bits para generar la muestra en paralelo (4 bits a cero + 8 bits del contador).
• Un multiplexor de 16 a 1 para serializar la muestra e introducir los bits de sincronización.
• Un contador de 4 bits para controlar el multiplexor.
• Un circuito auxiliar para seleccionar el sentido del contador de 8 bits, ya que el contador va de x”00” a x”FF” en sentido ascendente y vuelve a x”00” en sentido descendente, y así sucesivamente.
• Un circuito auxiliar para controlar el contador de 4 bits y la salida en tercer estado del modelo del ADC.

El esquema interno es el que sigue:

En cuanto a la interfaz, cabe resaltar que el modelo tiene 4 terminales, uno más que el circuito real (RESET). Como el bloque diseñado sólo se utilizará en simulaciones, se ha incorporado un terminal para la inicialización de circuitos internos. Los demás terminales se comportan tal y como describe la hoja de características del ADC: la señal de reloj se conecta a CLK; se inicia una nueva conversión para cada flanco descendente en CS; y la salida en serie se hace por SDATA siguiendo el protocolo descrito en la hoja de características:

Es importante comentar que el modelo no se ciñe completamente a las especificaciones:

• En el diagrama puede observarse cómo tras el flanco descendente de CS (aunque en el dibujo pueda parecer que durante la conversión CS debe permanecer a ‘0’, en el texto se indica que las conversiones se inician con un flanco descendente) se inicia la salida serie, mientras que en el modelo tal salida serie no se inicia hasta 2 ciclos de reloj después. Esto se traduce en el diseño introduciendo en la “unidad de adquisición” un bloque que retarde la adquisición 2 ciclos tras el flanco descendente en CS, que será eliminado cuando se introduzca el sistema en la FPGA, o bien en el arreglo ya que sus causas son conocidas: un ciclo porque el contador de 4 bits se queda en x”F” y no en x”0” y otro ciclo debido al biestable de salida con tercer estado.
• El reloj se invierte justo al llegar a la entrada del sistema, dado que el inicio de los bits en la salida serie se hace con flancos descendentes de reloj. Sería más correcto utilizar entradas por flanco descendente en los bloques internos, pero este modelo no va a ser implementado en la FPGA, motivo por el cual no se invertirá mucho tiempo en él, aunque si el tiempo lo permite se intentará depurar para ceñir su funcionamiento al máximo al circuito real.

Tales imperfecciones no tienen una gran importancia, el sistema funciona bien y su diseño es consistente, y no propagará problemas a los demás bloques si dichas imperfecciones son tenidas en cuenta. Reiteramos que el bloque diseñado no pertenece al sistema y no debe invertirse en él más tiempo del necesario, aunque si fuera necesario se volverá sobre su depuración y se informará de ello en la presente publicación.

Se incluye a continuación un extracto de la simulación real del modelo, en la que se muestran los terminales del bloque y los estados de los contadores:

Enlaces de interés:

• Hoja de características del ADCS7476:

http://www.national.com/mpf/DC/ADCS7476.html

A continuacion se puede observar el contenido de la primera version de cada uno de los ficheros vhd.

———————————————————————————-

– Company:        Universidad de Vigo

– Engineer:             Pablo Porta González

–                            Antonio José Vázquez Álvarez

– Create Date:    17:13:09 04/13/2008

– Design Name:

– Module Name:    Generador_pulsosync_horizontal – pulso_sincronia_horizontal

– Project Name:   Osciloscopio_Digital

– Target Devices: xc3s200

– Tool versions:  ise Foundation 8.2i

– Description:    Circuito generador de la senhal de sincronismo horizontal para

–                                 una senhal VGA (fin de la linea)

– Dependencies:

–

– Revision:

– Revision 0.01 – File Created

– Additional Comments:

–

———————————————————————————-

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

—- Uncomment the following library declaration if instantiating

—- any Xilinx primitives in this code.

–library UNISIM;

–use UNISIM.VComponents.all;

entity Generador_pulsosync_horizontal is

Port ( clk50MHZ : in  STD_LOGIC;  –senhal de reloj

reset : in  STD_LOGIC;     –senhal de reset sincrono

contador_horizontal : in  STD_LOGIC_VECTOR (10 downto 0); –contador del numero de pixeles

Pulso_sync_horizontal : out  STD_LOGIC);                  –senhal de sincronia horizontal

end Generador_pulsosync_horizontal;

architecture pulso_sincronia_horizontal of Generador_pulsosync_horizontal is

–Declaracion de senhales auxiliares

———————————————————————————-

SIGNAL h_ctr: integer range 1586 downto 0;  –contador de estado (tenemos 1586 ciclos de reloj para una linea)

SIGNAL pulsoH_aux, cambio_estado: STD_LOGIC;–senhal de pulso de sincronia horizontal auxiliar, estado del pulso

–Descripcion del circuito

———————————————————————————-

begin

Pulso_sync_horizontal<=pulsoH_aux;

h_ctr<=CONV_INTEGER (contador_horizontal); –conversion de tipos (vector->entero)

–generacion del pulso de sincronia horizontal

———————————————————————————–

PULSO: Process (clk50MHZ,reset,cambio_estado)

begin

if reset = ’1′ then

pulsoH_aux <= ’1′;

elsif clk50MHz=’1′ and clk50MHz’event then

if cambio_estado = ’1′ then     –comprobamos si el pulso horizontal ha de cambiar de estado

pulsoH_aux <= not pulsoH_aux;

else

pulsoH_aux <= pulsoH_aux;

end if;

end if;

end process; –end PULSO

–el pulso horizontal debe cambiar de estado en instantes determinados

———————————————————————————–

ESTADO: Process (h_ctr)

begin

if (h_ctr = 1326) or (h_ctr = 1514) then

cambio_estado <= ’1′;

else

cambio_estado <= ’0′;

end if;

end process;–end ESTADO

end pulso_sincronia_horizontal;

———————————————————————————-

– Company:              Universidad de Vigo

– Engineer:             Pablo Porta González

–                            Antonio José Vázquez Álvarez

– Create Date:    17:46:33 04/13/2008

– Design Name:

– Module Name:    Generador_pulsosync_vertical – Behavioral

– Project Name:   Osciloscopio_Digital

– Target Devices: xc3s200

– Tool versions:  ise Foundation 8.2i

– Description:    generador del pulso de sincronia vertical para una señal VGA

–                 (fin del cuadro de imagen)

– Dependencies:

–

– Revision:

– Revision 0.01 – File Created

– Additional Comments:

–

———————————————————————————-

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

—- Uncomment the following library declaration if instantiating

—- any Xilinx primitives in this code.

–library UNISIM;

–use UNISIM.VComponents.all;

entity Generador_pulsosync_vertical is

Port ( reset : in  STD_LOGIC;    –senhal de reset sincrono

clk50MHZ : in  STD_LOGIC; –senhal de de reloj

contador_vertical : in  STD_LOGIC_VECTOR (9 downto 0); –contador vertical

pulso_sync_vertical : out  STD_LOGIC);                 –pulso de sincronia vertical

end Generador_pulsosync_vertical;

architecture pulso_sincronia_vertical of Generador_pulsosync_vertical is

–Declaracion de senhales auxiliares

——————————————————————————–

SIGNAL V_ctr: integer range 524 downto 0;

–Descripcion del circuito

——————————————————————————–

begin

V_ctr <= CONV_INTEGER (contador_vertical); –conversion de tipos (vector->entero)

–generador del pulso de sincronia vertical

——————————————————————————–

PULSO:Process (clk50MHz,reset,V_ctr)

begin

if reset = ’1′ then

pulso_sync_vertical <= ’1′;

elsif clk50MHz=’1′ and clk50MHz’event then

if (V_ctr >= 500) and (V_ctr <= 502) then

pulso_sync_vertical <= ’0′;

else

pulso_sync_vertical <= ’1′;

end if;

end if;

end process;–end PULSO

end pulso_sincronia_vertical;

———————————————————————————-

– Company:              Universidad de Vigo

– Engineer:             Pablo Porta González

–                       Antonio José Vázquez Álvarez

– Create Date:    19:52:14 04/13/2008

– Design Name:

– Module Name:    CTR_horizontal – contaje_horizontal

– Project Name:   Osciloscopio_Digital

– Target Devices: xc3s200

– Tool versions:  ise Foundation 8.2i

– Description:    contador de los ciclos de reloj necesarios para el sincronismo horizontal

–

– Dependencies:

–

– Revision:

– Revision 0.01 – File Created

– Additional Comments:

–

———————————————————————————-

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

—- Uncomment the following library declaration if instantiating

—- any Xilinx primitives in this code.

–library UNISIM;

–use UNISIM.VComponents.all;

entity CTR_horizontal is

Port ( clk50MHZ : in  STD_LOGIC;  –senhal de reloj

reset : in  STD_LOGIC;    –senhal de reset sincrono

senhal_contaje : out  STD_LOGIC_VECTOR (10 downto 0)); –vector de contaje

end CTR_horizontal;

architecture contaje_horizontal of CTR_horizontal is

–Declaracion de senhales auxiliares

———————————————————————————–

SIGNAL contaje_int: integer range 1586 downto 0; –senhal de contaje

–Descripcion del circuito

———————————————————————————–

begin

senhal_contaje <= CONV_STD_LOGIC_VECTOR (contaje_int,11); –conversion de tipos (entero->vector)

–Proceso de contaje

———————————————————————————–

CUENTA: Process (clk50MHZ,reset,contaje_int)

begin

if reset = ’1′ then contaje_int <= 0;

elsif (clk50MHZ = ’1′ and clk50MHZ’event) then

if contaje_int = 1586 then

contaje_int <= 0;  –en el estado 1,586 volvemos a cero

else

contaje_int <= contaje_int + 1;

end if;

end if;

end Process; –end CUENTA

end contaje_horizontal;

———————————————————————————-

– Company:              Universidad de Vigo

– Engineer:             Pablo Porta González

–                       Antonio José Vázquez Álvarez

– Create Date:    20:25:01 04/13/2008

– Design Name:

– Module Name:    CTR_vertical – contaje_vertical

– Project Name:   Osciloscopio_Digital

– Target Devices: xc3s200

– Tool versions:  ise Foundation 8.2i

– Description:    Contador de ciclos de reloj para la senhal de sincronismo vertical

–

– Dependencies:

–

– Revision:

– Revision 0.01 – File Created

– Additional Comments:

–

———————————————————————————-

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

—- Uncomment the following library declaration if instantiating

—- any Xilinx primitives in this code.

–library UNISIM;

–use UNISIM.VComponents.all;

entity CTR_vertical is

Port ( Sync_horizontal : in  STD_LOGIC;

senhal_contaje : out  STD_LOGIC_VECTOR (9 downto 0);

reset : in  STD_LOGIC;

clk50MHZ : in  STD_LOGIC);

end CTR_vertical;

architecture contaje_vertical of CTR_vertical is

–Declaracion de senhales auxiliares

——————————————————————

SIGNAL contaje_int : integer range 524 downto 0;

SIGNAL H_sync_aux,H_sync_t_1,Fa_H_sync: STD_LOGIC; –senhales para el computo del flanco de reloj

–Descripcion del circuito

——————————————————————

begin

senhal_contaje <= CONV_STD_LOGIC_VECTOR (contaje_int, 10); –conversion de tipos (entero->vector)

–Detector de flancos ascendentes para el sincronismo horizontal

——————————————————————-

DETECTOR: Process (reset,clk50MHz,H_sync_aux,H_sync_t_1)

begin

if reset = ’1′ then     H_sync_aux <= ’0′;

H_sync_t_1 <= ’0′;

elsif (clk50MHz = ’1′ and clk50MHz’event) then

H_sync_t_1 <= H_sync_aux;

H_sync_aux <= Sync_horizontal;

end if;

FA_H_sync <= H_sync_aux and not H_sync_t_1;

end process;–end DETECTOR

–contador vertical

——————————————————————

CONTADOR: Process (FA_H_sync,reset,contaje_int,clk50MHz)

begin

if reset = ’1′ then

contaje_int <= 0;

elsif (clk50MHz=’1′ and clk50MHz’event) then

if FA_H_sync = ’1′ then

if contaje_int = 524 then

contaje_int <= 0;

else

contaje_int <= contaje_int + 1;

end if;

end if;

end if;

end process;–end CONTADOR

end contaje_vertical;

———————————————————————————-

– Company:              Universidad de Vigo

– Engineer:             Pablo Porta González

–                       Antonio José Vázquez Álvarez

– Create Date:    18:09:04 04/13/2008

– Design Name:

– Module Name:    Generador_blanking – pulso_de_blanking

– Project Name:   Osciloscopio_Digital

– Target Devices: xc3s200

– Tool versions:  ise Foundation 8.2i

– Description:    generador del pulso de blanking para la senhal VGA

–

– Dependencies:

–

– Revision:

– Revision 0.01 – File Created

– Additional Comments:

–

———————————————————————————-

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

—- Uncomment the following library declaration if instantiating

—- any Xilinx primitives in this code.

–library UNISIM;

–use UNISIM.VComponents.all;

entity Generador_blanking is

Port ( clk50MHZ : in  STD_LOGIC;  –senhal de reloj

contador_vertical : in  STD_LOGIC_VECTOR (9 downto 0);   –contador vertical

contador_horizontal : in  STD_LOGIC_VECTOR (10 downto 0); –contador horizontal

reset : in  STD_LOGIC;     –senhal de reset

pulso_blank : out  STD_LOGIC); –pulso de blanking

end Generador_blanking;

architecture pulso_de_blanking of Generador_blanking is

–Declaracion de senhales auxiliares

———————————————————————————-

SIGNAL H_ctr : integer range 1586 downto 0; –senhales de conteo

SIGNAL V_ctr : integer range 524 downto 0;

–Descripcion del circuito

———————————————————————————-

begin

H_ctr <= CONV_INTEGER (contador_horizontal); –conversion de tipos (vector->entero)

V_ctr <= CONV_INTEGER (contador_vertical);

–generacion del pulso de blankeo

BLANKEO:Process (H_ctr,V_ctr)

begin

if ((H_ctr >= 1258) and (H_ctr <= 1586)) or

((V_ctr >= 480) and (V_ctr <= 524)) then

pulso_blank <= ’0′;

else

pulso_blank <= ’1′;

end if;

end process;–end BLANKEO

end pulso_de_blanking;

para facilitar su consulta tambien se ha colgado la primera version de los ficheros en la carpeta skydrive.