对混合打招呼

提出了一些时间,虚拟仿真平台可以与硬件为了co-verify SoC的硬件和软件组件。然而,建议现在已经演变成混合仿真,一个实际的解决方案,允许pre-silicon今天复杂的SoC设计的验证和确认。

一流的工作标准身体Accellera和开放SystemC倡议(OSCI)给了我们所有事务级建模,或TLM。TLM已经使我们能够创建一个虚拟平台的CPU子系统,为速度而牺牲准确性提供早期目标来测试软件。在早期,一个常见的障碍,实现这样的虚拟平台SystemC模型各种组件的可用性,例如,一个新的CPU。如果没有可用,那么我们将失去时间生成一个可信赖的模型,侵蚀早期软件测试的好处。

这些天,那些差距已经由SystemC模型库的可用性和IP常用功能,如ARM的快速模型(更多关于以后),但仍有其他块;你知道,那些新,往往最重要的是区分功能独特的SoC ?一个证明的解决方案是实现这样的功能在一个fpga仿真平台,如Aldec的他,然后通过事务级接口链接到虚拟模型。

让我们探索七种不同的使用方式等平台。我们将看到如何混合虚拟平台和FPGA硬件仿真相结合,提供一个两全其美的方法。然而,我们也将讨论特定的实际约束和成功是如何测量时间;时间精度要求;时间设置;和项目所节省的时间这样做。

没有软件,SoC
SoC-based产品的区别是什么?如果我们做的是把相同的IP块周围其他人同样的公共汽车,那么我们如何区分我们的产品呢?我们如何增加价值我们的SoC如果我们都有几乎相同的平台?答案可能是额外的定制硬件,但通常软件的主要区别,当然,SoC没有它没有多大用处。然而,软件也的头疼在SoC发展和验证。软件交付、验证和批准可以直接坐在项目关键路径,所以项目时间表和工具链不应该更关注软件团队的成功吗?

考虑独立的fpga原型。很明显,主要受益者是软件团队,但也有硬件的人的回报。原型,其中往往有多个副本,是一个物理目标的软件及其集成的硬件可以进行测试。然而,在这些测试硬件的软件团队还强调新的,有时意想不到的方式,所以发现硬件错误未发现单靠验证。每个人都赢了,但是考虑到他们的SoC项目重要性,不是软件团队应该得到更多?当然,这就是为什么EDA行业发达SystemC和虚拟平台软件项目团队可以使用更早,而不是等待硬件。

让我们深入了解一下这些虚拟平台和建立的各种软件,他们是最有用的。

有软件。然后是软件
让我们考虑一下我们,当我们说“软件”。设计师和评论家可能松散使用术语“软件”没有明确定义他们的意思(认错paenitet)。毕竟,有很多不同类型的软件操作和互操作在不同级别的软件栈,如图1所示。用户空间,包括应用程序,出现在堆栈的顶部和依赖于下层越来越关注操作系统内核和硬件,当我们达到较低的水平。

图1:速度和性能的相对重要性在不同级别的软件堆栈。

如果我们开发软件堆栈在任何给定水平然后我们将需要一个环境代表的水平低于运行它。理想情况下这可能是真正的底层软件运行在真实的系统硬件,但是当不可用,那么我们必须依靠某种模型来代替。越高我们在堆栈中我们试图模型,所以需要速度越大,但值得庆幸的是,我们需要完整的准确性。事实上,该模型只需要足够的精度来欺骗软件实际运行系统。任何比这更准确性将不必要地放慢速度模型的操作。

只有软件堆栈的最低水平,如图1所示的绿色,依赖于SoC硬件和面具的一部分工作是任何硬件的依赖性更高级别的软件。在Aldec,软件在这些低水平称为“硬件相关的软件”。模型时,我们会测试方面的硬件相关的软件需要精度高和可能包括cycle-accurate模型相关的硬件本身,如RTL模拟,模拟,或者一个fpga原型,根据我们需要运行速度。

软件堆栈的最高层,另一方面,如应用程序和其他用户空间程序,需要最少的准确性,因此可以以最高的速度运行。欢迎来到这个世界的虚拟平台。

愚弄所有的应用程序,所有的时间
你曾经试图开发Android应用程序?如果是这样,那么你可能知道的模拟器的一部分是可用的Android SDK。这是一个软件工具,运行在主机工作站和雇佣其图形,内存和接口来代表目标安卓环境。可以看到从图2中,您可以看到屏幕上您的工作站的表示Android设备,可以用鼠标点击的按钮,看看现实的反应和数据。

图2:Android模拟器。来源:谷歌

