嵌入式系统芯片的软硬件协同仿真环境设计

2011-06-22官枫林习友宝刘斌

单片机与嵌入式系统应用 2011年11期

官枫林,习友宝,刘斌

(1.电子科技大学电子工程学院,成都610000;2.海思半导体成都研究所)

官枫林(硕士研究生),研究方向为ASIC芯片设计与验证。

1 概述

随着微电子产业日新月异的发展,IC设计的规模越来越大,集成度越来越高,已经足以将一套完整的系统集成到一块小小的芯片中。在这种形势下,SoC技术应运而生[1]。随着IP核复用技术的出现,SoC芯片的设计已经不再是很大的难题,SoC芯片的验证已逐渐取代芯片设计成为芯片开发阶段的瓶颈。现阶段SoC芯片设计的正确性要经过前仿真、后仿真以及FPGA验证来保证。前仿真包括单元验证、集成验证和系统验证,后仿真包括带反标时序SDF的网表仿真。其中系统验证和后仿真都需要关注SoC芯片的全局功能,这就涉及SoC的软件仿真和硬件仿真的协同问题。本文以DSM模型替代ARM核,以VMM验证方法学和VCS仿真器为基础,搭建一个可重用性高、调试和定位问题方便、仿真真实性高、软件和硬件能够很好配合的协同验证平台。

软硬件协同仿真架构如图1所示,协同验证分软件验证环境和硬件验证环境两部分。软件代码通常由C/C++和汇编语言混合编写而成,然后由软件编译器转换成二进制格式,最后将该二进制文件加载到SoC芯片的存储器中去,芯片boot启动时由ARM核调用软件代码并执行;硬件环境基于VMM验证方法学进行搭建,下文中会有详细介绍。协同仿真就是通过事件和命令,使用一些机制,在这两个环境间进行控制。

2 DSM模型的使用

1 软硬件协同仿真架构

SoC芯片的CPU一般选用ARM,协同验证平台中ARM可以用seamless CVE模型替代,或者直接选用ARM网表。采用seamless CVE模型进行仿真,虽然速度比较快,但需要替换设计中的Memory模型,且必须使用CVE自己的模型,这样与芯片真实情况有出入;采用ARM网表进行仿真,速度比较慢,调试也不方便,但是更接近实际情况。相比于这两者,本文采用的DSM(DesignSimulation Model)模型由ARM公司提供,能完全模拟ARM的接口和时序行为,具有更高的真实性,而且 DSM无需更换存储器模型和外挂仿真工具,使验证DUT与实际芯片完全一致,即不必为了满足仿真需求修改部分RTL代码。此外,DSM环境仿真过程中输出的LOG文件log.eis真实记录每个周期执行的CPU代码和操作。根据该文件能快速定位软件问题。CVE环境通过调用XRAY软件调试工具,虽然可以进行单步调试、设置断点等操作,但出现软件问题时定位没有DSM环境那么直观、方便。

DSM是ARM公司提供的设计仿真模型,该模型直接从ARM公司的RTL代码经过加密处理转化而来,具有同真实RTL代码完全一致的功能和特性。在时序仿真过程中,还能直接对该模型反标时序。在仿真过程中,将模型WRAPPER——也就是模型的最顶层——例化到RTL代码中,仿真器在仿真过程中触发WRAPPER,请求Model Manager动态调用模型库进行仿真。Model Manager响应请求动态调用模型库文件,达到功能仿真的目的。由此可以看出,Model Manager在仿真过程中充当中介角色,将模型和仿真器动态连接在一起。DSM模型的工作原理如图2所示。

图2 DSM模型工作原理

3.软件仿真

ARM汇编器工具ARMASM、ARM的C/C++编译工具 ARMCC和 ARMCPP,以及 ARM的链接工具ARMLINK,利用ARM工具对软件代码进行编译链接生成的文件格式为ELF格式(Executable Link File),原始代码在文件中的位置通过SCATTER文件指定。ARM提供了fromelf工具,该工具将ELF格式的文件根据运行时域转化为二进制文件,以便在仿真起始阶段将代码放到指定的Memory中。在makefile中将ELF格式转化为BIN文件的具体实例如下:

上述语句表示将software.elf文件转化为二进制文件放到当前目录。

