"[Common 17-69] Command Failed: '-scan_for_includes' and 'copy_to' are mutually exclusive and cannot be paired together."

Este es un error generado por vivado cuando uno está tratando de hacer un 'add sources'. La ventana de error que aparece es:

El mensaje no es claro en lo que respecta cual es el problema que origina ese mensaje de error. Por ejemplo en la figura de arriba estaba tratando de agregar (Add) el archivo pwm_ip_top.vhd usando el dialogo que aparece para esa tarea. Tal como se ve en la siguiente figura:

La fuente del mensaje de error, es que por defecto, los dos opciones, 'Scan ... ' y 'Copy ...' están seleccionadas por defecto. Para poder solucionar el problema se debe seleccionar una sola:

Hacer click en Finish, el archivo se agregará al proyecto, y no se generará el mensaje de error.

Como agregar el XUPV5 board para Co-Simulación en Hardware con System Generator/Simulink

Co-Simulación en Hardware (Hardware Co_Simulation) es una poderosa herramienta en el ambiente de desarrollo Simulink-System Generator. Permite al diseñador simular en 'paralelo' en real-hardware, lo mismo que se simula en software usando los bloques de SysGen. 
Cando uno installa la version full de ISE, al instalar System Generator por defecto se instalan lo que se llaman 'plug-in' de los boards DSP de Xilinx. Sin embargo, dado que el XUPV5 board no es considerado un 'board DSP' no aparece en la lista de opciones de los boards para llevar a cabo co-simulation. Si aparece el ML505 board, que CASI igual que el XUPV5, pero con una 'pequeña' diferencia: el ML505 tiene un Virtex 5 XC5VLX50T, mientras que el XUPV5 tiene un XC5VLX110T. Pequeña gran diferencia que hace que NO se pueda usar el plug-in del board ML505 para el board XUPV5. Entonces... cual es la salida/solución si uno tiene el XUPV5 y quiere hacer Co-Simulación?????? 

Agregando el XUPV5 a la Lista de Boards de Co-Simulación
Paso 1:
Una vez abierto Simulink y abriendo colocado el bloque 'System Generator' en un diseño cualquiera, abrir el bloque 'System Generator' (doble click sobre el bloque). La ventana de configuración del bloque 'SysGen' aparecerá. Seleccione en 'Compilation' la opción 'Hardware Co-Simulation', y luego en el menú siguiente seleccione 'New Compilation Target'. 

Paso 2:
La ventana 'System Generator Board Description Builder' se abrirá. En esta ventana hay varios elementos a configurar. 
a- Target Board Identification: Board Name: puede usarse cualquier nombre. Convenientemente use uno que facilite la identificación del board. Por ejemplo, XUPV5.
b- System Clock: 1- Frequency(MHZ): escribir la frecuencia del reloj del board que se usará normalmente como fuente de reloj para el FPGA. El oscilador de entrada al LX110T es de 100MHz. 2- Pin Location: el pin de E/S por el cual entra el oscilador el FPGA: AH15.
c- JTAG Options: por defecto la comunicación entre el board y el PC es hara usando JTAG. Hay otra opción que es la de usar Ethernet, pero como la configuración es mas complicada explicare ahora la de JTAG, después, de acuerdo a los pedidos, puedo explicar la de Ethernet. Las opciones de la configuración JTAG son: 1- Boundary Scan Position: esta es la posición del FPGA en la cadena JTAG de dispositivos en el board. El valor a introducir acá es 5, es decir es el quinto dispositivo de la cadena. Usando iMPACT es posible 'ver' la cadena y deducir la posición del FPGA. 2- IR Length: este es un parámetro necesario para la comunicación a través de JTAG. Si está el board conectado a su PC/Laptop por medio del cable JTAG, presione 'Detect' para que automáticamente se invoque iMPACT y llene los datos requeridos. Sino tiene el board conectado directamente escriba: 16,16,8,8,10.

