Diseñar con AC'97: ¿por qué no tiene un búfer (FIFO)?

3

El códec AC'97 parece dominar el mundo de la E / S digital, pero lo extraño es que no tiene interrupciones ni búferes, por lo que es difícil interactuar con un controlador, que tiene otras actividades. El AC97 exige realizar una encuesta periódica (44k veces por segundo), verificando el tiempo para comunicar una próxima muestra. Esta no es la forma habitual de comunicación por lo general. Por lo general, la CPU llena un búfer y se le notifica cuando la operación se completa o espera explícitamente el resultado si no tiene nada más que hacer. Dicho "procesamiento por lotes" es más eficiente porque, al principio, enviar ráfagas es más eficiente que hacer un artículo una vez y, en segundo lugar, reduce el cambio de contexto n veces, lo que también optimiza los recursos computacionales en consecuencia. Pero, necesitas un FIFO para eso. Lo que es bueno en esto, en la muestra a tiempo, el diseño terrible de AC97 y ¿por qué a nadie le importa? Veo que Xilinx lo arregla con la placa de demostración ML507 (veo FIFO en el controlador AC97 introducido allí) pero tengo la placa V5 Genesys de Digilent cuyo controlador no proporciona ninguna FIFO. Para que Microblaze deba comunicar una muestra cada 1/44100 de segundo. ¿Es eficiente? ¿Cómo se supone que debes controlarlo?

    
pregunta Val

3 respuestas

2

La parte de enlace AC de la especificación AC97 define la interfaz de cinco hilos entre el códec y un controlador . Esto no es solo una interfaz de datos, sino también una interfaz de temporización. Es posible que esta distinción no parezca importante en un sistema integrado pequeño con un solo códec, pero se vuelve crucial en un sistema más grande, como una consola de mezclas digital de 96 canales. En este tipo de sistema, todas las interfaces de audio deben ejecutarse exactamente a la misma frecuencia de muestreo y alineación de fase, y el estándar de enlace de CA está diseñado para admitir eso.

Como han indicado otras respuestas, es responsabilidad del dispositivo en el otro extremo del enlace, el "controlador", que podría ser un ASIC dedicado, parte de un FPGA o un microcontrolador, para administrar ambos la sincronización de los códecs en el sistema según sea necesario, así como el movimiento de datos de un dominio de temporización a otro con el uso de FIFO o búferes adecuados.

    
respondido por el Dave Tweed
3

Los codecs de audio son dispositivos en tiempo real. Esperan que les alimente (o lea) muestras en cada período de muestra. El diseño de un códec de audio simple sería mucho más complejo si transfiriera esa responsabilidad a ellos. Más fácil para usted, más difícil y más caro para el códec.

Una posible solución sería utilizar un motor / canal DMA. Así que ponga sus bits de audio pcm en una ubicación contigua en la memoria y apunte el motor DMA a esos bits y su interfaz AC97. Haga la frecuencia de escritura dma 44.1K y luego deje que se rasgue. Puedes hacer lo contrario para obtener audio.

Usted también podría hacer este bloqueo, solo teniendo su propia tarjeta de memoria interna de fpga.

Aquí hay un núcleo de controlador AC97 en OpenCores con soporte de dma externo enlace

    
respondido por el Some Hardware Guy
1

Probablemente podría diseñar el FPGA para que contenga un MicroBklaze para sondear y escribir datos en el subsistema AC97. Sin embargo, realmente sugiero dar un paso atrás y pensar de dónde provienen los datos de origen. En la mayoría de los casos, desearía diseñar un widget de hardware, en lógica FPGA, para capturar el flujo de datos de origen y enviarlo al subsistema AC97 sobre la marcha a la velocidad correcta. Si la velocidad de datos es correcta, pero puede haber algunas variaciones espurias en el flujo de datos, entonces tendría mucho sentido insertar búferes elásticos FIFO como parte del widget de hardware. Los FPGA tienen buenos módulos para crear FIFOs

    
respondido por el Michael Karas

Lea otras preguntas en las etiquetas