基于SystemC/TLM方法学的IP开发及FPGA建模

设计开发方法学

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



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

在事务级建模时，

*更加注重数据转移的功能-即转移的是什么数据，从那里来，到那里去

*不太关注实际的实现-即不太关注数据转移所用的实际协议

该方案使得系统设计师的实验变得更加容易，例如，可以利用不同的总线架构(所有都支持公共的抽象接口)，不一定需要对与任意总线进行交互的模型进行重新编码，只要这些模型能够通过公用接口与总线进行交互即可。

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

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



图2：从SystemCMACHW向VHDLRTLMACHW适配器的转换。

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

硬件/软件划分

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

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


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

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

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

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

在第二个范例中，当MACHW处理控制帧时，全局定时为：

窗口编程时间=T+tprg_winexp，故系统中，HW对及时打开发送窗口的指令进行编程。

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