d- Targetable Devices: en esta sección se debe introducir el FPGA que usa el board XUPV5. Click 'Add' y seleccione: Virtex 5, XC5VLX110T, Speed -1, package ff1136. Click OK.
Hasta acá la configuración de esta ventana debería ser similar a la mostrada a continuación: 

e- En la sección 'Non-Memory Mapped Ports' click el botón 'Add' para agregar algunos puertos de E/S del FPGA que considere necesarios. La ventana 'Configure a Port' aparecerá. Introduzca el nombre del puerto de E/S, seleccione la direccion del mismo, y la ubicacion (Location). Opcionalmente puede tambien seleccionar si el puerto deber ser configurado con el resistor de Pullup o Pulldown. Una vez terminado con estas configuraciones, Click 'Add Pin'. El puerto de E/S configurado sera ahora mostrado en la parte llamada 'Pin List'. Para introducir otro puerto seleccione 'Save and Starte New'. Se pueden introducir tantos puertos como hagan falta. Una vez concluida esta tarea, presione 'Save and Close'.

f- Con toda la configuración ya escrita la figura siguiente debería ser similar a la que tienes en tu computadora. 




fig




Si es así, presionar 'Install' para instalar la configuracion del XUPV board en el directorio de plug-in de SysGen.

g- Finalizada la instalación un ventana de Simulink aparecerá con los puertos de E/S configurados. 

Grabe la librería de los puertos de E/S. Estos puertos pueden ahora usarse en cualquier sistema con System Generator. 


i- Para probar que todo esta instalado correctamente, abra el bloque System Generator, y seleccione en 'Compilation', 'Hardware Co-Simulation'. Ahora deberia aparecer en la lista XUPV5 JTAG. 

j- Listo ! ... el XUPV5 puede ahora usarse para correr Co-Simulación en Hardware de su sistema Simulink. Documento pdf

Quartus-ModelSim: Como 'ver' mejor las formas de ondas y facilitar el debug

En un blog anterior (link) describí la personalización de las formas de ondas visualizadas en ModelSim en el entorno ISE de Xilinx. Debido al pedido de muchos de Uds. les presento ahora lo mismo para para los usuarios de Quartus de Altera. Como ya leerán en la nota de aplicación que presento, cuando se invoca cualquier tipo de simulación desde el Quartus, ModelSim es automáticamente abierto, mostrando las formas de ondas resultantes del test bench en el panel llamado Wave View. Debido a la configuración de ModelSim (detallada en un archivo tipo script) que por defecto se invoca, solo las señales de la entidad de mayor jerarquía son mostradas, y ... nada más... Entonces, una vez abierta esta ventana Wave View si se desean ver señales internas del diseño bajo test, o cambiar la posición y/o color de las señales mostradas, o agregar divisores, y tantas otras características que ofrece ModelSim para hacer, es posible llevarlas a cabo, pero una vez cerrado ModelSim todas las modificaciones realizadas se pierden!. Así, cuando se corra la misma simulación de nuevo, se deberá empezar otra vez con las modificaciones. Les suena familiar el problema?????

En la 'Application Note' que les presento se detallan los pasos a seguir, para que cuando se invoque ModelSim desde Quartus, la simulación, y específicamente, el Wave View contenga toda la información que uno desea/necesita para una buena verificación y un fácil debug.

Aqui esta el link para bajar la 'Application Note', que por ahora está en Inglés, pero si hay unos cuantos pedidos, la pasaré al Español: 

C7T AN-08

Hasta la próxima ! 

Como añadir variables en el Waveform window de ModelSim

Necesitas debug el valor de alguna variable? ModelSim te da la opción de poder añadir una o más variables al Waveform window. 
Sin embargo es dificil encontrar info de como 'ver' una variable. Dentro de Modelsim hay que hacer una serie de pasos para poder agregar una variable el Waveform window:

