利用基于SystemC/TLM的方法学进行IP开发和FPGA

liyf

利用基于SystemC/TLM的方法学进行IP开发和FPGA建模
随着系统级芯片技术的出现，设计规模正变得越来越大，因而变得非常复杂，同时上市时间也变得更加苛刻。通常RTL已经不足以担当这一新的角色。上述这些因素正驱使设计师开发新的方法学，用于复杂IP(硬件和软件)以及复杂系统的验证。ST公司建立了一个设计流，它从高级抽象开始，易于将模型写入IP的精密周期或RTL模型中。当转入低级抽象时，建模变得复杂，故IP验证也复杂。我们的方案最适合于这种应用场景，因为它允许人们在各地相似的环境中运行相同的测试平台和测试场景，因而允许在整个开发周期里高效地复用所有的测试范例和环境。

在半导体领域，开发产品的第一步就是以高级抽象开发规范的模型，通常用C/C++来实现。这里，SystemC和C++库提供了很大帮助。它简化了共存的硬件和软件设计的概念化。再加上实现事务级模型间对口连接的TLM传送库，SystemC加速了整个验证过程。另一个重要方面是所有不同抽象架构中经过增强的可移植性。同一测试配置可以无缝地用于不同抽象级的设计。

本文将讨论一种此类的方法学。最终的目标是设计和实现UWB MAC(媒体访问层)IP。出于架构开发的目的，决定用SystemC来实现整个IP。还开发了抽象级具有不同程度变化的不同架构。所付出的努力比较少，最后得到的仿真速度很快，软件的实际编写也可以在设计周期非常早的阶段开始。该IP的RTL结果被移植到了SPEAr系列的FPGA中。除了ARM内核和相应的一系列IP，SPEAr还提供一个可配置逻辑块，这为用户在实现其逻辑功能时提供了无与伦比的灵活性。从而缩短了上市时间，同样也实现了空前的成本节省。

设计开发方法学

图1所示的该方法学实现了开发的内核中的事务级建模(TLM)。TLM是一种对数字系统进行建模的高级方案，这里将模块之间的具体通信与功能单元或通信架构的具体实现分离开。把总线或FIFO这类通信机制模型化成信道，用SystemC接口类将这些信道提供给模块和部件。这些信道模型的信令接口功能将取代事务请求，这将减少具体的低级信息交换。




图1：IP开发方法学流程。

在事务级建模时，
* 更加注重数据转移的功能-即转移的是什么数据，从那里来，到那里去
* 不太关注实际的实现-即不太关注数据转移所用的实际协议
该方案使得系统设计师的实验变得更加容易，例如，可以利用不同的总线架构(所有都支持公共的抽象接口)，不一定需要对与任意总线进行交互的模型进行重新编码，只要这些模型能够通过公用接口与总线进行交互即可。

在我们的方法中，起始点是对整个功能系统平台进行建模。这是利用SystemC并通过sc fifo接口实现的。为了描述通信接口间的数据流，采用了各种架构。这些架构基本上都是协议需要遵守的参数和帧格式信息。围绕IP创建了一个测试环境，环境中开发了测试平台，来传输分别来自两侧的输入，即发送和接收。在这两种范例中，利用这种配置产生了预期的结果或参考。在抽象层，与平台一起使用来进行修改，快速并有效地做试验时将变得很容易，不过精度会降低一些。

图中所示为用于开发中下一级输入的配置平台。这里的核心思想是确定系统的瓶颈并执行软硬件划分。该方案在进行软硬件划分方面是有效并安全的，因为平台提供能够用来识别出整个系统瓶颈的原始统计信息。该阶段中，实现了IP的功能模型，使其具备了具体的接口，并嵌入了功能性。而在软硬件划分阶段将对该方法学中所用的方案进行具体化。附加到该平台上的另一个是DMA-PL080的TLM模型，下一步是用MAC HW RTL替代整个MAC HW SystemC功能模型，如图2所示。整个周边环境是一样的，因此测试注入与其他步骤中的注入一样。与之前环境的变化是采用了负责到信号变换的事务处理适配器。由于该系统基于ARM，适配器的书写必须遵从信号级AHB总线接口。实际上，该平台将相同的环境表征为现实系统，不过与此同时，开始面对仿真性能方面的问题。显然，我们还不能用该配置来执行广泛的调试/验证，不过可以运行简单的测试(具有较短的仿真时间)。





图2：从SystemC MAC HW向VHDL RTL MAC HW适配器的转换。

由于在当前仿真环境中发现瓶颈，我们对基于硬件模拟XTREME服务器的平台进行评估，该平台基本提供了硬件所需的FPGA块，并提供了软件与整个环境的无缝集成。基于XTREME服务器中早期平台的移植只需要很少工作量，并且相对于基于ncsim的仿真环境，实现了5倍的仿真速度。很显然，这使得我们能够调试并执行VHDL RTL设计的验证，否则将会浪费过多时间。同时，基于Xtreme服务器的平台还提供了同等调试能力。


