¿Es necesaria la declaración 'IF' para el proceso del reloj?

1

Estoy acostumbrado a escribir el siguiente proceso que reaccionará en el borde ascendente de CLK (secuencia de comandos 1):

X: PROCESS(CLK)
BEGIN
    IF RISING_EDGE(CLK) THEN OUTPUT <= CLK AND VAR;
    ELSE NULL;
    END IF;
END PROCESS X;

Ahora necesito el proceso para reaccionar en los bordes ascendentes y descendentes de CLK, así que de acuerdo con la hoja de datos del dispositivo escribí esto (secuencia de comandos 2):

X: PROCESS(CLK)
   BEGIN
        IF (CLK'EVENT) THEN OUTPUT <= CLK AND VAR;
        ELSE NULL;
        END IF;
END PROCESS X;

Ambos casos encajan y se pueden programar en el dispositivo. Pero parece que el segundo caso realmente no funciona: la SALIDA no cambia.

Necesito que la SALIDA se actualice en ambos bordes del CLK. ¿Sería funcionalmente equivalente al script 2 si reescribiera el proceso de la siguiente manera (script 3)? En otras palabras, ¿tengo que poner la condición IF o el proceso reacciona en el borde ascendente / descendente del CLK independientemente?

X: PROCESS(CLK)
   BEGIN
      OUTPUT <= CLK AND VAR;
END PROCESS X;

EDITAR: Con el script 2 recibo la advertencia de que falta la señal VAR en la lista de sensibilidad. Sin embargo, necesito la SALIDA para cambiar solo con CLK, pero depender del valor VAR.

Con el Script 4 (abajo), que espero que sea equivalente al script 2, la advertencia es diferente: ADVERTENCIA: Xst: 2110 - El reloj de registro OUTPUT también se usa en la lógica de datos o control de ese elemento .

X: PROCESS(CLK)
   BEGIN
       IF (CLK'EVENT) THEN
           IF CLK = '1' THEN OUTPUT <= ('1' AND VAR);
           ELSE OUTPUT <= '0';
           END IF;
       ELSE NULL;
       END IF;
END PROCESS X;

Aquí está el informe del instalador con vars relevantes (NICLK es para SALIDA y SampEn es para VAR):

    
pregunta Nazar

1 respuesta

2

Una declaración de asignación de señal concurrente de la forma:

OUTPUT <= CLK AND VAR;

Tiene un proceso equivalente (cómo se simula) de la forma:

process
begin
   OUTPUT <= CLK AND VAR;
   wait on CLK, VAR;  -- wait on 'sensitivity list'
end process;

Con la declaración de espera, el equivalente de poner ambos signals en una lista de sensibilidad del lado derecho.

El segundo proceso ya es sensible a los eventos CLK, el if CLK'EVENT es redundante. Yo sugeriría que su herramienta de síntesis probablemente debería haber generado una advertencia y no haber generado una asignación a SALIDA, algo que examine las advertencias de síntesis, cualquier lista de red producida o el esquema generado puede indicar. De lo contrario, el segundo y tercer proceso son equivalentes.

Es probable que reciba una advertencia tanto para el segundo como para el tercer proceso de que el VAR no se encuentra en la lista de sensibilidad, que probablemente se ignore con fines de síntesis. El efecto de esto no es el cierre entre los resultados de simulación anteriores y posteriores a la síntesis.

Tenga en cuenta que lo que ha definido es un reloj cerrado y tener VAR en la lista de sensibilidad no importará a menos que las transiciones VAR antes del borde ascendente de CLK o después del borde descendente de CLK, en cuyo caso podría mover la SALIDA borde del reloj ( if OUTPUT'EVENT and OUTPUT = '1' , if rising_edge(OUTPUT) , o el mismo para el flanco descendente).

Y si el VAR puede arruinar el borde del "reloj" resultante, tiene un problema que debería solucionarse de todos modos.

(Y, por supuesto, alguien está obligado a sonar en que una lista de sensibilidad puede usar la palabra reservada para indicar todas las señales del lado derecho en VHDL-2008).

addendum

El interrogador ha indicado que está intentando controlar los relojes, y la información agregada a su pregunta muestra que esto está usando las herramientas Xilinx.

Xilinx recomienda evitar el bloqueo de los relojes de esta manera [1], la razón más obvia es que el sesgo del reloj depende de la ruta hacia y desde una LUT, así como el propio retardo de la LUT. Usted podría imaginarse tratando de equilibrar los retrasos en todos sus relojes. Con los relojes generados a partir de una frecuencia de reloj más alta, podría, por ejemplo, desactivar un reloj con un borrado o reinicio. La idea aquí es retrasos de coincidencia en relojes cerrados y no sincronizados como un problema de implementación FPGA por encima y más allá de todas las medidas que tomaría para cruzar los límites del reloj de lo contrario.

Xilinx admite relojes sincronizados en FPGAs de la serie 7 y dispositivos ZYNQ que utilizan habilitaciones de reloj dedicadas a través del uso de la versión de pago de ISE (Vivaldo), algo que se llama sincronización de reloj inteligente, donde no controla sus relojes, deja que las herramientas hazlo por ti.

También puede notar que la restricción del período se pierde al pasar un elemento no secuencial que activa manualmente los relojes.

[1] Documento técnico: HDL Prácticas de codificación para acelerar el rendimiento del diseño , alrededor de la Figura 11. A partir de la página 10, Reloj habilitado y Relojes cerrados.     
respondido por el user8352

Lea otras preguntas en las etiquetas