ModelSim-Quartus: "Failed to find INSTANCE '/NA'"

Introducción

Como bien es sabido los mensajes de error dados por la herramientas que comúnmente usamos son bastantes encriptados, y por ende no fácil de darnos cuenta cual es el origen del mismo. Uno de estos casos es este mensaje generado por ModelSim cuando tratamos de ejecutar una 'gate level simulation", ya sea automáticamente desde Quartus o desde el mismo ModelSim:

Veremos en esta entrada del blog como se soluciona este error. 

Descripción

La simulación a nivel de compuertas, gate level simulation (también conocida como post-place and route simulation) es un paso importante para asegurarnos que el sistema implementado en el FPGA cumple satisfactoriamente los requerimientos de tiempo después de colocar (place) y rutear (route) la logica de nuestro sistema en el FPGA. Para ejecutar la simulación a nivel de compuertas, es necesario generar un archivo de simulación (netlist) con todos los retardos (logics y de ruteo) y simular el sistema con ese archivo (netlist).

Quartus tiene una manera de configurar la simulación a ejecutar de un modo bastante detallado. Para la simulación a nivel RTL el procedimiento fue explicado en este blog anteriormente.  

Para ejecutar la simulación a nivel de compuerta (gate level simulation) Quartus genera a partir del .vhd a simular y de la información provista por la herramienta de place & route (especialmente con los retardos, delays, incorporados) un archivo con extensión .sdo, (standard delay output,  usualmente llamado standard delay format, .sdf), que contiene toda la información de los delays lógicos y de ruteo, y un archivo .vho, que contiene toda la información del conexionado del sistema a implementar en el FPGA. Ambos archivos contienen todo lo necesario para llevar a cabo la simulación a nivel de compuerta. Para los que les interese pueden abrir los archivos generados en el directorio: 

.../tu_proyecto/simulation/modelsim/nombre_top_entity_.vho

.../tu_proyecto/simulation/modelsim/nombre_top_entity_.sdo

Pasos a Seguir

Si has intentado correr la simulación a nivel de compuertas es porque ya tienes el respectivo test bench escrito. Solo falta decirle a Quartus por medio de lo Altera llama NativeLink que el dispositivo bajo test esta identificado con el nombre de la instancia en el test becnh. 

Para configurar el proceso de correr automáticamente en ModelSim la simulación a nivel de compuertas llevá a cabo los siguientes pasos. 

1- Ir a Assignments -> Settings

2- La ventana de 'Settings' se abrirá. Seleccioná 'Simulation'.

3- Dentro de la ventana de 'Simulation', hace click en el cuadrado de 'Run gate-level simulation automatically after compilation'. 

La siguiente figura muestra los pasos 2 y 3. 

4- En la misma ventana 'Simulation', y en la parte inferior done dice 'Compile test bench', simple click en 'Test Bench'. 
5- La ventana 'Test Benches' se abrirá. Simple click en 'Edit'.

6- Ahora deberá aparecer la ventana titulada 'Edit Test Bench Settings'; mostrando el nombre del test bench que será usado en la simulación. En esta ventana seleccione 'Use test bench to perform VHDL timing simulation'. Y en la parte donde dice 'Design instance name in test bench' debes escribir el nombre de la instancia del componente en el test bench. Por ejemplo en el test bench tengo la siguiente instrucción de instanciación de componente: 

En el caso que estoy detallando, yo use U1 como nombre de la instancia. 
Hay que ser muy cuidadoso de verificar cual es el nombre de la instancia y escribirlo en "Design instance name in test bench". 

7- Click Ok. y cerrar cualquier otra ventana que haya quedado abierta. 
8- Ya puedes efectuar una simulación a nivel de compuertas usando

Nota 1: por favor acordate después de ejecutar una simulación a nivel de compuertas de borrar el archivo vsim.wlf generado por ModelSim, porque es inmensamente grande.
Nota 2: agradezco la inquietud de mis alumnos Mario Ruiz, y Germán González en este post. 

Nota 3: como podrán ver en el calendario me borre por unos meses.... bueno.. anduve haciendo otros trabajos no tan lindos como codificar en VHDL e implementar en FPGA..... así es q estoy muy contento de poder volver a mi temática favorita!!

Operadores de Reducción Lógica - Operadores 'Unarios'

Introducción

