试验次数： 20次/人

为了显示本系统设计性能的优越性，我们选择  PC  机与之对比。  PC 的配置性能如下：

表2 PC与DE2平台运行MFCC系数提前速度对比

表3 PC与DE2平台运行端点检测速度对比

语音识别的运行时间与端点检测后截取出来的语音帧长有关，在本系统中，将语音信号以  256  个语音采样数据为一帧（  8Khz  采样率）。以下运行时间对比是基于三段分别为 

表4 PC与DE2平台对三段语言识别运行时间对比

机的主频很高，但其在这些复杂的数字信号处理中运算效率不够高，计算一次需要几个时钟周期，而我们设计的基于  FPGA  的数字信号处理采用并行处理方式，以较少的资源消耗换取了较大的性能提升。

而在端点检测中，只有  Fir  滤波部分需要大量的乘法运算，其他部分大致都是加法和判断处理状态转移过程，此时  PC  主频高的优势得以发挥，拉近了与硬件实现方法的差距。

倍左右，这已是一个非常好的成绩，完全满足本系统设计的要求了。

芯片，处理器为芯片内部的硬核  Power PC 405  。我们将两个方案进行对比：

表5 本方案与竞争方案对比

分析两方案的异同，本方案采用相对流行的  MFCC  语音特征提取办法，而对比方案采用  LPCC  语音特征提取办法。就计算复杂程度而言，  MFCC  MFCC  系数提取模块，并用  DMA  进行数据搬运。这使得更为复杂的语音特征提取时间较竞争方案的时间更短。

在识别部分，两方案均采用  DTW  识别算法。而竞争方案采用了硬件实现的方法，性能较我们好。

就总体情况而言，若同为  10  个参考模板，本方案模板形成与识别的总时间在  0.4s  左右，而竞争方案模板形成与识别的总时间在  0.7s  左右。我们以合理的设计思路、较低的设计成本取得了良好的性能参数。

平台运算后提取出来的数据：

Nios  处理器从  AVALON 总线上读取上述矩阵进行  MFCC  系数提取后的数据截图。从图中的数据可以看到，两者间的绝对误差大约保持在  0.0001  左右，这个精度已经可以满足本系统的要求。

MFCC 系数提取中，只有对数运算没有采用标准的直接求取法来求解（事实上也很难采用直接求解法在硬件平台上求解对数），所以对其做误差评价也是很有必要的。

——  3.999  的  CORDIC 对数运算结果即可。详细的设计论证请参考本文第四部分的设计方法。

作人机友好交互。同时系统利用DE2的外扩插槽扩展自己设计的射频识别读卡器和CAN总线接收器。

在设计过程中，充分考虑SOPC系统的特色，充分发挥了SOPC系统在数字信号处理中的并行运算优势和Nios自定义指令加快程序运行速度的优势。下图为本系统的SOPC builder定制图：

RFID  识别模块采用的是ZLG500B系列的射频识别模块，而Mifare 卡则采用NXP公司的MF1S50系列射频卡。该模块基于NXP高集成度读卡芯片MFRB500。当读卡模块初始化工作完成后，便开始监测 Mifare卡，Mifare卡一共有五种状态，以下是Mifare卡的状态转移图。

ID   卡是客户身份卡，装载客户的ID信息和自行设定的48bit密码，当客户刷卡成功，蜂鸣器提示一重认证通过，开启语音识别认证，确保门禁系统的安全。

本模块模拟监控实验室温度的过程，由于在实际实验室中，各种干扰信号及通讯距离较远，故本模块采用CAN总线进行通讯。CAN(Controller Area Net)是一种现场总线，主要用于各种过程检测及控制，其具有抗干扰性强、通信距离较远等优点。在本模块的设计框图如下：

图11  环境参数监控模块原理图

本模块采用SJA1000做为CAN总线控制器，CAN总线收发器则采用CTM1050T高速隔离收发器。在实物设计中，我们选择对环境的温度进行实时监控，如果要对其他的环境参数进行监控，只需更换传感器即可。

环境参数实时采集卡的设计基于AT89S51单片机，单片机采集温度数据后，将温度h数据通过CAN总线发送到Nios II。下图为环境参数采集卡CAN总线网络连接图：

本模块要实现的功能是采集语音信号，并对其进行FIR滤波、语音数据归一化、语音的端点检测处理。

语音采集部分采用DE2板上的WM8731进行设计，通过I2C总线设置后，WM8731就会一直工作在设定的模式中。语音采集单元包含一个PLL，一个I2C总线控制器、一个左对齐模式下的语音采集控制器。