• Cargá la simulación de tu diseño en ModelSim siguiendo el proceso que usualmente haces (ya sea desde ISE, ModelSim stand-alone, Quartus, etc.)
• En caso que aún no esté abierto, abre el Waveform window: del menú principal selecciona View y luego Wave.
• En el Worksapce window de ModelSim seleccioná (highlight) el dispositivo que se quiere simular (DUT en este ejemplo).

Tal como se vé en la figura anterior en ModelSim en la Objects window NO se muestran las variables. 

Para habilitar la visualización de las variables, primero se debe habilitar la visualización de los procesos del proyecto general. Para eso, sobre el dispositivo a simular, DUT en este ejemplo, presioná botón derecho, y seleccioná Show, y luego Process. 

Ahora debajo del nombre del componente que se quiere simular (DUT en este ejemplo) deberán aparecer varios otros nombres/números. Entre ellos en nombre del proceso en el cual está definida la variable que se quiere agregar al Waveform window.  Por eso la IMPORTANCIA de poner nombre a los procesos.

Tal como se aprecia en la figura, el proceso que nos interesa se llama pwm_pr.  Este nombre viene del .vhd.

Próximo paso es seleccionar View en el menú principal y luego Locals. Ya que las variables son locales al proceso, es decir no existen fuera del proceso.

Luego seleccioná el nombre del proceso (highlight), pwm_pr en este caso, y entonces deberá aparecer una nueva ventana donde se mostrará el nombre del proceso, y debajo las variables definidas en el.

Seleccioná la variable (counter en este ejemplo) y luego Add Wave para que aparezca en el Waveform window. 

Grabá la nueva configuración del Waveform window, así la próxima vez que corras la simulación la(s) variable(s) estarán disponibles. Si trabajás con Quartus usá esta nota técnica C7T_AN08_Customized_WaveView_ModelSim_Quartus. Si trabajas con ISE usá esta C7T_AN05_Customized_WaveView_ModelSim_ISE_2.

Guía de Codificación para Diseños y Proyectos VHDL-FPGA

Basado en mis años de experiencia profesional y educativa les presento un documento de lineamientos generales tanto para la codificación en VHDL como para la partición de un proyecto de un sistema complejo, pasando por clocking, sintesis, nombres, FSM hasta test bench. Es un documento extenso, a pesar de que lo he resumido a los puntos mas importantes, pero siempre útil al momento de comenzar un nuevo proyecto, o como referencia para la codificación en HDL (VHDL o Verilog)/FPGA.

Link al documento es el siguiente. .....   ; )   ......

Se reciben sugerencias en caso que alguno de Uds. tengan alguna 'guia' que haya omitido.

PD: por ahora esta versión está en inglés, si recibo suficientes pedidos, la pasaré al español....

Frecuencia Máxima de un Sistema Digital Sincrónico (Básico)

Introducción 

Comúnmente se expresa que un sistema puede correr satisfactoriamente a 100MHz, o a 133MHz o cualquier otra frecuencia. Qué significa esto? Porqué a esa frecuencia como máxima frecuencia? Quién fija ese límite en un circuito digital? y Cómo se obtiene 6 calcula, ese número? ? Muuuchas preguntas para contestarlas en un simple blog, pero... haré lo que pueda para contestarlas . . .  :) .

Periodo Mínimo

En primer lugar recordemos que el periodo de reloj de un sistema es el que 'marca el paso' en el sistema. Si el periodo es largo, el sistema da pasos (entrega resultados/valores) a pasos grandes (sistema lento), si el periodo del reloj es pequeño, el sistema entregará resultados a pasos mas cortos, es decir mas rápidamente. 

Recordemos también que la frecuencia de funcionamiento de un sistema es la inversa del periodo de ese mismo sistema: F = 1/T (periodo). Por ello para encontrar la máxima frecuencia debemos encontrar el periodo mínimo . . . 

