请问怎样去设计一种音频控制器？

　　引言
　　符合Audio Codec‘97协议（简称AC’97，是由Intel公司提出的数字音频处理协议）的音频控制器不但广泛应用于个人电脑声卡，并且为个人信息终端设备的SoC（如Intel的PXA250）提供音频解决方案。本文设计的音频控制器可为DSP内核提供数字音频接口。全文在介绍音频控制器结构的同时，着重强调其与内核之间数据的协调传输，并给出基于FPGA实现SoC内核仿真环境对音频控制器进行功能测试的方法。
　　音频控制器的结构和原理
　　AC‘97系统由音频编解码器（Codec）和音频控制器（CONTROLler）两个部分组成。其中音频编解码器实现A/D、D/A转换、音效处理等功能，而音频控制器则是SoC内核与音频编解码器之间的数字接口，负责控制数据和音频数据的串/并、并/串转换以及传输。
　　● 性能指标
　　本设计的音频控制器符合AC’97规范V2.3，其主要指标如下：支持双声道录放音；支持定采样率（48kHz）和变采样率录放音；20位宽16层深PCM音频数据FIFO；支持省电模式；支持中断、DMA和轮询3种方式实现与内核或内存的数据交换。
　　● 组成结构
　　音频控制器的主结构如图1所示。
　　
　　内核/内存和音频控制器接口（CORE/Memory，CTRL INTERFACE）连接音频控制器与内核或内存。CS是片选信号，WR和RD分别是读写使能，ADDR（16位宽）是音频控制器的端口地址，DIN和DOUT（都是32位宽）分别是总线上的输入输出数据，IRQ和DMA REQ分别是中断和DMA请求。
　　主模块（AC‘97 CTRL MASTER）负责音频控制器（AC’97 CONTROLLER）与内核或内存（DMA模式下）之间PCM音频数据、控制和状态寄存器组（CONTROL&STATUS REGS）数据以及音频编解码器（AC‘97 CODEC）内部寄存器数据各并行数据的传输，由主时钟CLK同步。电源控制模块（POWER CTRL）可以启动省电模式，也由主时钟CLK同步。
　　4组FIFO用于存放PCM音频数据，都是20位宽16层深，因此可以支持最高20位宽分辨率。当FIFO满或者空时，可以发出中断或DMA请求。
　　音频编解码器内部寄存器读写缓存器（CODEC REG WRITE/READ BUF，简称CRBUF）是2个32位寄存器。写缓冲器可以缓存准备写入音频编解码器内部寄存器的控制字，其空时可以发出中断请求；读缓冲器可以缓存已经从音频编解码器内部寄存器中读出的状态字，其满时可以发出中断请求。
　　控制和状态寄存器组包含8个32位寄存器，其中，通用控制寄存器的主要功能是系统冷启动、热启动；通用状态寄存器反映音频编解码器状态；其他寄存器的功能包括配置PCM输入输出声道、配置和产生中断或DMA请求。
　　辅模块（AC’97 CTRL SLAVE）实现音频控制器与音频编解码器之间（AC-LINK）数据帧的串行发送和接收。输出数据（SDATA_OUT）由辅时钟BIT_CLK上跳沿同步，输入数据（SDATA_IN）由BIT_CLK下跳沿同步。
　　● 工作原理
　　DSP内核通过读写音频控制器CSRS分别来获得音频编解码器状态和设置音频编解码器工作模式；通过读写FIFO来缓冲音频录制和播放过程中的PCM音频数据；通过读写CRBUF来获得音频编解码器内部寄存器状态和设置音频编解码器内部寄存器参数。下面以音频播放中的主要步骤为例，介绍音频控制器的工作原理。
　　（1）写满PCM左声道输出FIFO；
　　（2）写满PCM右声道输出FIFO；
　　（3）轮询音频编解码器准备好（Codec ready）信号是否有效；
　　（4）读音频编解码器的26H寄存器，判断D/A转换器是否准备好；
　　（5）允许CRBUF产生中断请求；
　　（6）写0到音频编解码器的02H寄存器，使主音量衰减最小；
　　（7）等待CRBUF产生中断，响应中断并写0到音频编解码器的18H寄存器，使PCM输出音量衰减最小；
　　（8）等待CRBUF产生中断，响应中断并写1到音频编解码器的2AH寄存器，即以变采样率播放音频；
　　（9）等待CRBUF产生中断，响应中断并写5622（十六进制）到音频编解码器的2CH寄存器，即以22.05kHz采样率播放音频；
　　（10）允许PCM左右声道FIFO产生满中断；
　　（11）设置PCM左右声道定速率或者变速率传输，并开始播放音频；
　　（12）等待FIFO中的PCM码传送掉16层并发出中断请求；
　　（13）判断是否是PCM左声道FIFO发出中断请求，如果是，则写16层PCM左声道数据；
　　（14）判断是否是PCM右声道FIFO发出中断请求，如果是，则写16层PCM右声道FIFO数据；
　　（15）如果内存中PCM数据被读完，则放音结束，否则返回第12步继续放音。
　　SoC仿真环境的构成和原理
　　由音频控制器的工作原理可见，其每一个步骤都是在DSP内核控制下进行的。因此在对音频控制器进行功能验证时，不但要保证其本身的逻辑正确，更要保证其与内核的数据传输正确，这样才有利于音频控制器和内核的整合。由此提出通过构件SoC内核仿真环境来逼近真实内核，并在这个仿真环境中测试所设计的音频控制器。
　　● 仿真环境的构成
　　SoC内核仿真环境的硬件以Xilinx公司的MicroBlaze多媒体开发电路板为基础，其核心是Vertex II FPGA。电路板上还集成了National Semiconductor公司的AC‘97 CODEC LM4549芯片，并且提供了LINE IN/OUT、耳机以及麦克风插口。可以通过这些插口来测试音频录放效果，也可通过电路板上的测试点调试部分关键信号。SoC内核仿真环境的构成如图3所示。
　　
　　内核模拟模块（CORE SIM）是SoC内核仿真环境的核心，以RTL代码形式下载到Vertex II FPGA中模拟DSP内核的单周期指令，可以实现读写内存、访问音频控制器（包括读写FIFO、CRBUF以及CSRS）、响应并处理中断请求或DMA请求。
　　其中，DIN_RAM是32位内存数据输入总线；DIN_CTRL是32位音频控制器数据输入总线；DOUT是32位数据输出总线；IRQ是音频控制器中断请求；DMA REQ是音频控制器DMA请求；RST是音频控制器异步复位。
　　块内存模块是由Vertex II FPGA中的块内存实现的单端口内存，这种内存的时序与常规SRAM相同，可以模拟最大126KB的片上SRAM。在Xilinx集成开发环境（ISE）中调用CORE Generator，就可以生成这种静态内存。如果运用Memory Eidtor工具生成cgf和coe文件（块内存的配置文件），就可以在为FPGA下载BIT文件的同时给块内存赋初始值。基于FPGA这项强大的功能，就可以将从个人电脑上提取出来的PCM音频码下载到块内存中，然后在内核模拟模块的控制下，通过音频控制器传送到音频编解码器中，由此实现音频播放。
　　时钟发生模块（CLOCK GENERATOR）可发出27MHz、54MHz以及108MHz三种时钟，并且产生音频控制器异步复位信号RST。MicroBlaze开发电路板上的晶振发出27MHz和50MHz的占空比1:1的方波信号作为时钟发生模块的输入，调用数字锁相环硬核模块（CLOCKGEN.v和CLOCKGEN.ucf）可输出各倍频时钟（本设计用108MHz）以及异步复位信号RST。
　　AC’97 CTRL是以RTL形式下载到Vertex II FPGA中的音频控制器逻辑。AC‘97 CODEC是National Semiconductor公司的LM4549 AC’97 CODEC芯片。
　　内核模拟模块的实现原理
　　RTL代码模拟的都是流水线中的指令执行级，是音频控制器和内核直接交互数据的级别。根据DSP内核在指令执行级的行为和接口特性，可以灵活地改变内核模拟模块的接口和内部信号（通过改变RTL代码），形成不同的仿真环境。测试在新的仿真环境中音频控制器与内核的工作是否协调稳定，如果结果不理想，就应更改音频控制器的设计。这样就能使音频控制器的特性也能和内核达到最好的协调。
　　基于SoC内核仿真环境的放音实例
　　下面给出基于SoC内核仿真环境播放音频的实例，流程如图2所示。
　　
　　音频来源于Windows2000操作系统初始安装后winnt/media目录下的Utopia Windows Start.wav（153KB，16位单声道的wave文件），提取出文件中的PCM音频码后下载到Vertex II的块内存中。
　　音频控制器在SoC内核仿真环境中控制音频编解码器工作，连接耳机到MicroBlaze开发电路板的耳机插口，可以听到维持将近3秒钟的音频信号，和原音频文件的声音基本一致。
　　使用音频分析软件Audicity来分析音频播放效果，原始音源与开发板播放的音频略有不同，其原因有以下3点。
　　（1）电脑声卡录音起点和原音频的放音起点不同；
　　（2）由于块内存的最大容量为126KB，所以所录波形文件只截取了原文件（153KB）的前2/3部分。
　　（3）经过SoC内核仿真环境放音，并由电脑声卡录音得到的音频与原音频的幅度必然不同。
　　第1、2两个因素引起两个波形在时间轴方向上的偏差，因素3引起幅度轴方向上的偏差。尽管存在这些差异，但完全可以说明在SoC内核仿真环境中，所设计的音频控制器逻辑功能正确，与内核能够协调工作。
　　总结
　　本文根据所设计的音频控制器的结构详细介绍了构建SoC内核仿真环境来测试音频控制器的思想和实现方法。基于这个仿真环境，不但可以测试音频控制器实际录放音的效果和性能，更重要的是可以及时反映其与内核的协调程度。这样就可避免孤立设计音频控制器而不考虑其与SoC系统协调的弊端，明显提高后期整合SoC系统的效率。