与电子产业的其它领域一样，在设计自动化领域，借助标准化，许多技术和方法学得以被广泛接受。例如，硬件描述语言Verilog的标准化使得RTL综合在80年代中期就开始应用。
在验证领域，使得基于事务的验证方法学被广泛接受的背后推动力是新兴标准。诸如OSCI的TLM(事务级建模)2.0和Accellera的标准协同仿真建模接口(SCE-MI)等标准导致了对事务的兴趣高涨。此外，验证流程目前使用硬件加速和仿真来加速基于事务的验证。
为什么要使用事务?
Cadence Design Systems系统设计和验证产品管理部门总监Ran Avinun表示，在系统设计建模时，通常要实现三个目标。“第一个是早期软件开发，第二个是早期系统定义，第三个是可执行规范的描述，当你进行架构权衡的最初会需要它们，”Avinun说。
事务适合用在哪些地方?为什么设计工程师希望从事务级模型开始，并最终将这些模型用硬件加速实现?对许多用户来说，答案在于它可实现快得多的模拟。“如果你将模型写成TLM，或通过基于事务的验证进行通信，就可实现更快速的模拟。”Avinun指出。
采用TLM的另一个好处是调试起来更快、更容易。“一般来说，如果你编写TLM，则生成的错误更少，且调试所花的时间也更少。它还提供了一个区分功能和实现的机会，”Avinun称。
“你想要编写一个能表述功能的模型，然后将约束分开。它们可以是时钟约束或是针对特定工艺节点，随时间变化的东西。当你从一个应用转到另一个应用或从一个节点转向另一个节点时，复用模型会更容易。”Avinun说。
事务是如何使用的
据Synopsys的系统级解决方案产品营销总监Frank Schirrmeister介绍，当谈及TLM时，至少有五种使用模型已成主流(见下表)。排在列表首位的是复用的情况。
在这种情况下，你的设计的很大一部分已经用RTL编写。此时，最佳方案是一种混合模式的模拟方法学，其中，现有的RTL在FPGA上运行。与此同时，该设计中面向新模块的TLM作为虚拟样机运行。
排名第二位的是验证使用模式。在这种情况下，你启动一个测试平台，然后在RTL可用之前开发一个虚拟样机。这是借助无时序TLM实现的。
“人们从无时序模型着手定义其想要涵盖的验证场景。”Schirrmeister说，“当我用手机玩游戏和下载东西时，它还能接电话吗?借助虚拟平台，你可在早期很容易地定义这些情况，因为它们由运行在处理器上的软件完成。随后你可以在项目中使用它们。”
第三种使用模式是评估系统与外部世界之间的联系。这些联系既可以是物理的也可能是虚拟I/O形态。
“例如，对于USB接口，你希望在高保真条件下与真实世界建立连接。但如果这一接口还不存在，你可以用虚拟的方式与其建立连接，这样你就能着手软件开发，”Schirrmeister说。
虽然USB是一个具有说服力的例子，但Schirrmeister 还列举了设计团队采用该方法学在手机中接入无线接口的例子。它是通过FPGA软件在虚拟端实现的。
第四个使用模型是针对远程软件开发的情况。为满足物理硬件尚不存在这一情况下的需求，可借助于以虚拟原型形式出现的早期软件开发环境。“在这种情况下，你要创建一个开发环境，工作在该环境下的软件开发人员甚至不需要知道其软件是运行在FPGA原型还是虚拟平台上。”正如Schirrmeister 所言，这是一种“使软件开发人员置身实验室之外”的做法。
第五个(也是最后一个)使用模式是一种涉及在FPGA上构建硬件原型的更简单的软件开发方法。“事实证明，FPGA不是运行处理器的首选，因为FPGA更多地是关注DSP。”Schirrmeister 说。通过将处理器模型本身转为软件实现，你可以通过连接硬件原型以及在软件侧进行处理获得更均衡的处理速度。此外，因不再需要考虑软件的某些部分，可获得非常快的运行速度。
工具和流程演变
为实现进一步发展，TLM需满足三个要求。其中最显而易见的两个是嵌入式软件开发和设计验证。“验证工程师需要简单、直接的测试。”Schirrmeister说。另一个不断发展变化的要求是随机测试生成，它采用校验监控器以及包含用TLM表述的用于系统级芯片(SoC)综合验证的覆盖范围。随机测试模式的生成、覆盖检查以及监视器的使用等情况将及时传播到TLM领域和虚拟样机。
TLM有待融合的第三个要求是与实现的直接链接。“我们称这一流程为‘TLM到GDSII’。”Schirrmeister 说。 “过去有两个世界。一个侧重虚拟平台，而另一个侧重高级综合。我们认为在将来某个时候，这两个世界将合二为一。”
对许多设计工程师以及EDA供应商来说，问题是如何在虚拟平台和高级综合(HLS)流程之间建立链接。
“一直以来都试图用TLM链接这些世界。”Forte Design Systems的市场和销售副总裁Brett Cline说。“但问题始终是该标准只考虑了验证而没考虑综合。在TLM规范中缺少了一些非常基本但对硬件设计而言至关重要的东西。例如，没有专有的复位机制。”
OSCI内部的努力最终导致了TLM 1.0标准的修订，进而催生了TLM 2.0版本。 “我们对OSCI TLM 1.0进行了扩展，做了一些你或许期望我们做的一些事，也即对综合的了解。”Cline说。“TLM 2.0是一个更加关注综合的标准，它主要专注于基于总线的系统。”TLM 2.0包括各种面向基于总线系统的事务应用编程接口(API)。
Cline认为，由于验证工程师和实现之间的鸿沟，虚拟平台和HLS是分开的。“人们从两个角度来看待它。你或者是一位验证者(从虚拟平台角度来看)，或者是一位用SystemC进行硬件设计的实现者。”Cline说。“现在，验证者已经认识到，TLM代表着一条无需重写就能完成实现的可行途径。同时，实现者也正开始明白该如何将一些东西集成进运行得非常快的系统模型。”
Schirrmeister表示，过去，大部分厂商和用户在隔离时已经使用了虚拟平台和/或HLS。“创制TLM 2.0是为有助于早期软件开发和高性能模拟，但它对HLS考虑不多。实际上，我们正借助可综合子集来推动TLM 2.0标准解决HLS需求。这是业界需应对的发展方向。”他说。
硬件生成
基于事务验证的一个重要组成是借助TLM可实现极高速验证的硬件。最近，Synopsys推出了其快速原型系统HAPS-60系列作为Confirma平台的组成部分。基于赛灵思Virtex-6 FPGA构建的HAPS-60系统是对“自建还是购买”决策的最新回应，过去涉及快速原型技术时会面临该问题。
该系列产品包括三种型号：HAPS-61(单 FPGA，多达450万门容量)，HAPS-62(双FPGA，900万门容量)以及HAPS-64(4 FPGA，1800万门容量)。除了容量是上一代HAPS-50系列的一倍以外，HAPS-60还将性能到时钟频率高达200MHz。
对Confirma快速原型系统(图1)中组件的一种高级概述是从贯穿综合始终的RTL设计文件开始。接着在快速原型板上对设计进行分割。系统的Confirma软件执行这一分割过程，而且该软件明白其目标是一块HAPS板。然后，用户就可以进行模拟原型所需的接口实例化，以及协同仿真和基于事务的验证所需的将设计链接到其它环境中。
图1：一个Confirma快速原型系统从RTL设计文件开始，接着进行综合然后对设计进行分割。
早期的快速原型系统与带宽的限制相冲突，这一限制是由FPGA引脚数无法跟上设计规模和速度要求而引起。过去，对该问题的解决办法是互连复用，这可以作为权宜之计，但最终会限制系统的整体性能。
HAPS-60系统采用自动高速时分复用避免了这些带宽限制。该系统的软件自动(而不是强迫用户手动)插入时分复用逻辑(图2左)。“按照过去的方式将需要深入解读RTL设计文件。”Synopsys方案营销业务拓展经理Doug Amos说。
图2：HAPS-60系统通过采用自动高速时分复用避免了带宽限制。该系统的软件自动(而不是强迫用户手动)插入时分复用逻辑(图2左)
这种自动化方法最终实现了一种与自动时序同步耦合的1Gb数据速率。这相当于将管脚带宽效率提高7倍，以及将平均系统性能提高30%(图2右)。
包含UMRbus架构使得HAPS-60系统尤其适用于基于事务的验证(图3)。UMRbus是一种高性能、低延时通信总线，它能为所有板载FPGA、存储器、寄存器和其它资源提供连接。
“UMRbus被用于整个电路板控制，”Amos说。它支持用于配置和监控的对整个系统的远程访问。许多设计互动和监控功能(图3右)均包括在内。“用户可以控制设计、访问设计、补充设计、回读存储器并调试纠错，”Amos说。
UMRbus还支持若干先进模式，包括基于事务的验证和协同仿真(图3左)。 “用户可编写程序来实现各种设计互动和监控功能，” Amos说。该系统包含许多基于主机的调试模式，这些模式过去是与仿真关联的。
当涉及基于事务的验证时，通过使用SCE-MI 2.0事务接口(图4)，HAPS-60系统可以大大缩短验证时间。“这正是开发SCE-MI 2.0的目的，”Amos说。“SCE-MI接口使我们能用软件进行事务处理，将事务传递到硬件，以及硬件再生成事务。该技术被用在仿真器类型的环境中来模仿真实世界的做法。”
现在，HAPS-60系统使这种仿真器型方法学可以在一个快速原型系统上实现。SCE-MI允许在原型部分使用高级概念。“这个系统模糊了原型和仿真器之间的界限，而SCE-MI是使其得以实现的推手，”Amos说。其结果是，当在HAPS硬件上运行简化的测试平台时，速度可比仿真快10,000倍。
支持TLM 2.0
提供支持基于事务的验证的另一家硬件供应商EVE，最近在其ZeBu仿真平台产品线中增加了对TLM 2.0标准的支持。 TLM 2.0是Open SystemC Initiative(OSCI)用于SystemC模型互操作性和重用的接口标准。“考虑到我们在此背景下引入了仿真器，因此对我们来说，这更像是基于事务的协同仿真，”EVE-USA总经理Lauro Rizzatti说。
EVE已通过一种事务处理适配器(图5)实现了对 TLM 2.0的支持。该适配器支持多个目标和发起人、阻断和非阻断传输接口，以及松散定时(LT)、松散定时时间解耦(LTD)和近似定时(AT)编码方式。
在系统级，用户可以将虚拟平台、TLM 2.0事务处理适配器以及先进SystemVerilog硬件验证环境整合起来。在仿真器级，ZeBu TLM-2.0事务处理适配器是一种可实现与其它ZeBu事务处理器的互操作的开放架构，其它的ZeBu事务处理器既或是来自EVE的事务处理器目录，或是由ZEMI–3生成。ZEMI–3是EVE用于事务处理器总线功能模型(BFM)的行为SystemVerilog编译器，该编译器使得编写周期精确的BFM以及与C++或SystemVerilog测试平台进行信息交换变得非常容易。
据Rizzatti称，在基于事务的模式中，70%至80%的EVE客户使用ZeBu。“在简单的基于C的循环模式(而不是事务模式)中，他们也可能将其用于调用。但即使这样做，他们仍然因为事务模式的好处而采用该模式，”他说。
EVE营销总监Ron Choi表示，对TLM 2.0的支持使EVE的仿真器在互操作性方面更上一层楼。“多年来，我们都采用一个事务级接口。但它必须通过一个专有API来实现。这是一种非常有用的方法学，但现在对于基于标准的方法有更强烈的诉求，”他说。
TLM 2.0事务处理适配器解决了设计工程师为桥接不同产品必须编写不同代码这个问题。“一般来说，ESL工具总是有能力通过编程语言接口(PLI)连接到RTL模拟器，以及通过API调用C/C++函数连接到仿真器，”Rizzatti说。“这要求他们针对不同的接口编写外围应用。他们在编程时必须写入其自有的互操作性。一个更好的办法是使用定义了互操作层的 TLM 2.0，它使用户无需考虑底层实现。这样，他们是否使用SystemC模型就不重要了。”
欢迎转载，本文来网络通讯员(http://网络通讯员m/)