在软硬件协同仿真的初始阶段,需要将生成的二进制文件导入相应的存储器中,这通过Verilog提供的系统函数fread实现。下面是一个将二进制文件导入存储器的实例,先通过＄fopen函数读出文件地址,然后通过＄fread函数将指定地址的文件数据传给变量inst_file_word,最后将变量inst_file_word中的值传给存储器中的相应地址单元。在DSM仿真中都需要一个这样的“桥梁”文件,将软件和逻辑链接起来。

软硬件协同仿真的软件结构如图3所示,系统BOOT起来后直接跳转到main()函数进行单进程任务,如果出现中断异常,则boot代码中根据中断向量表地址跳转到中断处理函数。中断处理函数中包含对各中断的处理,main()函数中调用各个模块的TC(Test Case)函数,TC调用底层的驱动代码。驱动代码的编写则基于各个模块的寄存器定义文件和全局变量。该软件结构清晰可控,便于各测试用例TC的并行提交和管理。

图3 软件结构图

4 构建基于VMM的软硬件协同仿真平台

在软硬件协同仿真环境中,完全可以采用基于VMM的验证架构,但软硬件协同仿真环境较一般的纯逻辑集成验证环境难度大,主要体现在软硬件协同仿真环境因为仿真过程中有软件代码在执行,同时验证环境也在执行,因此如何将软件代码和硬件环境协调起来是关键。在仿真过程中,软件和验证环境之间需要建立一种通信机制,如可以通过中断通信,也可以通过某一特殊信号线通信。软硬件协同仿真环境中,某一项功能点的测试常常需要软硬件两条测试用例TC,软件TC需要驱动代码,而一般的集成测试用例不需要软件TC和驱动。典型的VMM的验证架构如图4所示。

验证的总体架构是分层次的,层次化的验证环境具有很好的扩展性和重用性,各个层次完成自己特定的功能。Test层又叫TC层,主要完成数据激励的定义、环境的控制工作。Generator层定义的数据“模板”,产生各种数据激励。Function Layer层完成输入和输出数据激励的收集,进行自动比对。Command Layer层主要按接口时序收发数据,同时将一些底层方法(如数据读写等)进行封装。Signal Layer层主要是完成接口信号连接工作。不同的人关注不同层次,一般的验证人员只需要在Test层工作,编写测试向量。只有搭建环境的验证人员才需了解各个层次。验证架构的层次化降低了验证环境复杂度和环境维护成本,提升了验证效率。

图4 传统VMM验证环境架构

本文基本采用图4的验证环境架构的思路,并在其基础上进行修改,添加相应组件。VMM验证环境架构如图5所示,环境数据流从测试用例Test Case开始,经过数据包产生器Generator和数据处理器Transactor送给BFM处理,BFM把验证环境的抽象层次从信号级抽象到Transaction级,在实现上只做时序转换功能,利于重用。从发送方向看,BFM只负责将接收到的数据发送给DUT;从接收方向看,BFM只负责将接收到的数据发给Transactor,实现任何数据的解析。Monitor抓取接口上的信号,并分析各组控制信号之间的逻辑时序关系,检查其是否满足协议所规定的逻辑时序关系,同时把监测到的数据信号转化为数组送到RM解析。与BFM一样,Monitor只实现时序转换功能,不做数据解析。从Monitor上采样数据再送入RM,是基于重用的角度考虑。参考模型(RM)用于预测数据响应[2],Check组件将RM的输出数据与被观测响应进行比较。

图5 VMM验证环境架构

该验证环境架构还添加断言(Assertion)来提高观察和定位设计问题的能力。断言是检查DUT中信号行为是否正确的观察器,用来描述被预期的特定性质。本文采用的断言为SVA断言语言,可以应用到设计过程的各个阶段,还可以统计功能覆盖率。

5 基于DSM的软硬件协同仿真调试

由于DSM模型在仿真过程中,会将ARM执行的每一步动作打印出来,生成一个log.eis文件,由该文件给出的信息定位问题非常方便,如图6所示。

图中第1列表示程序执行到ARM的第几个时钟周期。第2列是ARM执行的指令类型。第3列的CCFAIL表示条件执行时是否执行,如果条件执行了,则不打印CCFAIL,反之则打印出CCFAIL。第4列是 ARM执行的机器码。最后几列是详细的ARM执行的动作,从图中可以看出ARM执行哪一步指令,将哪些数据读写到哪些地址。对应的仿真波形图如图7所示。可以看出,log.eis完整无误地将ARM执行的动作打印了出来。