estrategia de reloj fpga

Puede crear tantos relojes como desee, y puede usar PLL o DCM para crear relojes arbitrarios. La pregunta es si lo necesita o si debería hacerlo de otra manera.

Encuentro que termino ejecutando tanta lógica en una frecuencia de reloj común o "central", digamos los 54MHz que estás usando, pero necesito activar ciertos procesos para que se ejecuten periódicamente. Diga una idea de rebote de 100 ms, una actualización de PWM de 10 kHz, una marca de 1s del temporizador para el reloj de pared, se le ocurre la idea. En lugar de generar estos relojes, en lugar de eso, ejecuto todo a la frecuencia central del reloj y genero señales de habilitación de reloj arbitrarias.

Por lo general, no desea crear relojes divididos por varias razones. Los relojes generados por lógica están inestables, las herramientas pueden terminar enrutando estas señales de "reloj" a lo largo de las rutas de enrutamiento destinadas a la lógica (ya que se generan a partir de la lógica) y, como se mencionó anteriormente, otros PLL y DCM son opciones mucho mejores si usted Realmente necesito generar un reloj diferente.

Reloj gating es lo que quieres. Las primitivas del dispositivo tienen una señal de habilitación de reloj adicional que "bloquea" la señal de reloj, lo que permite propagarse hacia la primitiva o no. Cuando se anula la habilitación del reloj, el FF no ve el reloj y mantiene efectivamente su estado como si el pulso del reloj nunca hubiera ocurrido. Cuando se activa la señal de habilitación del reloj, el FF ve el reloj normalmente y las cosas continúan como se espera. Las habilitaciones de reloj están diseñadas específicamente para controlar el acceso de un FF a su reloj y, como tal, no tienen problemas con la generación de relojes runt. Tampoco ocupan ningún recurso adicional, así que úsalos.

por ejemplo Generando un reloj en lógica. Esto es malo, no hagas esto:

process gen_100ms_clk (clk, rst)
variable ctr: integer range 0 to 5399999;

begin
    if rst = '1' then
        ctr := 0;
        out <= '0';
    elsif rising_edge(clk) then
        if ctr = ctr'high then
            out <= not out;
            ctr := 0;
        else
            ctr := ctr + 1;
        end if;
    end if;
end process gen_100ms_clk;

Este código tiene el estado de alternancia de señal out cada 100 ms; Esta señal sería una mala elección para usar como la señal de reloj de un nuevo proceso, como aquí:

process do_100ms(out, rst)
begin
    if rising_edge(out) then
        ...
    end if;
end process do_100ms;

Esto es malo porque las FF en el proceso do_100ms() están usando una señal creada a través de la lógica en el proceso gen_100ms_clk() .

En su lugar, use un reloj habilitar , como se muestra aquí:

process gen_100ms_ce (clk, rst)
variable ctr: integer range 0 to 5399999;

begin
    if rst = '1' then
        ctr := 0;
        out <= '0';
    elsif rising_edge(clk) then
        if ctr = ctr'high then
            out <= '1';
            ctr := 0;
        else
            out <= '0';
            ctr := ctr + 1;
        end if;
    end if;
end process gen_100ms_clk;

Ahora gen_100ms_ce() crea una señal out que es alta para 1T cada 100 ms. Esta es una excelente manera de indicar a su código que es hora de hacer algo:

process do_100ms(clk, rst)
begin
    if rising_edge(clk) then
        if out = '1' then
            ...
        end if;
    end if;
end process do_100ms;

Ahora su proceso do_100ms() se está ejecutando en el mismo reloj de 54MHz que todo lo demás y utiliza una habilitación de reloj adecuada para activar lo que quiera que ocurra cada 100 ms.

Eche un vistazo a la salida RTL de su conjunto de herramientas; verá que la primitiva utilizada en su proceso do_100ms() usará su señal de habilitación de reloj.

Este método también logra un ahorro de energía ya que habrá grandes franjas de lógica que permanecerán "estáticas" durante largos períodos de tiempo, aunque la red global del reloj se esté alejando a 54MHz en su caso. Una vez cada 100 ms en mi ejemplo anterior, todos los relojes que están sincronizados con la habilitación de 100 ms se activan para 1T y luego vuelven a ser estáticos durante otros 99.9999815 ms. :-) El CMOS consume muy poca energía cuando no está cambiando de estado, por lo que el único consumo de energía en la lógica con el reloj cerrado está en las corrientes de fuga de su lógica.

Puede extender esto a un medio completo de administración de energía. Usted crea habilitaciones de reloj para todos los subsistemas y su administrador de energía niega la habilitación de reloj para cualquiera de las subsecciones que no quiere que tengan alimentación.

Permítame citar a Donald Knuth (su objetivo era el desarrollo de software, pero también se aplica en FPGA):

  

La optimización prematura es la raíz de todo mal

