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标准(或事实上的)子集。

对TLM IP的功能验证可应对验证吞吐量的爆发

TLM IP验证相对RTL验证具有很多优势。首先，仿真运行更快——相对RTL仿真有数量级的提升，从而允许验证更多功能性实例。同时，在TLM抽象级别上进行的调试比RTL调试更容易、更快速。

通过在更高抽象级别上编码，TLM IP需要的代码行更少，bug也更少。功能性bug在设计早期就能被发现和解决。因而可大幅减少验证工作的总体投入。

在TLM抽象级别上，定位和理解bug更容易，修正bug也更容易，原因是需要处理的详情更少。TLM流程允许在最合适的抽象级别来验证各关注重点，如TLM用来验证功能、信号级验证用于验证接口等。

TLM验证流程始自算法功能验证，允许用软件进行功能验证，然后转向TLM功能验证(见图2)。通过C-to-Silicon Compiler的编译，用户可转向微架构RTL验证和RTL到门级等效性检查。除支持仿真很快的非定时建模外，TLM还允许用户进行改进，逐渐包含微架构详情，并改进时序精确性。

软硬件协同验证及早期软件开发

TLM模型抽象级别高、执行快，足够执行切实可行的软硬件协同仿真。设计师能将嵌入式软件与TLM硬件模型进行协同仿真，来检查软硬件依赖性，并对依赖于硬件的软件进行早期调试。有可能将这些技术当做对软硬件交互的随机化激励与覆盖进行应用。

用于早期软件开发和调试的虚拟平台可能包含由SystemC TLM模型组成的子系统。得益于它们的快速执行，为创建硬件设计而开发的模型也可用来加速软件设计。

支持TLM和RTL混合验证

在SoC级别需要TLM和RTL混合功能验证，是因为有大量将被复用的遗留RTL IP，且仍有必要针对设计各部分进行详细RTL功能验证。某些验证任务将只能在RTL上才能完成，包括针对存储器存取顺序或状态迁移覆盖等属性的微架构结构验证。

由于大部分验证工具如验证计划(vPlan)、开放验证方法学(OVM)验证组件、testbench、序列、测试、检查和覆盖等在各种抽象级别都能复用，因此TLM/RTL混合信号验证也变得更容易实现。功能验证规划与管理跨TLM与RTL两个级别，允许团队在混合级别设计中的各级别上对验证进行跟踪和控制，并在需要时对结果进行整合，确保了整体品质。

用于SystemVerilog的OVM已得到扩充，可支持包括e与SystemC在内的多种语言。OVM库也支持TLM。目前，OVM方法学描述正在进行扩充，以显示怎样在一个综合性回归解决方案中整合TLM和RTL模型。这将有助于创建工作于多语言、TLM/RTL混合验证环境的验证IP(VIP)。

多级功能验证testbench基于事务，当它连接到基于RTL的IP、总线或接口时，需要一个事务处理器在事务级域和管脚精确的RTL域之间进行转换。类似地，