FastPRO平台在SOPC设计中的应用

罗敏，王晨旭，喻明艳

0 引言

嵌入式系统是微电子技术和计算机两大领域相结合的产品，随着嵌入式系统的各个领域应用需求的多样化，嵌入式系统的芯片设计技术也在经历着一次又一次的技术更新，一方面，虽然ASIC的成本很低，但设计周期长，投入费用高，风险大；另一方面，随着现场可编程门阵列（FPGA）集成度和速度不断提高，功能不断增强，再加上可编程逻辑器件的设计灵活性，这又使得高复杂度、高成本的嵌入式系统根据产品的特定要求在短时间内设计出性能价格比高的片上系统已成为可能，事实上，目前以FPGA为核心的嵌入式系统设计领域，已占据着越来越重要的的地位。

本文首先介绍了FastPRO平台的构成和特点，SOPC的技术，然后借助 FastPRO平台迅速搭建了一个基于ARM7TDMI的车载微控制器硬件系统，最后利用FastPRO评估开发板对所搭建的硬件系统进行了原型验证，并基于此原型系统进行了验证程序的开发和 µCOSII操作系统的移植。

1 SOPC技术与FastPRO平台

1.1 SOPC技术

SOPC技术最早是由美国Altera公司于2000年提出的一种灵活、高效的片上系统设计方案。它的实质是 SOC（System on Chip）设计技术，与其他SOC设计技术相比，它的主要特点在于其可编程性，也即它利用PLD的可编程性来进行SOC设计，将处理器、存储器及系统外设集成到一个可编程逻辑器件中。

SOPC技术的目标是将尽可能大而完整的电子系统在一块FPGA中实现，然而，在上市时间的压力下，必须要求缩短产品的设计与生产时间。为了快速设计生产出产品，设计人员必须利用预先定义并验证好的 IP（Intellectual Property）核，事实上，IP 核已经成为SOC或SOPC设计的关键技术之一。SOPC的主要思想就是利用所提供的 IP库，用户从IP库中选择组件来快速组装一个硬件系统。

1.2 FastPRO平台的构成和特点

通常FPGA供应商为了推广其PLD产品和开发软件，会向终端用户提供一些简单的 IP，很多情况下其提供的 IP库中的组件不能满足用户需求，这时就需要用户自定义逻辑来实现这些功能，而这又势必会使产品的开发周期变长。FastPRO平台通过提供大量的IP核网表资源库，借助强大的评估系统可以快速形成一个SOC的FPGA原型，如图1所示。

图1 FastPRO平台的构成

FastPRO平台的核心不仅包括大量的经过充分验证的IP核网表资源库，还包括一个完善的评估系统，此评估系统的主要目标器件采用Xilinx公司的VirtexTM-II系列可编程FPGA器件，最大可包含800万系统门，可以满足大多数SoC开发的需要，FastPRO评估系统的拓扑结构如图2所示。

图2 FastPRO平台评估系统的拓扑结构

在传统的SOC设计流程中，软件的开发和调试要占整个设计工作量的60%左右，然而要实现一个复杂的设计的完整RTL描述所花费的时间常常达数月，一直要等到硬件设计全部完成之后，才能在硬件上运行软件程序以验证和调试软件，这就使得硬件和软件的调试工作只能按时间顺序进行，这种按序调试的方法成为了SOC设计周期的瓶颈，因此，为了加快产品上市就必须缩短硬件设计的周期，快速形成SOC的硬件原型，使软件队伍能够较早地进行OS的移植和应用软件的开发。图3是传统片上系统的设计流程。

图3 传统SOC的设计流程

在SOC设计中，系统设计人员总是期望在做硬件设计和开发的同时，就能着手于软件程序的开发，使软件的开发尽可能的早， FastPRO平台SOPC技术借助所提供的IP核网表资源库，可以快速形成该SOC的FPGA原型比特流，使较早的进行软件开发成为可能，图4给出了FastPRO平台在SOC设计中的应用。

图4 FastPRO平台在SOC设计中的应用

2 FastPRO平台的应用实例

2.1 基于ARM7的车载微控制器的解决方案

车载微控制器除具有通用微控制器的特点外，通常还包括CAN总线或LIN总线等现场总线技术，对于行驶记录仪等要求有数据存储转移的微控制器，可能还需要有USB控制器接口逻辑，基于 ARM7的车载微控制器的解决方案如图5框图所示。

图5 基于ARM7的车载微控制器的结构框图

在图 5中的解决方案中，由于应用对性能要求不是很高，所以在系统中并没有加入DMA控制器，并且只采用了一层AHB总线。

2.2 基于ARM7的车载微控制器的系统级验证