En versiones anteriores de VHDL, los operadores lógicos and, or, nand, nor, xor and xnor eran definidos solo como operadores boleanos, es decir, se necesitaban dos operandos para realizar la respectiva función lógica boleana. Para casos en que los operandos eran arreglos y se necesitaba un simple valor escalar como resultado, se escribía un loop para aplicar el operando lógico a los elementos del arreglo.

VHDL-2008 extiende la definición de operandos lógicos para permitir que sean usados como operadores 'UNARIOS' (unary operands). Veremos a continuación cuales son los operandos unarios definidos en VHDL-2008 y como se usan. 

Repaso Operadores Booleanos

De acuerdo a la defincion del estandard de VHDL hay tres difrentes familias de operadores booleanos. Estos operadores estan definidos para tipo bit y boolean, y sus derivados, como asi tambien para los arreglos de estos tipos. 

1- Operador booleanos básico: realizan la operación lógica booleana entre cada bit de los operandos (bitwise logic), y produce como resultado un arreglo del mismo tamaño que los operandos. 

2- Operador booleano selectivo (operador unario): realiza la operación lógica booleana entre un simple bit y cada elemento del operando. El resultado es del mismo tamaño que el del operando. 

3- Operador booleano reducido: definido en VHDL-2008. Realiza la operación lógica booleana entre todos los elementos del arreglo, produciendo como resultado un simple bit. 

Cuáles son y Cómo se usan: Operadores Unarios

Los operadores unarios se usan específicamente en arreglos, y se aplican a cada elemento del arreglo para producir un escalar como resultado (en realidad también se pueden aplicar a arreglos de un elemento, pero en realidad no tiene mucho sentido). 

A continuación algunos ejemplos de uso y resultado de operadores unarios: 

and"0110" = '0' and '1' and '1' and '0' = '0'
or "0110" = '0' or  '1' or  '1' or  '0' = '1'
xor"0110" = '0' xor '1' xor '1' xor '0' = '0'

Los operandos de reducción nand, nor, xnor, son la negación de los operandos and, or y xor respectivamente. Por lo que: 

nand"0110" = not ( '0' and '1' and '1' and '0') = not '0' = '1'
nor "0110" = not ( '0' or  '1' or  '1' or  '0') = not '1' = '0'
nxor"0110" = not ( '0' xor '1' xor '1' xor '0') = not '0' = '1'

Los operandos de reducción tienen la misma precedencia que el operador unario not. En caso de ausencia de paréntesis estos operadores son evaluados antes de los operadores binarios. Así por ejemplo esta expresión: 

and Z xor B

Se evalúa primero el operando de reducción and, es decir la operación and Z, y luego se aplica el operador binario xor entre el resultado de la operación and Z y B.

Un caso típico de ventaja de uso del operador unario es por ejemplo en calculo de paridad de un vector. En versiones anteriores el código era escrito mas o menos de la siguiente forma:

parity <= data(7) xor data(6) xor data(5) xor data(4) xor
          data(3) xor data(2) xor data(1) xor data(0);

Usando el operador unario, se puede escribir sencillamente como:

parity <= xor data;

Especificando el 'timescale' en Verilog

Introduccion

después de algunos pedidos, empezaré también a escribir blogs con respecto al otro HDL, Verilog. En este caso en particular detallo el uso de la directiva de compilación (compiler directive) "timescale". 

Detalles

La directiva 'timescale' especifica la unidad de tiempo y precisión ha ser usada por la herramienta de simulación. 

La sintaxis es la siguiente: 

'timescale time_units / precision_units

Donde "time_units" es un valor que declara la unidad de tiempo de los retardos en el módulo en el que se especifica este valor. Mientras que "precision_units" es un valor que declara la precisión de la unidad de tiempo ha ser usada por el simulador cuando simule el módulo en el que se especifica este valor. Como regla práctica trate de usar como valor de la precisión un valor cercano al valor de la unidad de tiempo. Ambos valores deben ser números enteros (1, 10, 100), y son seguidos por un string que representa la unidad de tiempo (s, ms, us, ns, ps, fs). 

Reglas: 

