TURBO51嵌入式微处理器功能验证

 

　　1 引 言

　　1. 1 背景

　　TURBO51的工程背景是TURBO51嵌入式微处理器结构设计上采取经时间考验过的32位机主流系统结构， 在严格保证对8051 指令集兼容的前提下， 通过重新定义其处理器核的系统结构来挖掘处理器结构上的并行性实现。在传统8051软件开发环境下实现本要由更高位宽的32位处理器来完成的工作并完全重用所有现有软件资源。在 8051指令级多种寻址方式混合且指令不定长的现实下实现了高性能的体系结构， 乱序发射， 分支预测， 精确例外处理， 基于猜测的先行预取， 片上一级指令高速缓存。处理器系统结构的复杂给验证提出了很高的要求。而且， 由于TURBO51 是作为SoC 的嵌入式处理器核， 是整个大规模SOC 的控制核心和用户接口， 如果嵌入式处理器设计中验证不完善或性能达不到设计要求， 都会导致整个SoC 项目的开发致命失败， 因此对嵌入式处理器的验证在SoC 设计中是最重要的部分之一。

　　一切对高性能体系结构的追求都必须首先建立在以设计的正确性为前题才是有意义的。TURBO51的验证面临三个主要挑战:

　　( 1)正确性， 所采用的高性能体系结构也是复杂和高风险的， 只有设计正确才会带给SoC 性能上的提升。

　　( 2)兼容性: 相对于传统8051， 在程序的执行过程中， 中断和异常常会打断程序的执行， 动态流水线的处理器由于指令的动态乱序执行， 但又必须对外部程序来说是和完全顺序执行只存在速度的差别而非结果的差别， 所以它必须能精确地与顺序执行条件下的例外结果保持一致。

　　( 3)指令和操作数空间巨大， 寻址方式复杂:

　　8051指令集共有111条指令， 有多种寻址方式和不定的指令长度。另外， 8051指令集还将输入输出设备寄存器与体系结构寄存器作为同种寄存器访问。

　　这些都成为了结构设计和验证中的难点问题。

　　( 4)验证充分性的衡量: 在验证过程中根据发现错误的性质、原因和数量分布， 评估正确性程度和调整下面的验证计划， 使验证更深入， 实现设计错误的快速收敛。

　　1. 2 微处理器验证现状

　　目前世界各处理器公司用于功能验证的方式主要是模拟验证， 形式验证， 硬件仿真加速。但总的看来， 由于指令集庞大， 比如， 它的完全无错的测试向量的数量是指令条数阶乘及每个操作数， 地址数阶乘。在有限的时间很难实现。除非指令和操作数的所有两两组合都已测试过， 否则， 即便经过了这些验证， 也只能证明在测试已覆盖地方正确而不能证明设计在任何情况下都正确。

　　形式验证是指通过数学方法证明设计的完备性， 即这种方法下的样本空间是测试对象所有可能的状态。A rithSMV， * PHDD。由于状态样本空间巨大， 它只用设计属性检查工具， 目前仅用于局部逻缉验证。

　　模拟验证: 包括RTL仿真和门级仿真。这一阶段验证的效果很大程度上由测试激励和判定模拟结果的方法决定。在微处理器验证中， 采用汇编语言编写测试激励， 运行操作系统， 应用程序和随机生成测试向量。

　　硬件加速仿真: 为克服模拟仿真验证速度慢的缺点， 采用FPGA 的物理原型验证可以在流片前运行操作系统和应用程序， 进一步在系统级验证正确性。

　　2 TURBO51的验证方法

