¿Reloj sesgado? ¿Bueno o malo?

La desviación del reloj ocurre cuando los bordes del reloj ocurren en diferentes momentos en diferentes bloques del circuito. Esto puede deberse a la distancia física, los búferes de reloj o las reactancias parásitas. El sesgo puede ser positivo o negativo (reloj adelantado o retrasado), según la señal que se tome como referencia.

Normalmente, en una red síncrona el sesgo de reloj puede generar errores en los datos: un ejemplo son las puertas dinámicas, donde la salida se precarga en una fase del reloj y se elabora en la otra. El sesgo puede provocar la propagación del estado de precarga en lugar del correcto.

En la lógica síncrona, el sesgo se considera junto con la latencia, el tiempo de configuración y el tiempo de espera de las puertas y los registros para determinar la frecuencia de reloj máxima que se puede usar. Si el sesgo no se conoce a priori , debe considerarse como una tolerancia y contribuirá negativamente a la velocidad del sistema.

Skew también se puede usar para retrasar el reloj a un registro, proporcionando más tiempo para que la lógica antes de ese registro se elabore. Por lo tanto, se puede usar un reloj más rápido que aún satisfaga los requisitos de configuración y tiempo de espera del registro.

Esta es una breve explicación y puede no ser clara, pero siempre puede buscar en Google o consultar en wiki para obtener más detalles.

Te equivocaste en que el sesgo del reloj puede ser increíblemente útil. Sí, establecer el sesgo correcto puede ayudarlo a aumentar la frecuencia del reloj a veces, pero el efecto es bastante limitado.

Por otro lado, tener un núcleo que requiere sesgo de reloj para funcionar tiene muchas desventajas. No puede sintetizarlo para FPGA / ASIC que no tienen un PLL adicional solo para generar el sesgo correcto para usted. Cambiar solo la familia FPGA probablemente requerirá que vuelva a estimar la cantidad de sesgo requerido. Modificar ese núcleo creado por otra persona es una pesadilla.

El único caso que tocaría para sesgar la configuración es cuando tengo un diseño completo para un chip específico y no puedo obtener la frecuencia de reloj requerida por otros medios.

Piense en la optimización del software como una ilustración: puede ir más rápido reescribiendo su función en ensamblador, pero tiene que ser la función correcta (la que está en el ciclo activo), y pierde portabilidad, mantenibilidad y reutilización de código. La optimización prematura está en la lista principal de errores que cometen los programadores sin experiencia.

En muchos sistemas lógicos digitales, habrá combinaciones de eventos (llámelos X e Y) que no deben ocurrir simultáneamente. El sistema se comportará de una manera definida si X sucede antes que Y, y se comportará en una función definida (típicamente diferente) si Y sucede antes que X, pero su comportamiento será indefinido si ocurren simultáneamente (ya que la mayoría de los eventos de interés toman un tiempo determinado). cantidad de tiempo pequeña pero distinta de cero; los eventos se consideran simultáneos si alguna parte se superpone).

Si los eventos X e Y son activados por el pulso del generador de reloj, a menudo será necesario asegurarse de que el tiempo entre ese pulso y X sea definitivamente más largo que el tiempo entre ese pulso e Y, o bien definitivamente más corto. El sesgo de reloj en un sistema generalmente tendrá el efecto de cambiar la cantidad de tiempo entre el momento en que el generador de reloj comienza a emitir un pulso y los momentos en que ocurren diferentes eventos. El sesgo del reloj que empujaría los eventos más juntos en el tiempo es malo y puede provocar un mal funcionamiento si los tiempos terminan superponiéndose. El sesgo de reloj que aumentaría la separación entre eventos que se supone que están separados es generalmente bueno, siempre que no disminuya demasiado la separación entre otros eventos que también necesitan estar separados .

Muchos sistemas tienen una variedad de restricciones de tiempo interrelacionadas; Si bien podría ser posible mejorar los márgenes de tiempo si se tuviera un control suficientemente preciso del sesgo de tiempo, a menudo en la práctica, dado el nivel de control que está fácilmente disponible, sería difícil mejorar algunos márgenes de tiempo críticos agregando sesgo de tiempo sin hacer otros márgenes de tiempo igualmente críticos peores. Generalmente es más fácil desde una perspectiva de ingeniería tratar de minimizar el sesgo que "optimizarlo", así que eso es lo que generalmente hacen las implementaciones.