¿La ubicación de IOB / BUFGMUX del reloj no óptima se puede corregir en software o hardware?

Navega tus respuestas
0

Recibo este desagradable error al sintetizar mi diseño utilizando ISE Studio para Spartan-6: 

ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found
   that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock
   IOB component <PIN_ADC_CLKOUT_P> is placed at site <C17>. The corresponding
   BUFG component <adc_clkout_BUFG> is placed at site <BUFGMUX_X2Y10>. There is
   only a select set of IOBs that can use the fast path to the Clocker buffer,
   and they are not being used. You may want to analyze why this problem exists
   and correct it. If this sub optimal condition is acceptable for this design,
   you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote
   this message to a WARNING and allow your design to continue. However, the use
   of this override is highly discouraged as it may lead to very poor timing
   results. It is recommended that this error condition be corrected in the
   design. A list of all the COMP.PINs used in this clock placement rule is
   listed below. These examples can be used directly in the .ucf file to
   override this clock rule.
   < NET "PIN_ADC_CLKOUT_P" CLOCK_DEDICATED_ROUTE = FALSE; >

Esta entrada en particular es una entrada de LVDS y la tengo en mi código: 

wire adc_clkout;
IBUFDS ibuf_adc_clkout(.I(PIN_ADC_CLKOUT_P), .IB(PIN_ADC_CLKOUT_N), .O(adc_clkout));

y el archivo ucf dice: 

NET "PIN_ADC_CLKOUT_P"  LOC="C17" |IOSTANDARD=LVDS_25 |DIFF_TERM=true;
NET "PIN_ADC_CLKOUT_N"  LOC="A17" |IOSTANDARD=LVDS_25 |DIFF_TERM=true;

Hay otras señales LVDS con definiciones idénticas de las cuales no recibo este error.

Intenté todo lo que imagino para deshacerme de este error sin éxito. Al final, solo usé CLOCK_DEDICATED_ROUTE = FALSE y lo llamé el día.

Sin embargo, ahora estoy teniendo problemas de tiempo cuando cambio el código de Verilog que no tiene nada que ver con el lugar donde ocurre el error. Sin embargo, tiene que ver con esta línea CLKOUT. Así que me imagino que podría tener que ver con este error y me gustaría resolverlo.

Sin embargo, el hardware ya se ha creado, yo no puedo cambiar los pines de E / S .

¿Puedo eliminar de alguna manera este error en el software?

Algunas observaciones:

  • Esto no es una señal de reloj en el sentido de que se usa en múltiples ubicaciones, por lo que no necesitaría un árbol de reloj, etc. Es solo un reloj de emparejamiento proporcionado por el ADC junto con los datos en serie para que pueda bloquear los datos en el borde ascendente de este reloj.

  • El reloj ADC lo genera yo mismo dentro del FPGA. La señal PIN_ADC_CLKOUT no es más que una copia sesgada de eso, concuerda con las líneas de datos y el sesgo viene dado por el procesamiento del ADC y el recorrido de ida y vuelta de PCB

  • Este reloj ADC está "en servicio". Para referencia, el ADC es el LTC2323 y el tiempo se ve así:

pregunta divB

2 respuestas

0

Conduce entradas de reloj de registro, es una señal de reloj, tan simple como.

¿Tiene el reloj de origen ADC también conectado al FPGA en un par de entrada de reloj real? Si es así, podría (verifique la sincronización en el ADC con más cuidado) ser capaz de ignorar la salida del reloj del ADC y usar un MCMM o similar para producir un reloj interno que tenga el sesgo apropiado en comparación con su entrada de reloj real para bloquear los datos. / p>

Tal vez podría utilizar esta entrada SOLAMENTE para registrar un registro en los problemas de IO y luego usar un lío de flip-flops de sincronización para cruzar a un dominio de reloj controlado por una entrada de reloj real a la misma velocidad. El resto de tu lógica.

A falta de eso, el consejo responde.

    
respondido por el Dan Mills
0

Hay algunos puntos que necesitan ser aclarados. La señal CLKOUT es lo que comúnmente se llama "reloj de datos" . El reloj de datos es básicamente una copia de la referencia de reloj (SCK) alineada con los datos para que pueda usarse para muestrearlos.

Como se señaló correctamente anteriormente, el problema principal es que el reloj de datos no estaba conectado a las entradas con capacidad de reloj del dispositivo y, por lo tanto, no hay una forma óptima de enrutarlo a la red del reloj.

La razón por la que está teniendo problemas de sincronización es mediante el uso de esta señal como un reloj. ¿Lo usa junto con la instrucción @posedge (o rising_edge ()) en cualquier parte del código? (Finalmente, verifique su lista de redes de síntesis en PlanAhead para ver si hay flip flops sincronizados con esta señal).

Para responder a su pregunta: todo depende de lo que espera, por ejemplo, qué tasa está tratando de alcanzar. Hay varias opciones:

  • Puede volver a muestrear la señal CLKOUT mediante un reloj más rápido y usarla como luz estroboscópica "válida para datos" para bloquear el SDO. Tenga en cuenta que incluso esto puede ser difícil si planea usar frecuencias de reloj de + 100MHz. Recomendaría usar un sincronizador 2-DFF para minimizar la posibilidad de problemas de metastabilidad.

  • Para tasas más bajas, use el SCK para el muestreo de datos e ignore el CLKOUT por completo. Allí podrá muestrear los datos en el flanco ascendente de SCK, ya que los datos se presentan en el flanco descendente (como en las aplicaciones SPI). Puede usar el osciloscopio para asegurarse de que las transiciones SDO no se produzcan demasiado cerca del borde de SCK.

  • Si planea hacer una nueva revisión de PCB de todos modos, use las soluciones provistas anteriormente como solución temporal y conecte el CLKOUT_P / N a los pines con capacidad de reloj en el mismo medio banco que el SDO

respondido por el lemikainen

Lea otras preguntas en las etiquetas

tareas sincronizadas e interrumpe conflictos con el sistema de archivos protección contra sobretensiones coaxial de rayos