　　TURBO51在设计中用到了形式验证、模拟仿真和硬件加速仿真。采用自底向上的子模块级验证再自顶向下的宏模块及系统级验证的方法。在整个设计过程中， 验证与设计是一个整体， TURBO51在进行文档时序设计时就同时开始针对正在进行的设计编写验证计划， 设计和验证的工作在设计文档和验证计划中进行精确到每个时钟周期的行为描述和变量定义开始， 是整个设计和验证最重要的部分。由于TURBO51的设计要保证对传统8051指令集的后向兼容， TURBO51采用两台可进行单步调试的8051硬件仿真器， 两片传统8051， 两片采用了简单流水结构的改进版8051 作为正确标尺。测试激励在此先逐一运行， 并将其运行结果作为界定执行正确和兼容正确的标准。每个模块在每个时钟周期的每个寄存器读写和各个设计阶段的验证方法， 验证结果，问题分布， 验证策略在此规定， 并手工编写测试程序进行仿真。在验证文档中记录如何判定设计正确的与严重设计漏洞及原因， 并在设计文档中记录哪些临界态已考虑过了， 为以后怀疑某种情况下有没有可能是此出错提供重要依据。在TURBO51的设计中覆盖率指标在文档阶段已经引入， 每个设计了的逻辑一定要用测试来证明有必要这样设计和功能正确。功能设计中每个条件判断总能在测试文档中找到测这个条件的方法及判对标准。很多时候在写测试方法时发现了很多设计中没有考虑过的情况。功能设计文档和以覆盖率为指导的验证文档相互作用， 使TURBO51在开始RTL之前就己经完成了时序设计， 寄存器定义及全部块级测试的完全覆盖， 比如在寄存器重命名中多种寻地方式下对同一物理地址写入的重命名， 乱序发射， 精确例外。一般说来，越是文档级描述的错误越容易修改， 越是硬件级的错误越难于发现， 修改量很大且容易引入其他错误。

　　这个阶段可以较容易用排列组合等进行形式验证进行完全的情况覆盖， 排除了绝大部分严重错误， 而且用于仿真的手工编写的测试程序也用于此后的验证中。RTL不过是文档的一个V erilog 描述的翻译过程， 因此RTL并不是TURBO51设计最重要的地方，只是要按功能设计文档和代码检查的要求可很快完成， 但期间要用综合结果指导对流水线负载平衡并在细节上进一步调整， 但每一处与原功能设计文档描述不同的RTL修改首先是修改功能及验证文档，再次审核通过后才能改动RTL 代码。仿真和RTL编写是一体的， 在Turbo51 验证中分为模块、宏模块、系统级3个阶段。只有在一个阶段的设计和验证及文档完全达到计划要求， 即代码检查和代码覆盖率后才能再开始下一阶段工作， 这样使得错误得以快速收敛。这期间把错误分为高风险区错误和低风险区错误。出现不正常时首先从影响程序运行走向的高风险区开始排查， 排除高风险区的错误后再去找低风险区错误。模块级RTL 模拟仿真完成后就是宏模块级， 指令流水线， LOAD /STORE， Cache等， 再下来是系统级RTL 仿真。在Turbo51 的设计验证中， 只有在TURBO51 整个的RTL代码规范检验代码覆盖率达到RTL模拟仿真对覆盖率的要求并通过设计描述文档与验证文档相结合的审议通过后才可以再进行FPGA 验证。所以TURBO51设计验证的底线是在FPGA 硬件原形验证前至少排除全部会引起死机或兼容性的这类严重错误。TURBO51的设计验证不是依赖下一阶段测试发现本应在上个阶段发现并解决的错误， 而是只用下阶段确认上阶段目标的完成。FPGA 验证的目的是用于测试长时间在真实环境下运行应用程序， 因为毕竟很多对外部信号的响应不易在RTL 仿真中模拟， 而不是用来发现调试应在仿真中排除的问题。

　　3 形式验证

　　形式验证的好处是它能遍历全部状态空间， 可以实现验证的完备。它在设计行为描述规格书中就开始使用， 用于高风险区的存贮访问， 高速缓存， 分支预测， 动态执行， 例外处理中最高风险组合的完备性证明。比如在TURBO51 的片内一级指令高速缓存的替换策略设计时， 必须要处理每个可能的状态，吞则可能会出现状态机死锁。在这里首先就是对是否有且仅有的几种状态进行数学证明， 然后再开始编写功能行为描述和验证计划。这种方式可以使出错影响大但状态空间不大的逻辑达到完全正确， 而且后来的事实也证明， 通过形式的设计在此后的所有测试激励下没有出现异常。

　　形式验证在TURBO51 验证中的另一个地方是在进行RTL代码风格检查的时候用形式验证工具对修改前后的RTL进行功能比较， 另外类似的做法也用于物理网表与前端网表的等价性比较。