图13  语音采集控制器的采样图

从图中可见，左对齐语音采集过程一共有19个脉冲，其中前16个脉冲为有效语音数据提取脉冲，后三个脉冲为将来处理扩展预留。有效语音提取出来之后便存入SRAM中。本模块通过计数器，从启动录音开始，自动录制4s的语音信号。

语音归一化处理典型的计算公式为：DATA/MAX(DATA)，如果按照这种标准归一化处理，则需要消耗2个硬件乘法器资源。本着节约片上资源的设计理念，我们创新地提出了一种经过简化的归一化处理模型，该模型只需移位即可实现归一化运算。流程如下：

第一步：先取语音数据的最大值MAX(DATA)。

第三步：将归一化运算由DATA/MAX(DATA)改为DATA/m。在数字电路中除以2^n只需简单的移位即可实现。

鉴于我们这里将16位的原始语音归一化为8位的小数，所以只要将每一个语音数据右移（n-8）位即可。当n小于8时，则无需再移位。

经过修改后的归一化运算，运行速度更快，资源消耗更少，其不足在于牺牲一点采样精度而已。

由于原始录入的语音高频部分的频谱比低频部分的成分少，为此要在预处理中加入预加重处理，预加重的目的是提升高频，使得信号的频谱变得平坦。一般采用的是一阶高通滤波器，系统函数为 。我们利用了DSP Builder设计了一阶FIR滤波器。方法如下：

第一步：由系统函数得到差分表达式：

设计的FIR模型顶层文件如下：

从DSP builder的截图可以看出，Fir滤波器的输入是16位的Q8定点小数，运算后输出也取16位Q8定点小数。下图为Fir在Quartus II的仿真图：

我们在MATLAB对该仿真结果进行验证：

由于原始数据中含有噪声和无声段以及静音段，为了获取有效语音数据，必须从原始数据中截取有效的语音数据。在端点检测中，我们把语音分为：静音段，过渡段，语音段，结束段。语音端点检测状态转移图如下所示：

图17  语音的端点检测状态图

端点检测后的语音数据仍保存于SRAM中。我们将DE2板上的512KB的SRAM划分为5个区：地址0——0x7fff为原始语音数据保存区，0x8000——0xffff为经端点检测后的第一段语音数据（在端点检测之前已对该段语音数据进行归一化处理与Fir滤波处理）保存区。0x10000——0x17fff为经端点检测后的第二段语音数据保存区。0x18000——0x1ffff为经端点检测后的第三段语音数据保存区。0x20000——0x3ffff（0x3ffff 是SRAM的最终地址）为将来扩展而预留。

下图为语音预处理模块处理我们录进去的“大家好“效果图。本图是通过DE2控制面板软件读取SRAM前256KB数据（地址：0——0x1ffff）在MATLAB软件上画出来的图形：

图18 语音的端点检测效果图

从图中可以看出语音预处理模块可以很好地完成Fir滤波、语音归一化、语音端点检测的任务。

在设计之初，我们曾计划将MFCC模块做成一个Nios II的指令，以此加快其对语音数据的处理速度。但是每次MFCC运算的输入数据为256Byte，如果将MFCC做成Nios II的指令，这就意味着需要Nios II从SRAM读取（搬运）这大量的语音数据。此时Nios II的工作效率和最终系统的运行速度将会大大降低，所以我们将MFCC模块做成了一个Avalon总线的从设备，使用DMA来为它搬运数据。设计结构图如下：

图19  识别部分整体设计结构图

在介绍MFCC中各运算单元实现步骤之前，有必要详细说明一下本系统的数据格式变换，数据变换的原因下文会有讲解。在上文中提到，语音经过归一化处理后，成为16位的Q8格式小数语音信号，整个MFCC数据格式变化如下图所示：

MFCC  特征提取模块包含：FFT运算、数据取模运算、Mel滤波器运算、对数运算、DCT离散余弦变换、一阶倒谱提升。由于篇幅的关系，在此仅选择其中最复杂的三个部分进行介绍。

在FFT运算单元设计之初，我们有两个设计方案：浮点型FFT和定点型FFT。两者的区别在于：前者计算的值的范围大，而后者所能计算的范围较小。在前文我们提到，在本系统中语音归一化处理后变为8位有效数据，如果采用浮点FFT，则得将原来的八位数据扩展为32位，而采用定点的FFT则只需在原来数据位宽的基础上扩充一倍即可。无论逻辑资源的消耗、乘法器资源的消耗还是FPGA内部存储资源的消耗都是定点型FFT比浮点型FFT来得少。基于上述原因，本系统采用定点FFT。