• se deben usar valores de 1, 10, 100 para la unidad de tiempo y para la precisión.
• puede usar 's' para segundos, 'ms' para milisegundos, 'us' para microsegundos, 'ns' para nanosegundos, 'ps' para picosegundos y 'fs' para fentosegundos, para ambos, la unidad de tiempo y la de precisión.
• la unidad de tiempo debe ser por lo menos tan grande como la unidad de precisión
• no existe un valor de 'timescale' por defecto; pero los simuladores pueden asignar uno por defecto.
• para mantener consistencia de los valores de 'timescale', se debe usar una directiva de timescale para TODOS los módulos del diseño.

Esta directiva se escribe fuera de la definición del módulo.

IMPORTANTE: Se debe tener cuidado de que no exista una gran diferencia entre el valor de la unidad de tiempo y el valor de la unidad de precisión  ya el tiempo de simulacion avanza en incrementos de la unidad de precisión. Así  por ejemplo, si escribimos

`timescale 1ns/100ps

el simulador hará 10 pasos para avanzar 1 ns de tiempo de simulación. Si, escribimos

`timescale 1ns/1ps

el simulador hará 1000 pasos para avanzar 1 ns de tiempo de simulación. 
Otro ejemplo: 

`timescale 1ns/10ps
module1 (. . .);
  not #1.23 (. . .) // 1.23ns (12300 simulation time units)
  . . .
endmodule

Use valores de precisión que no sobrecarguen la tarea del simulador. Valores demasiados pequeños  incrementarán sin sentido el tiempo de simulación y el uso de memoria. Un valor práctico es el siguiente: 

`timescale 1ns/1ns

En caso de proyectos con múltiples módulos  el valor de 'timescale' es pasado a todos los módulos que no tienen definido el 'timescale' y que son sub-módulos del mismo. El simulador usualmente da un 'warning' para los módulos que no tienen definido el valor (los valores de 'timescale').

Finalmente un figura es mejor que mil palabras....

Primer blog de Verilog..... !!! pero, por supuesto no el último :) !! 

Personalizando el uso de ISim

Introducción

El simulador ISim puede fácilmente ser personalizado a fin de facilitar las tareas de visualización y depuración del diseño bajo test.

Procedimiento

Ejecutar el test bench como normalmente lo ejecuta.

Modifique las señales mostradas en el visualizador de formas de ondas de acuerdo a lo que necesite. Algunas de las opciones que brinda ISim son las siguientes:

• Mover las señales a fin de juntarlas por funcionalidad. Seleccione la señal a ser movida con un simple click sobre la señal, luego mantenga el botón izquierdo de mouse apretado y arrastre la señal hacia arriba o hacia abajo.
• Cambiar de color de la forma de onda. ISim ofrece la opción de cambio de color de la forma de onda de cada señal. Para ello simple click en la señal a cambiar el color, para seleccionarla, y luego presione botón derecho, y seleccione Signal Color, y luego el color que quiera usar para esa señal en particular. Este cambio de color es muy útil para señales que en cierto modo son de referencia para otras señales, pudiendo ser identificadas fácilmente en el conjunto de todas las señales.
• Inserción de divisor de grupo de señales. Una vez realizado el paso 1, es conveniente colocar un titulo que de alguna idea de la funcionalidad de las señales. Para ello coloque el icono del mouse donde desea colocar el titulo del grupo de señales, presione botón derecho del mouse, y seleccione New Divider, y escriba el titulo correspondiente. Puede colocar tantos divisores como necesite.
• Cambio de número relacionado a buses. Por cada bus se puede  seleccionar distinta representación del número correspondiente. Por ejemplo, se puede seleccionar Hexadecimal, Decimal, etc.
• New Virtual Bus, permite juntar señales y formar un bus que solo es válido en la simulación.

Una vez realizados todos los cambios que desee, grabe esa configuración haciendo File->Save as. Escriba el nombre correspondiente, y se le agrega la extensión .wcfg.

Ahora bien, para usar esa configuración cada vez que se invoque el simulador debe hacerle saber al simulador que use esa configuración ya grabada en vez de la que usa por defecto. Seleccione Simulate Behavioral Model, y luego presionando botón derecho seleccione Process Properties. Tal como se ve en Figura 1.

Figura 1 - Acceso a las opciones del simulador

Una vez abierta la ventana de propiedades del ISim, haga clikc en la opción Use Custom Waveform Configuration File, y luego en la opción Custom Waveform Configuration File, navegue para agregar el archivo grabado en el paso anterior, tal como se puede observar en Figura 2.

