¿Por qué no puedo usar un pin marcado como GCLK en la hoja de datos como un recurso de reloj, cuando un pin marcado de forma idéntica funciona, en un Spartan-3E?

1

Estoy tratando de crear un circuito secuencial en una placa de desarrollo con un Xilinx Spartan3E XC3S500E en un paquete FT256. La placa tiene un oscilador de cristal de 50MHz conectado al pin B8, que está marcado como una entrada y GCLK en la hoja de datos . Además, hay más pines IO que están marcados como GCLK, que están desglosados (y accesibles para mi uso), incluidos A9 y C8 (que he tratado de usar específicamente).

Cuando trato de usar el pin B8 como una entrada de reloj, todo se sintetiza normalmente, sin búferes de reloj manual o primitivos IBUFG. Sin embargo, también necesito poder cronometrar mi circuito utilizando un reloj externo diferente conectado a un pin diferente (ya que el cristal está permanentemente soldado), a un nivel mucho más bajo frecuencia (en el orden de kilohertz). Anteriormente, simplemente había ignorado las advertencias sobre el enrutamiento del reloj subóptimo, utilizando la restricción CLOCK_DEDICATED_ROUTE = false . Sin embargo, parece que el FSM del circuito estaba terminando en un estado no válido debido a un enrutamiento de reloj deficiente. (¿sesgo, posiblemente?) Para determinar si ese fue el caso o no, actualmente estoy tratando de usar un reloj con el enrutamiento óptimo utilizando las rutas de reloj dedicadas.

Cuando restringo la entrada de mi reloj a un pin como A9 (etiquetado como I / O y GCLK), recibo errores durante la etapa del Mapa:

  

ERROR: Lugar: 1018 - Se ha encontrado un par de componentes IOB / reloj de reloj que son      no colocado en un reloj óptimo par de sitio IOB / reloj. El componente del reloj       <BUFGCE_inst/BUFGMUX> se coloca en el sitio <BUFGMUX_X2Y10> . El componente IO       <CLK_INPUT_PIN> se coloca en el sitio <C8> . Esto no permitirá el uso de la ruta rápida.      entre el IO y el buffer del reloj. Si esta condición sub óptima es      aceptable para este diseño, puede usar la restricción CLOCK_DEDICATED_ROUTE      en el archivo .ucf para degradar este mensaje a una ADVERTENCIA y permitir que su diseño      continuar. Sin embargo, el uso de esta anulación está altamente desaconsejado ya que puede      conducir a resultados de tiempo muy pobres. Se recomienda que esta condición de error.      Se corregirá en el diseño. Una lista de todos los COMP.PINs usados en este reloj      la regla de colocación se enumera a continuación. Estos ejemplos pueden ser utilizados directamente en el      Archivo .ucf para anular esta regla de reloj.
< NET "CLK_INPUT_PIN" CLOCK_DEDICATED_ROUTE = FALSE; >

Originalmente estaba ejecutando este reloj en un BUFGCE para usar un reloj habilitado. También he intentado quitar el BUFGCE y conectar el reloj directamente al resto de mi diseño, así como agregar un IBUFG. Cuando miro el esquema de RTL, el búfer del reloj se muestra como se esperaba.

También he intentado modificar las restricciones en el pin en el archivo UCF. Originalmente, el pin se configuró con un LOC, velocidad de giro y fuerza de accionamiento. Intenté modificar las restricciones para especificar solo el LOC, que no ayudó, y también intenté reutilizar las restricciones dadas en el pin del reloj de trabajo, con una ubicación diferente.

Informe final de síntesis:

=========================================================================
*                            Final Report                               *
=========================================================================

Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal                       | Clock buffer(FF name)  | Load  |
-----------------------------------+------------------------+-------+
CLK_INPUT_PIN                      | IBUFG+BUFGCE           | 79    |
-----------------------------------+------------------------+-------+

Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design

Timing Summary:
---------------

Speed Grade: -5

   Minimum period: 9.194ns (Maximum Frequency: 108.772MHz)
   Minimum input arrival time before clock: No path found
   Maximum output required time after clock: 7.258ns
   Maximum combinational path delay: 7.683ns

Si alguien pudiera sugerir una solución de trabajo o arrojar más luz sobre este tema, sería genial.

Editar con respecto a los DCM: revisé la hoja de datos en preparación para agregar un DCM a la entrada que no estaba funcionando. Esto no parece ser factible ya que la hoja de datos / guía de implementación especifica que 5MHz en la frecuencia mínima.

    
pregunta Andrey Akhmetov

0 respuestas

Lea otras preguntas en las etiquetas