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可重新定为不同微架构的RTL代码。而且，得益于更高的抽象程度，正确地创建功能要容易得多。TLM模型具有的代码行比对应的RTL模型要少得多，从而在最终设计中实现了编码效率和品质的同步提高。

　　开发与维护作为IP模块黄金源码的TLM所需的综合和验证解决方案，需要产生有品质保证的结果并验证其正确性，且无须编辑RTL或门级设计。这使设计团队在TLM环境内就能做出所有决定，并可通过将TLM源码复用于系统来约束完全不同的其他设计。

　　SystemC是描述事务级设计的最佳标准，并连接到实现，提供了最好的可复用机会。它可对硬件的并发特性进行建模，并针对进程、管脚、线程和控制逻辑描述定时或非定时的行为。TLM 1.0和2.0标准提供了创建可互用IP模型的能力。最终，需要有一个合格的可综合TLM IP库，及可综合TLM标准(或事实上的)子集。