uvm_tlm通信篇总结

UVM通信篇之一：TLM通信概论

TLM是一个基于事务（transaction）的通信方式，通常在高抽象级的语言中被引用作为模块之间的通讯方式，例如SystemC或者UVM。TLM成功地将模块内的计算和模块之间的通信从时间跨度方面剥离开了。在抽象语言建模的体系中，各个模块通过一系列并行的进程实现，并且通过通信和计算来模拟出正确的行为。而如果要提高系统模型整体的仿真性能，需要考虑两个方面。一个是建模自身的运算优化，另外一个是模型之间的通信优化。前者需要依靠开发者的经验还有开发工具的性能分析工具，来逐步优化模型自身；后者则可以将通信的频率降低，内容体积增大的方式，来减少不同进程之间的同步带来的资源损耗。而TLM正是从通信优化的角度提出的一种抽象通信方式。

• TLM通信需要两个通信的对象，这两个对象分别称之为initiator object和target object。
• 谁首先发起通信的要求，谁就属于initiator，而谁作为发起通信的响应方，谁就属于target
• 按照transaction的流向，我们又可以将两个对象分为producer和consumer。区分它们的方法是，数据从哪里产生，它就属于producer，而数据流向了哪里，它就属于consumer。
• 在target中实现TLM通信方法。

端口的按照类型可以划分为三种：

• port：经常作为initiator的发起端，也凭借port，initiator才可以访问target中实现的TLM通信方法。

• export：作为initiator和target中间层次的端口。

• imp：只能是作为target接收request的末端，它无法作为中间层次的端口，所以imp的连接无法再次延伸。

首先来看看下面的例子中，关于TLM端口的类型、层次和对应的连接。可以从对应的连接关系中初步得出TLM端口连接的一般做法：

• 在initiator端中例化port，在中间层次例化export，而在target端例化imp。

• 多个port可以连接到同一个export或者imp；但是单个port或者export无法连接多个imp。这可以抽象为多个initiator可以对同一个target发起request，但是同一个initiator无法连接多个target。

• port应为request起点，imp应为request终点，而中间可以穿越多个层次。基于单元组件的自闭性考虑，建议在这些穿越的中间层次中声明export，继而通过一级一级的连接实现数据最终的通路。

• port可以连接port、export或者imp；export可以连接export或者imp；imp只能作为数据传送的终点，无法扩展连接。
  

UVM通信篇之二：单向、双向及多向通信（上）

UVM通信篇之四：通信管道应用

从该组件的内部实现来看，它内置了一个mailbox #(T)。该mailbox没有尺寸现在，用来存储类型T的数据。同时，uvm_tlm_fifo的多个端口对应的方法均是利用该mailbox实现了数据的读写。一个uvm_tlm_fifo内主要包含下面几个TLM端口，实际上还有例化其它的TLM端口名，但为了简化起见，我们只提供下面几个端口供用户选择使用：

• put_export：用户可以通过该端口调用put()、try_put()、can_put()。

• put_ap：调用了put方法写入的数据同时也会通过该端口的write()函数送出。

• get_peek_export：用户可以通过该端口调用get()、try_get()、can_get()、peek()、try_peek()、can_peek()。

• get_ap：调用了get和peek方法读出的数据也会通过该端口的write()函数送出。
  

在使用过程中，我们将以用户将uvm_tlm_fifo的功能类比于mailbox，而不同的地方在于uvm_tlm_fifo提供了各种端口供用户使用

Analysis Port

利用软件的设计模式之一观察者模式（observer pattern）来实现这一要求。observer pattern的核心在于用户需要记住，第一，这是从一个initiator端到多个target端的方式；第二，analysis port采取的是"push"模式，即从initiator端调用多个target端的write()函数来实现循环式的更新。

Analysis TLM FIFO

由于analysis端口的提出实现了一端到多端的传输，而一个新的数据缓存组件类uvm_tlm_analysis_fifo为用户们提供了可以搭配uvm_analysis_port的端口uvm_analysis_imp和write()函数。

UVM通信篇之六：同步通信元件（上）

在之前SV的章节中，我们为大家介绍了SV中用来做线程间同步的几种方法，它们分别是semaphore、event和mailbox。然而在UVM中，同步的不再只局限于同一个对象中的各个线程，而是还有各个组件之间的同步问题。一旦发生同步的要求发生在各个组件之间，这就要求组件之间通过某种可以同步的方法来实现。而考虑到UVM各个组件的封闭性原则，我们并不推荐通过层次索引的形式在组件中来索引公共的event或者semaphore。UVM为了解决封闭性的问题，定义了如下的类来满足组件之间的同步：

uvm_event，uvm_event_pool和uvm_event_callback

uvm_barrier, uvm_barrier_pool

如果用户无法确定在等待事件之前，uvm_event是否已经被trigger，那么用户还可以通过方法wait_ptrigger()和wait_ptrigger_data()来完成等待。这样即便在调用等待方法之前，事件已经被触发，方法仍然不会被阻塞，可以继续执行下去。

那在日常应用中，什么情况下会使用uvm_event呢？我们在之前的组件通信中已经提到过，组件之间的常规的数据流向是通过TLM通信方法实现的，比如sequencer与driver之间，或者monitor与scoreboard之间。然而有些时候，数据的传输的偶然触发的，并且需要立即响应，这个时候uvm_event就是得力的助手了。同时，uvm_event也解决了一个重要问题，那就是在一些uvm_object和uvm_component对象之间如果要发生同步，那么无法通过TLM传输，因为TLM传输必须是在组件（component）和组件之间进行的。譬如，在sequence与sequence之间要进行同步，或者sequence与driver之间要进行同步，都可以借助uvm_event来实现。