基于Palladium的TransactionBased Acceleration验证技术.docx
《基于Palladium的TransactionBased Acceleration验证技术.docx》由会员分享，可在线阅读，更多相关《基于Palladium的TransactionBased Acceleration验证技术.docx（14页珍藏版）》请在冰点文库上搜索。
基于Palladium的TransactionBasedAcceleration验证技术
基于PXP的Transaction-BasedAcceleration验证技术
作者1：
杨超，中兴通讯，陕西省西安市高新区唐延南路10号。
作者2：
闫新强，中兴通讯，陕西省西安市高新区唐延南路10号。
作者3：
石磊，中兴通讯，陕西省西安市高新区唐延南路10号。
摘要：
由于芯片的规模和复杂度日益增加，工程师用传统的模拟方法难以在短期时间内完成验证工作。
尽管各种验证方法学不断提出，但是传统方式的芯片验证工作的效率还是改善不大。
硬件加速器的出现为这个问题提供了一种新的解决方法。
PXP作为Cadence公司开发的硬件仿真器，其仿真速度较传统验证方式有大幅提高，且Debug能力也可以与传统的仿真软件相媲美。
PXPTransaction-BasedAcceleration（TBA）平台是基于传输级的验证平台，其基本的原理是在HVL的平台部分进行transaction级的处理，而所有与时序相关的signal级的传输处理都放在HDL部分。
这种使用方式可以将处于验证速度瓶颈的DUV运行于PXP上，仿真速度比软件仿真加速很多倍。
本文所介绍的PXPTBA方式在实际芯片项目进行了工程使用，并取得了较好的效果。
关键词：
PXPTBA硬件加速器Pipe-BasedAcceleration
Abstract：
Withchipsizeandcomplexityincreasing,traditionalverificationworkwouldtakeaverylongtime.Althoughvariousmethodologiesproposed,theefficiencyimprovementshaveonlybeenmodest.Hardwareverificationaccelerationequipmentprovidesanewsolution.PXP,asoneofhardwareverificationaccelerationequipments,whichisdevelopedbyCadencecanspeedupverificationspeedremarkablyandhaveequivalentdebugabilitycomparetotraditionalverification.TBA（TransactionBasedacceleration）modeisoneofverificationmodebasedonPXPismostsimilarwithtraditionalco-simulation,itsbasicprincipleistoseparatetransactionlevelpartprocessingonHVLsideandtimesequencerelatedsignaltransferpartprocessingonHDLside.Byimplementingmosttime-consumedDUVpartintoPXP,simulationtimecanbemanytimesfaster.PXPTBAhasbeenapplicationpracticedonchipdesignprojectandachievesgoodresults.
Keywords:
PXP,TBA,HardwareAccelerationEquipment,Pipe-BasedAcceleration
1.引言
传统的协同验证方法已经使用了多年，这种方法最大的优势在于验证平台、激励构造灵活且易实现，对复杂场景、随机场景的验证覆盖全面，能够有效的降低流片风险。
但是随着芯片规模及复杂度的增加，这种验证方法速度低的劣势暴露无遗。
为了解决这个问题，硬件加速仿真器的解决方案就此诞生了。
硬件加速仿真的概念出现已经很久了，随着各家EDA公司对其不断的研究使得硬件加速出现了2种方向发展，一种是基于传统的FPGA方向进行发展，这种加速器的加速效果明显且debug能力较FPGA原型验证有一定的提升，但软件进行FPGA自动划分时还是需要多次才能成功，目前市场上有很多这类产品；另外一种方式就是采用分布式概念的多核CPU阵列并行进行加速仿真的方式，如PXP，这种方式仿真速度甚至比有些基于FPGA的硬件加速器速度快，且比传统的协同仿真速度却提升了几十甚至成百上千倍，而且Debug能力可以与传统的协同仿真相媲美。
笔者公司这两种方式的硬件加速工具都有，经过评估与比较，笔者项目最终采用的硬件加速设备是PXP。
本文将围绕基于PXP协同验证平台的工作原理以及平台搭建技术展开介绍。
2.技术方案和实现方法
PalladiumXP是Cadence公司为了加快验证速度研制的最新硬件仿真器系列，以下简称为PXP。
PXP是业界唯一一个将Simulator，Emulator和目标板有机地集成在一起的系统。
它的编译速度、dump波形的深度及最高的使用率，都要比其他的同类产品性能高。
PXP的使用模式有以下几种，各种模式的加速效果如下图所示：
●Signal-BasedAcceleration
●Transaction-BasedAcceleration
●Vectors-BasedAcceleration
●Embedded-TestbenchAcceleration
●In-CircuitEmulation
Figure1PXP各种加速模式性能比较
其中第4种和第5种这两种方式的加速也是最快的，在PXP上最快可以达到4M。
本文主要针对第2种使用方式TBA技术做一些介绍。
虽然TBA方式相对于ICE和STB这两种方式加速效果稍微低一些，但是PXP与Workstation的结合使得TBA具有软仿的各种灵活性。
2.1TBA的概念和基本原理
2.1.1TBA概念
TBA（Transactionbasedacceleration）是基于PXP硬件加速器验证平台的一种实现模式。
TBA模式属于PXPSA模式的一种，也属于co-simulation的范畴。
使用PXP的TBA模式就是为了充分利用高级语言的优势来弥补PXP其他验证模式，如ICE模式的不足。
从简单的纯simulator的仿真扩展到可兼容高级语言的复杂验证平台的验证模式。
TBA模式的平台实现需要有co-simulation的基本知识，需要熟悉TBA的基本实现原理。
在此基础上，才能够掌握TBA平台搭建的方法和技术。
2.1.2TBA分类
TBA模式按照交互的方式可以分类，如Figure2图所示：
Figure2TBA模式分类
TBA模式交互的基本概念会在后面的章节说明。
在此只对分类作一简单介绍。
红色标识的为基于SCEMI标准协议Cadence自研的几类TBA模式交互方式；绿色标识的为SCEMI标准协议提供的几类TBA交互方式。
本文介绍的属于IncisiveBasedCosimulation下的SCE-MI2.0Pipes-basede的TBA，其他方式不做介绍。
2.1.3TBA工作原理
TBA验证环境分为Design和TB两部分，两个部分分别放在PXP和Workstation中，分别由PXP（UXE）和IES两个引擎进行仿真，两部分之间可以交换信息进行共同仿真运行，如Figure3所示。
Figure3TBA工作原理示意图
SCEMI标准协议提供了多种服务器侧和PXP侧交互的实现方式。
SCEMI标准的典型应用是在软件侧使用C语言，硬件侧使用SystemVerilog语言。
如果软件侧TB不是使用C语言而是其他语言，如E、SV，则需要使用所谓adapter的组件来实现C语言和其他语言的功能转换。
TBA验证平台之所以能够缩短仿真验证时间，提高仿真效率，主要原因是使用PXP取代仿真软件对可综合的DUT进行仿真，从而大幅度提高了仿真速度。
虽然可综合的DUT可以下载到PXP中仿真，然而TBHVL部分仍然需要在服务器中仿真运行。
因此，限制仿真速度的主要原因有两个方面，一是PXP侧的DUT和服务器侧的TB之间的交互次数。
二是纯服务器侧的软件的仿真时间。
为了减少DUT和服务器侧的TB的交互次数，TBA模式下软硬件交互是基于传输级的，相比基于信号级的SBA模式而言可以明显减少了交互的次数。
基于传输级的交互和UVM验证模型十分类似，TBA平台在软件侧只处理传输级的数据，而在PXP侧处理信号级数据。
因此，需要对传统的TestBench划分为两个部分，一是传输级数据处理的部分、二是信号时序处理的部分。
如图Figure4、Figure5。
TBA平台要求按照RTL方式实现时序处理部分，并且将这部分放在PXP中运行。
这样一来，即实现了事务级交互，减少了交互次数，又可以把原本TB中的部分转移到了PXP中运行，也提高了仿真效率。
Figure4传统Co-sim验证平台结构示意图
Figure5TBA模式验证平台结构示意图
TBA模式是SA模式的一种，他具有SA模式的所有优点和缺点。
其最大的优点就是兼顾了软件侧的灵活性，又利用了PXP快速的仿真速度。
软件的灵活性不仅仅指数据产生的随机约束，更多地是提供了平台本身的灵活性，相对于ICE模式而言，实现了以最小代价实现最大化验证覆盖的目的。
也可以说TBA模式是高级验证方法的PXP实现。
而且支持的语言也很多，C/SC/SV/E等语言均可以使用。
TBA的仿真速度和ICE模式相比相对较慢，原因是不可综合的TB需要在软件侧运行，并且也需要软硬侧交互，都是影响仿真速度的因素。
然而TBA模式仿真速度在某种程度上讲弹性较大。
比如针对同一验证对象，采用不同的SCEMI实现方式，transactor设计的不同等诸多因素可能都会导致平台仿真时间的巨大差异。
2.2TBA平台设计与实现
2.2.1TBA平台架构
TBA验证平台的详细结构图如所示Figure6。
整个TBA平台由左侧深蓝色HVL部分和右侧红色HDL平台部分组成，红色组件为待测的DUT，可以为RTL，也可以为网表。
下面对平台各个组成部分分别进行描述：
Figure6基于SCEMIPipe的TBA验证平台结构图
1）TransactionLevelTestBench负责处理传输级的数据，包括传输级数据的产生、处理、比对等。
2）ProxyModel负责把传输级数据模型传递到SCEMIPipe接口上，具体的也可以认为连接某个SCEMIPipe使得在软件侧可以调用该Pipe提供的API函数完成数据传输级交互。
3）E/Cinterface是前面提到的Adapter的一种，其目的就是为了实现E语言和标准SCEMIPipeC侧之间的转化，从而实现SCEMI协议的多语言扩展。
4）SCEMIPipeinterface是标准SCEMI协议提供的软硬交互实现的组件，其实现方式是基于DPI调用的，实现C侧的函数和SV侧的函数的相互调用，从而完成交互。
而Pipe实质就是封装这些函数的类。
BFM/Collector是基于信号级的TestBench部分的实现，包括信号层次上的时序实现以及和DUT的交互通信，这些部分都是在PXP内实现的。
TBA平台通过SCEMI标准提供的方式进行传输级交互通信，每次传输的信息更多，这样就不需要像基于信号级的平台每个时钟周期都需要同步HVL侧和HDL的信息，TBA平台必须通过事件方式进行同步，频繁的交互方式由若干必要的事件交互的方式代替,从而减少了两侧的交互通信次数，加速仿真效率。
2.2.2TBA平台的关键组件及设计方法
验证平台的主要目的就是能够产生激励并将激励驱动到DUT中，检查激励的响应结果是否与预期一致。
TBA平台与传统平台目的一致，有激励产生组件和响应检查组件，也有与传统平台有区别的组件，如Transactor组件。
这些组件都是TBA验证平台不可或缺的部分。
如图Figure7所示：
Figure7基于SCEMIPipe的TBA验证平台结构图
TBA平台设计到的关键组建包括：
●StimulusGenerator组件（STIM）.
●ResponseChecker组件（RESP）.
●Master/SlaveTransactor组件.
●MonitorTransactor.
2.2.2.1STIM组件
STIM组件的作用就是为了产生激励。
STIM组件通过TransactionCommunicationChannel与Master/SlaveTransactor组件相连接，将产生的激励数据发送给Master/SlaveTransactor组件。
STIM相连的Transactor有两种类型，Push和Pull类型，这两种类型也会影响STIM的工作方式。
两者的区别为激励产生时控制流的方向相反，如图Figure8、Figure9所示：
Figure8Pushstimulus
Figure9Pullstimulus
Push模式为STIM组件决定如何控制激励数据发送到硬件侧BFM以及DUT，而Pull模式意味着STIM组件发送激励数据受到BFM/DUT反馈信号的控制。
后者往往还需要和Monitor的协作共同完成激励数据的发送。
2.2.2.2RESP组件
RESP组件通过TransactionCommunicationChannel与MonitorTransactor相连。
其作用在传输级层处理MonitorTransactor采集的DUT结果。
需要明确的是，并不是所有的MonitorTransactor都与RESP相连。
正如在STIM组件中提到的，有些MonitorTransactor采集的DUT结果只是为了提供STIM发送激励的控制流，因此并不需要RESP组件处理。
2.2.2.3Transactor组件
如Figure10所示，Transactor组件分为MasterTransactor,SlaveTransactor,MonitorTransactor组件。
这三种transactor的功能是不同的，但是结构确是相同的，都由三部分组成，Proxymodel、CommunicationsChannel和BFM/Collector。
使用逻辑Transactor这个概念是因为实际中的加速Transactor不会作为一个完整的物理组件存在，在真实的TBA平台中，ProxyModel和BFM/Collector都是放在不同的物理部分里。
ProxyModel与BFM/Collector部分的通信是通过CommunicationChannels完成的。
每个Transactor都需要与DUT中的信号层次的接口进行交互，都要满足特殊接口协议方面的需求。
当然，这些组件也可以根据DUT的实际需求进行合并和多次例化。
我们以MasterTransactor为例，对Transactor组件做一个具体描述。
Figure10Transactor逻辑结构图
MasterTransactor中的BFM和ProxyModel是成对出现的，ProxyModel的作用是将很多的transactions打包成为message，然后发送给BFM。
BFM将接收到的message再翻译成信号级别的DUT接口需要的sequence。
因为Transactor在验证平台的搭建过程中是被分开的，所以ProxyModel和BFM必须要进行绑定。
事实上，绑定ProxyModel和BFM的说法并不准确，在后面介绍完Transactioncommunicationchannel后我们会有更加准确的说法。
有2种方法可以完成二者之间的绑定，一是采用确定hierachy路径绑定，另外可以通过在BFM中调用函数实现。
Transactor内ProxyModel与BFM之间所有的message的通信都是通过communicationchannel完成的。
CommunicationChannel有三种实现方法：
⏹SCE-MIMacro-Based
⏹SCE-MIFunction-Based
⏹SCE-MIPipes-Based
三种方式都是基于标准协同仿真建模接口SCE-MI协议的，目前的版本已达2.1，这是一个可以提供将事务级模型与硬件加速、仿真和快速模型平台相关联的方法的规范，可以提供一个更快、更好且更新的接口。
SCE-MI规范具有向后兼容性。
它通过数据成型增加了一个流接口，从而优化了仿真速度。
先前版本支持Verilog语言，SCE-MI2.0则支持SystemVerilog直接编程接口（DPI），且与OpenSystemCInitiative（OSCI）组织交易级模型（TLM）兼容。
文章开始我们针对TBA模式进行的分类事实上也是基于使用哪一种CommunicationChannel来分类的。
上述三种实现方法中，第一种方法本文不会进行讨论。
为了更好的描述Pipechannel，我们后面会对第二种方式简单说明并和Pipechannel做一比较。
下面对SCE-MIFunction-Based和SCE-MIPipes-Based两种方法进行简单的介绍，二者的区别请见Table1。
Table1Function-Based和Pipes-Based的区别
SCE-MIFunction-Based
SCE-MIPipes-Based
仅支持固定长度的message
支持定长及任意长度的message，Message长度独立于buffer的大小
一次仅支持一个message
一次可以支持一个及多个message
仅支持阻塞接口
支持阻塞与非阻塞的接口
支持单向和双向通信
支持单向的通信
Message数据可以位对齐
Message数据以byte对齐
SCE-MIFunction-Based方式实现起来很简单，只需利用c函数及其在BFM中的引入即可。
尽管这种方式很简单，但是当有大规模的数据需要通过接口时，这种方式的性能会受到一定约束。
SCE-MIPipes-Based通过利用一系列的C侧和HDL侧的API来实现，可以分别建立inputchannel和outputchannel，当然两者是互相独立的。
基于Pipe的通道最好的使用方式就大规模的数据量时，Pipe可以自动把message切成很多的小片，然后分批发送，这样BFM也可以很轻松的将这些数据处理掉。
基于Pipe的通信通道可以支持任意格式的message，而无需修改，加上分批分组的发送数据，这也使得Pipe方式的通信通道具有最好的通信性能。
SCEMIPipe结构可参见Figure4黄色虚线框部分。
HVL侧使用标准C语言实现，HDL侧使用可被PXP综合的HDL语言，两侧分别有相应的函数来处理数据流。
SCEMIPipe里面的具体实现已由Cadence做好，所以我们只需例化使用即可。
之前提到说绑定ProxyModel和BFM并不准确的原因是，事实上需要绑定的是ProxyModel和BFM中例化的Pipe。
因为只有Pipe才是真正实现交互的载体。
当Pipe被绑定后，就可以通过API将数据从ProxyModel传递到BFM中，BFM会根据DUT所需的Sequence将收到的数据做时序处理并在信号级发送给DUT。
MonitorTransactor和Master/SlaveTransactor的区别在于前者是在信号级上通过Collector采集DUT数据，并通过Pipe发送给基于传输级的ProxyModel，后者是在基于传输级的ProxyModel上发送激励数据，再将这些激励数据通过Pipe发送给信号级的BFM，最终发送信号级的激励给DUT。
2.2.3PXP验证平台搭建建议
下面给出搭建PXP验证平台一些基本的建议：
1.TransactionTestBench内信号的同步与触发由原信号级平台中的时钟沿触发，改变为事件触发控制。
2.由于TransactionTestBench侧没有时钟，因此整个平台的时钟必须由PXP侧来产生，并且需要使用Cadence封装好的时钟产生模型来实现，如下：
SPDclkgen2#（.phase_length（half_cycle））osc_0（.phi1（）,.phi2（clk_name））;
3.利用SCEMIpipeAPI接口，将原来的Signallevel信号传输转变为Transactionlevel级事务级传输。
SCEMIPipe为软件/硬件侧提供了许多可直接使用的API，既有阻塞的也有非阻塞的，推荐尽量使用阻塞行为的API.
4.Pipe需要在HDL侧定义，在HVL侧绑定，如下代码所示：
scemi_input_pipe#（16/8,1,128）ab_input_pipe（）;
scemi_output_pipe#（24,1,1024）l2_ram0_port（）;
Pipe在HVL侧的绑定
extandUVM_ACCELmaster_bfm{
m_ip:
uvm_accel_input_pipe_proxyoftransfer_sisinstance;
keephdl_path（）==“xi0”;
keepm_ip.hdl_path（）==“inbox0”;
m_in:
interface_portoftlm_putoftransfer_sisinstance;
connect_ports（）isalso{
m_in.connect（m_ip.m_in）;
};
};
5.编写信号级BFM/Collector时在一个block内同一个信号使用阻塞或非阻塞要保持一致。
不能够既用阻塞也用非阻塞。
6.Pipe初始化均为Reactive工作模式，如果需要使用Batch模式，需要对Pipe进行模式设定，指明该pipe使用Batch模式。
Batch模式相对Reactive模式更加高效，但需要显示调用flushAPI函数，对平台设计挑战大于Reactive模式。
7.尽量优化TransactionTestbench的代码，减少其运行时间，提高整个平台的仿真速度。
这部分工作和具体使用某种高级语言相关，无法给出具体细节。
8.脚本包括makefile和shellscript.由makefile去调用各个shell脚本来编译运行。
这种脚本架构思路比较清楚，灵活性较好。
9.推荐使用单独的shell来做环境配置，避免和其他仿真平台冲突。
3．结论
笔者曾经对TBA在PD3做过相应的评估工作，并在PXP上做过实际的项目工程，在PXP上没有进行过TBA与基于信号级软仿的精确的性能对比，粗略的结果在160倍以上。
对于大规模芯片的验证，TBA方式与有约束的随机验证可以很好的结合，并能提高验证人员的效率，对于芯片的Time-to-Market有很大的帮助。
参考文献
[1]Cadence,IXCOMCompilationUser’sGuide.
[2]Cadence,UXEDebugUser’sGuide.
[3]Cadence,UXEUserGuide.
升级会员 