Figura 2 - Configuración del simulador para usar la plantilla creada

A partir de ahora cada vez que se invoque ISim, se abrirá con la configuración grabada. 

Útil? te sirve de algo este blog? Avisame !!!  :) 

Replicación de Lógica - Inserción de Buffer - Alta Cargabilidad (High Fan-Out)

Introducción

Entre las tantas tareas que llave a cabo la herramienta de síntesis, hay una que se encarga de revisar la cargabilidad (fan-out) de cada señal lógica.Por defecto existe un número límite máximo de cargabilidad permitido. Este numero básicamente depende de la familia del FPGA con que se este trabajando. Por supuesto existe la opción de incrementar ese número, aunque no es lo mas aconsejable. La mejor solución para casos en que la cargabilidad de una señal sea mayor a la permitida, es lo que técnicamente se llama replicación de la lógica que genera la señal de tan alta cargabilidad. La cargablidad de cada registro, compuerta lógica y cualquier otro elemento lógico es analizado por el compilador de la herramienta de síntesis. Si el numero de cargabilidad encontrado supera al establecido por el diseñador, el compilar replica el nodo fuente de la señal hasta que el número de cada copia esté por debajo del número máximo de cargabilidad permitido. 

Cargabilidad (Fan-out)

Fan-out es definido como el número máximo de entradas de componentes lógicos que pueden ser conectadas con la salida de otro componente lógico. De acuerdo al diseño o circuito que se implementa algunas señales internas del mismo (salidas) se conectan a las entradas de otros componentes. Esta cantidad de conexiones puede ser un número desde 1 hasta un numero muy alto (por ej. 10000), este es el números que se conoce como fan-out. No hace falta que uno sea el que lleva la cuenta de la cargabilidad de cada señal, todas las herramientas de síntesis detallan en su reporte las señales que tienen un alto fan-out. 
Por qué existe un número máximo de fan-out? El número conexiones máximas están limitadas,  por un lado, por la degradación que puede tener la señal de del alta cargabilidad debido a que la principal carga que ve la salida es la capacitancia de entrada de los componentes a los que está conectada; así mientras mas conexiones tiene la salida, más capacitancia, más tarda en subir (rise-time) y en bajar (fall-time) la señal. Al tardar mas en subir y en bajar, la señal sufre un retardo generado solo por la cargabilidad, de este modo el rendimiento del sistema puede verse reducido. Finalmente, en el caso de los FPGAs, otro problema de una señal con un número alto de fan-out es que crea dificultades para rutear la señal dentro del FPGA, a no ser que se use una ruta dedicada para la señal de alta cargabilidad. 
Normalmente las herramientas de síntesis de los distintos fabricantes tienen un valor de fan-out para todas las señal (valor global) configurado por defecto. Sin embargo, este valor puede ser sobrescrito usando ya sea restricciones en el archivo correspondiente, (.sdc para Altera; .ucf para Xilinx), o usando atributos de síntesis, cuyo nombre depende de la herramienta de síntesis que se use.  

En el caso de Synplify, la herramienta permite configurar el valor de fanout máximo desde una ventana de configuración: 

Project -> Implementation Options -> Device

en la opción Fanout Guide se muestra el numero máximo de fanout.

El valor configurado para fanout, se aplica a TODAS las señales del diseño, se por ello se lo denomina fanout global. Tal como se explico anteriormente este valor no puede ser demasiado alto, pero tampoco demasiado bajo. En este último caso se corre el riesgo que la herramienta de sintesis duplique lógica o inserte buffers sin realmente necesitarse. Ambos extremos afectan el ruteo y el rendimiento del diseño. 
Para sobrescribir el fnaout global e imponer un fanout distinto en un mas bajo nivel se puede usar el atributo:

syn_maxfan 

Este atributo se aplica a distintos niveles de jerarquía del diseño, descripto en el siguiente cuadro: 

Cuál es la diferencia entre límite duro y blando? 
En el limite blando la herramienta puede o no puede replicar la logica o introducir un buffer, una vez superado el valor límite. En el caso de aplicar syn_maxfan a un registro por ejemplo, si se supera el valor de fanout configurado por el atributo SI o SI la lógica es replicada o se agrega un buffer a la señal.  
A continuación se presenta un ejemplo de un valor alto de fanout que afecta el rendimiento máximo del sistema. Como puede apreciarse el retardo de ruteo es excesivamente largo, principalmente debido a un muy alto valor de fan-ou (seguramente también esta señal no esta usando un ruteo dedicado). 

