TLM驱动式设计和验证方法学新方案

　　引言

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

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

　　Cadence设计系统公司目前提供一种全面的SystemC TLM驱动式IP设计与验证解决方案，包括方法学指南、高阶综合、有TLM感知的验证以及客户服务，推动用户向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中，这些微架构详情都是固定和预先决定的。