在确定好结构框图后，就可以使用FastPRO平台IP核网表资源库所提供的相关IP去搭建此微控制器的顶层文件了，之后还必须根据传统SOC设计的流程对此顶层模型进行模拟验证，由于这里所采用的各个功能模块均为IP的网表，其正确性已经经过充分验证，所以这里的模拟验证周期不会很长，主要是克服搭建顶层模型时所可能引入的错误，验证各个子模块在整个系统中能否正常工作。由于系统中集成了处理器核，所以所有的验证操作可以通过处理器来执行。这样验证子模块在系统中的功能正确，也间接的验证了集成的处理器核在系统中的功能正确。在系统验证时，对验证代码的描述采用C语言来编写，由于C语言比较灵活，可以比较方便和更加完全的描述所有的子模块功能验证点。C测试代码通过编译器编译成处理器识别的二进制的机器码。在验证平台中将编译生成的机器码通过系统任务$readmemb读入Flash存储器模型中。上电复位后，通过Flash启动系统和执行机器码，即处理器指令产生对被验证的子模块的操作来实现对各个子单元进行验证。在进行系统级功能验证时，使用仿真器VCS进行验证。

（1）验证平台的搭建

验证平台是用Verilog语言编写模块来实现的，该模块由所需要验证的系统Pine、用来实现对某些子模块的验证的仿真模型、监视验证结果的模块以及初始化任务和向待测模块输入的激励构成。在验证平台之外，既不需要任何的输入，也不会有任何的输出，所以验证平台是一个全封闭系统，进行系统级验证的测试平台如图6所示。

图6 基于ARM7的车载微控制器的验证平台

在所设计的系统中有四个与片外通信的控制器，UART、CAN、USB和I2C，由于UART和CAN控制器在系统中集成了两个，所以在验证接收发送时可以在测试平台简单相连来验证，比如通过UART0向UART1发送数据，同时UART1接收数据来验证UART0的发送功能和UART1的接收功能。而只有一个USB控制器和一个I2C控制器，而且没有USB的物理模型，所以为了验证USB-OTG的功能时需要在测试平台上例化一个物理模型和一个用于验证的USB系统，该验证USB系统由USB核、物理模型和存储器构成，和Pine系统AMBA总线以及PHY相连来进行验证。而为了验证I2C的功能，也需要例化一个用于验证的I2C控制器，和Pine系统AMBA总线以及系统内的I2C相连来进行验证。其它的子模块测试可以通过处理器读写相应的寄存器来测试，在测试代码中控制输出测试结果信息。图7是系统级验证的部分波形图。

图7 对所搭建的SOC的UART进行模拟验证

（2）利用验证平台监视结果

在自动化验证过程中，为了监视验证结果是否正确，需要在验证的过程中打印能够表明该测试项正确与否的打印信息。在本系统功能验证中，各个测试项的打印信息一般在各个测试项中编写，然后通过编译器编译成二进制机器码。由于用C语言编写的打印函数编译后无法在VCS仿真器中运行，所以构造DEBUG模块调用系统函数$display将测试信息打印出来。

在利用DEBUG模块在VCS仿真器中打印信息时，需要在C语言测试代码中，调用一些向DEBUG模块提供测试信息的函数。这些测试信息函数，使用指针指向的方式，通过编译器编译成向DEBUG模块的APB接口写操作的指令，DEBUG模块通过接口上的地址总线上的偏移地址的译码和写总线等来选择打印验证提示信息。

2.3 FPGA的实现

在完成系统验证后，需要对整个设计进行FPGA实现。布局布线的过程中，使用Xilinx的FPGA实现工具（这里采用的是ISE 7.1）得到供下载的比特流，而后经FastPRO评估板上的JTAG口（这里选择的是边界扫描模式）下载到FPGA器件中。

需要说明的是，图5中有关片上SRAM的实现采用的是ISE集成软件环境中的CORE Generator，由于VirtexTM-II系列FPGA器件中，并没有内置FLASH工艺，而且此处仅仅是为了做此微控制器的原型功能性验证，因此这里采用SRAM代替FLASH的方式。

布局布线是两个独立而又互相联系的过程。所谓布局，就是放置元件到分区规划所映射的 FPGA的相应的可编程逻辑块（CLB）和输入/输出块（IOB）结构中。若对特定的元件上放置延时约束，那么布局布线器将试图按那些约束要求对相应逻辑块的布局进行修正。布线是在FPGA上逻辑块按原电路的逻辑要求被相互指定连接。布局布线过程是由PAR运行完成。

将布局布线后的设计生成一个Verilog的仿真模型，以验证所实现的设计最后是否能在实际的 FPGA器件上正确编程、正确运行来进行验证。

布局布线后的时序仿真需要加入 Xilinx的仿真库应该为Simprim库。时序仿真是反标带有逻辑单元延时和连线延时的sdf文件到设计而进行的仿真，它具有和所实现的设计在FPGA器件上运行时基本一致的信息，所以可以验证最后设计的实现是否可以在FPGA器件上正确运行。由于FPGA实现后设计的层次不像原来那样清晰，内部信号的命名也已经改变，原有验证平台的监视器不能使用，这时应该修改testcase，使得testcase 运行的中间数据保存在外部SDRAM内，这样通过一个memory 监视器可以监视并查看testcase的运行情况，并据此判断testcase 的运行是否正确。