Cómo calcular u obtener el periodo mínimo?
Bien, en un sistema digital el periodo mínimo está compuesto por los retardos MÁXIMOS de los componentes sincrónicos, de los componentes combinacionales , y de las interconecciones entre ellos.
Veamos que significa esto: primero, en un sistema hay muchos caminos sincrónicos (camino de conexión entre flip-flops), pero el que es de interés para el calculo del periodo mínimo es el camino (path) MAS LENTO de todos, es decir el que tiene los retardos MÁXIMOS. El camino mas lento también es llamado camino CRITICO (critical path).

Componentes del periodo mínimo: 

1. Retardo Sincrónico: cuanto se demora en estar estable el dato a la salida de un flip-flip luego del flanco activo del reloj.
2. Retardo combinacional: está compuesto por los componentes no sincrónicos, pueden ser compuertas lógicas, mux, decodificadores, LUTs (en el caso de un FPGA), etc, del camino crítico. Puede haber mas de uno de estos componentes; el retardo de cada uno se suma para lograr el retardo total. La cantidad de componentes combinacionales en el camino critico es normalmente informado en el reporte de frecuencia máxima como 'niveles lógicos' (logic levels). Si se informa que el 'logic level' es 5, significa que en el camino critico hay 5 componentes lógicos combinacionales. 
3. Retardo de ruteo o de conexiones en el camino critico:
1. Entre la salida del componente sincrónico (flip-flop) y la entrada a los componentes combinacionales.
2. Entre los componentes combinacionales.
3. Entre la salida de los componentes combinacionales y la entrada del flip-flop.
4. Tiempo de establecimiento del flip-flop donde termina el camino critico. El dato de entrada tiene que estar un tiempo de establecimiento (dado por la hoja de datos) antes de la llegada del flanco activo del reloj, a fin de evitar problemas de metaestabilidad.
5. Margen de periodo: normalmente los valores de los retardos máximos de los puntos anteriores pueden estar afectados por lo que se llama PVT (process, volume, temperature) y los valores dados por la hoja de datos no son los que realmente tenga el circuito en funcionamiento. Por ello se agrega un cierto margen para asegurarse la estabilidad del sistema.  

Como bien se dice, una imagen vale mas que mil palabras, la siguiente figura muestra gráficamente lo anteriormente descrito en palabras:

En ésta figura los tiempos detallados son los siguientes: 

• Tco: retardo sincrónico, comúnmente llamado 'clock to output'. 
• Rr  : retardo de ruteo.
• Rc  : retardo total de la lógica combinacional, que puede tener varios niveles.
• Tsu: tiempo de establecimiento del flip-flop. 

Con todo esto podemos ahora describir la fórmula para calcular el periodo mínimo que nos va dar la frecuencia máxima de funcionamiento del sistema: 

El 10% de margen se calcula sumando los otros retardos y sacando el 10% de esa suma, el valor obtenido se usa como margen de seguridad del periodo mínimo. 

Periodo Mínimo en FPGAs

Los softwares provistos por los fabricantes de FPGAs ofrecen herramientas que realizan el análisis de todos los caminos sincrónicos del sistema. Estas herramientas realizan lo que se llama un Static Timing Analysis (STA) y reportan el camino más críticos y los siguientes casos no tan críticos. Por ejemplo Altera Quartus provee TimeQuest, Xilinx ISE ofrece Timing Analyzer, Libero de Actel ofrece SmartTime. En un anterior post detallé la información dada por Timing Analyzer. 

A modo de ejemplo de la informacion proviste por una herramienta STA, se puede ver a continuación un ejemplo de la información de un camino critico dada por la herramienta TimeQuest de Altera. 

