适用于系统级验证的VMM多层框架
发布时间：2011-11-16 14:44
发布者：李宽
|
作者：ADI公司 Ashok Chandran，Sajeev Thomas，Saj Kapoor 基于验证方法手册(VMM)的验证是非常有效的模块级验证环境实现方法。在系统级采用模块级验证组件可显著改善验证质量，缩短满足系统级覆盖率所需的时间。但是，这种方法也给系统级测试平台带来了一系列需要应对的挑战，包括运行时间、随机化质量、系统存储器管理、多寄存器访问接口、时钟域和随机稳定性。此外，模块到系统的重用方法应当简单、可扩展。 对于具有专有内核和系统接口的片上系统(SoC)，通过汇编语言编码进行各种外围器件不同模式下的测试并不是一个可扩展的解决方案，也不大适合基于VMM的流程。在VMM流程中，会出现多个仿真线程同时访问外设的情况。例如，在配置一个外设时，可能有另一个线程正在读取同一寄存器空间以检查中断状态。在汇编测试中，一个内核只有一个指令流，因此无法模拟这种行为。本文所述方法将内核替换为总线功能模型(BFM)，直接驱动系统接口总线。每个模块测试平台在不同的线程中处理，并可以访问相应的外围组件。采用VMM寄存器抽象层(RAL)可确保由模块级测试平台迁移到系统级时，仅发生极小的行为改变。 系统测试平台需要根据外设要求对系统组件进行编程。例如，通用异步接收机/发射机(UART)模块在发射之前，需要配置直接存储器访问(DMA)引擎并且初始化存储器。由于系统架构是所有外设的公用资源，因此提供一个统一的平台和一些实用任务来根据外设要求配置系统会更合理。多层架构能够确保系统支持每个外围组件。同时各层实现了随机化，确保系统和外设覆盖率最大化。 环境针对性能进行了优化，支持线程管理、条件编译和模块级测试平台的即插即用。因此，这是一种自下而上的方法，模块级需要遵守一套基本但宽泛的原则，以便简化集成。 本文将介绍传统的系统级验证方法，并说明改进的新方法，进一步阐述分层架构及其优势。本文还将讨论通过适当的线程和存储器管理来改善运行时间的技术，以及利用分离编译和多核编译技术解决编译时间较长问题的方法。最后，本文将涉及该测试平台如何利用VMM录制/回放方法来避免随机稳定性问题，以及如何支持汇编格式的测试转储。 设计详情 本文考虑的设计是一个复杂的通用SoC，它包含多个内核、一个中断控制器、大量专有外设模块、L1/L2/L3存储器、存储器控制器、DMA引擎和多个IP(知识产权)模块。一些模块可以通过内置的DMA引擎访问系统存储器，另一些模块则使用系统DMA引擎访问存储器。虽然没有明确显示，但外设与存储器之间有多个仲裁层。 该芯片还有多个模块、电源和用于仲裁的系统交叉开关，如图1的简化示意图所示。外部引脚通过多路复用方案由多个外设共用。 
图1 ：设计概览。 系统级验证挑战 系统级验证旨在验证系统配置与外设模式的不同组合，这会揭示许多有意义的情况，其中包括： 是否经历了所有可能影响外设的系统配置模式下的外设模式？ 1.关于连接是否存在遗漏？一旦处在特定的系统/外设配置下，该连接就可能变得可见。 2.是否所有模块都已连接到适当的时钟域？ 3.当多个外设为获得系统资源而竞争时，系统中是否存在带宽问题？ 4.每个DMA/外设都有对整个存储器空间的读写权限吗？ 5.系统内的所有寄存器都可以访问吗？ 6.是否会产生流量模式，从而验证系统真正支持使用案例？ 7.模块是否采用了在系统上无效的行为，或者模块是否看到了它不是为此而设计的行为？ 由于涉及到大量组合，对于如此复杂的SoC利用定向测试来验证上述各种情况是不可行的。 使用模块级VMM测试平台可在系统级提供良好的覆盖率，但是随着模块数量的增加，将会带来一系列全新的挑战。 1.系统编程应与外设模式相关。例如，针对接收模式下的一个外设，需要在存储器写入模式下对DMA进行编程。当模块级测试平台在系统级工作时，将系统配置信息封装在外设交易(transaction)类中，这种分层方法提供一种可在所有模块上实现的通用方法。 2.大量模块子环境和线程一起运行必然会拖慢仿真，因此必须对线程进行管理，确保只有活动的测试平台占用CPU周期。 3.庞大的测试平台和复杂的设计会导致编译时间过长，形成严重的开发瓶颈，必须利用工具的高级特性来克服这一障碍。 4.寄存器访问机制必须对所有模块和系统测试平台一致。VMM RAL提供了合理的解决方案，消除了寄存器访问的物理接口在模块级与系统级之间改变时的所有问题。 5.引起故障的测试案例必须能够再现，以充分验证解决办法有效性。 多层框架 测试平台组件在不同层工作。图2所示的分层架构支持模块到系统重用和系统级的即插即用功能。下面将从下至上描述各个不同的层。 
图2:分层架构。 1. VMM寄存器抽象层 此层处理基于RAL的寄存器读写操作。RAL对于测试平台从模块到系统的重用起着重要的促进作用。测试平台独立于物理总线协议。高级RAL交易转化为RAL访问层内的物理层交易。物理层交易描述物理协议(如APB、AHB和AXI等)。物理层利用RAL访问层提供的交易驱动总线信号。 2. 系统组件层 此层管理所有系统组件，如DMA、存储器和中断控制器等。该层与软件API相似，提供一套任务、对象、协议和原则用于系统管理。例如，请求n个数据项将转换为适当的DMA编程，利用所需数据初始化存储器并处理DMA中断。该层还增加了数据校验以验证数据路径，并向外设层显示中断。 3. 外设层 此层管理模块级子环境(subenv)。它还能同步系统事件，如中断和利用模块级子环境进行配置等。 4. 测试层 此层利用VMM方案和多流方案发生器(MSSG)产生随机交易。通过对外设属性和系统配置应用限制条件，能够产生定向随机方案。 设计方法 本部分阐述如何实现分层结构，同时讨论对系统级验证有价值的其他内容。 内核无关的测试平台 大部分SoC使用的内核要么是经过充分验证的，要么仅进行了极少的更改。即使更改较大，其验证也需要与系统级验证完全不同的方法。因此，内核验证应与系统验证分开进行。测试平台取代内核，直接驱动到系统中，如图3所示。这种方法可提供更强大的控制能力和更多的功能，并且无需更改便可支持模块级VMM测试平台。由于设计开销减少，其仿真速度更快。它还支持生成覆盖率分级的汇编测试，以及在实际内核上运行测试。 
图3 :BFM取代内核。 从模块级到系统级的基本类变化 基本类从vmm_data转变为系统级基本类，如图4所示。用于转变的基本类是与外设和系统配置关系最密切的基本类，其参数能够影响系统配置，包括外设方向和所有已使能的中断等。系统特性现已嵌入此交易类中，换言之，系统层插入发生级；编码样式如示例1所示。以下几个优点值得注意： 
图4 : 基本类变化。 示例1 : 外设基本类的编码样式。 
1.可以将更多限制条件添加到随机系统级类上，使外设模式与系统模式相关。因此，无需更改任何代码，就能将同一组类同时用于模块和系统测试平台。 2.使用VMM数据宏确保类层级无缝改变。 3.唯一的peripheral_id识别系统内的外设。 4.系统基本类中的寄存器功能和vmm_opts的使用确保当中断改变或焊盘引脚位置改变时，无需更改代码。因此，测试平台能够在不同项目之间高效移植，系统中测试平台的多个实例也能得到有效支持。 集成和管理子环境 在传统的VMM流程中，所有模块级子环境都被添加到顶层环境内部，然后从vmm_env调用subenv的配置、启动和停止等。这种流程会带来以下问题： 1.大量子环境会导致顶层环境变得异常复杂。 2.所有子环境的初始化任务混在一起导致移植更加困难。 3.子环境与性能下降之间存在相关性。 与传统流程相同，在新方法中模块级子环境在顶层VMM环境内分层次实例化，不同之处在于对子环境的管理由一个xactor接手。xactor产生于一个公共系统级类，它构成外设层与系统组件层之间的接口层。 xactor分阶段处理子环境，就像它是在模块级一样。此外，系统级任务从xactor内部调用，以便配置外设所需的系统组件支持。此xactor内接收的系统中断通知经由通知或函数/任务调用传递到模块测试平台。这种方法的优势在于： 1.顶层无需执行子环境初始化任务。 2.使用VMM xactor迭代器可以实现即插即用功能。一旦一个xactor实例化，连接和共识(consensus)就会自动添加。顶层针对实例化的唯一变化是只需调用xactor和子环境的构建器。 3.子环境的整个阶段处理完全在xactor内部进行，测试平台的移植能力更强， 。 示例2为用于实现外设xactor的代码示例。 示例2 :IO xactor的实现。 
下面的示例3说明添加IO到系统vmm_env如何大大简化，无需连接通道或启动/停止xactor，这些任务将由VMM xactor迭代器完成，迭代器会寻找系统xactor基本类的衍生类。 示例3: Xactor插入env中。 
测试结束由系统状态和外设状态决定，外设状态由子环境所传递的共识决定。结束测试之前，测试平台会查看所有活动组件的共识状态。 指定交叉关系 在指定同一外设交易内不同类型或模式的外设交易间关系上，使用VMM多流方案是一种有效的方法。如前所述，所有交易都产生自一个公共基本类，因此它们可以通过一个公共框架传递。一个路由器类(产生自vmm_broadcast)将交易路由至相应的交易器，由其处理分组数据。该流程如图5所示。 
图5：交易流程。 路由器回调函数也可以根据需要丢弃或修改分组数据。当引脚通过多路复用方案由多个模块共用时，就需要进行修改。这种情况下，可以丢弃引脚冲突的交易。由于路由器知晓所生成的交易，因此它可以决定仅针对那些在测试中处于活动状态的外设调用start_xactor()，从而避免不必要的线程。 功能覆盖率 每个系统组件都会增加功能覆盖率，这样可以确保模块与系统的功能覆盖率之间有一个良好的交叉关系。由于模块交易和xactor被重用，因此来自模块级测试平台的功能覆盖率也可以在系统级重用。 流水线式RAL访问 在多核系统中，任何一个内核都可以访问外设寄存器，并没有一种直接的方法来指定在RAL读写期间外设在哪个内核上工作。间接方法则是通过读写任务的data_id字段指定内核，但其缺点是data_id的这种用法无法对来源不同的模块级环境实施。 另一种解决办法是将交易随机映射到任一内核，但是要求一个模块的所有交易必须使用同一内核接口。可以通过将内核分配变为非随机方式进行优化 。然而，即便有多个接口可用，由于RAL访问任务execute_single()一次只能接受一个交易，其效率仍然低下。如果启用流水线式RAL，则所有接口可以同时使用，接口的使用将得到进一步优化。 使用VMM-MAM进行存储器管理 对于本身具有DMA引擎的IP模块，必须直接配置系统存储器，这将需要分配存储器段。使用VMM存储器分配管理器(MAM)进行系统存储器分配，可以防止试图访问存储器的不同模块发生冲突，并且有助于模块到系统的重用。通过改变存储器指针，模块测试平台可以访问不同的系统存储器，但同时仍然在系统级运行。VMM-MAM还能分配具有所需存储器对齐方式的随机区域。 VMM录制/回放 利用VMM录制功能可以录制交易，这有助于保存测试案例，即使测试平台后来经过多次变更，保存下来的测试案例仍然可以回放。如果没有录制，则在线程顺序发生改变的情况下，测试可能无法利用种子再现相同的方案。 使用RAL回调函数进行测试转储 通过附加RAL回调函数，可以将动态完成的配置打印输出为汇编语言格式，这将生成所执行测试的一个静态版本。回调函数可以在配置开始之前插入，然后在配置完成时删除，如下面示例4所示。 示例4 : RAL转储示例。 
|
网友评论