Esta señal, sig, es un típico caso en el que un alto fanout está afectando la frecuencia máxima de funcionamiento del sistema, por lo que se debería replicar la lógica generada de esa señal.

Quartus Configuración y Atributo

El atributo que controla el valor de fanout máximo en la herramienta de síntesis del Quartus II maxfan. 
El valor global de fanout se configura en en el Assignment Editor

XST Configuración y Atributo

El atributo que controla el valor de fanout máximo en la herramienta de síntesis XST del ISE de Xilinx se denomina max_fanout. 
El valor global de fanout se configura en: 
Process -> Properties -> Xilinx Specific Options -> Max Fanout

Detalles Lógicos

La herramienta de síntesis a fin de cumplir con los requisitos del valor máximo de fanout, puede hacer dos cosas: 

- replicación de lógica

- introducción de un buffer

 

Replicacion de Lógica

Cuando el fanout de un registro o una lógica combinacional supera el valor configurado, la herramienta de síntesis reduce el fanout al replicar la lógica de salida, ya sea secuencial o combinacional.

 

Introducción de Buffer

Un buffer es introducido por la herramienta de síntesis cuando una señal de entrada al FPGA tiene un alto fanout. 

 

Replicación Manual

Teniendo en cuenta que no todas las señales con alta cargabilidad originan problemas de bajo rendimiento, se puede proceder a una replicación manual del componente con una alta cargabilidad. Para ello en el código VHDL o Verilog se describe el componente las veces que sea necesario. Un punto muy importante en estos casos, es el uso de atributos de síntesis para prevenir que la lógica replicada sea optimizada por la herramienta de síntesis. Para ello se usan atributos tales como syn_preserve, syn_keep (en el caso de usar Synplify).

Excepciones

Como siempre ocurre hay excepciones a estas reglas y algunas son las siguientes:

• Se puede 'exigir' a la herramienta de síntesis que use un 'buffer' en lugar de replicar la lógica. En el caso de Synplify esto se logra configurando el atributo syn_replicate a valor lógico '0', ya sea globalmente, o sobre el modulo o sobre un registro en particular. Este atributo previene la replicación, por lo que el software usará buffers para evitar los problemas relacionados con un fanout muy elevado
• Para especificar que un puerto de entrada, por ejemplo una entrada de reloj, no sea usada con un buffer, se puede usar el atributo syn_noclockbuf, sobre esa entrada. Esto se usa comúnmente cuando se esta muy al limite con el numero de buffers globales y se necesita el buffer para una senal que no tiene un alto fanout pero que tiene una restricción de tiempo muy critica. 
• Para casos en que el rendimiento del sistema no se muy crítico, es decir cuando la frecuencia de trabajo del sistema es baja o muy baja, se puede directamente evitar cualquier replicación de lógica o introducción de buffer al configurar el valor de fanout a un numero muy alto.  
• Otros atributos que se pueden usar para que la lógica no sea replicada y en su lugar se introduzca un buffer, son los atributos syn_keep y syn_preserve. syn_keep es usado cuando se quiere mantener una señal, mientras que syn_preserve se utiliza para preservar un registro. En ambos casos si se supera el numero máximo de fanout, un buffer sera introducido en lugar de replicar la lógica.
 

Conclusión 

Es importante resaltar que las señales con alta cargabilidad en un diseño  no deberían ser tocadas a menos que esté en riesgo el rendimiento del diseño, es decir que la técnicas detalladas mas arriba se deberían usar en caso que la señal que tiene alta cargabilidad este afectando la frecuencia máxima a la que se desea funciones el diseño . 

La cargabilidad de las señales es detallada en los distintos reportes presentados por la herramientas de síntesis, ya sea Synplify, Quartus, XST, etc. En función de ese número y de que si se trata de una señal que es crítica para el máximo rendimiento del diseño, es que se deben aplicar las técnicas presentadas en este blog, para sea replicar la lógica o insertar un buffer.

Inicialización y Asignación de Vectores - Aggregate

 Introducción