SDK的目的是使开发人员安装和运行他们的应用程序和其他用户空间程序,实际上愚弄上运行的应用程序让他们以为是一个物理Android设备。因此,Android SDK不支持USB连接,耳机,电池特性,蓝牙,当然,它不能打电话。

谷歌的Android模拟器是一个非常具体的例子,一个虚拟的平台。回顾一下,一个虚拟平台的任务是有足够的精度来支持软件运行的水平。这在很大程度上是通过模仿行为和内嵌通讯事务级,这使得它们固有的速度远远超过相当于cycle-accurate表示。

如果我们有必要的库的模型我们可以创建一个虚拟平台,任何SoC。这样的图书馆通常是写在SystemC通常可用的开源,而另一些则商业许可,如从Synopsys对此系统级图书馆。然而,让我们面对现实吧,今天的SoC设计是由手臂IP,所以至少我们需要我们的ARM核的模型和总线子系统。好消息是,手臂供应这样的模型,经过快速模型(商标)的名字,这些都是常用在虚拟平台。

虚拟平台和fpga仿真:一个模型婚姻?
所以我们主要的IP块占,但其余的SoC呢?你区分硬件或新的IP块需要模型,同时,为了创建一个完全填充的虚拟平台。这些SystemC从一开始可能不可用,但这些模块的RTL可能经常是可用的(甚至验证)。如果我们可以使用RTL的地方的一些失踪的SystemC模型?

我们可以编译RTL变成正常的模拟器和链接我们SystemC虚拟平台使用事务级接口。别忘了,虚拟模型已经操作在事务层面上。这种组合会解决missing-model问题。然而,它会限制总体的成本模型的速度的RTL模拟器。RTL太准确的模型软件堆栈的最高层,所以我们将在RTL模拟器运行速度和获得任何回报。

好消息是,这种放缓可以最小化通过加速RTL仿真与模拟,甚至取而代之一个fpga模型。让我们用Aldec名称简称他(硬件仿真解决方案),因为它包含了这两种方法。这种组合给出了事务级虚拟平台与他的名字混合仿真。

有许多使用模式的混合仿真平台可以是有益的;这些都是表1中列出。

表1:7混合仿真的关键使用模式。

我们将考虑每个反过来,但是所有这些混合仿真使用模式的关键驱动因素之间的联系虚拟和物理系统的部分。幸运的是,已经有一个事务级的方法连接SystemC虚拟平台模拟器,fpga或;这是标准的Co-Emulation建模界面,或SCE-MI。

为什么SCE-MI如此梦幻?
SCE-MI节省每个人都很多工作,此外,这是一个开放的行业标准。Aldec雇佣SCE-MI兼容的接口以链接他各种各样的模拟环境中,包括SystemC-based虚拟平台,如图3所示。在这里我们可以看到,FPGA在模拟器的RTL实现SoC的一个子集,也许一个新的图形功能或高速外围,而其他的SoC由快速模型。

图3:SCE-MI链接虚拟模型的简化视图和FPGA仿真器。

在实际的SoC设计中,所有的块通过总线通信网络,包括在fpga中实现的函数。图3显示了在混合仿真的一些事务级交流需要通过fpga。可能有很多这样的接口在一个真正的混合仿真平台(见下面的分区讨论),但我们只有显示一个图。

交易相关函数在FPGA中实现必须转化为内(从)cycle-accurate信号转换的硬件。SCE-MI并不是整个故事的一部分,然而,读者应该检查的说法“别担心;我们从板供应商SCE-MI太”。SCE-MI,连同所需额外的基础设施,应该被视为验证IP (VIP)。

认为贵宾,不仅SCE-MI
VIP的接口的一个重要组成部分的层将在虚拟交易平台的总线模型转化为事务理解SCE-MI模拟器上做交易的。通常,在一个虚拟平台,都写在SystemC TLM通讯和模型,我们也使用SystemC创建TLM包装为目的的集成虚拟平台与外部模块。Aldec,例如,提供了一个适配器,图书馆相关SystemC TLM活动转化为SCE-MI消息然后与他的身体交易人。

我们展示一个通用TLM2SCE-MI块在图3中,但事实上,不同的适配器用于不同的接口,具体到每个总线协议或外围标准VP-Emulator边界。例如,Aldec TLM2SCEMI-AXI验证IP提供了他们之间的联系他fpga仿真器和一个虚拟平台采用ARM的安巴AXI总线。更完整的VIP图书馆,更大的灵活性在分区之间的SoC虚拟平台和仿真器。

进入第二部分:7使用混合仿真的方法,并在虚拟分区一个SoC和硬件平台。