Advertencias de tiempo para el modelo funcional

Estoy escribiendo un controlador para un módulo DDR móvil/de baja potencia en mi FPGA. Para permitir la depuración, uso un modelo funcional escrito en Verilog. En él, el tiempo de configuración y espera para alguna señal se establece en 1,5 ns. Si entiendo todo correctamente, esto significa que la señal no puede cambiar 'dentro de' 1,5 ns de un flanco ascendente del reloj.

Sin embargo, el RTL que he escrito no incluye el tiempo, por lo que la señal parece cambiar instantáneamente, lo que genera advertencias de tiempo de espera.

Por un lado, no me preocupa demasiado; Solo recibo advertencias, y creo que durante un proyecto para mi universidad, nos dijeron que simplemente ignoráramos estos errores.

Por otro lado, no me gusta ignorar las advertencias. El fabricante no habría implementado estas advertencias si no tuvieran ningún propósito. Dado que Xilinx ISE puede verificar las restricciones de tiempo, creo que debería ser posible enrutar y mapear mi diseño, y usar los tiempos generados de alguna manera (pero tal vez estoy haciendo las cosas demasiado simples aquí).

Seguro que hay más gente con el mismo problema. ¿Cuál es la forma correcta de manejar estas advertencias?

Editar: En esta página , encontré más información. Puede generar un modelo de simulación posterior al mapa o posterior al lugar y la ruta. Sospecho que esto incluye los tiempos. Sin embargo, parece que solo modelsim puede realizar la simulación.

Aclaración: Idealmente, sería capaz de sintetizar (o al menos llegar lo más lejos posible en el proceso de generar el diseño) mi parte del diseño (tengo el RTL y he especificado la placa, así que creo que esto debería ser posible), luego combínelo en un banco de pruebas con el modelo funcional para probar si mi diseño tiene los retrasos de tiempo adecuados. Sin embargo, no puedo hacer que esto funcione en Xilinx ISE 14.7.

Respuestas (3)

