Configuración de un transceptor de GTXE2 serie 7 de Serial-ATA (Gen1/2/3)

Question

Hola este será un punto de expertos preguntas :) Usted debe estar familiarizado con los siguientes temas

• Xilinx Multi-Gigabit-Transceptores (MGTs), en especial las 7 de la Serie GTX/GTH transceptores (GTXE2_CHANNEL)
• Serial-ATA Gen1, Gen2 y Gen3, especialmente Fuera de Banda (OOB) comunicación

Pregunta:

¿Cómo debe un GTXE2 ser configurado para Serial-ATA?

OOB que la señalización no es trabajo ni RX_ElectricalIdle ni ComInit.

Introducción:

He implementado un controlador SATA para mi final licenciatura en proyecto, que soporta múltiples proveedores y plataformas de dispositivos (Xilinx Virtex-5, Altera Stratix II, Altera Stratix IV). Ahora es el momento para que el puerto este controlador para el dispositivo siguiente familia: Xilinx 7-los dispositivos de la Serie, por el nombre de un Kintex-7 en un KC705 de la junta.

El controlador SATA tiene un adicional de la capa de abstracción en la capa física, que se basa en SAPIS y de la TUBERÍA 3.0. Así que para el puerto de la controladora SATA a un nuevo dispositivo de la familia, solo tengo que escribir un nuevo transceptor contenedor para una GTXE2 MGT.

Como de Xilinx del CoreGenerator no soporta SATA protocolos en el CoreGen asistente, empecé un transceptor proyecto desde cero y aplicar todos los ajustes necesarios, como la medida en que son formuladas por el asistente. Después de que he copiado el GTXE2_COMMON la creación de instancias en mi contenedor de módulo, ordenó a los medicamentos genéricos y de los puertos en un sentido completo esquema.

Como tercer paso, he conectado todos los puertos desconectados (los asistentes no asignar todos los valores !!) a sus valores por defecto (el valor predeterminado de UG476 o cero si no se ha definido).

En el paso 4 he comprobado todos los medicamentos genéricos y los puertos de nuevo contra el UG476 si son compatibles con la configuración de SATA. Después de que he conectado mi contenedor de puertos para la MGT y se inserta cruz-reloj de módulos si es necesario.

Como de la KC705 de la junta no tiene 150 MHz reloj de referencia, I programa de la Si570 para el suministro de este reloj como "ProgUser_Clock" después de cada junta de "arranque". MGT es en desconectar el modo (P2), mientras que esta reconfiguración. Cuando el Si570 es estable, la MGT está encendido, el Canal utilizado PLL (CPLL) bloquea después de ca. 6180 ciclos de reloj. Este CPLL_Locked eventos de lanzamientos de la GTX_TX|RX_Reset los cables, lo cual causa un GTX_TX|RX_ResetDone evento después adicionales 270/1760 ciclos (todos los ciclos de @ 150 MHz -> 6,6 ns).

Este comportamiento puede ser visto en chipscope, capturado con una estable e ininterrumpido de los auxiliares de reloj de 200 MHz, ligeramente muestreado).

Así que el GXTE2 costuras ser impulsada, operacionales y de todos los relojes son estables.

GTXE2 puertos para el control de la OOB de señalización:

MGT tiene varios puertos para OOB de señalización. En TX estos son:

• TX_ElectricalIdle - fuerzas TX en condición de inactividad eléctrica
• TX_ComInit - enviar una secuencia ComInit
• TX_ComWake - enviar una secuencia ComWake
• TX_ComFinish - secuencia fue enviar a -> listo para el siguiente comando

En RX:

• RX_ElectricalIdle - RX_n/TX_p son eléctricos condición de inactividad (interfaz de bajo nivel)
• RX_ComInit_Detected - una completa ComInit secuencia fue enviar
• RX_ComWake_Detected - una completa ComWake secuencia fue enviar

Detallada del error desciption:

1. TX envía OOB secuencias si TX_ComInit es alto para un ciclo.
2. RX_ElectricalIdle es siempre alta

Pruebas:

1. SATA cable de retorno: cortar un cable SATA y soldadura de los cables apropiados ;) -- Estoy usando un especial de SFP a SATA adaptador, el cual se extiende la KC705 con un conector SATA - http://shop.trioflex.ee/product.php?id_product=73
2. SMA de bucle invertido de cables: he movido el MGT y conectado los cables LVDS a la SMA tomas e instalado 2 cables SMA como cross-over.
3. He programado mi viejo ML505 (Virtex-5) con onboard SATA conector para enviar ComInit secuencias. El 2 placas están conectadas con un especial SATA cable cruzado.
4. He conectado un disco duro con un parcial despojado cable SATA a la KC705 (SFP2SATA adaptador) y conectado a un 2.5 GSps alcance (sí, las señales están submuestreada, pero es bueno ver las explosiones y los períodos de inactividad...).

Experiencias:

• Prueba 3 muestra transmitida OOB secuencias de Virtex-5 a Kintex-7, pero la ChipScope evento de disparo no se produce - Rx_ElectricalIdle es todavía alta.
• Prueba 4 muestra no transmisión OOB secuencias en el cable.

Debo publicar partes o el transceptor completo instanziation?