定点FFT设计的关键就在于蝶形结单元的设计和地址产生逻辑的设计。蝶形结是FFT处理器的基本运算单元，本模块的蝶形结消耗了8个硬件乘法器，一半用于数据的实部相乘，另一半用于数据的虚部相乘。鉴于Cyclone II的乘法器均为9bit，因此我们在蝶形运算单元将原来的8位小数扩充为10位，组成高8位为整数位，低10位为小数位的Q10格式数据。这样即充分利用了现有资源又提高了FFT运算的精度。蝶形结采用流水线设计，数据输入到输出有6个时钟周期的延迟，由于蝶形运算数据的连续输入，所以每计算一次蝶形结只需一个时钟周期。

模块设计的难度主要在地址产生逻辑，地址产生逻辑的设计直接影响FFT模块的性能和FFT运算结构。我们的FFT地址产生模块按照标准FFT地址跳变方式设计并满足蝶形运算单元流水线运算的需要。为了得到高速的FFT处理速度，我们在FFT模块中开辟了两个RAM数据存储区，以此组成典型的乒乓操作模式：在FFT第一级运算中，数据从RAM1经蝶形单元计算存入RAM2，在第二级中则正好相反，依次类推……下图为FFT整体设计框图：

在这种设计结构下，计算一次蝶形运算只需要一个时钟，处理速度达到同类设计结构的最高极限。经Quartus II综合后FFT模块的时钟可达162Mhz，消耗的逻辑资源约为700多。在100Mhz时钟下，计算一个256点FFT的时间不到11us，达到了数据高速处理的目的。以下为FFT模块仿真图：

0.97911i，两者相差不大，定点FFT运算模块与MATLAB计算的结果相比存在小小误差。

为了更直观地验证FFT模块计算的正确性，对一帧实际语音数据进行FFT计算：下图中蓝色代表FFT 模块对一帧语音数据经过FFT 运算后的频谱图，红色代表同样的语音数据是用MATLAB 指令fft(data)运行的仿真图，可以看到我们自行设计的模块能达到应用的要求，并且与MATLAB软件有同样的效果。

图23  一帧语音数据的频谱图

MFCC  （Mel-Frequency Cepstral Cofficients）的分析着眼于人耳的听觉特性，因为，人耳所听到的声音的高低与声音的频率并不成线性正比关系，而Mel频率尺度则更符合人耳的听觉特性。所谓Mel 频率尺度，它的值大体上对应于实际频率的对数分布关系。Mel频率与实际频率的具体关系可用下式表示：

这里，实际频率f 的单位是Hz。根据Zwicher 的工作，临界频率带宽随着频率的变化而变化，并与Mel频率的增长一致，在1000Hz 以下，大致呈线性分布，带宽为100Hz左右；在1000Hz 以上呈对数增长。类似于临界频带的划分，可以将语音频率划分成一系列海明窗滤波器序列，即Mel 滤波器组。

在本系统中，此MEL滤波器组是一个24阶的海明窗滤波器，此滤波器系数是一个24X128的矩阵，而在这个滤波器系数组中，有许多的系数都是0，如下图示：

从图中可以清晰看到，MEL滤波系数组大部分元素均为0。对该系数组在MATLAB下调用plot函数绘图可以看到Mel滤波器系数组的图形：

从上图可以发现Mel滤波系数组每一阶的非零数据是不相同的。也就是说想在FPGA上构造一个与C语音类似的稀疏矩阵，难度很大。而如果将整个滤波系数矩阵的24*128个系数均存入FPGA的存储区中，又会造成非常大存储资源浪费。

为了以最少的资源、最快的速度实现Mel滤波器，我们将Mel滤波系数组设计成单一状态转移结构。即采用一个计数器，给予每一级Mel滤波一个特定的值，从Mel滤波计算开始，该计数器便开始计数，利用该计数器便可决定Mel滤波器的计算状态。采用这种设计方式便可在FPGA中仅仅保存Mel滤波系数中的非零系数，且综合后的运行速度可达180多Mhz。下图为Mel滤波器第一阶计算的结果：

图26  Mel滤波器第一阶计算仿真结果

MFCC   中语音信号的幅度谱在每一个滤波器组中累加将得到一个较大的加权值，算法中需要对各个加权值取对数来达到压缩数据的目的。