Como señaló dave_59, las comprobaciones de tiempo en RTL no son muy significativas. Dicho esto, aquí hay 4 enfoques posibles:

  1. No compile las comprobaciones de tiempo con RTL
  2. Use una macro de directiva de compilador ( `ifdef ... `endif) alrededor de sus controles de tiempo; controles de tiempo deshabilitados con RTL
  3. Inyecte tiempo de espera en el comportamiento de RTL cambiando todas las asignaciones de flop ( <=) a <= `D, donde `Destá su retraso (ex `define D #2)
    • Idea de la NBA con retrasos , por Cliff Cummings
    • Para sintetizar definir `Dcomo vacío (también conocido como `define D)
  4. Hackea tus fichas para tener un atributo de enmascaramiento. ex:
    $setuphold( D, CLK &&& actiming_enable, tSETUP, tHOLD);
Pero si tengo el RTL y sé a qué FPGA voy a mapear (puedo producir el flujo de bits), esencialmente se conoce todo el diseño. ¿No debería poder generar los tiempos, ya que tengo toda la información necesaria?
La síntesis es uno de los pasos para obtener esa información. Puede ejecutar la simulación con puertas sintetizadas con anotación SDF, pero eso no es una simulación RTL. La simulación RTL es para validar la lógica. La simulación de puerta de Verilog es una verificación de cordura para el tiempo y la equivalencia lógica (hay herramientas dedicadas para cada uno que hacen un trabajo más completo que la simulación de puerta)

Las comprobaciones de tiempo de configuración y retención solo tienen sentido con la información posterior al diseño. Hace un siglo, se podía realizar un análisis de tiempo sin información estructural del diseño porque los retrasos del dispositivo eran abrumadores en comparación con los retrasos en el enrutamiento. Ya no puede realizar un análisis de tiempo preciso con el código RTL.

Algunos modelos están escritos para usarse tanto en RTL como en simulaciones estructurales, por lo que puede ignorar estas advertencias. Aún mejor sería desactivar las comprobaciones de tiempo que mejoran el rendimiento de la simulación RTL (tal vez no sea relevante en su proyecto, pero eso es lo que hace la gente en la industria).

Esto no es realmente cierto. Hay modelos de tiempo muy precisos generados todo el tiempo sin información de diseño final. Así es como se generan las MCU. Cada bloque se cronometra de forma independiente y cada E/S se caracteriza en términos de velocidades de configuración/retención/retraso/carga/giro. De lo contrario, costaría miles de millones de dólares solo iterar en un chip. Dado que está programando un FPGA, debe haber alguna forma de decirle que sintetice su RTL en un mapeo de placa física. A partir de aquí, R/C es muy predecible en una tecnología FPGA probada.
@ jbord39 para FPGA más grandes/más rápidos, no puede obtener una sincronización precisa para RTL porque depende en gran medida del enrutamiento. El mismo diseño en una parte de un FPGA puede cumplir con el tiempo, pero un enrutamiento/ubicación ligeramente diferente puede generar demoras adicionales en el enrutamiento y fallas en el tiempo, incluso si el RTL en ambos es idéntico .
@TomCarpenter: No quise insinuar lo contrario, el enrutamiento generará demoras a medida que las tecnologías se hacen más pequeñas. Pero el software debería poder realizar una colocación de prueba desde el RTL. A partir de aquí, sabe hasta dónde tendrán que llegar los cables y el abanico de cada compuerta (junto con la potencia de accionamiento). También debería poder estimar la resistencia/capacitancia de cada cable. Una vez que tenga una ubicación de prueba, debería poder estimar con precisión casi todos los parámetros. Si el tiempo es malo, puede reiniciar y colocar de nuevo. Pero puede haber algunas razones por las que esto no es posible en las que no estoy pensando.
@ jbord39 RC de cada ruta no es del todo útil. Todos los interruptores de enrutamiento (que básicamente son solo SRAM) representan bastante. Los modelos de temporización de hoy en día suelen contener el retraso de cada segmento de cada ruta y los retrasos típicos de cada multiplexor, por lo que el retraso total de la ruta se puede calcular una vez que se conoce la ruta. Pero hacer una "ubicación de prueba" no es muy diferente de simplemente hacer una síntesis/ajuste/enrutamiento de diseño completo y luego hacer la simulación con una lista de conexiones posterior al ajuste (en lugar de RTL).
@TomCarpenter: Bueno, la ubicación y el tiempo de prueba con parásitos estimados es mucho más rápido que la extracción completa del diseño (y es necesario para ubicarlo en el estadio correcto la mayor parte del tiempo). Quiero decir, 5 minutos para un lugar de prueba de 500 puertas + ruta + tiempo en comparación con quizás 10 horas de lo contrario. Las herramientas también pueden manejar cambios de retardo debido al ruido de conmutación (integridad de la señal). Las CPU modernas ni siquiera están cronometradas todas juntas. Cada pieza se caracteriza en algún formato (biblioteca) y estos se cronometran en el nivel superior utilizando las bibliotecas. La especia se puede usar en las piezas de nivel inferior, pero no en el bloque de nivel superior.

Debería haber alguna forma de ingresar un retraso de tiempo.

Esto podría hacerse de un par de maneras en las que puedo pensar (tal vez más):

  • Modifique el flip flop de lanzamiento para que tenga un retraso de reloj->salida mayor que el tiempo de espera del flip flop de captura.
  • Modifique el modelo de flip flop para que tenga un tiempo de espera de -0,1 ns.
  • Modifique cualquier puerta (como un búfer) para que tenga un retraso fijo de 1,6 ns y colóquelo antes de cada flip flop de captura.
  • Cambie la señal del reloj en el flip flop de captura (segundo flop que experimenta la violación de retención) en al menos 1,5 ns en relación con el reloj de lanzamiento (va al primer flip flop).

La mayoría de estos implicarán modificar la representación de alguna puerta o búfer para incluir un retraso. Si está utilizando .libs para la caracterización, puede configurar toda la tabla de carga/giro/retraso en un valor predeterminado de 2 ns.

¿Cómo se te ocurrieron estos tiempos? ¿Puedo estar seguro de que son precisos? Prefiero usar un proceso automatizado que me proporcione estimaciones de tiempo (para que me resulte más difícil equivocarme).
@Ruben: Depende, debe ver qué modelo está usando para averiguarlo. Pero, dado que dice que no hay demora a través de las puertas lógicas, y una configuración plana de 1,5 ns y un tiempo de espera en los pestillos, puedo decirle que NO son precisos. Cada puerta lógica debe tener un retardo asociado (retraso plano como mínimo). Los modelos de retardo más precisos para PnR se caracterizan mediante una tabla de carga/pendiente.
Advertencias de tiempo para el modelo funcional
RespuestasAquíPolítica de privacidad1y, 0v