ignition rx running disparity update is sub-optimal

Abierto
  • ¿Algo no está bien?
#292 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Área
embedded-iot, networking

Línea de trabajo

Lee hdl/ip/bsv/ignition/IgnitionReceiver.bsv alrededor de las líneas 239 y 344-352, y luego revisa cómo el receiver obtiene la running disparity del decodificador 8b10b y cómo gestiona IDLE1 e IDLE2. Ejecuta o añade la simulación que solicita el issue para verificar el seguimiento de la disparity y el comportamiento de la inversión de polaridad; se considera terminado cuando el receiver ya no depende de patrones IDLE seleccionados por el transmisor para la running disparity.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Ignition Controller ignition-target

https://github.com/oxidecomputer/quartz/blob/5e7b0fe8a9a0e9a6345f8282f60f7d9c61497b79/hdl/ip/bsv/ignition/IgnitionReceiver.bsv#L344C12-L352C16

I believe this to be a fundamentally incorrect way of determining a receiver's running disparity as it relies on the transmitter transmitting specific patterns on specific disparities, which isn't something you'd typically see in a link. Normally, you'd take the output of your actual 8b10b decoder. It does "work" in our case here because the transmitter is doing extra work to pop between IDLE1 and IDLE2 sequences based on it's running disparity. I believe this was done to facilitate polarity inversion detection but it isn't required and while flipping between IDLE1 and IDLE2 sequences is fine, it really should have no bearing on the rx side's running disparity.

I need to get in and do some actual simulation on this, but all links should generally capture the current running disparity from the 8b10b decoder but i think the resetting of the rd on IDLE sequences can and should just be removed, leaving this state to keep the running disp up-to-date:

https://github.com/oxidecomputer/quartz/blob/5e7b0fe8a9a0e9a6345f8282f60f7d9c61497b79/hdl/ip/bsv/ignition/IgnitionReceiver.bsv#L239

^ The above provides a self-correcting mechanism. Upon link start up you assume some running disparity (say negative) and if you're wrong you get a disparity error (don't care b/c you had a 50-50 chance of getting it right) but you always get your K28.5 comma regardless of polarity inversion. After the first byte, you have a correct running disparity from the decoder, and the next byte can be decoded. Note that you'll never get the wrong decoded byte just due to disparity mismatch, all the byte patterns are uniquely coded.

Longer-term, I think while we can accept IDLE1 or IDLE2 sequences and may continue bouncing between them there's no reason to tie them into a specific running disparity. And regardless of which IDLE sequence you get, the bit-inverse of it is always detectable for polarity inversion, regardless of the running disparity.

Lenguaje dominante
VHDL
Estrellas
24
Forks
2
Merge medio
36 min
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de oxidecomputer/quartz

Todos los issues de oxidecomputer/quartz

Issues similares

Más issues de Embedded & IoT

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.