Manipulación de relojes inferidos durante la síntesis de RTL.

Question

Estoy tratando de sintetizar un diseño en VHDL en un ProASIC3 FPGA usando el Synplify Pro de la herramienta. El informe de síntesis, me da el siguiente mensaje de advertencia en la inferirse de los relojes.

@W:MT420 :  | Found inferred clock counter_unit| pstate_inferred_clock[1] with period 10.00ns. Please declare a user-defined clock on object "n:bcu_ins.ctr_ins.pstate[1]"

Me remonta a la parte del código donde la advertencia se genera y el mismo se reproduce aquí por referencia.

p_fsm_clk : process(reset_n_in, clk_25mhz_in)
begin
    if (reset_n_in = '0') then
        pstate <= s0;
    elsif rising_edge(clk_25mhz_in) then
        pstate <= nstate;
    end if;
end process p_fsm_clk;

p_fsm : process(pstate,restart_ctr,enable_ctr2,sys_fail)
begin
    start_ctr1 <= '0';
    start_ctr2 <= '0';

    case pstate is
        when s0 =>
        --Reset state. All counters are reset
            if (sys_fail = '0' and restart_ctr = '1') then
                nstate <= s1;   --move to start counter1
            else
                nstate <= s0;
            end if;

        when s1 =>
            start_ctr1 <= '1';  --Initiate counter1
            if (restart_ctr = '1') then
            --restart the counters
                start_ctr1 <= '0';  --reset counter1
                nstate <= s1;
            elsif (enable_ctr2 = '1') then
            --move to start counter2
                nstate <= s2;
            else
                nstate <= s1;
            end if;

        when s2 =>
        --Save the counter1 value and start counter2
            start_ctr2 <= '1';  --assert flag to start counter2
            if (restart_ctr = '1') then
            --restart the counters
                nstate <= s1;
            else
                nstate <= s3;
            end if;

        when s3 =>
            start_ctr2 <= '1';
            if (sys_fail = '1') then
                nstate <= s0;
            elsif (restart_ctr = '1') then
            --restart the counters
                nstate <= s1;
            else
                nstate <= s3;
            end if;

        when others =>
            nstate <= s0;

    end case;
end process p_fsm;

--counter1
p_ctr1 : process(reset_n_in, clk_25mhz_in)
begin
    if (reset_n_in = '0') then
        ctr1 <= 0;  --value on reset
    elsif rising_edge(clk_25mhz_in) then
        if (start_ctr1 = '1') then
        --flag is asserted to start counter1
            ctr1 <= ctr1 + 1;   --increment counter
        else
        --flag de-asserted
            ctr1 <= 0;  --reset the counter
        end if;
    end if;
end process p_offset_cnt;

--save the value of counter1
offset_val <= ctr1 when pstate = s2;

La lógica contiene dos contadores – ctr1 y ctr2. Los contadores se ejecuta cuando no hay fallas en el sistema. En la primera fase ctr1 se ejecute, lo que es seguido por ctr2. ctr1 deja de contar cuando ctr2 está habilitado. El valor de ctr1 determina cuánto más tarde se ctr2 comenzó (en términos de 25MHz reloj período), conocido como el desplazamiento. Este valor de desplazamiento se almacena a una señal, vector, como se puede ver en la última línea del código. El estado s2 es utilizado para capturar el valor de ctr1 antes de que se restablece a 0.

offset_val <= ctr1 when pstate = s2;

Me di cuenta de que esta instrucción de asignación está causando el supuesto reloj en el diseño (pero no sé por qué). Cuando pongo la misma instrucción dentro de un reloj proceso, el supuesto reloj de advertencia desaparece. Sin embargo, mi lógica no funciona correctamente.

Estoy buscando un par de aclaraciones a este respecto.

1. ¿Por qué hay un inferirse reloj en pstate[1] en este diseño?
2. Está bien que tienen esas declaraciones en el diseño? La presencia de los inferirse relojes indican un mal diseño de la práctica?
3. Si no aceptar que han deducido los relojes en el diseño, ¿cómo puedo solucionar este problema mediante la codificación de la lógica de manera diferente?
4. Si está bien que se han deducido de los relojes, ¿cómo puedo dejar que la herramienta se sabe de ella? ¿Qué período de restringir puedo proporcionar para tales inferirse relojes? ¿Cómo puedo determinar un período significativo de tales inferirse relojes?

Answer 1

Se ha añadido un FPGA etiqueta, así que voy a responder de una FPGA perspectiva. Si usted está creando un ASIC o utilizando algún otro flujo, una respuesta diferente podría aplicar.

1. ¿Por qué hay un inferirse reloj en pstate[1] en este diseño?

offset_val <= ctr1 when pstate = s2;

Esta línea no describe nada de lo que sucede cuando pstate es no s2. Esto constituye una comunidad cerrada seguro. En cualquier FPGA que he utilizado, se llevará a cabo mediante la activación de un "pestillo" modo normal para un flip flop, utilizando el 'reloj' pin 'puerta'. Su puerta de la señal en ese punto es el uso de reloj de recursos, pero en última instancia se deriva de otro de los 'datos' de la señal, en oposición a un 'real' del reloj.

2. Está bien que tienen esas declaraciones en el diseño? La presencia de los inferirse relojes indican un mal diseño de la práctica?

Se enclava en general debe evitarse a menos que haya una razón fuerte para que ellos, ya que por lo general proporcionan la mala sincronización de rendimiento, y puede más fácilmente resultar en peligros y de razas en el diseño. Un ejemplo de que los pestillos debe ser utilizado sería si la interfaz externa que tenía que usar un nivel de entrada sensible de algún tipo. En su caso parece que debería ser bastante fácil de evitar un pestillo.

3. Si no aceptar que han deducido los relojes en el diseño, ¿cómo puedo solucionar este problema mediante la codificación de la lógica de manera diferente?

Utilice una velocidad de reloj de proceso que contiene la asignación. Esto se infiere de un flip-flop para offset_val. Usted tendría que simular el diseño de la sonda a bordo para asegurarse de que la función es equivalente en su caso particular, pero la filosofía básica en la FPGA, debe ser que cualquier asignación sencillo a <= b and c; o some_vec <= smaller_vec & another_bit; utiliza una velocidad de reloj de proceso. Esto le dará momento predecible resultados y hacer que sea más fácil escribir las restricciones. Hay excepciones, pero este debe ser el punto de partida.

4. Si está bien que se han deducido de los relojes, ¿cómo puedo dejar que la herramienta se sabe de ella? ¿Qué período de restringir puedo proporcionar para tales inferirse relojes? ¿Cómo puedo determinar un período significativo de tales inferirse relojes?

Para el caso de una interfaz externa, el nivel de entrada sensible tendrá un mínimo de ancho de pulso, y usted puede usar esto para crear un período de restricción que constituye el peor de los casos, el modo en que la señal puede alternar. Para cualquier interfaces internas, me gustaría trabajar para evitar el pestillo de la existente en todo, pero con la misma técnica se podría aplicar. Evitando los pestillos en total, se evita tener que pensar en este tipo de problema.

---

Además de estos, los dos-estado del proceso de diseño de la máquina se muestra en el código, no es necesario. Usted puede poner el conjunto de la máquina y las transiciones de estado a una velocidad de reloj de proceso. El proceso resultante sería muy similar a la de su segundo proceso anterior, con todo envuelto en un if (rising_edge(clk)) then, y todas las ocurrencias de nstate reemplazado con pstate. Usted debe ser capaz de encontrar respuestas sobre el estado de diseño de la máquina, ya sea aquí en EE, o a través de Stack Overflow en VHDL de la etiqueta.