tempo do processo no FPGA

Eu sou novo no fpgas, e há algumas sutilezas de tempo que não tenho certeza se entendi: se todos os meus processos síncronos são acionados na mesma borda, isso significa que minhas entradas são 'capturadas' em uma borda ascendente e minhas saídas mudam .. a mesma borda? a próxima borda ascendente?

se eu tiver dois módulos, nos quais a saída de um flui para as entradas do próximo, pode surgir a situação em que as entradas do meu módulo (as saídas de um módulo anterior) estão mudando ao mesmo tempo em que são capturadas.

O marcador em 205ns mostra do que estou falando, sendo op e data_write minhas entradas. Tudo parece "apenas funcionar" neste caso de teste, mas na simulação não está claro exatamente o que está sendo capturado quando. O data_write = "0001 ..." está sendo capturado em 205ns ou (205ns + 1 ciclo de relógio)? Existe uma maneira de obter formas de onda mais detalhadas no ISim que mostram os tempos de configuração e espera?

Obrigado.

Sempre há algum atraso de propagação no flip-flop. É frequentemente chamado de atraso de "relógio para Q".

Isso significa que suas entradas são capturadas na borda e as saídas mudam na mesma borda, mas apenas alguns nanossegundos depois. Esse atraso de poucos nanossegundos é suficiente (se os flip-flops forem projetados com "tempo de espera zero", como na maioria dos FPGAs), para que as alterações não afetem nenhum flip-flops a jusante até a próxima borda do relógio.

Na simulação funcional ou RTL (que é provavelmente o que você está fazendo para gerar seu resultado), o atraso não será simulado como nanossegundos duradouros. No VHDL, será um ciclo delta único do relógio do simulador, que tecnicamente não há tempo. Isso torna impossível ver o atraso na saída do simulador. No entanto, para os flip-flops simulados como ideais, basta que as alterações na saída não afetem os flip-flops a jusante.

Se você fizer uma simulação pós-local e rota, deverá poder incluir atrasos apropriados para ver claramente esses efeitos, à custa de um maior esforço de simulação.

Na extremidade do relógio desejada (subindo ou descendo), a entrada em D aparece na saída Q. Isso leva um tempo finito (atraso de Clock para Q) e, assumindo que não há violações de tempo, D passará apenas por um FF por vez (ou seja, se houver outra entrada de FFs conectada a Q, o segundo FF passará o valor de FF1 Q antes de mudar.

Para incluir tempos em sua simulação, você precisa sintetizar, colocar e rotear seu design e executar uma simulação de local e rota. Isso terá todos os atrasos combinacionais, de relógio para Q, etc. incluídos. A simulação HDL não possui nenhum desses tempos, portanto, é útil apenas para testar a operação básica, não os limites de tempo. Você também receberá um relatório de tempo, informando os limites de velocidade de um domínio de relógio específico, informando se há alguma violação de tempo e mostrando a folga de vários caminhos. Você pode usar essas informações para descobrir onde as mudanças podem precisar ser feitas ou adicionar regras para informar ao software que a violação não é um problema (por exemplo, para coisas como caminhos de vários ciclos ou caminhos de relógio cruzado)

Isto é uma adição às respostas anteriores, das quais acredito que você entendeu a idéia.

De fato, essas questões podem ser um pouco complicadas no início quando os projetos de RTL de simulação são difíceis, pois é difícil ver qual é a causa e qual é o efeito nas simulações ideais / funcionais / RTL (= sem atrasos na propagação).

Com o simulador certo, os atrasos delta podem realmente ser visualizados. O ISim não faz isso, mas no ei ModelSim, você pode ativar a expansão delta nas bordas do relógio. Abaixo está um exemplo de captura de tela de um IP de terceiros com bugs que eu resolvi.

cé o sinal do relógio e +1etc. são os ciclos delta, visualizados com o tempo.

Se um projeto é simulado onde a simulação e o projeto são realmente ideais e síncronos , sem atrasos simulados, você pode, em princípio, visualizar todas as alterações de sinal em um flanco de relógio específico como ocorrendo um pouco depois desse flanco de relógio. No seu exemplo, portanto, em 205 ns, data_write= 0000...é o que está sendo capturado. Alguma outra lógica na primeira unidade está alterando o sinal data_writepara 0001...no mesmo flanco, e esse sinal aparece data_writeum pouco após o flanco do relógio. Esse "pouco depois" seria um ou vários deltas da simulação em uma simulação ideal (seu exemplo) (não visível no ISim, mas no ModelSim com expansão delta), ou alguns ps / ns posteriormente no mundo real.

Em uma nota lateral: Uma coisa importante no design de RTL é garantir que as entradas sejam sempre amostradas no flanco do relógio - mesmo um ciclo delta mais tarde é tarde demais. A entrada pode não ser válida um delta mais tarde. Ou em outras palavras: "não mexa com o caminho do relógio".