Hola, esta será una pregunta de expertos :) Debe estar familiarizado con los siguientes temas
¿Cómo se debe configurar un GTXE2 para Serial-ATA?
La señalización OOB no funciona ni en RX_ElectricalIdle ni en ComInit.
Implementé un controlador SATA para mi proyecto final de licenciatura, que admite múltiples plataformas de proveedores/dispositivos (Xilinx Virtex-5, Altera Stratix II, Altera Stratix IV). Ahora es el momento de trasladar este controlador a la siguiente familia de dispositivos: dispositivos de la serie 7 de Xilinx, cuyo nombre es Kintex-7 en una placa KC705.
El controlador SATA tiene una capa de abstracción adicional en la capa física, que se basa en SAPIS y PIPE 3.0. Entonces, para portar el controlador SATA a una nueva familia de dispositivos, solo tengo que escribir una nueva envoltura de transceptor para un GTXE2 MGT.
Dado que el CoreGenerator de Xilinx no es compatible con los protocolos SATA en el asistente de CoreGen, comencé un proyecto de transceptor desde cero y apliqué todas las configuraciones necesarias en la medida en que el asistente las solicitó. Después de eso, copié la creación de instancias de GTXE2_COMMON en mi módulo contenedor, ordené los genéricos y los puertos en un esquema completo de significado.
Como tercer paso, conecté todos los puertos no conectados (¡los asistentes no asignan todos los valores!) a sus valores predeterminados (el valor predeterminado de UG476 o cero si no está definido).
En el paso 4, verifiqué todos los genéricos y puertos nuevamente contra el UG476 si son compatibles con la configuración de SATA. Después de eso, conecté los puertos de mi contenedor al MGT e inserté módulos de reloj cruzado si era necesario.
Dado que la placa KC705 no tiene un reloj de referencia de 150 MHz, programo el Si570 para que suministre este reloj como "ProgUser_Clock" después de cada "arranque" de la placa. El MGT está en modo de apagado (P2) mientras se realiza esta reconfiguración. Cuando el Si570 está estable, el MGT se enciende, el PLL de canal usado (CPLL) se bloquea después de aprox. 6180 ciclos de reloj. Estos eventos CPLL_Locked liberan los cables GTX_TX|RX_Reset, que provocan un evento GTX_TX|RX_ResetDone después de 270|1760 ciclos adicionales (todos los ciclos a 150 MHz -> 6,6 ns).
Este comportamiento se puede ver en chipscope, capturado con un reloj auxiliar estable e ininterrumpido (200 MHz, ligeramente sobremuestreado).
Entonces, el GXTE2 parece estar encendido, operativo y todos los relojes son estables.
El MGT tiene varios puertos para señalización OOB. En TX estos son:
En RX:
Pruebas:
Experiencias:
sólo la instancia tiene ca. 650 lineas :(
El ralentí eléctrico significa que el MGT impulsa ambos cables LVDS (TX_n/TX_p) con voltaje de modo común (V_cm) que está en el rango de 0 a 2000 mV. Si se cumple esta condición, el voltaje delta de modo común es inferior a 100 mV, lo que se conoce como condición de inactividad eléctrica.
La señalización OOB significa que el MGT transmite ráfagas de símbolos de datos normales y de inactividad eléctrica (D10.2 en notación 8b/10b) en los cables LVDS. SATA/SAS define 3 secuencias OOB llamadas ComInit, ComWake, ComSAS que tienen diferentes duraciones de ráfaga/inactividad. Los controladores y dispositivos host utilizan estas "señales Morse" para establecer un enlace.
Después de configurar Common Voltage Trim (RX_CM_TRIM) y (Differential Swing Control) TXDIFFCTRL al máximo y conectar TX_ElectricalIDLE y TX_ComInit a los botones, pude ver algunos pequeños resultados:
También traté de usar el reloj OOB alternativo, pero esto no tiene ningún efecto.
Así que creo que encontré algunas respuestas al problema y quiero compartirlas.
Empecé a simular la hardmacro GTXE2_CHANNEL. La simulación se está comportando como "falsa" como el hardware. Así que traté de simular el MGT en Verilog y usé una plantilla de instancia 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 condiciones de inactividad eléctrica y secuencias OOB casi correctas. Entonces comencé a diferenciar ambas soluciones:
TXPDELECIDLEMODE, que es un puerto para elegir el comportamiento de TXElectricalIDLE, no funciona como se esperaba. Así que ahora estoy usando el modo síncrono.
PCS_RSVD_ATTR es un genérico bit_vector sin restricciones de 48 bits. Si observa el código contenedor del componente GTXE2_CHANNEL de secureip, encontrará una conversión de bit_vector => std_logic_vector => string. Internamente, todos los genéricos se tratan como DOWNTO ranged. ¡Así que es importante pasar una constante DOWNTO a los genéricos GTXE2!
Entonces, ahora podría preguntarse por qué está usando constantes y genéricos de rango a.
Xilinx ISE hasta la última versión 14.7 tiene un error importante en el manejo de vectores de tipos definidos por el usuario en genéricos sin restricciones. La dirección predeterminada de los vectores es TO. Si está pasando vectores de enumeraciones como DOWNTO a genéricos sin restricciones en un componente, ISE está invirtiendo los elementos del vector y "emite" un vector de rango TO en los componentes.
Esto es especialmente "divertido" si la jerarquía de diseño, que utiliza este genérico, no es un árbol equilibrado...
Si está utilizando enumeraciones de 2 elementos, el problema no existe -> tal vez esta enumeración esté asignada a un valor booleano.
Hay otro error en el comportamiento de reinicio de la GTXE2. Si se usa GTXE2 con divisores de reloj de salida establecidos en 1 (TX_ y RX_RateSelection = "000"), GTXE2 se inicia y emite solo 3 ciclos de reloj (con un período de reloj incorrecto) en TX_OutClock. Después de eso, TX_OutClock es 'X'. Si restablece el GTXE2 después de esa salida incorrecta, se inicia una segunda vez con un error ahora y un reloj correcto en TX_OutClock.
Además de este error, el GXTE2 ignora todos los restablecimientos asignados (CPLL y TX/RX_RESET) hasta que se puede ver 'X' en TX_OutClock. Por lo tanto, DEBE esperar alrededor de 2,5 para emitir un reinicio.
Si está utilizando divisores de reloj con 2 o 4 (8 y 16 aún no se han probado), este problema no ocurrirá.
Solución para el error 1:
He agregado un contador de tiempo de espera cuyo tiempo de espera depende de la generación actual (frecuencia de reloj) y la secuencia COM actual que se enviará. Si se alcanza el tiempo de espera, genero mi propia señal TXComFinished. No omita la señal de tiempo de espera con la señal TXComFinished original de GTX, porque a veces esta señal es alta mientras se envía COMWAKE, ¡pero esta luz estroboscópica finalizada aún pertenece a la secuencia COMRESET anterior!
Solución para otro error:
¡RXElectricalIDLE no está libre de fallas! Para resolver este problema, agregué un elemento de filtro en este cable, que suprime los picos en esa línea.
Así que actualmente mi controlador se ejecuta en SATA Gen1 con 1,5 GHz en una placa KC705 con un adaptador SFP2SATA y creo que esta pregunta está resuelta.
usuario8352
Paebbels
testbench <=> phy-layer <=> GTXE2 <=> GTXE2 <=> phy-layer <=> testbenchchico funky
Paebbels