Realmente no prestaría demasiada atención a bajar el reloj hasta que haya una necesidad real. No sé qué FPGA utiliza, pero en el caso de los dispositivos Xilinx, 54 MHz no es una frecuencia muy alta y XST no debería tener problemas con la sincronización.

Creo que en el caso de proyectos muy grandes, se podría ahorrar mucho tiempo de síntesis optimizando la sincronización. Si no es el caso, no lo hagas. Lo mismo se aplica al consumo de energía.

Es ciertamente posible utilizar múltiples relojes en cualquier FPGA actual.

La mayoría tiene un "administrador de reloj digital" o un bloque de ip duro similar disponible para generar múltiples frecuencias desde una sola frecuencia de entrada. Si este es un diseño relativamente sencillo, sería una buena oportunidad para aprender a usar las funciones de administración del reloj en su FPGA.

Sin embargo

• Si necesita tener señales conectadas entre el dominio de reloj rápido y el dominio lento (en cualquier dirección), deberá tener mucho cuidado de cómo hacerlo.

• Probablemente no ganará mucho en consumo de energía en comparación con el caso alternativo en el que usa el reloj rápido en todas partes, pero algunas señales simplemente no cambian muy a menudo.

Una técnica alternativa, en lugar de enrutar dos relojes, es tener una señal de "fase" vinculada al pin ENable de los flip-flops en la sección "slow", de modo que solo operen en cada n-ésimo borde del reloj rapido Esto ralentiza parte de la lógica, permite bloques combinatorios más profundos entre los registros (si puede averiguar cómo explicar a la herramienta de análisis lo que está haciendo), pero limpia la mayoría de los problemas de conexión entre los bloques rápidos y lentos. / p>     

Yo diría que en general no, no hagas eso. Sin embargo, solo usted sabe cuáles son sus limitaciones y objetivos de diseño.

La ventaja es que PERHAPS ahorra energía y las restricciones de tiempo de su diseño pueden ser más fáciles de cumplir y más rápidas de procesar. Sin embargo, esto puede no ser muy diferente a la lógica de habilitación de reloj diseñada casi de manera equivalente.

Hay grandes desventajas:

• estás dividiendo tu diseño en diferentes dominios de reloj. Si no eres MUY cuidadoso, cruzar dominios de reloj puede ser un problema real. El diseño puede parecer que funciona, pero a veces falla extrañamente en formas excepcionalmente difíciles de depurar. De hecho, comprender los dominios de reloj y cómo administrarlos es probablemente el concepto más difícil de dominar por los recién llegados.

• el uso de la lógica del usuario como un reloj puede causar muchos problemas de sesgo en su diseño y mucho más esfuerzo por parte de la herramienta de síntesis. Esto se debe a que las rutas lógicas a través del tejido de enrutamiento (muchas interconexiones - > lentas y más variables) en lugar de líneas de reloj dedicadas (pocas / ninguna interconexiones - > rápidas y menos variables). Si es posible, debe enrutar un reloj generado a un búfer de reloj (para obtener una red de reloj adecuada ANTES DE QUE algo lo use) o usar un bloque de administración de reloj dedicado.

• usar un bloque de administración de reloj dedicado desperdiciaría un recurso valioso y posiblemente costaría más energía de la que está ahorrando.

Sugerencia:

Si realmente te importa la potencia, diseña tu lógica de división del reloj ... pero usa esa salida como habilitación de reloj para tu lógica lenta. En lugar de ejecutar un contador ancho a toda velocidad, avance un contador más pequeño usando la habilitación de un reloj más lento.

Si es solo un pensamiento ocioso sin una necesidad real de conducción detrás de él, entonces no se moleste hasta / a menos que se convierta en un problema. SIN EMBARGO ... no convierta esto en una "mejor práctica" ciega. Siempre déjelo en la caja de herramientas como una opción.

...

Esto suena como una pregunta de mejores prácticas de pesca (lo cual es bueno, no hay nada de malo en eso) ... sin embargo, me gustaría decir que, en general, las mejores prácticas deben estar vinculadas a la comprensión de cuándo deberían o no deberían estarlo. aplicado.

Muy a menudo, las personas toman las mejores prácticas y las hacen casi absolutas. ¿Debería usar una máscara de buceo cuando saque un perno de una brida? Suena tonto, todos dirían que no. Ahora digamos que la brida está a 50 pies bajo el agua. Este ejemplo físico es súper obvio y más que un poco ridículo (a menos que sea un problema XY y debas obtener un subwoofer o un ROV), pero las condiciones que hacen que una idea sea buena o mala a menudo no son obvias (especialmente en ingeniería).

Si más adelante se encuentra con un presupuesto de energía o quizás mucho más comúnmente que su herramienta de síntesis no puede cumplir con el tiempo ... considere dividir la lógica que no necesita ser rápida para los relojes más lentos. No solo golpee su cabeza contra la pared tratando de resolverlo con un solo reloj, ya que algunas personas en Internet le dieron una respuesta general a su pregunta general del caso.