tiempo de proceso en FPGA

Soy nuevo en fpgas, y hay algunas sutilezas de temporización que no estoy seguro de entender: si todos mis procesos sincrónicos se activan en el mismo borde, eso significa que mis entradas se 'capturan' en un borde ascendente, y mi salidas cambian en .. el mismo borde? el siguiente borde ascendente?

Si tengo dos módulos, donde la salida de uno fluye a las entradas del siguiente, podría surgir la situación en la que las entradas a mi módulo (las salidas de un módulo anterior) están cambiando al mismo tiempo que se capturan.

El marcador en 205ns muestra de lo que estoy hablando, op y data_write son mis entradas. Todo parece "funcionar" en este caso de prueba, pero en la simulación no está claro exactamente qué se captura cuando. ¿Se está capturando data_write = "0001 ..." a 205ns o (205ns + 1 ciclo de reloj)? ¿Hay alguna forma de obtener formas de onda más detalladas en ISim que muestren los tiempos de configuración y retención?

Gracias.

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

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

En la simulación funcional o RTL (que probablemente sea lo que está haciendo para generar su 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 en absoluto. Esto hace que sea imposible ver el retraso en la salida del simulador. Sin embargo, para los flip-flops simulados como ideales, es suficiente que los cambios de salida no afecten los flip-flops aguas abajo.

Si realiza la simulación posterior al lugar y la ruta, debería poder incluir los retrasos apropiados 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 lleva una cantidad de tiempo finita (retraso de reloj a Q) y suponiendo que no haya violaciones 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 los tiempos en su simulación, debe sintetizar y colocar y enrutar su diseño, luego ejecutar una simulación de ubicación y ruta posterior. 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 el funcionamiento básico, 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 falta de tiempo para varias rutas. Puede usar esta información para averiguar dónde es posible que se deban hacer cambios, o se agreguen reglas para indicarle al software que la violación no es un problema (por ejemplo, para rutas de ciclo múltiple o rutas de reloj cruzado)

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

De hecho, estos asuntos pueden ser un poco complicados al principio cuando los diseños de simulación RTL 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 demoras de propagación).

Con el simulador correcto, se pueden visualizar los retrasos delta . ISim no lo hace, pero en ei ModelSim, puede habilitar la expansión delta alrededor de los bordes del reloj. A continuación se muestra una captura de pantalla de ejemplo de una IP de terceros con errores que solucioné.

ces la señal del reloj, y el +1etc. son los ciclos delta, visualizados como tiempo.

Si se simula un diseño donde tanto la simulación como el diseño son verdaderamente ideales y sincrónicos , sin demoras simuladas, puede, en principio, ver todos los cambios de señal en un flanco de reloj específico como sucediendo ligeramente después de ese flanco de reloj. En su ejemplo, por lo tanto, a 205 ns, data_write= 0000...es lo que se está capturando. Algunos otra lógica en la primera unidad está cambiando la señal data_writea 0001...en el mismo flanco, y que la señal aparece en data_writeun poco después de que el flanco de reloj. Este "poco después" sería uno o varios deltas de simulación en una simulación ideal (su ejemplo) (no visible en ISim, pero en, por ejemplo, ModelSim con expansión delta), o algunas ps / ns más adelante en el mundo real.

En una nota al margen: Una cosa importante con el diseño 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 puede no ser válida un delta más tarde. O en otras palabras: "no te metas con la ruta del reloj".