sólo la instancia de ca. 650 líneas :(

Apéndice:

Eléctrica de inactividad significa que el MGT unidades de ambos cables LVDS (TX_n/TX_p) con el voltaje de modo común (V_cm) que esté en el rango 0..2000 mV. Si se cumple esta condición, el modo común delta del voltaje es menor de 100 mV, lo que se conoce como ElectricalIdle condición.

OOB-señalización significa que el MGT transmite ráfagas eléctricas en reposo y normal de símbolos de datos (D10.2 en 8b/10b notación) en los cables LVDS. SATA/SAS define 3 OOB secuencias de llamada ComInit, ComWake, ComSAS que tienen diferentes ráfaga/reposo de duración. Los controladores de Host y los dispositivos de uso de estas "señales de Morse" para establecer un enlace.

Edit 1:

Después de la configuración de Voltaje Común Trim (RX_CM_TRIM) y (Diferencial de Control de Oscilación) TXDIFFCTRL a maxima y la conexión de TX_ElectricalIDLE y TX_ComInit a los botones, yo era capaz de ver algunos resultados:

1. TX_ElectricalIDLE está funcionando, pero el TX OOB FSM no (TX_ComInit, TX_ComWake)
2. si TX_ComInit es alto para siempre, el transceptor transmitts ALINEAR primitivas, pero a un cuarto de la correcta reloj alrededor de 375 MHz en lugar de 1.5 GHz
3. RX_Electrical de INACTIVIDAD sigue sin funcionar

También trató de utilizar la alternativa OOB reloj, pero esto no tiene ningún efecto.

Answer 1

Así que creo que me he encontrado algunas respuestas al problema y quieren compartirlas.

Empecé a simular el GTXE2_CHANNEL hardmacro. La simulación se está comportando como "falso" como el hardware. Así que traté de simular el MGT en Verilog y se utiliza una instancia de la plantilla de aquí: http://forums.xilinx.com/t5/7-Series-FPGAs/Using-v7gtx-as-sata-host-PHY-and-there-is-issue-bout-ALIGN/td-p/374203

Esta plantilla simula ElectricalIDLE condiciones y OOB secuencias casi lo correcto. Así que empecé a diff ambas soluciones:

1. TXPDELECIDLEMODE, que es un puerto para elegir el comportamiento de TXElectricalIDLE no está funcionando como se esperaba. Así que ahora estoy usando el modo de sincronización.

2. PCS_RSVD_ATTR es un sin restricciones bit_vector genérico de 48 bits. Si usted tiene una mirada en el código de contenedor de la secureip GTXE2_CHANNEL componente, usted encontrará una conversión de bit_vector => std_logic_vector => string. Internamente todos los medicamentos genéricos son tratados como DOWNTO a distancia. Por eso es importante pasar un DOWNTO constante a la GTXE2 genéricos!

Así que ahora usted podría preguntarse por qué es él el uso a distancia de las constantes y los medicamentos genéricos?

Xilinx ISE hasta la última versión 14.7 tiene un error importante en el manejo de los vectores de tipos definidos por el usuario en el indiscriminada de medicamentos genéricos. La dirección por defecto de los vectores es. Si usted está pasando vectores de las enumeraciones como DOWNTO para indiscriminada de medicamentos genéricos en un componente, ISE es revertir los elementos del vector y "emite" un A distancia de vectores en los componentes !!

Esto es especialmente "divertido", si el diseño de la jerarquía, que utiliza este genérico, no es un árbol equilibrado...

Si usted está utilizando las enumeraciones de 2 elementos, el problema es que no existe -> tal vez esta enumeración se asigna un valor booleano.

Los errores de la izquierda?

1. TXComFinish es todavía el no reconocer al enviar OOB secuencias.
2. Tengo que investigar esto dos correcciones de errores en la síntesis y la medida de la OOB secuencias con un ámbito de aplicación - esto puede durar algunos días :)

Edición 1 - más errores:

Hay otro error en el comportamiento de restablecimiento de la GTXE2. Si GTXE2 se utiliza con salida de reloj de divisores 1 (TX_ y RX_RateSelection = "000") de la GTXE2 botas y emite sólo 3 ciclos de reloj (con mal reloj período) en TX_OutClock. Después de que TX_OutClock es "X". Si restablece el GTXE2 después de que mal de salida se arranca un segundo tiempo con un error correcto y un reloj en TX_OutClock.

Además de este error, el GXTE2 ignora todos los asignados restablece (CPLL así como TX/RX_RESETs) hasta 'X' puede ser visto en TX_OutClock. Así que usted DEBE esperar alrededor de 2.5 nosotros para realizar un reset.

Si usted está usando el reloj de divisores con 2 o 4 (8 y 16 años no se ha probado aún) no se producirá este problema.

Edición 2 - problemas resueltos:

Solución de Error 1:

He añadido un contador de tiempo de espera, cuyo tiempo de espera depende de la generación actual (frecuencia de reloj) y el actual COM secuencia que se envíe. Si el tiempo de espera es alcanzado puedo generar mi propio TXComFinished de la señal. No o el tiempo de espera de la señal original con la TXComFinished señal de GTX, porque a veces esta señal es alta, mientras que la COMWAKE es para que se envíen, pero esta terminado estroboscópica pertenece todavía a la anterior COMRESET secuencia!

Solución para un Error:

RXElectricalIDLE no es fallo gratis! Para resolver este problema he añadido un elemento de filtro en este hilo, que suprime los picos de la línea.

Por lo que actualmente mi controlador se está ejecutando en SATA Gen1 a 1.5 GHz en un KC705 de la junta con un SFP2SATA adaptador y creo que esta cuestión se resuelve.