Tengo un pequeño problema con mi dominio de reloj que cruza las restricciones de tiempo.
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_Aa clk_Bsean tratadas como caminos falsos.
Sin embargo, me gustaría restringir algunos de estos caminos como
set_max_delay -to [get_registers {*|*|some_reg}] 8
Pero si entendí correctamente la documentación de Altera. Las rutas falsas implícitas creadas a partir de los grupos de relojes asíncronos harán que se ignore la última restricción.
Por ahora me supera 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 necesito dejar de usar grupos de relojes y restringir todas las rutas relevantes manualmente?
A pesar de que es bastante común en la industria cortar globalmente todos los caminos entre dos grupos de relojes, desaconsejaría encarecidamente esta práctica, ya que hace que sea muy difícil detectar lugares en los que involuntariamente volvió a muestrear una señal entre dominios de relojes.
Es mejor usar un bloque común para transferir datos entre dominios. Incruste las restricciones en el bloque común o use 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 pautas de codificación.
Luego puede informar todos los cruces de dominios de reloj y encontrar lugares donde no estaba utilizando un mecanismo de transferencia seguro. También puede incluir verificación automática en su flujo y localizar rápidamente cualquier cruce de reloj accidental en su diseño.
También podrá usar su set_max_delayrestricción y no ignorarla :)
+1 para los comentarios de @chiggs que sugieren que no corte caminos entre dominios. Es fácil de hacer y, a menudo, funciona, pero puede fallar cuando las herramientas de P&R se presionan con fuerza, como cuando la pieza está casi llena.
Si va a usar set_max_delay, también necesitará 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 busca una ventana de 8 ns, puede configurar el retraso mínimo en -1 y el retraso máximo en 7. Sin embargo, aunque conoce el tamaño total de la ventana (también conocido como sesgo) que está buscando, todo lo que necesita lo que puede hacer es adivinar dónde colocar la ventana con respecto al reloj, [-1,7] o [-2,6], etc. Por esa razón, este enfoque no es necesariamente óptimo, particularmente para reloj alto. tarifas
En última instancia, para la corrección funcional, lo que realmente le 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 de uso, consulte la documentación de Altera para set_max_skew
carajo