（1）FPGA对数算法运算方案对比

通常情况下FPGA实现对数运算的方法一般采用一下三个：

方法一：采用查表的方式来实现

方法二：采用泰勒级数来近似这个函数，也就是：

对比三个方法，其中方法一的实现最为简单。但是方法一的计算精度与所制作的表的大小成正比，也就是说采用方法一实现较高精度的对数运算将要耗费巨大的存储器资源。显然在本系统中并不适用。

而方法二和方法三，在其收敛区间上均可以取得较好计算结果。在方法二中，每一个级数的计算需要3到4个的硬件乘法器。如果采用各级共享乘法器的设计方法，则计算一次对数需要较长的时间。而如果使用流水线结构设计，又会消耗大量的乘法器资源。

采用方法三的CORDIC算法具有突出的优势：不需要硬件乘法器，所有运算只有移位累加；可以使用流水线方法，以提高工作频率与效率；也可以使用循环迭代方法，以节约硬件资源。其计算精度与运算迭代次数成正比（也就是逻辑资源）。我们设计的15次流水线迭代的CORDIC对数运算单元消耗的LE约为1100左右。

对比方案二和方案三，显然方案三在各个方面都具有突出的优势。故本系统采用CORDIC算法实现对数运算。

（2）CORDIC对数运算实现方法

三角函数的CORDIC算法最初由Jack Volder提出，应用与实时导航的数字处理，John Walther等人将CORDIC理论进行了扩展。现在CORDIC算法已经应用与众多领域。

本文不涉及过多的理论，关于CORDIC的资料可以参考《A survey of CORDIC algorithms for FPGA based computers》一文。要实现CORDIC对数运算的关键就是找到它的迭代多项式。本系统采用的是利用CORDIC结构实现双曲线坐标变换，而双曲线函数可以很方便转换为对数函数，在本系统中采用的迭代方程推导如下：

进一步分析这一迭代方程，对该多项式迭代后的结果为：我们所需的ln(t)等于2* 。为了省去乘2这一步，我们再将迭代多项式优化为：

在此迭代多项式下，只需令x的初值等于t+1，y的初值等于t-1，z的初值等于0。经过n次迭代后，ln(t)= 。

通过对后一个多项式的迭代运算，我们就可以得到所需的对数运算结果。需要注意的是，在这个CORDIC迭代方程中无法满足整个自然域的实数运算，此时可以通过简化公式进行化简：

可以发现， 正好是浮点格式数据。也就是说，只要输入CORDIC对数运算的数据为浮点格式，就可以轻松处理大范围的实数。

为了对数运算的方便，本处没有采用标准浮点格式，而是针对CORDIC对数运算的需要设计了一个简单的浮点格式。该浮点格式表示规定为： 且 。这样定义的原因是：CORDIC对数运算方程y的初始输入变量为：t-1，当t趋近于1时，y趋于0，这样迭代结果就会产生较大误差。所以在此直接规定了t的取值范围，防止y=0的情况发生。又MEL滤波器输出的数据恒为正数，所以浮点的符号位也可忽略。最终这种简化的浮点格式为： 

下图为对数运算在Quartus II仿真结果：

（3）定点小数转浮点格式小数的实现方法

上文提到，在对数运算单元中，输入的数据为浮点制的格式。但我们之前的数据一直都采用定点小数格式，所以必须在对数运算之前将定点格式的数据转换成浮点格式的数据。

定点转浮点格式采用状态机的方法设计，下图是其状态转移图：

图28  定点转浮点格式状态转移图

按照这一流程便可将原来的32位Q16格式数据转换为CORDIC对数运算设计的浮点格式数据。

下图为定点格式转浮点格式的Quartus II仿真结果：

图29  定点格式转浮点格式仿真结果

从图中可以看到，输入32位Q16格式0x.0625，

随机密码产生模块采用伪随机序列（也称为m序列）的原理进行设计。伪随机序列在通信、雷达、导航以及密码学等重要的技术领域中获得了广泛的应用。在本系统中，随机密码起到了非常重要的作用，在每次语音识别之前，系统通过随机序列得到随机数，要求用户录入相对应的语音密码，这就相当于扩大了系统密码库。即相当于将10个语音密码扩展为1000个语音密码。伪随机序列采用移位反馈寄存器设计，下图为设计顶层结构图：

图30  随机密码产生顶层结构

