tiempo de proceso en FPGA

Soy nuevo en fpgas, y hay algunas sutilezas de tiempo 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 las salidas cambian en ... ¿el mismo borde? el próximo flanco ascendente?

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

Captura de pantalla de ISim

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

Gracias.

Respuestas (3)

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

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

En la simulación funcional o RTL (que es probablemente lo que está haciendo para generar su resultado), el retraso no se simulará como nanosegundos de duración. En VHDL, será un ciclo delta único 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. No obstante, para los flip-flops simulados como ideales, es suficiente que los cambios de salida no afecten a los flip-flops aguas abajo.

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

En una simulación VHDL RTL, el retraso es un solo ciclo delta. Esto toma exactamente cero tiempo, pero permite que la simulación avance de manera ordenada ya que todas las actualizaciones en el ciclo delta actual se completan antes de que comience el próximo ciclo delta. Cuando no hay más ciclos delta programados, el tiempo puede avanzar.

En el flanco del reloj deseado (ascendente o descendente), la entrada en D aparece en la salida Q. Esto toma una cantidad finita de tiempo (retraso del 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 FF conectada a Q, la segunda FF pasará el valor Q de FF1 antes de que cambie.

Para incluir tiempos en su simulación, debe sintetizar y colocar y enrutar su diseño, luego ejecutar una simulación posterior de ubicación y enrutamiento. Esto incluirá todas las demoras combinacionales, de reloj a Q, etc. 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 obtendrá un informe de tiempo, que le indicará los límites de velocidad de un dominio de reloj en particular, le informará si hay alguna violación de tiempo y le mostrará la holgura de tiempo para varias rutas. Puede usar esta información para averiguar dónde es posible que se deban realizar cambios o agregar reglas para decirle al software que la infracción no es un problema (por ejemplo, para cosas como rutas de varios ciclos o rutas de reloj cruzadas)

Esto pretende ser una adición a las respuestas anteriores, de las cuales creo que tienes la idea.

De hecho, estos asuntos pueden ser un poco complicados al principio cuando se simulan diseños RTL, ya que puede resultar 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 adecuado, los retrasos delta se pueden visualizar. 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 resolví.

Expansión de retraso Delta en ModelSim

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

Si se simula un diseño donde tanto la simulación como el diseño son realmente ideales y sincrónicos , sin retrasos simulados, puede, en principio, ver todos los cambios de señal en un flanco de reloj específico como si ocurrieran un poco después de ese flanco de reloj. En su ejemplo, por lo tanto, a 205 ns, data_write= 0000...es lo que se captura. Alguna otra lógica en la primera unidad está cambiando la señal data_writeal 0001...mismo flanco, y esa señal aparece un data_writepoco después del flanco del reloj. 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, por ejemplo, ModelSim con expansión delta), o algunos ps/ns más tarde 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. Es posible que la entrada no sea válida un delta más tarde. O en otras palabras: "no te metas con la ruta del reloj".