【摘 要】随着SoC设计规模的增大和设计复杂度的提高，对芯片设计深层次验证的必要性、工作量和难度也变得越来越大。在此背景下分析了SoC软硬件协同验证的原理及实现技术，研究了μC/OS-II在基于ARM7TDMI内核的SoC上的移植工作，提出了使用μC/OS-II及其上层应用程序验证SoC芯片硬件可用性和可操作性的方法。

　　【关键字】片上系统　协同验证　μC/OS-II　多任务调度

　　中图分类号：TP368 文献标识号：B 文章编号：

　　【Abstract】With the the size and design complexity increase of SoC chip ,the in-depth verification has become more and more necessary and difficult. In such context ,this article analyses the principles and technologys of SoC hardware/software co-verification, then studies the work of porting μC/OS-II on SoC which is based on ARM7TDMI core, introduced the method of verifying Soc on μC/OS-II and its upper application program.

　　【Keyword】system on chip(SoC) co-verification μC/OS-II Multitask scheduling 引言SoC是许多嵌入式IP核的集成，由于其同时具有软件灵活性和硬件高性能的特点，SoC的应用领域已更加多样化和更为复杂，从而使得SoC设计日趋复杂化，验证工作也越来越繁重。据统计，验证工作占据了整个设计周期的40%～70%[1]。如何缩短验证时间、提高验证效率和质量、缩短芯片面市时间，是当今SoC设计领域中最为关注的问题。操作系统不仅能使芯片的性能得到充分发挥，而且也可以提高芯片使用的可靠性，同时可改善设计的可重用性。尤其是当芯片性能需要在多种异构平台上进行验证时，通过操作系统可以减少验证的工作量，加快验证的进程。

　　μC/OS-II是一个免费的、源代码公开的实时嵌入式内核，它提供了实时系统所需的基本功能，如邮箱、消息队列、信号量、大小固定的内存块的申请与释放，时间相关函数等。其包含全部功能的核心部分代码只占用8.3K字节，此外由于μC/OS-II是可裁剪的，用户系统中实际的代码最少可达2.7K字节，具有结构小巧，易于移植等优点。

　　本文在分析SoC软硬件协同验证技术和方法的基础上，讨论μC/OS-II在SoC芯片上的移植，以及μC/OS-II调度上层应用程序测试和验证SoC芯片的方法，重点研究了实时操作系统μC/OS-II对SoC验证的支持技术。 1.SoC设计验证的层次所谓软硬件协同设计技术是指在最终硬件没有准备好之前进行软件和硬件的协同设计和验证，其目的是希望在设计的早期验证系统软硬件的正确性，特别是功能的正确性和性能的高效性[2]。

　　为了减少模块内部和模块接口之间的错误，缩短SoC芯片设计中的查错、纠错的时间，同时也为了加快SoC芯片的设计进度，SoC设计中采用自底向上的系统级验证方案。由图1给出的SoC芯片软硬件协同设计与验证流程，可以看到验证在SoC芯片设计中的作用，验证工作主要分为三个阶段：

　　第一阶段是系统集成前IP/模块级验证，包括片上总线接口的功能验证，各IP/模块的所有功能点在这一层得到充分验证。对IP/模块的验证主要使用HDL语言，开发testbench和testcase给设计施加激励并观察其响应来进行。

　　第二阶段是系统集成后IP/模块级验证，这一阶段主要验证的对象是各IP/模块的各功能点，但是与集成前验证不同的是，这里的验证环境是集成后的系统环境，测试输入是通过处理器执行测试程序来完成的，测试结果的收集也是通过处理器来输出到外设或其功能仿真模型的。由于基本模块的规模都相对较小，此时无论是发现错误还是纠正错误都比较容易，从而保证了各基本模块功能的正确性。如果在以后的系统级全局验证时再发现错误，则可以直接将错误的原因定位在模块之间的接口上。

　　第三阶段是系统集成后的系统级验证，这一阶段验证的重点不再是各IP/模块的某个功能点是否正确，而在于通过小系统的运行来验证SoC芯片的系统级特性，如互联、流控制、信号之间的时序关系以及模块间的互操作性等是否正常。这一阶段的内容主要包括系统各模块之间互操作的功能验证及基于操作系统的验证。

　　图1　SoC芯片软硬件协同设计与验证流程

2.SoC验证平台　SoC验证与测试的方法及平台主要有两种: 一是创建虚拟原型仿真平台，采用EDA 软件仿真工具(如：ModelSim)来测试SoC 内部逻辑设计。另一种是基于FPGA验证技术，将SoC系统集成的逻辑综合后下载到FPGA芯片中，并将测试程序下载到FPGA的SRAM或FLASH中，上电后处理器从SRAM或FLASH中开始取指执行，这样就达到与SoC芯片实际工作过程相同的效果;此外，在后端设计中还可使用静态时序分析方法[3]。其中虚拟原型验证的优点是方便除错，但速度较慢;FPGA验证的优点是速度快，但可观测性较差。两者结合可以得到很好的效果与效率的平衡。 3.基于μC/OS-II的SoC软硬件协同验证 本文讨论的SoC集成了ARM7TDMI内核、协议处理器以及其它的IP核。系统性能依赖于每个基本IP模块。为方便发现错误和纠正错误，本系统的验证工作首先进行IP子模块的验证，如协处理器，VIC，SRAM，DMA，RTC，UART等，IP子模块的验证采用虚拟原型和FPGA原型两种平台。各模块验证正确后进行μC/OS-II操作系统验证，由于虚拟原型运行很慢，故μC/OS-II操作系统验证主要基于FPGA验证平台。

　　μC/OS-II的验证需要实现操作系统移植、硬件驱动程序、中断处理程序，应用程序与硬件平台的交互等，验证流程见图2。

　　图2　μC/OS-II验证流程图

　　3.1　μC/OS-II的移植

　　在SoC芯片的FPGA验证平台中移植μC/OS-II，主要是修改OS_CPU.H、OS_CPU_C.C、OS_CPU_A.ASM这三个文件[4]。具体工作中需要注意事项：(1) 根据不同处理器及编译器的支持情况定义堆栈增长方向，#define OS_STK_GROWTH 1，表示堆栈由上向下增长，#define OS_STK_GROWTH 0，表示堆栈由下向上增长;(2) 所有中断处理的总入口定义在OS_CPU_A.ASM中，需在此基础上根据具体硬件及软件开发需求编写具体的中断处理程序;(3) μC/OS-II要求用户提供一个周期性的时钟Tick中断，以提供时间的延迟和超时功能的依据，该Tick中断是系统心脏的脉动，μC/OS-II的Tick中断间隔可设置为10-200ms。

　　3.2　硬件驱动程序

　　操作系统加载时要进行各个IP核的初始化，完成IP核的驱动需要做如下三个方面工作：

　　一是对IP核的初始化，也即对各模块硬件寄存器的设置;二是对各个IP核中断的处理， 各IP核的中断处理程序一般在其初始化函数中向SoC的中断控制器注册，这样，当CPU 响应该IP 核中断时就会调用相应的中断处理程序进行处理;三是要向上层应用程序提供应用程序接口API函数，以向上屏蔽底层实现的细节。

　　3.3　中断处理程序

　　ARM7TDMI支持两种中断，快速中断FIQ与标准中断IRQ[5]。中断控制器的任务是在片内外围和外部中断源组成的多重中断发生时，经过优先级判断选择其中一个中断，通过FIQ或IRQ向ARM7TDMI内核发出FIQ或IRQ中断请求。

 1/2    1 2 下一页 尾页