在伪随机序列产生的这些移位寄存器中，不允许全零的状态出现。所以我们设置了一个延时复位单元，在系统上电后一段微小的时间后，图中的所有移位寄存器都会被置1。下图为随机密码模块仿真图：

在本系统中，定制了基于Nios II的DTW计算指令，DTW的计算结果取值范围较大，一般从几百到几十万，而用于计算DTW的MFCC系数的值大多从0到正负十几之间，如果此时继续采用定点数据，显然已经无法满足系统要求。所以，我们自己设计定制了计算DTW的浮点Nios指令。

1  ）定点Q16格式数据转浮点格式数据

3  ）浮点欧式距离计算指令

4  ）浮点数据大小比较指令

通过这些指令的定制，使得本系统在DTW识别算法的计算时间缩短了4.12倍：

表6  自定义指令运行时间对比

可见在Nios中自定义指令可以获得很好的性能提升幅度。需要注意的是，在Nios IDE中，如果直接定义浮点型变量无法直接输入到自定义指令中进行运算，所以本系统采用alt_u32型变量来“装载”浮点变量。当然，这样处理后，就不能在Nios IDE中直接采用+-*/等运算符直接对这些变量进行运算了，只能采用自定义的指令来操作。

本系统采用了两个Nios II处理器，一个负责识别算法实现，另一个则负责与上位机的TCP/IP网络通信等。

系统上电复位后，液晶屏上将显示系统初始化成功，将等待用户刷卡，由串口接受合法用户的ID号，非法用户将无法进入下一步语音识别，并在液晶屏上显示非法ID，验证ID 合法后，产生随机密码并液晶回显，并开始采集四秒钟语音数据，进入语音识别验证。最后系统通过TCP/IP网络发送识别结果给远程监控中心。下图为CPU_1的程序流程图：

在孤立词语音识别中，最为常用的方法就是DTW 动态时间规整算法，它与其它识别算法如HMM算法在相同环境条件下，识别效果相差不大，但HMM算法的实现要复杂得多，这主要体现在HMM 算法在训练阶段需要提供大量的语音数据，通过反复计算才能得到模型参数，而DTW算法的训练中几乎不需要额外的计算。在本系统中考虑到算法复杂程度以及对系统速度性能的要求，选择兼顾识别效果和低复杂度的高效算法DTW。

（1）首先读取SD卡里面的语音模板库，客户的语音参数模板都是以经过特殊处理的二进制文件存放在SD卡内。Nios II读入文件，作为语音特征矢量R。

(2)  特征参数提取模块组件处理得到的实时采集的测试客户模板，作为语音特征矢量T。

比较T和R之间的相似度，即使计算累积距离，距离越小则相似度越高。这一失真距离，可采用动态规划的方法。下图是把测试模板的各个帧号在一个二维直角坐标系中的横轴标出，把参考模板的各个帧号在纵轴标出，通过这些帧号的整数坐标画出一些纵横线即可形成一个网络，交叉点表示测试模式中某一帧与训练模式中某一帧的交汇点。DP算法可以归结为寻找一条通过此网格中若干格点的路径，路径通过的格点即为测试和参考模板中进行距离计算的帧号。路径的选择必须从左下角出发，在右上角结束，且生长点的斜率必须在1/2到1之间。如下图所示。

FAT  是Microsoft推出的文件系统，具有高度兼容性，目前仍然广泛应用。FAT(File Allocation Table)是“文件分配表”的意思。顾名思义，就是用来记录文件所在位置的表格，它对于存储盘的使用是非常重要的，假若丢失文件分配表，那么存储盘上的数据就会因无法定位而不能使用了。

在本系统中，FAT文件系统在一张1G的SD卡中实现，所以选择移植FAT16文件系统。FAT16使用了16位的空间来表示每个扇区(Sector)配置文件的情形，故称之为FAT16。

要实现FAT16文件系统，最关键就是对FAT16目录项32个字节的操作，下表为该目录项32个字节的定义：

在SD卡中进行读取二级目录文件的程序流程图：

如果要进行三级目录文件读写，只需重复上述黄色部分的流程即可。而如果要进行根目录下文件读写，则只需去掉黄色部分流程。由此可见，其实文件夹在FAT16文件系统中将会占1个簇的存储空间。

CPU_0  负责的工作在实时操作系统下以多任务的形式是与电脑进行TCP/IP网络通信、收集实验室环境数据和门禁识别结果等。程序整体框架如下图所示：