Analicemos ésta información: La primer columna muestra los tiempos de ya sea de una celda lógica o de un ruteo. La tercer columna detalla el componente o conexión motivo del retardo: el tiempo referenciado como CELL es el retardo combinacional de la celda lógica detallada en le última columna de la derecha. El tiempo IC se refiere al retardo de ruteo o de interconexión entre las celdas lógicas combinacionales. Como puede verse algunos retardos de IC es igual a 0.000; esto se debe al ruteo dedicado que existe dentro de cada bloque básico del FPGA. El retardo total de este camino mas critico, que es el periodo mínimo al que puede correr satisfactoriamente este sistema, es de 2.331ns. Solo como referencia: La información de la quinta columna detalla el componente lógico usado, y la ultima columna el nombre dado por la herramienta de Place and Route para asociar el componente lógico con el nombre usado en el código VHDL.  

Esta información es mas fácil de interpretar viendo el esquemático de éste camino. Tanto Altera, como Actel y Xilinx ofrecen esta vista. He preparado una figura que relaciona todo lo visto hasta acá, asociando el esquemático generado por la herramienta de análisis de tiempo y la figura anteriormente presentada. 

  

Como ya dije al principio este es un cálculo básico del periodo mínimo de un sistema; en un próximo blog trataré de ir mas en detalle teniendo en cuenta por ejemplo el corrimiento del reloj (clock skew), retardos del camino de datos, jitter del reloj, etc....

De todos modos espero que este post haya sido de utilidad (avisen si es así :) .
(version .pdf click acá :) )

Código Assembler del 'C' para el Zynq

Introducción

Para los que hicimos nuestros primeros programas para microprocesador en Assembler (algún tiempo atrás :) ) , aun hoy en día es lindo 'ver' el código assembler generado desde el 'C' que escribimos en nuestra aplicación que sera ejecutada en el Zynq. 

Pero, por otro lado, algunas veces es necesario escribir una rutina o una funcion directamente en Assembler, sobre todo cuando es necesario una muy alta frecuencia de funcionamiento/calculo. 

La herramienta SDK, que es parte del entorno Vivado de Xilinx, tiene un modo de 'ver' el Assembler generado desde el 'C'/

Uso de la Herramienta Xilinx Microprocessor Debugger (XMD) 

XMD es una herramienta que facilita la depuración (debug) y verificación de sistemas implementados en Dual ARM Cortex-A9 (también se puede usar con MicroBlaze y Power PC). 

SDK provee una consola llamada Consola XMD, donde se puede escribir un comando XMD para que sea ejecutado. Los comandos usados son del tipo Tool Command Language (Tcl). 

La Consola XMD se puede abrir de dos modos diferentes: 

1. Cuando se activa la perspectiva Debug, la Consola XMD se abre automáticamente. 
2. En la perspectiva C/C++, se debe hacer Xilinx Tool-> XMD Console. 

Una captura de pantalla de la Consola XMD (en la perspectiva Debug) es mostrada a continuación:

Tal como se puede apreciar, la Consola XMD es una típica consola Tcl, donde es posible ejecutar cualquier comando Tcl permitido por XMD. El comando a ejecutar se debe escribir a continuación del indicador XMD%.

Nota: hay una herramienta mas completa que 'casi' reemplazaría a XMD, que se llama Xilinx System Debugger Command-line Command-Line Interface (XSDB). SDK también provee una Consola XSDB (que será explicada dentro de poco). Sin embargo, aun hay comandos que solo están disponibles en la Consola XMD, tal como es el comando que veremos a continuación. 

 

Entonces, volviendo al objetivo de este post, para ser capaz de 'ver' el código Assembler generado desde el 'C', el comando XMD a escribir es el siguiente: 

arm-xilinx-eabi-objdump -S .elf

En la figura debajo se muestra el lugar donde se debe escribir el comando, y la sintaxis completa (notar el uso de doble barra atrás '\\'): 

Para ejecutar el comando se presiona . El resultado de la ejecución del comando se muestra en la siguiente figura, junto con algunos títulos indicativos de las distintas partes del archivo generado: 

El archivo es de un gran tamaño. Pero es fácil de seguir si se tiene algo de experiencia usando lenguaje Assembler. 

Bien, hasta acá llegamos con este post, espero que les sea útil..  :)