硬件/软件划分

系统中软硬件划分决策是最为重要的一个方面。之所以硬件/软件划分变得如此关键，是因为如下一些因素，如系统的实时处理需求，应用软件的存储限制以及其他因素。许多时候，设计开发阶段一些决策依赖于直觉判断或者先前的经验。但当某些事情发生错误时这将蕴含一个风险。随着系统复杂度以及流片成本的增加，这种决策方法可能会铸成大错。强调需要一种有助于实现更好软硬件划分决策的方法学具有许多原因。

在UWB MAC系统开发范例中，具有很多必须很好遵守的时间约束，这是因为应用层完全依赖于空中——即来自射频天线的全局广播定时。实现决策的方案建立在我们从具体的系统级平台的执行中所获取的经验。我们能够分析流水线数据通道中的数据流，能够有效地发现它们是否将对系统构成任何瓶颈。通常，当系统中的数据流发送时，数据帧必须从MAC发送到PHY，而对于接收，所产生的数据帧则从PHY到MAC，并存入到存储器中由软件进行进一步的分析。在仿真场景分析过程中，能够识别出是否需要在硬件中进行一些协议解析以采取及时的措施。





图3：系统中着重硬件支持需求的应用场景。

图3中详细给出了一个决策范例。根据协议的需求，接收数据中有一个控制包，它通知下次发送事件的通用定时，即何时发送下一个数据包。考虑到MAC硬件是一个典型的数据通道，并将控制帧传送到存储器中，软件对控制帧进行处理并决定打开发送窗口。在发送窗口打开出现问题时，用这种方案就能发现瓶颈。系统平台结果被用来确认这一理解，于是能够做出更好决策来实现效率更高的系统。图3中的另一个场景显示了软硬件划分后的结果。

第一个范例中，当软件处理控制帧时，全局定时如下：

窗口编程时间=T+t RP +tPM+tintr+tsw_lat>T+texp，故在系统中，SW没有对及时打开发送窗口的指令进行编程。

在第二个范例中，当MAC HW处理控制帧时，全局定时为：
窗口编程时间=T+tprg_win<T+Texp，故系统中，HW对及时打开发送窗口的指令进行编程。

与此同时，现有的SPEAr板起到了很大的帮助作用，因为在板上测出了AES-CCM引擎的性能。因此能够推断出硬件中存在AES-CCM，因为AES-CCM软件算法给不出所需要的性能。

挑战

被测设计(DUT)或被测单元(UUT)的测试对任何设计方法学来说都是最关注的一个方面。在开发的初始阶段，即架构评估阶段，必须需要一个高性能的性能仿真环境。具有行为功能TLM平台能够满足这一需求，并对将要执行的功能进行功能检查。当进入到低级抽象设计阶段时，仿真性能大大降低，这成为有效验证IP的一个问题。

软硬件的系统级仿真与软硬件的协同仿真一块进行。ST有自己的平台，这是一个包含硬件(RTL)的混合平台，软件利用SystemC书写(见图2)。该平台的瓶颈是环境中所引入IP的RTL，而且注意到这将大大地降低性能。正如预期，这是所遇到的约束，而且对是否能够比主仿真运行更快的可能性进行了评估。该方案基于Xtreme服务器硬件仿真，使得运行速度至少要比NCSIM仿真快10倍。





图4：配有软件的Xtreme服务器配置。

图4所示的该技术对第一次仿真特别实用，不需要任何有关环境配置方面的工作量。其概念是在Xtreme的FPGA中运行RTL IP。开始时，引入的时钟为软件时钟，但结果相当可喜，还简化了RTL的系统验证和调试。配置过程中，整个仿真环境是类似的，仅有的改变是用VHDL RTL IP替代SysC IP。试验结果是仿真速度快了10倍。因此，Xtreme服务器平台满足了RTL验证/调试所用平台的需求。最重要的方面是具有与ncsim同等水平的调适能力。还提供了与SystemC环境的无缝集成。

调试功能

硬件方面的一个更具挑战性的问题是调试。当自检失败时，就需要一个相关的测试范例。为了验证该测试范例，在检查失败原因时必须检查所有的主要信号。所以需要对信号进行存放，验证，从而找出具体的原因。利用基于XTREME服务器的平台可以很容易地执行所有这些功能，无须额外的工作量。通过将实际硬件移入独立的FPGA，可以很容易地改善仿真速度，不过这种方法提供的调试功能较少。因此，基于XTREME服务器的平台不仅改善了仿真速度，还能提供非常好的调试功能。图5给出了分析结果。




图5：A）不同平台上的仿真性能。B）不同平台上的调试复杂性。