¿Por qué no es confiable este detector de borde de caída VHDL?

1

Estoy intentando escribir un decodificador RS232 para mi Mojo v3 (Spartan 6 XC6SLX9). Sé que puedo encontrar bibliotecas existentes para hacer esto, me gustaría hacerlo yo mismo. Como parte de la decodificación, necesito detectar la transición de alto a bajo para el bit de inicio.

Muchas fuentes, como el detector de bordes de fpgacenter y el libro de ejemplos de creación de prototipos FPGA de Pong Chu por VHDL, recomiendan algo como esto:

architecture arch of edge_detector is
    signal last: std_logic;
begin
    process(clk)
    begin
        if rising_edge(clk) then
            last <= signal_in;
        end if;
    end process;

    output <= (not signal_in) and last; 
end arch;

No he encontrado que sea un detector confiable de bordes caídos. En particular, parece que se pierden los bordes descendentes cuando el FPGA ve el borde cerca del borde ascendente del reloj:

LENTOesundetectordebordesqueusadosregistrosparahacerladetección.MientrasqueFASTdispararáenelmismocicloderelojqueelflancodescendente,SLOWsedispararáenelsiguienteciclo.MALAvaaloaltocuandovefuegolentosinunticcorrespondientedeRÁPIDO.RAW_RXesdirectodesdeeltransceptorUSBaserieFTDI,sinpasarporelFPGA;RXeslamismaseñalquesevedesdeelinteriordelFPGA(ysedesvía,comoFAST,SLOW,etc.).CLKesunrelojde50MHz.

Elmismodetectordeflancodescendentesedisparacorrectamentecuandoveunatransicióndealtaabajaduranteelciclodelreloj:

Esa detección exitosa también ilustra por qué he llamado lento LENTO.

¿Qué estoy haciendo mal? ¿Se espera que este detector funcione cuando las transiciones coinciden con los flancos ascendentes del reloj?

    
pregunta simmonmt

2 respuestas

4

"signal_in" no es cronometrado por las herramientas de desarrollo hasta que se introduce en un elemento temporizado (es decir, registro). Debido a esto, no hay nada que diga que "not signal_in" tiene que ser válido antes / después de que se actualice "last".

Por lo tanto, cuando "last" y "not signal_in" se combinan con AND, hay esencialmente una condición de carrera, en la que el resultado final puede variar (entre las compilaciones debido al enrutamiento y entre los FPGA debido a las variaciones en el tejido específico). Esta es la razón por la que las señales siempre deben incorporarse a un reloj antes de ser utilizadas en los cálculos.

    
respondido por el ks0ze
1

Está tomando el último en el mismo ciclo que su prueba, Signal_In puede cambiar entre las instrucciones.

Debería ser más así.

begin
    if rising_edge(clk) then
        output <= (not signal_in) and last; 
        last <= signal_in;
    end if;
end process;
    
respondido por el Trevor_G

Lea otras preguntas en las etiquetas