Altera  公司已经为用户移植好了uC/Os-II实时操作系统，并将其像外设驱动一样当作一个软件模块集成到了Nios II IDE，在Nios II IDE环境下，用户不用修改其源文件对uC/Os-II的配置，只需通过图形界面就可以实现，使用起来非常方便。正是这些原因，在Nios系统中使用uC/Os-II操作系统非常方便。

LWIP  全称为Lightweight IP TCP/IP stack，是一个轻量级的TCP/IP协议栈，其主要特性是以最小的资源占用实现完整的TCP/IP协议，因此特别适用于嵌入式系统。Altera公司已经在Nios处理器上为用户移植好了LWIP，并内嵌到Nios IDE中。所以在本系统的软件设计中，我们很方便地将uC/Os-II和LWIP结合到我们的系统中，并大大减少了系统开发的时间。

网络通信采用DE2板载DM9000A以太网控制器芯片。它集成了介质访问控制子层（MAC）和物理层的功能，它为嵌入式系统实现的以太网连接提供了良好、便捷的解决方案。

DM9000A  与LWIP的衔接通过LWIP提供的几个重要的结构体实现，如下图所示：

例如：netif结构体作为LWIP中网络接口的基础数据类型，描述了网络接口的基本属性以及输入、输出函数。alt_lwip_dev结构体描述了符合LWIP规范的网络端口设备。alt_lwip_dev_list：设备链表。在LWIP定义的这些结构体类型的基础上，我们在主程序中定义了针对DM9000网络接口的一个结构体：alt_avalon_dm9k_if。有了这个结构体，DM9000的寄存器读写操作开始与LWIP的工作机制发生了联系。

2  ）网络应用程序的开发

移植成功LWIP后，就能够利用socket API来完成应用程序的设计。本系统基于Nios IDE提供的simple_socket_server模板进行网络应用扩展。这使得TCP/IP网络通信的实现更加简单。

网络Socket通讯过程：先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。

当连接建立后，我们就可以在sss_handle_receive()函数中建立自已在TCP/IP连接中所需的任务。如下图所示：

当TCP/IP连接断开后，再把在TCP/IP连接中建立的任务删除即可。

RFID  选择现在最为常见的MF1S50系列。系统上电复位，读卡芯片装载正确的密钥到非易失性密匙存储器，等待有RFID卡的到来，启动卡的验证 ，将验证命令发送到卡，当从卡接收到第一个报文令牌后，微控制器必须检测通信状态标志。如果通信到目前为止保持成功，则启动卡验证的第二部分。卡将会以第二个报文令牌进行响应。然后微控制器必须检测通信状态标志。如果验证已成功，则与MIFARE卡继续进行CRYPTO1加密下的通信，读出ID，卡置为挂起状态，蜂鸣器响，发送ID号。 在RFID射频识别的设计中，需要注意的是：RFID射频识别的流程如下图所示：

在实际设计中，环境参数采集卡是安装在离主控板（DE2板）较远的地方，直接采用主控板进行数据采集显然不合理。所以在此我选择低价、应用普遍的89S51单片机完成环境参数采集的任务。采集卡的任务就是通过相应的传感器采集环境参数，再通过CAN总线将环境参数发送到主控模块中去。

其程序流程如下图所示：

图41  环境参数采集卡程序流程

本系统设计了一个简单的监控软件，对门禁系统实时进行远程监控。监控软件上可以看到门禁监控系统采集的环境参数变量和门禁识别结果。下图为软件运行截图：

图42  上位机监控软件运行截图

除了使用监控软件进行远程监控外，也可以使用Windows自带的远程登录命令登录到监控系统中。下图为采用windows自带的telnet命令登录本系统后的截图：

CPU1   和CPU2有各自的存储区，为了他们之间通信的方便，添加了一个共享的存储区以此来交换数据，为了避免两个CPU 同时访问共享的存储单元时引起资源冲突，而导致系统崩溃，这里添加了互斥核，在访问共享区时，任何一个CPU 都必需先打开互斥核，这时可以实现消息传递，然后关闭互斥核。另一CPU 同样可以通过这样的操作获取消息。设计框图如下图所示：

本系统在语音识别部分的综合后时钟可达130Mhz左右，但在这一部分我们仅使用50Mhz的时钟，因为现在的处理速度已经能满足我们的要求，而且每次综合所得电路存在随机性，无论从稳定性还是系统功耗考虑，都是采用较低时钟。如果更换更高时钟，性能参数还能继续增加。

下面是作品在软硬件整合后运行的演示图：