Contador para reloj de 20 GHz

Estoy diseñando una aplicación de tiempo crítico en la que necesito una resolución de tiempo del orden de 100 picosegundos.

Estoy considerando hacer un oscilador de anillo de 20 GHz y un reloj de oscilador de anillo.

¿Hay IC para ello o puedo implementarlo usando CoolRunner II CPLD u otro FPGA?

Miré su hoja de datos y la frecuencia máxima para el reloj del sistema es de aproximadamente 256 MHz y el reloj externo es de 145 MHz. Ficha de datos

¿Debo buscar un dispositivo más rápido o hay alguna otra forma de construirlo?

Los pines de E/S en ayunas de los últimos FPGA pueden manejar alrededor de 1 GHz para la memoria DDR. La red de reloj interno de un FPGA está restringida a alrededor de 900 MHz. Entonces, los FPGA no pueden resolver sus problemas.
¿Esto es para mediciones de tiempo de vuelo? Hay IC TOF dedicados con una resolución inferior a 100ps. Funcionan como un cronómetro. ¿Quizás podría poner uno de estos en servicio? Eche un vistazo a ti.com/lit/ds/symlink/tdc7200.pdf .
Normalmente, para este tipo de resolución de tiempo, usaría un convertidor de tiempo a digital, no un contador. Básicamente, estos activan un pequeño condensador con las señales de activación, y luego mide el voltaje acumulado en él. Para obtener algunas ideas, eche un vistazo a cómo funcionan los osciloscopios de muestreo de tiempo equivalente (ETS).
@Paebbels: Los dispositivos Stratix 10 más rápidos de Altera pueden manejar E/S a 28,3 Gb/s. Los dispositivos Virtex-7 más rápidos de Xilinx pueden manejar 28,05 Gb/s. Su conocimiento está varios años desactualizado.
@DaveTweed Sé de transceptores de 28 GHz. Los estoy usando yo mismo en diseños de alta velocidad. Pero no creo que puedas usarlos para hacer mediciones de tiempo. Incluso con transceptores multi GHz, la red de reloj está limitada a alrededor de 1 GHz.
@Paebbels: E/S a 28 GHz es E/S a 28 GHz. Puede muestrear cualquier señal a esa velocidad. ¿Por qué no serías capaz de usarlo para medir el tiempo? Obviamente, la estructura tendría que lidiar con muestras que salen del deserializador como un bus paralelo, pero eso es sencillo.
@DaveTweed, ninguna señal. Una señal con series muy largas de 0 o 1 probablemente provocaría que el CDR del transceptor perdiera el enganche, lo que haría que el reloj crítico se desviara. Tendría que encontrar una manera de hacer que el evento que desea sincronizar cambie entre dos patrones de entrada, cada uno con una densidad de transición adecuada, para usar estas entradas en el FPGA para la sincronización de eventos.
Para OP, tenga en cuenta que no necesita relojes de 20 GHz para lograr una sincronización de 100 ps. Por ejemplo, dos relojes de 5 GHz con una diferencia de fase de 90 grados pueden lograr una temporización de 100 ps. O 5 relojes de 1 GHz, cada uno compensado por 36 grados. Pero en algún momento, mantener un gran grupo de relojes alineados con la suficiente precisión y muestrearlos a todos lo suficientemente cerca de la misma hora se convierte en un problema mayor que hacer un reloj más rápido.
Los osciladores de anillo tienen ruido de fase causado por fluctuaciones. Para un oscilador de reloj estable en el rango de gigahercios, un diodo Gunn (colocado dentro de la guía de ondas usando una esfera YIG) sería una mejor opción para un generador de frecuencia estable.

Respuestas (5)