在完成FPGA实现后，经查看时序报告分析，结果没有时序违反，也没有错误以及严重的警告信息。整个设计占用LUT单元数23764个，触发器为9901个，没有锁存器生成。

2.4 板级调试与程序开发

（1）调试系统的构成

为叙述方便，下文称上述车载微控制器为 Pine。由于Pine是基于ARM7的，所以调试系统的构成与传统的ARM微处理器的调试系统大致相同，如图8所示，所采用的可视化调试硬件为Multi-ICE，软件调试器为ADS1.2。

图8 Pine原型验证调试系统组成

（2）串口调试和利用串口调试

在诸多微控制器资源调试中，串口的调试通常是在验证CPU核和存储器正常之后所面临的首当其冲的问题，这里对串口主要作了如下验证和调试。

① 通过Pine的串口0向PC发送字符串“Hello World”，PC通过运行串口调试程序（如串口调试助手等）来监视PC的COM2是否接收到字符串“Hello World”

② 通过PC的COM2向Pine的串口0发送字符串，当Pine接收到这些字符串后再通过Pine的串口0发送回PC的COM2

③ 通过PC的COM2向Pine的串口0发送字符串，当Pine接收到这些字符串后再通过Pine的串口1发送回PC的COM1

当然，还有其他的一些调试，比如寄存器调试、中断、波特率、Modem的调试、pine的两个串口相互传送等等，这里不再一一列举。

当 Pine的串口调试通过之后，就可以任意的通过串口发送任意的字符串了，串口也就成了 Pine系统的输出设备“显示器”了，事实上，在LCD调试完毕之前一直在利用串口的显示功能调试其它外设和软件，毕竟串口使用起来比较方便。

（3）其它外设的调试

由于Pine系统的外设比较多，这里仅以CAN总线控制器的调试做以简要说明。

Pine系统中包含了两个符合CAN 2.0A和2.0B的CAN总线控制器，这里的调试包括CAN总线控制器寄存器、中断、波特率、睡眠模式、自检测模式、只听模式、滤波、溢出和数据传送等。在数据传送调试中，不仅在本系统中的CAN0和CAN1之间完成了数据传送，而且与ST72F561中的CAN节点组成了一个3节点的CAN网络，实现了一发多收且在两个节点同时发送时验证了总线仲裁功能。

（4）µC/OS-II的移植

µC/OS-II 是一种源代码公开、结构小巧的实时操作系统，其内核提供任务调度与管理、时间管理、任务间同步与通信、内存管理和中断服务等功能。它比较适用于小型控制系统，具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点，现已被广泛应用在航空、医疗器械、工业控制等领域。同时，µC/OS-II的95%代码是由ANSI C写成的，并充分考虑到在不同平台上移植的需求，将与平台相关的部分局限在一个很小的范围内，因此µC/OS-II具有很好的移植性。基于上述特点，考虑用 µC/OS-II作为本文工作中Pine微控制器开发移植的第一个操作系统。

在移植过程中，选择外设RTC（Real Timer Controller）模块的中断作为µC/OS-II的时钟，以此时钟来实现对多任务的调度。µC/OS-II操作系统在Pine上移植成功后所作的第一个验证如图9，在此验证中采用了两个任务。

图 9 Pine中 µC/OS-II对任务的调度

3 结束语

随着可编程逻辑器件规模的逐渐增大和性能的日益提高，片上可编程系统SOPC以其灵活的设计方式、高效的开发手段以及廉价的设计成本必将得到广泛的应用，而SOPC的重要技术则是 IP核的复用技术和完善的评估系统，FastPRO平台SOPC技术通过提供评估系统和大量已经充分验证过的IP核网表资源库，使用户可以根据需求选取相关功能模块快速组建一个实用的处理器系统，这也必将使软件开发能够较早进行从而赢取更早的产品上市时间。

[1] 汪洋.基于 SOPC 的嵌入式系统设计[J] .仪器仪表用户,2008,(02):59-61.

[2] 杜春雷.ARM 体系结构与编程[M] .北京:清华大学出版社,2003.

[3] 何慧珠,秦丽,张会新.基于FPGA的UART IP核设计与实现[J] .微计算机信息, 2008,(02): 223-224,114.

[4] 解峰. SOPC的技术研究[D] .天津理工大学, 2007.

[5] 蒋宏旭.基于片上系统(SOPC)的嵌入式平台开发及其在电力设备检测中的应用[D] .西安电子科技大学, 2007.

[6] 方茁,陈泽文,彭澄廉.SOPC设计中的用户自定义逻辑[J] .计算机工程, 2004,(17).