interfaz AXI de un núcleo FFT que espera más datos de los que debería

0

Estoy trabajando con el FFT v9.0 core de Xilinx.

La FFT está configurada para usar la arquitectura de E / S de ráfaga Radix-4.

Cuando llego al último elemento de mi señal, configuré s_axis_data_tlast a 1 (mientras transmitía el último punto de datos) y lo puse de nuevo a cero. No obtengo un event_tlast_unexpected ni un event_tlast_missing .

¡Mi problema es que la señal s_axis_data_tready de la FFT permanece alta!

Para satisfacer el FFT tuve que darle 15 puntos de datos adicionales después de que ya haya aceptado el último punto de datos:

Con incredulidad, reduje la longitud de mi flujo de datos de 4096 puntos a 64 puntos para poder contar manualmente los puntos de datos que se transmitieron. Esto provocó el mismo comportamiento: de nuevo, la FFT requiere 15 puntos de datos adicionales para poder continuar.

¿Cómo puedo resolver este problema?

EDIT 1

Tal vez debería proporcionar más información:

El núcleo de FFT tiene una velocidad de 200 Mhz mientras que mis puntos de datos llegan a una velocidad de 50 Mhz, por lo que estoy desacelerando activamente la FFT con s_axis_data_tvalid . Cada muestra tiene una duración de 81,92 microsegundos y comienzo a transmitir una nueva muestra cada 300 microsegundos.

Mi plan era alimentar mi primera muestra durante 81,92 microsegundos, recibir la salida en 218,08 microsegundos y luego alimentar la siguiente muestra.

Si no lleno el búfer (vea la respuesta de Dave Tweed), la FFT simplemente espera 218,08 microsegundos y llena su búfer con 15 puntos de la siguiente muestra. Luego, s_axis_data_tready baja y la FFT devuelve su salida, mientras que debería estar recibiendo datos de la nueva muestra.

    

2 respuestas

1

El documento al que está vinculado confirma cómo esperaría que se manejara TREADY. La página 51, párrafo 2 dice:

  

En particular, el comportamiento de TREADY en el canal de datos de entrada [diagrama de temporización] no es totalmente exacto porque   el canal de entrada de datos almacena los datos (16 símbolos en modo no en tiempo real y 1 símbolo en   Modo en tiempo real). Sin embargo, estos datos esperan en el búfer hasta que el núcleo de procesamiento de FFT está listo   para ello. El canal de entrada de datos TREADY en estos diagramas se utiliza como una indicación de cuándo   el núcleo de procesamiento FFT desea datos en lugar de cuando el canal AXI (con su búfer) desea   datos.

Y se repite la página 52, párrafo 3:

  

Nota: Esto se refiere al núcleo de procesamiento de FFT. Como el canal de entrada de datos tiene un búfer profundo de 16 elementos en   En su entrada, puede comenzar a crear un búfer previo mientras se está procesando un marco. En el caso de 8 y   FFTs de 16 puntos, puede pre-buffer de fotogramas completos. Sin embargo, estos datos almacenados en búfer esperan en el búfer hasta que   El motor FFT ha terminado de lidiar con el marco actual.

Toda la sección que comienza en la página 52 proporciona mucha información adicional sobre el almacenamiento en búfer y el control de flujo en las interfaces del módulo. ¿Por qué está concluyendo que los datos no se están procesando correctamente?

    
respondido por el Dave Tweed
0

Dave Tweed y Sourabh Tapas tenían razón, s_axis_data_tready normalmente no baja cuando la FFT ha recibido la muestra.

La página 54 de la guía del producto ilustra lo que Dave Tweed señaló gráficamente:

s_axis_data_treadysolobajacuandolaFFTharecibidodemasiadosdatos.

Asíescomodebeverse:

    
respondido por el Chandran Goodchild

Lea otras preguntas en las etiquetas