Hace 15 años diseñé un digitalizador de dos parámetros (energía y tiempo) para medir el tiempo de vuelo. Para este sistema, utilicé una fuente de corriente constante en una tapa mantenida en reinicio por un JFET. Al recibir el disparador (lógica rápida NIM, cambio de nivel mantenido en el régimen analógico (a diferencia de la conmutación saturada), el JFET se abrió y pude lograr una resolución de 50ps digitalizando la rampa lineal e interpolando desde un ADC de 62.5MSPS en un FPGA El circuito era bastante simple y encajaba perfectamente con las simulaciones.

Como alguien ya señaló, hay circuitos integrados dedicados para ese propósito.

Si desea hacerlo por su cuenta, un posible enfoque sería utilizar las llamadas líneas de retardo de Vernier.

Tiene dos líneas de retraso (cadenas de búferes) donde una cadena usa búferes más rápidos que la otra. La resolución de su medida es igual a la diferencia de los retrasos de los elementos en la cadena rápida y "lenta".

Para medir el retraso, envíe el pulso de inicio a través de la cadena lenta y el pulso de parada a través de la cadena rápida. El pulso de parada viaja más rápido y finalmente alcanzará al pulso de inicio. El número de búferes necesarios será una medida del retraso.

Mi atención se centra en el diseño de circuitos integrados, por lo que no estoy seguro de si esto podría hacerse con un FPGA. Sin embargo, la literatura sugiere que es posible.

Hace mucho tiempo, como experimento mental, 'diseñé' un FPGA de captura de tiempo.

Tenía un oscilador en anillo, convencional aparte del hecho de que tenía 41 inversores. El período fue mucho más bajo que el retraso de cualquier puerta. El proceso de FPGA tenía retrasos de puerta individuales de decenas de pS donde el enrutamiento era local y el fan-out bajo, pero solo podía manejar relojes del sistema del orden de 100 MHz, debido a retrasos de multiplexación, enrutamiento y carga entre bloques.

El proceso de captura de tiempo usó entonces 41 latches D, cada uno de los cuales capturaba la transición de entrada, pero, por supuesto, cronometrado en diferentes fases del ciclo del contador del anillo. Las salidas de los latches D podrían interpretarse como un 'código de termómetro', interpolando la transición de entrada a precisión de subciclo, con una resolución en los 10s de pS. Otros 41 pestillos D capturaron un reloj de referencia.

Hay dos dificultades principales con tal estructura. El primero es obtener las herramientas de síntesis para diseñar el contador de anillos y las líneas a los D-latches a alta velocidad. Esta parte probablemente se manejaría mejor mediante la colocación manual directa. Es posible que necesite un tipo específico de FPGA pequeño de alta velocidad, ¡quizás uno sin multiplicadores ni núcleos de procesador! El segundo es el manejo sin carrera de la superposición entre el código del termómetro y un contador convencional sincronizado por la referencia de frecuencia más baja, pero se puede hacer, ocupándose de los problemas de metaestabilidad.

No lo seguí porque encontré una mejor manera de resolver el problema, pero fue divertido.

Estas estructuras ahora están integradas en FPGA, tanto en los bloques de gestión de reloj (PLL y DCM) como en las estructuras de E/S de alta velocidad.
Si bien esas estructuras se integrarán en los DCM, no estoy seguro de que pueda llegar a ellas para cronometrar pulsos que llegan al azar. Sin duda, podría DPLL a los pulsos que llegan regularmente. Sin embargo, las cuñas de temporización de E/S pueden configurarse. Es posible que nuevamente necesite una configuración manual, ya que el optimizador del temporizador de enrutamiento PAR ciertamente no entenderá lo que está tratando de hacer y lo 'mejorará' por usted.
Todo lo que estaba diciendo es que ya no necesitas usar LUT individuales para crear una línea de retardo programable. Y las líneas de retardo en los IOB son definitivamente configurables; con un poco de esfuerzo, puede implementar la lógica para autoecualizar los retardos en un bus de datos de memoria, por ejemplo.

El tejido FPGA, como señalan otras respuestas, no se puede sincronizar a la velocidad que necesita.

Sin embargo, algunos FPGA también tienen interfaces seriales de alta velocidad en el rango de 5 Gb/s a 10 Gb/s, destinados a SATA, PCIe y otros protocolos de comunicación de alta velocidad.

Probablemente haya formas de aprovecharlos para mediciones de tiempo de alta resolución (100ps pero quizás no 50ps).

Lo siento, no puedo ser más específico sobre los detalles.

Los detalles están aquí para Xilinx (capítulo 3 en particular). Los dispositivos Virtex-7 más rápidos admiten velocidades de hasta 28 Gb/s. Altera tiene guías similares, y algunos de sus dispositivos Stratix V y Stratix 10 también alcanzan los 28 Gb/s.
Gracias Dave, enlace útil. Los bloques SERDES (a partir de la pág. 143) son la característica que tenía en mente.

Un reloj de 2 GHz tiene un período de 500 ps. Entonces, si necesita una resolución de 100 ps, ​​diría que necesita al menos 10 GHz.

2GHz y más está fuera de la liga de cualquier FPGA hasta donde yo sé. Ahora estás en territorio RF, que es solo analógico :-)

Texas Instruments y los dispositivos analógicos fabrican circuitos integrados generadores de reloj que pueden generar relojes de hasta varios GHz que pueden satisfacer sus necesidades.

Vaya, olvidé un cero allí. Corrección hecha
Necesitas actualizar tus conocimientos. Los FPGA de hoy en día pueden manejar fácilmente E/S en serie a 12,5 Gb/s y más, utilizando la lógica de serializador/deserializador de alta velocidad (SERDES) dedicada que está integrada en las estructuras de E/S.
@DaveTweed OK, ¿puede señalarme un ejemplo de tal FPGA?
Vea mi comentario sobre la respuesta de Brian Drummond .
Contador para reloj de 20 GHz
RespuestasAquíPolítica de privacidad1y, 0v