TLM驱动式的新方案探讨

引言

Cadence设计系统公司提供一种全面的SystemC TLM驱动式IP设计与验证解决方案，包括方法学指南、高阶综合、有TLM感知的验证以及客户服务，推动用户向TLM驱动设计与验证流程转变。

下一个抽象级别建立在事务级建模(TLM)基础之上。创建TLM IP作为黄金源码后，设计团队可简化IP创建和复用，在功能验证上节省人力物力，并减少bug。设计迭代减少，原因是TLM验证比RTL验证快得多，且架构选择在RTL验证进行之前就能得到确定。此外，事务级模型可用于软硬件协同验证，并可组成用于早期软件开发的虚拟平台的一部分。所有这些优势将大幅提升设计效率。

TLM通过函数调用而非信号或线路进行模块间通信。它允许用户分析读或写这些事务，而不用担心底层逻辑的实现和时序。SystemC是开发可复用、可互用TLM IP的最佳语言标准。此外，因为SystemC建立在C++基础上，它还允许对C语言算术函数的完全复用。开放SystemC行动(OSCI)为TLM模型定义了若干抽象层，分别是程序员视角(无定时)模型、宽松定时模型和近似定时模型。

要求对RTL进行改变的关键难题

在RTL中，有限状态机的结构要进行充分描述。这意味着，在编写RTL时需关注微架构详情，如存储器结构、流水线、控制状态或最终实现中使用的ALU等。 这一要求导致更长、可复用性更低的设计与验证流程。

有时当TLM用于当前流程时，现有的基于RTL的流程需要进行两次设计意图手工输入——一次在系统级、一次在RTL级。这种过程粗笨低效且易出错。架构直至产生RTL后才能确定，而重新确定IP目标成本很高。一个真正的TLM驱动式设计与验证流程将只需要一次设计意图简单的表达，并提供一条自动化的转换方法。

从RTL开始查找和解决架构问题过程长，代价高

RTL驱动式设计方法学的一大问题是，一种架构是否能实现，直到建立了RTL并对其进行验证后才能确认。由于RTL是架构的直接表示，大部分RTL设计师不得不同时探究功能正确性、架构和设计目标。这导致很长的周期，始于做出架构决定，终止于验证功能性。通常，设计与验证团队会发现需要修改架构的功能性bug，每次发现这样的bug就需要重新开始整个周期。

在RTL上复用IP设计限制了架构灵活性

当今SoC中，可能有高达90%的IP模块来自以前项目的复用。但是，当IP的黄金源码为微架构级别时，复用是很困难的。重定RTL IP的微架构目标费力且容易出错。目标系统应用可能差别很大，意味着不通过重新架构，仅通过简单复用，新的SoC设计目标是不能达到的。例如，RTL设计师可能需要将设计重新分割成RTL块、改变流水线级数、或创建新的存储器架构，因为在原有IP中，这些微架构详情都是固定和预先决定的。

RTL功能验证时间比当前技术的最高吞吐量增加得更快

在很多SoC项目中，功能验证已成为主要瓶颈。RTL功能验证开始时，在系统级的大量验证投入已然损失。虽然验证规划、指标驱动式验证等方法使设计团队尚能应付当前的大部分验证难题，但时间限制和日益增多的门数正在使验证变得难以为继。RTL功能验证所需时间可能随设计的增大而呈指数式增长，因为相互作用的各种模式及该IP需要测试的许多软硬件配置导致了各种极端情形，它们也需要进行验证。

RTL是有精确时钟周期的，涉及的代码行远多于TLM逻辑。对RTL模型进行仿真时，仿真器检查所有事件或时钟周期，即使在协议级上并未发生任何重大情况。仿真器要在微架构详情上浪费大量机器周期，而这些需要在架构确定后才能确认。TLM仿真在更高抽象级别进行，能更早完成，并提供更高性能。

TLM正是需要的解决方案

TLM驱动的设计和验证流程可实现在功能级别上描述IP，然后在快速仿真中验证事务的功能行为。TLM流程的主要优点包括能更快创建设计;减少了黄金源码中的代码行;bug更少;表达设计意图更容易，且仅需一次;更快的仿真和调试;功耗预估可更早进行;支持软硬件协同验证;可将模型纳入虚拟平台;RTL生成前可进行架构验证;在RTL验证中可复用TLM验证IP;无需微架构重新设计即可进行IP复用;ECO模式下产生的RTL变化很小。

基于TLM的流程与高层次综合(HLS)配合，可将抽象级别提高。这是大约15年前设计师转向RTL后的又一次重大转变，根据之前的经验，这次转变有可能使设计效率呈现数量级的提升(见图1)。

下面几部分描述了TLM驱动式设计和验证流程的具体属性和优势。

创建TLM作为黄金源码

——更快的IP创建与设计IP复用

与RTL不同的是，TLM不描述最终实现的微架构详情。不描述微架构详情大幅提高了TLM设计在要求各不相同的多个项目间的可复用性，因为相同的TLM IP可重新定为不同微架构