王纪,冯志华
(中国航天科工集团第二研究院706所,北京100854)
SoC多语言协同验证平台技术研究
王纪,冯志华
(中国航天科工集团第二研究院706所,北京100854)
SoC基于IP设计的特点使验证项目中多语言VIP(Verification IP)协同验证的需求不断增加,给验证工作带来了很大的挑战。为了解决多语言VIP在SoC验证环境灵活重用的问题。提出了一种基于开放的多语言构架库的解决方案,详述了多语言协同验证技术的原理以及验证平台的搭建方法,并通过实例验证了所提方案的有效性和灵活性。
片上系统;验证知识产权核;多语言协同验证;重用
随着高级验证方法学越来越多的成功应用于实际的SoC验证项目中[1],产生了大量由不同语言、不同验证方法学编写的可重用组件;而且由于IP来自不同的EDA厂商,相应的验证IP也是由不同的厂商提供。仅在SoC验证环境中重用由同一种语言和验证方法学实现的组件或VIP,已经不能满足日益增长的SoC验证需求[2]。如何灵活的重用多语言验证组件、搭建SoC多语言协同验证平台已然成为热点。
现有的多语言的解决方案分为两种:一种是基于SystemVerilog DPI(Direct Programming Interface)直接引用外部语言程序的方法[3];另一种是使用EDA厂商提供的多语言库的方法[4]。前者验证平台无法对外部语言程序实现配置,灵活性差[5];后者则存在当前使用的多语言库针对语言种类单一,不能跨仿真器平台的缺点[6]。
文中针对当前多语言协同验证解决方案存在的不灵活,支持的语言种类单一等特点,基于一种新的解决多语言问题的开源库——UVM-ML OA(Universal Verification Methodology-Multi-Language Open Architecture library),详述了多语言协同验证的原理,并描述了搭建SoC多语言协同验证平台的过程,以一个具体的实例验证了这种方法在灵活性和可重用方面的优点。
UVM-ML OA库是由AMD和Cadence公司联合推出[7],致力于解决多语言验证组件的快速整合与重用。它提供的一些方法和工具能够将不同语言的验证组件整合到一个大的验证环境中。抽象验证组件具体实现的语言与方法学,使多语言组件在同一验证环境实现无差别的通信和配置。UVMML OA的基本结构如图1所示,它由开源的基类和多种构架的多语言适配层组成。例如,SV(SystemVerilog)适配层,SC(SystemC)适配层等。
图1 UVM-ML OA基本结构Fig.1UVM-ML OA basic structure
构架是指由同一种语言或验证方法学实现的验证组件的集合。构架可能由硬件验证语言(SystemVerilog)、建模语言(SystemC)或一般的编程语言(C/C++)实现。不同的构架也可以由同一语言实现:例如,UVM和VMM都是由SystemVerilog编写。
基类是两个或更多构架的连接路由,是整个星形拓扑结构的中心点。提供不同组件间控制和数据通讯的API(Application Programming Interface)。这种CS(Client-Server)结构能够忽略具体的方法学和语言的实现细节,协同不同构架间的工作。
适配层是基类和构架的连接层,提供与其对应构架连接到基类所必须的的API接口。
UVM-ML OA拥有包括多构架结构、事务级通信、分阶段机制、跨构架配置机制等特征,使其能够很好的解决实际应用中多语言的难题,灵活的搭建多语言协同验证平台[8]。
多语言协同验证平台由多种构架的VIP组成。验证平台可能有一个或很多逻辑顶层,每一个顶层都是由不同构架子组件组成的树形结构。每一棵树都可能包含其他构架的子树。如图2所示,构架1的A组件是整个多语言协同验证平台的顶层。它除了实例化了A1、A2两个同一构架下的子组件外,还例化了一个构架2下的子组件B。
图2 不同构架下的统一树形结构Fig.2Unified hierarchy in different frameworks
搭建多语言协同验证平台首先要将不同构架的子组件实例到验证平台中,使整个验证平台形成一个统一的树形结构。结构建立后,为了实现整个平台的数据流动,不同构架的组件需要建立事务级的通信。最后建立起跨构架的可配置机制,增强多语言协同验证平台的灵活性。
2.1多构架组件的整合
UVM-ML OA通过基类来实现父组件和外部子组件的连接,确保平台间数据和控制请求被正确传递。每一个父组件通过各自构架适配层的API与基类的API相连;然后基类再与子组件的相应构架适配层的API相连。这样,经由代理父节点和代理子节点建立起了不同构架父组件和子组件的抽象连接。如图3所示,还以构架1的A组件为例:在构架1的范畴内,A正常的实例化了A1、A2两个组件;而属于构架2的B子组件则如图中虚线所示,经由各自构架的适配层和基类来完成在A中的实例化,完成多构架组件的整合。
图3 组件的跨构架连接Fig.3Parent child relationship maintained through the backplane
要实例化一个不同构架的子组件,有必要正确的指定外部组件的构架类型和名称,以及实例化后的实例化名。以SV适配层的API实例化外部构架组件为例:使用下面的方法在SV环境中实例化其他构架的组件。
其中,参数target_frmw_indicator是待实例化组件的构架类型;参数component_type_name是待实例化组件的顶层模块名;参数instance_name为组件的实例化名;参数parent指定当前组件的父节点。
2.2事物级连接的建立
多构架组件的通讯基于TLM(Transaction Level Modeling)接口[9],UVM-ML OA的基类提供了指定的多语言接口库,它维护着平台运行时事物级交易所需的必要信息。多语言平台中的TLM接口要跨构架实现通信,有两个步骤:首先TLM的端口或套接字必须在基类中注册;注册后将接口绑定,不同架构组件间便可以经由相应的适配层和基类实现数据交易。
2.2.1注册
注册的多语言端口会在相应的适配层中产生与基类进行数据流动的通道,适配层提供了相应的底层结构支持不同构架与基类的连接。还以SystemVerilog构架的API注册TLM1端口和TLM2套接字为例。使用SV适配层的register方法实现注册功能,register方法定义为:
static function void register(uvm_port_base#(uvm_tlm_if#(TRAN_T,P))sckt);
其中参数sckt代表被注册接口的全路径名称。
2.2.2绑定
接口被注册后建立起了适配层与基类进行数据流动的通道。绑定则是在不同构架的适配层与适配层、组件与组件之间建立连接。接口在基类中注册后,接着进行接口之间的绑定。绑定时,需要为基类提供被绑定的两个接口的全路径名称,基类会检测两个接口的合法性,然后将两个接口的连接信息加入它的内部数据库。以SC构架的API绑定TLM1端口和TLM2套接字为例,使用uvm_ml_connect方法实现绑定。uvm_ml_connect方法的定义为:
其中,port_name是指port端口的全路径名,如sc.env. port;export_name是export端口的全路径名,如sc_env. export.name();map_transaction默认为true。
2.3验证平台的配置
灵活的跨架构配置机制是UVM-ML OA解决方案的一大特点。配置机制用来配置验证平台的众多参数,在不同构架和层次的组件间传递数据,增加平台的灵活性。配置机制是分层次的,在平台的树形结构中较高层次组件的配置信息会覆盖低层次组件的配置信息。配置使用间接的方式:配置发起组件将配置数据传递到多语言基类中;被配置的外部构架组件再从基类中获取配置数据。
在多语言协同验证平台中,配置和获取数据总是成对出现的。例如,在某个顶层组件中做配置操作,那么在平台的驱动器组件就要做相应的获取操作。
2.3.1配置
一般来讲,验证平台中每种构架的组件只处理本构架内的配置操作。但在一个多语言验证环境中,不同构架的组件在整合到一个平台并建立事物级连接后,配置数据也能够经由基类的API传播到其他语言的构架中。
以在SV构架的组件配置其他子组件为例,使用uvm_config_*::set(this,inst_name,field_name,value)函数来设置配置值。其中,inst_name参数是被配置子组件的名称;field_name参数是子组件内被配置对象的名称;value参数代表了具体配置值。设置的配置值会在子组件的bulid阶段传递给子组件。UVM-ML OA支持3种数据类型的配置:使用“uvm_config_int”方法配置整型值;使用“uvm_config_string”方法配置字符串;使用“uvm_config_objects”方法配置对象。
2.3.2获取
在平台运行期间,配置数据被传递基类中,相应的目标组件要有对应的接收操作从基类中获取配置数据。以e构架组件中获取配置值为例,使用get_config_*(field_name,value)方法获取配置值。其中,参数field_name是组件内的某一个被配置过的变量;value参数是配置值的存储位置。与set方法类似,get方法也支持3种数据类型:使用“get_config_int”方法获取整型值;使用“get_config_string”方法获取字符串;使用“get_config_objects”方法获取对象。
上一节中,介绍了UVM-ML OA库处理多语言协同验证的原理,本节将以一个SoC多语言协同验证项目中的UART模块为具体实例,说明SoC多语言协同验证平台的实现方案,整个平台的结构如图4所示。
图4 多语言验证平台结构Fig.4Multi-language verification platform structure
作为整个SoC验证项目的一部分,UART模块经由桥接器集成到整个SoC系统中。针对项目组手中拥有由厂商提供的SV的APB总线验证IP和先前的验证项目中留下的,由e语言实现的UART验证IP。决定搭建多语言协同验证平台对UART模块进行验证。
如上图所示,搭建多语言协同验证平台的关键在于:虚拟序列产生器如何驱动异构组件的数据激励、异构组件的监视器如何与平台建立连接、异构验证组件在平台中如何实现无差异的配置。
遵循前面章节多语言协同验证平台搭建的方法,主要步骤如下:
1)整合异构组件:实例化异构组件到顶层是整个平台搭建的基础。将e语言构架组件整合到SV环境中,需要在SV构架的testbench文件中实例化e构架的顶层文件e_uart_top。这样就把所有的组件整合到一个统一的树形结构中,部分代码如下。
function void build_phase(uvm_phase phase);
super.build_phase(phase);
//建立多语言组件连接节点
etop=uvm_ml_create_component("e","e_uart_top"," e_uart_top",this);
...
endfunction
2)事物级接口的连接:将不同构架的组件整合到一个统一的结构中后,序列产生器和监视器要通过TLM接口与SV架构的验证顶层建立事物级的连接。
这里通过使用register方法和connect方法建立事物级的连接。以激励产生器的连接为例,部分代码如下。
//建立阶段
seqr_proxy=ml_sequencer_proxy:type_id:create(" seqr_proxy",this);
...
class my_env extends uvm_component;
...//连接阶段
uvm_ml:connect({e_seqr,"b_isocket"},
my_uvc.seqr_proxy.b_target_socket.get_full_name())
…
endclass
3)跨架构配置验证平台:配置平台的参数可以增加平台灵活性,动态的控制平台的运行。在这个案例中,在顶层配置e构架UART验证组件的address参数,验证平台运行过程中观察测试结果。部分代码如下。
//顶层的配置操作
uvm_config_int:set(this,"uvm_test_top.testbench. e_uart_top.e_env.e_seqr","address",'h7f);
super.build_phase(phase);
...
//e构架的序列产生器获取配置数据
unit e_seqr{
keep uvm_config_get(address);
...
}
经过上面几个步骤,完成了SOC验证项目中UART模块的多语言协同验证平台的搭建,使用IES仿真后的部分结果如图5所示。
图5 仿真结果Fig.5Simulation results
实验结果表明,UVM-ML OA被成功应用于SoC多语言协同验证项目中,对于多语言验证IP的重用提供了一种有效地解决方案。验证IP由EDA公司提供,或来自于项目组长期积累的成熟模块,它们的重用提高了验证的可靠性和可信度。
文中基于UVM-ML OA呈现了一种全新的SoC多语言协同验证的解决方案。详细讲述了多语言协同验证的原理,并基于实际案例阐述了解决方案的有效性和灵活性。结果表明UVM-ML OA能有效的应对实际应用中SoC验证面临的多语言协同验证问题,为验证人员提供了更可靠、更灵活的多语言验证解决方案。
[1]王嘉良.SoC可重用验证平台研究与开发[D].上海:东华大学,2011.
[2]Yang X,Niu X,Fan J,et al.Mixed-signal System-on-a-Chip(SoC)verification based on SystemVerilog model[C]// System Theory(SSST),2013 45th Southeastern Symposium on.IEEE,2013:17-21.
[3]Aynsley J.SystemVerilog Meets C++:Re-use of Existing C/ C++Models Just Got Easier[C]//Design and Verification Conference&Exhibition(DVCon).San Jose,CA:Accellera,2010:255-262.
[4]Erickson A.Transaction-Level Friending:An Open-Source,Standards-Based Library for Connecting TLM Models in SystemC andSystemVerilog[C]//Design and Verification Conference&Exhibition(DVCon).San Jose,CA:Accellera,2013:321-330
[5]Edelmen R,Glassar M.Inter Language Function Calls BetweenSystemCandSystemVerilog[C]//Designand Verification Conference&Exhibition(DVCon).San Jose,CA:Accellera,2007:143-150.
[6]文良,靳荣利,吴龙胜,等.基于AHB总线接口的可重用性验证环境的实现[J].微电子学与计算机,2011,28(7):201-207. WEN L,JIN R,WU L,et al.Building Reused eVC Verification Based on AHB Bus[J].Microelectronics& Computer,2011,28(7):201-207.
[7]M.Guy.UVM-ML Open Architecture-version 1.4.4:Enabling Multi-Language and Multi-Framework Verification[EB/OL].[2014-12-02].http://forums.accellera.org/files/file/65-uvm-mlopen-architecture.
[8]B.Sniderman,V Yankelevich.Multi-Language Verification:SolutionsforRealWorldProblems.[C]//Designand VerificationConference&Exhibition(DVCon).India:Accellera,2014:87-92.
[9]F.Hannes,S.Kishore.Multi-Language Verification:Solutions forRealWorldProblems.[C]//DesignandVerification Conference&Exhibition(DVCon).India:Accellera,2014:63-70.
Research of SoC multi-language co-verification platform technology
WANG Ji,FENG Zhi-hua
(Institute 706,Second Academy of China Aerospace Science and Industry Corporation,Beijing 100854,China)
The characteristic of SoC based on IP design makes the verification projects increase the demand for multi-language VIP(Verification IP)Co-verification,which has brought great challenges to the verification work.In order to solve the problem of the multi-language VIP be flexible reused in SoC verification environment.Proposes a solution which is based on an open source multi-language Framework Library,detailed multi-language co-verification technology and the method of building the verification platform,and through a example demonstrates the effectiveness and flexibility of the proposed approach.
SoC;VIP;Multi-Language;co-verification;reuse
TN406
A
1674-6236(2015)20-0130-04
2015-01-08稿件编号:201501062
中国人民解放军总装备部预研基金(513150502)
王纪(1990—),男,安徽宿州人,硕士研究生。研究方向:嵌入式设计与验证。