Restricciones de tiempo de cruce del dominio del reloj para Altera

Question

Restricciones de tiempo de cruce del dominio del reloj para Altera

#1 de Chiggs (1 votos)
#2 de David Gardner (0 votos)

3

Tengo un pequeño problema con las restricciones de tiempo de cruce de mi dominio del reloj.

Tengo dos grupos de reloj

set_clock_groups -asynchronous -group {clk_A} -group {clk_B}

Según tengo entendido, esto hará que todas las señales de clk_A a clk_B se traten como rutas falsas.

Sin embargo, me gustaría restringir algunas de estas rutas como

set_max_delay -to [get_registers {*|*|some_reg}] 8

Pero si entendí la documentación de Altera correctamente. Las rutas falsas implícitas creadas a partir de los grupos de reloj asíncronos harán que la restricción posterior se ignore.

Por ahora es mejor que mi por qué una restricción más específica tiene menos prioridad que la más general.

¿Alguien ha resuelto esto de manera práctica o debo dejar de usar grupos de reloj y restringir manualmente todas las rutas relevantes?

fpga constraints intel-fpga timing-analysis cdc

pregunta AxelOmega

2 respuestas

Lea otras preguntas en las etiquetas fpga constraints intel-fpga timing-analysis cdc

Protección contra cortocircuito de CA ¿Por qué recibo un Estado de módem (0x8A) en los mensajes de transmisión (XBee)?

score 1 · Answer 1

A pesar de ser bastante común en la industria para cortar globalmente todos los caminos entre dos grupos de reloj, recomendaría fuertemente esta práctica, ya que hace que sea muy difícil detectar lugares donde se vuelve a muestrear involuntariamente una señal entre dominios de reloj.

Es mejor utilizar un bloque común para transferir datos entre dominios. Incruste las restricciones en el bloque común, o utilice comodines en las rutas para restringir cada instancia del bloque en su diseño. Haga que el uso de un bloque de sincronización común forme parte de sus directrices de codificación.

Luego puede informar todos los cruces de dominio de reloj y encontrar lugares donde no estaba usando un mecanismo de transferencia seguro. También puede incluir la verificación automática de su flujo y localizar rápidamente cualquier cruce accidental de reloj en su diseño.

También podrás usar tu restricción set_max_delay y no hacer que se ignore :)

score 0 · Answer 2

+1 para los comentarios de @chiggs que sugieren que no cortes las rutas entre dominios. Es fácil de hacer y a menudo funciona, pero puede fallar cuando las herramientas P & R se presionan con fuerza, como cuando la parte está casi llena.

Si vas a usar set_max_delay, también necesitarás usar set_min_delay. Tenga en cuenta que debido a la forma en que se analizan las rutas, es posible que los retrasos sean negativos. Por ejemplo, si va a buscar una ventana 8ns, entonces puede configurar el retraso mínimo en -1 y el retraso máximo en 7. Sin embargo, aunque sepa el tamaño total de la ventana (también conocido como sesgo) que está buscando, todo lo que necesita es lo que se puede hacer es hacer una conjetura acerca de dónde colocar la ventana con respecto al reloj, [-1,7] o [-2,6], etc. Por esta razón, este enfoque no es necesariamente óptimo, especialmente para el reloj alto. tarifas

En última instancia, para la corrección funcional, lo que realmente te importa es el sesgo entre el conjunto de redes que cruzan el límite. Y la mejor manera de especificar eso es con una restricción de sesgo máximo. Para obtener información sobre el uso, consulte la documentación de Altera para

Restricciones de tiempo de cruce del dominio del reloj para Altera

Publicaciones recientes del blog

2 respuestas