Un punto de mucha importancia cuando se escribe código VHDL es la escritura en forma parametrizada del mismo. Esto significa usar los distintos atributos e instrucciones de VHDL a fin de evitar hacer uso de referencias fijas las que deberán ser cambiadas si se modifica el tamaño de algún dato o señal del código escrito. Así, las referencias a tamaños de un dato o señal deberían ser expresadas en términos de atributos de VHDL o parámetros definidos por el diseñador. 

Aspectos Prácticos

Para simplificar los ejemplos comenzaremos con la inicialización de una señal. La asignación de un valor a una señal de tipo arreglo (array) normalmente se hace de la siguiente manera: 

data_out <= "00000000";

Si bien esa asignación es correcta, no es la más adecuada si se quiere escribir el código de forma parametrizada. La misma función cumple la siguiente asignación conocida como aggregate: 

data_out <= (others => '0');

Que también se puede usar para inicializar a todos ‘1’:

data_out <= (others => '1');

Similarmente se puede escribir: 

data_out <= ( 0 => ‘1’, 3 => '1’, others => ‘0’);

Para formar de este modo el dato “00001010”. 

Un error común cuando se escribe código parametrizado es que un aggregate no puede ser usado en una expresión y debe usarse con un objeto de tamaño conocido. Así, el siguiente código dará un error el ejecutarse: 

signal internal_bus: std_logic_vector(width-1 downto 0);
 . . .
output_bus <= x"FF" when (internal_bus=(others=>‘0’)) else . . .

En este comparación el tamaño de internal_bus es conocido, pero no el tamaño del dato con quien se esta comparando internal_bus. Para solucionar este problema se usa el atributo ‘range para proveer el tamaño del objeto. 

output_bus <= x"FF" when (internal_bus=(internal_bus’range=>’0’)) else . . .

Otro manera de hacer algo similar a lo detallado en el ejemplo anterior, sería mediante el uso de una constante tal como se detalla a continuación: 

constant all_zero: std_logic_vector(width-1 downto 0) := (others => ‘0’);

signal internal_bus: std_logic_vector (width-1 downto 0);
. . .

output_bus <= x"FF" when (internal_bus = all_zero) else . . .

Una nota con respecto al uso de aggregate, es que cuando se usa en un arreglo compuesto por solo un elemento, la asociación por nombre debe ser usada para especificar el valor. Por ejemplo: 

constant valor_ini: std_logic_vector(2 downto 2):= (2=>’’); -- correcto

constant valor_final: std_logic_vector(2 downto 2):= (‘0’); -- incorrecto  

Finalmente quiero recordarles que un aggregate también se usa para asignar valores de señales a otra señal en particular. Ejemplo: 

signal a, b, c, d: std_logic;
signal tmp: std_logic_vector(3 downto 0);

 .. .

tmp <= (a, b, c, d);

De este modo tmp(3) toma el valor de a, tmp(2) el de b, tmp(1) el de c y tmp(0) el de d. En caso de querer cambiar el orden se lo debe especificar en la asignación, por ejemplo: 

tmp <= (3 => c, 2 => a, 1 => d, 0 => b);

Asi, tmp tiene los siguientes vlaores asignados (c, a, d, b).

Tambien se puede expresar un aggregate de la siguiente manera: 

tmp <= (3 => ‘1’, 2 | 1 | 0 => ‘0’);

tmp <= (3 => ‘1’, (2 downto 0) => ‘0’);

tmp <= (3=> ’1’, others => ‘0’);

tmp <= (‘1’, ‘0’, ‘0’, ‘0’, ‘0’);  

Todas estas ultimas cuatro asignaciones son equivalentes.

Lazos Combinacionales

Introduccion

Lazos combinacionales son estructuras lógicas que contienen realimentación sin ningún elemento sincrónico en el camino. Normalmente los lazos combinacionales provocan inestabilidad y sistemas pocos confiables, violando los principios de diseño sincrónico al establecer un lazo de realimentación sin registros. 

Porqué? Cómo se genera un lazo combinacional?

Un lazo combinacional es implementado en hardware cuando en el código VHDL escrito una señal que está del lado izquierdo de una instrucción de asignación (a la izquierda del símbolo <=) también aparece en la expresión aritmética/lógica del lado derecho de la instrucción de asignación (a la derecha de <=); siempre y cuando se esté describiendo lógica combinacional. Por ejemplo las siguientes líneas de código generaran un lazo combinacional si se escribe en un proceso combinacional o directamente como una instrucción de asignación concurrente.
  

1 acc <= acc + data;
2
3 Z <= Z nand B;
4
5 cnt <= cnt + 1;
 

Sin embargo es importante, muy importante, aclarar que si estas mismas líneas de código son escritas dentro de un proceso controlado por reloj, se generara la respectiva lógica secuencial; debido a que el reloj del proceso almacena el valor correspondiente por un ciclo de reloj, de este modo no existe una realimentación combinacional.

Hardware

La siguiente figura representa un esquema de un lazo combinacional:

Como se ve en la figura, la salida de la lógica combinacional se realimenta a si misma sin ningún tipo de registro en el medio. Este tipo de esquema lógico, normalmente no se desea, no es lo que se desea implementar, por ello la herramienta de síntesis genera una advertencia (warning) tal como se detalla en el siguiente ejemplo.

 1 library ieee;
 2 use ieee.std_logic_1164.all;
 3
 4 entity lazo_comb is
 5   port(
 6     a: in  std_logic;
 7     z: out std_logic);
 8 end lazo_comb;
 9
10 architecture beh of lazo_comb is
11
12  signal y: std_logic;
13
14 begin
15     z <= y; 
16
17 process(a,y)
18  begin
19     y <= y nand a;
20 end process;
21
22 end beh;

La herramienta de síntesis, Synplify en este ejemplo, genera el siguiente mensaje de advertencia para este código:

El mensaje ‘found combinational loop at y’ significa que la señnal ‘y’ es realimentada combinacionalmente tal como se puede apreciar en el diagrama RTL de la respectiva implementación del código descrito:

  
A continuación se puede ver la simulación del sistema descrito arriba.

                Esta figura merece un detallado análisis. En primer lugar la primer ventana (de arriba hacia abajo) grafica las formas de ondas de las señales del sistema cuya principal expresión es la de la línea 24 de la segunda ventana. La tercer ventana, Transcript, detalla un error de simulación, diciendo que el limite de iteraciones del simulador fue alcanzado a los 50ns y no se llego a ningún valor estable. Es decir que el sistema empezó a oscilar y se quedo oscilando. El numero de iteración limite es programable en ModelSim (Simulate->Runtime Options), y en la mayoría de los simuladores. Por defecto este valor es de 5000. Viendo mas en detalle la parte inferior de la ventana donde se grafican las formas de ondas, se puede leer que el numero de Delta alcanzado es de 5000, que es justamente el numero limite de iteraciones configurado. Han transcurridos 5000 Deltas y aun el sistema no es estable.  

Otro punto importante a considerar en este ejemplo es el hecho de lo importante que es simular un sistema aun cuando sea muy simple. Suponiendo que hubiéramos directamente configurado el FPGA sin haber realizado la simulación (ya que la herramienta de síntesis nos da solo un ‘warning’), hubiéramos visto que la salida del sistema no era estable; y hubiéramos perdido una considerable cantidad de tiempo tratando de ver porque la salida no es estable

         En diseños con una gran cantidad de código a veces es muy fácil cometer errores como el del código descrito arriba. Por ello, hay que seguir un cierto orden en la escritura del código, tratando de mantener un cierto flujo de datos, por ej. de derecha a izquierda.

            En casos en que deliberadamente se desea implementar cierta lógica con un lazo combinacional tener en cuenta:

• Comentar suficientemente el código de modo que se puede fehacientemente conocer la razón de existencia del lazo. 
•  Realizar todas las simulaciones posibles, primero en PC y luego en hardware para comprobar que aun con la existencia del lazo el sistema sigue funcionando correctamente.

       Otro punto importante a tener en cuenta cuando deliberadamente se implementa un lazo combinacional, es que la herramientas de análisis de tiempo estático (Static Taming analysys, STA) normalmente incrementan por un valor (2-8 veces) el periodo mínimo cuando encuentran un lazo combinacional. Por ello, en estos casos se debería decirle a la herramienta STA que ‘ignore’ ese camino en particular. La sintaxis para el caso de Quartus (Altera), es ‘set_false_path’ (recordar que las herramientas de Altera usan constraints con las sintaxis de Synopsys; para ISE (Xilinx) use TIG con su respectiva sintaxis.