¿Restricciones de tiempo para los relojes de muestra central generados reenviados?

Navega tus respuestas
1

Descripción del problema

Estoy tratando de descubrir la forma "correcta" de restringir (en formato .xdc - esto es en Vivado) un reloj sincronizado de fuente reenviado que se genera (por división) del reloj del sistema y se realiza un muestreo central en el módulo de recepción. La situación es como tal:

Tenemos un ADC al que nuestro FPGA está enviando datos. La interfaz del ADC es sincrónica al origen: enviamos un reloj junto con los datos. También es una muestra central, ya que generamos los datos (en el FPGA) en el flanco descendente del reloj reenviado, y capturamos los datos en el flanco ascendente del reloj reenviado. Para aumentar la complejidad, este reloj reenviado se genera al dividir el reloj del sistema. Queremos poder configurar el retardo de salida de este reloj / datos reenviado para que podamos especificar la configuración y los tiempos de espera del ADC. El problema es que no estamos seguros de cómo especificar las restricciones de varios ciclos, de modo que Vivado se dé cuenta del lanzamiento y la ventaja de captura correctos.

En la vida real, nuestro reloj reenviado solo se divide en dos en comparación con el reloj del sistema, pero queremos saber cómo hacerlo en el caso más general, por lo que estableceremos la tasa de división en ocho por el bien de ejemplo.

Visualización

Elgranproblemaesaveriguarlasrestriccionescorrectasdevariosciclos.Parecequenohayunamaneraintuitivadeespecificarquelosdatosselanzanenelflancodescendentedelrelojgeneradoyquesoncapturadosporelflancoascendente.Elproblemaprincipalesquelosdatossonrealmentegeneradosporelrelojdelsistema:unFSM(quecreaelrelojgenerado)garantizaquelosnuevosdatossoloseinicienenlosbordesdondecaeelrelojgenerado.El"reloj de lanzamiento" es, por lo tanto, el reloj del sistema, mientras que el "reloj de captura" es SCKO.

Abajo hay un dibujo del sistema.

Intentodesoluciones

Pudimosresolverconbastantefacilidadlacuestióndelmulticicloenloquerespectaalaconfiguración:enestecasoestablecemos:

set_multicycle_path4-setup-from[get_clockssys_clk]-to[get_clocksSCKO]-start

Estotienesentido:nuestrobordedecapturaestáa4ciclosdenuestrobordedelanzamiento,porloqueimpulsamoslosciclosderetenciónhaciaadelantedeltiempodeconfiguración.Estos4ciclossonentérminosdelrelojdelsistema,porloquenosaseguramosdeutilizarelindicadordeinicioparaqueelmultiplicadordelaconfiguraciónseaentérminosdelrelojdeinicio.

Lapreguntaes:¿quédebemoshacerparalarutaderetencióndemulticiclosyporqué?

Investigación

Parainvestigación,podemosconsultar UG903 de Vivado: Usando Restricciones . De particular uso es la sección sobre rutas multiciclo, específicamente la sección "Multiciclos entre relojes FAST-to-SLOW" en la página 117. Pero esto solo nos dice cómo manejar una ruta de datos extendida. No entendemos cómo aplicar esto a nuestra proyecto, donde debemos asegurarnos de que Vivado sepa que los datos solo se lanzan en el flanco descendente de SCKO (que NO es el reloj que lo genera, sys_clk lo genera, sino solo ciertos flancos ascendentes de sys_clk ...).

Hemos intentado pasar por diferentes multiplicadores de retención, pero no estamos seguros de cuál es la forma correcta de hacerlo. Para nuestro ejemplo de "dividir por 2", encontramos que establecer un multiplicador de retención de 1 funcionaría: el informe de ruta parecía indicar que pudimos convencernos de que era la respuesta correcta (a saber, comenzó el "reloj de origen" un período después de el "reloj de lanzamiento": correspondería a la ruta de lanzamiento que comienza en el borde descendente del reloj reenviado y la ruta de captura que comienza en el borde ascendente del reloj reenviado.

También hemos analizado varios parámetros para nuestro reloj generado, el retardo de salida y el establecimiento de restricciones de ruta de varios ciclos. Hemos visto la bandera "-clock_fall", pero esto le dice a la herramienta que queremos capturar en el borde descendente (cuando realmente necesitamos decirle que se lance en el borde descendente ... pero de un reloj diferente). También hemos analizado "-rise" y "-fall", pero no hemos podido averiguar realmente qué hacen o qué efecto tienen.

Pregunta

En resumen: ¿cuál es la restricción de ciclo múltiple correcta para poner aquí y por qué?

    
pregunta YSl

1 respuesta

0
  

Queremos poder configurar el retardo de salida de este reenviado   reloj / datos para que podamos especificar la configuración y los tiempos de espera del ADC.

De la explicación anterior, necesita generar demora en los datos y líneas de reloj, Tengo dos soluciones para este problema.

1) usando Recursos de retardo de entrada (IDELAY) o ODELAY enlace

en el diseño de alta velocidad, algunos retrasos en PCB compensados con búferes de retardo. (Estos son algunos tab de retrasos)

2) la segunda solución es sincronizar el reloj FPGA con la retroalimentación del reloj ADC (se genera en PLL) ¡Creo que no es fácil y útil para su caso!

Editado:

Creo que en FPGA primero debes considerar qué circuito necesitas , luego dile al compilador que genere eso. Xilinx dijo que "la ruta lógica que requiere más de un ciclo de reloj para que los datos se estabilicen en el punto final. Si el circuito de control del punto de inicio y el punto final de la ruta lo permite, Xilinx recomienda que use la Ruta del ciclo múltiple".

Ahora en su ejemplo, donde tiene dos señales desde el lado de FPGA al ADC, (no dice el requisito de bajo consumo, el multi-ciclo ayuda a este objetivo) el Xilinx dijo "datos para estabilizar" porque esto puede generar metastabilidad . con el reloj y el pin de datos de FPGA a ADC, entonces la demora entre el borde del reloj y los datos estables tiene dos casos, el primero más grande que un ciclo del reloj o menor, para el último caso IDELAY está bien, pero si tiene más grande más de un retardo de ciclo (cuando le preocupa) usted compensa su retardo, configurando un dato en el último ciclo de reloj o en dos o más, y luego el retardo de reloj secundario se compensa con (IDELAY).

Creo que su caso no necesita "set_multicycle_path" . Si desea un bajo consumo de energía, puede preocuparse por "Multiciclos en el dominio de un solo reloj" . Si tiene un pin recibe una señal del lado ADC, cuando el ADC no sea estable menos que el ciclo del reloj, debe probar "Multiciclos en el dominio de un solo reloj" por razones de metastabilidad .

    
respondido por el M KS

Lea otras preguntas en las etiquetas

Reduciendo la cantidad de salida del controlador requerida - haciendo que k de n sea binario a decodificador único de los decodificadores 1-de-n MOVs, fusible térmico y comportamiento térmico fuera de control