tiempo de procesamiento en FPGA

Siempre hay algún retraso de propagación a través del flip-flop. A menudo se llama retraso de "reloj a Q".

Eso significa que sus entradas se capturan en el borde, y las salidas cambian en el mismo borde, pero solo unos nanosegundos más tarde. Este retraso de pocos nanosegundos es suficiente (si sus flip-flops están diseñados con un "tiempo de retención cero" como lo están en la mayoría de los FPGA), los cambios no afectarán a ningún flip-flops en sentido descendente hasta el siguiente límite de reloj.

En la simulación funcional o RTL (que es probablemente lo que estás haciendo para generar tu resultado), el retraso no se simulará como nanosegundos duraderos. En VHDL, será un solo ciclo delta del reloj del simulador, que técnicamente no es tiempo. Esto hace que sea imposible ver el retraso en la salida del simulador. No obstante, para los flip-flops simulados como ideales, es suficiente que los cambios de salida no afecten a los flip-flops en sentido descendente.

Si realiza una simulación posterior al lugar y la ruta, debería poder incluir los retrasos adecuados para que pueda ver estos efectos claramente, a costa de un mayor esfuerzo de simulación.

En el borde del reloj deseado (ascendente o descendente), la entrada en D aparece en la salida Q. Esto toma una cantidad de tiempo finita (Retardo de reloj a Q) y suponiendo que no hay infracciones de tiempo, D solo pasará a través de un FF a la vez (es decir, si hay otra entrada de FF conectada a Q, el segundo FF pasará el valor de FF1 Q antes de que cambie.

Para incluir tiempos en su simulación, necesita sintetizar y colocar y enrutar su diseño, luego ejecutar una simulación de lugar y ruta de publicación. Esto tendrá todos los retrasos combinacionales, de reloj a Q, etc. incluidos. La simulación HDL no tiene ninguno de estos tiempos, por lo que solo es útil para probar la operación básica, no los límites de tiempo. También recibirá un informe de tiempo, que le indicará los límites de velocidad de un dominio de reloj en particular, le informará si hay violaciones de tiempo y le mostrará la holgura de tiempo para varias rutas. Puede usar esta información para averiguar dónde se deben realizar los cambios, o agregar reglas para indicar al software que la infracción no es un problema (por ejemplo, para cosas como rutas de múltiples ciclos o rutas de reloj cruzadas)

Esto se entiende como una adición a las respuestas anteriores, de donde creo que se entiende la idea.

Estas cuestiones pueden ser un poco difíciles al principio cuando la simulación RTL diseña, ya que uno puede encontrar difícil ver cuál es la causa y cuál es el efecto en simulaciones ideales / funcionales / RTL (= sin retrasos de propagación).

Con el simulador correcto, los retrasos delta pueden realmente visualizarse. ISim no lo hace, pero en e.i. ModelSim, puede habilitar expansión delta en los bordes del reloj. A continuación se muestra una captura de pantalla de ejemplo de una IP de terceros con errores que resolví problemas.

ceslaseñaldelreloj,y+1etc.sonlosciclosdelta,visualizadoscomotiempo.

Sisesimulaundiseñoenelquetantolasimulacióncomoeldiseñosonverdaderamenteidealesysíncronos,sinretrasossimulados,puede,enprincipio,verqueseproducentodosloscambiosdeseñalenunflancoderelojespecíficoPocodespuésdeeseflancodereloj.Ensuejemplo,porlotanto,a205ns,data_write=0000...esloquesecaptura.Algunaotralógicaenlaprimeraunidadestácambiandolaseñaldata_writea0001...enelmismoflanco,yesaseñalapareceendata_writeligeramentedespuésdelflancodelreloj.Este"ligeramente después" sería uno o varios deltas de simulación en una simulación ideal (su ejemplo) (no visible en ISim, pero en ModelSim con expansión delta), o algunos ps / ns más adelante en el mundo real.

En una nota al margen: una cosa importante con el diseño de RTL es asegurarse de que las entradas siempre se muestreen en el flanco del reloj , incluso un ciclo delta más tarde es demasiado tarde. La entrada podría no ser válida una delta más adelante. O en otras palabras: "no te metas con la ruta del reloj".