UVM里为什么到处弄个monitor？

有没有用UVM的筒子啊？问个问题，为什么UVM里到处是monitor啊？
拿总线做例子，master端从sequencer发出transaction，经driver送到bus，然后再由monitor送到sb。slave则是driver和monitor同时收到tr,driver做出response，monitor将tr上送到sb。slave这边好理解，master这边为什么要经过monitor再绕回来呢？如果sequencer在送到driver的时候直接送到sb不更好吗？
另外其实slave这边把driver和monitor合在一起作为一个大的monitor也可以啊。

monitor原则上是抓bus上的一些数据，抓transaction也是可以的吧。
monitor还可以放function coverage相关的代码。
忘记什么地方有说过了，不要在driver里面做monitor的事情，虽然这样也是可以的。。。。。或许还更直观些。

这里的master monitor观测的是经过master打包好的协议输出流，负责验证master功能正确

你这问题和uvm无关啊
验证环境都是这么做的
我用vmm

monitor抓的，更真实。当然如果非得直接给SB，心里足够清楚的话，也不会出问题。

主要是为了在从block-level TB转到system-level TB的时候monitor可以复用，因为在system-level TB的时候，大部分block的激励都来自于真正的RTL module了，这就意味着它们的sequencer/driver都是inactive的了，而这时候monitor还是得开着，以抓取这一interface上的transaction然后送给scoreboard做比对。当然这样的前提是在system-level TB的时候需要验证block的function。
Anyway，功能划分较细还是好处不少的，主要是结构清晰、复用度高。

原来是为了重用。。。
难怪肯绕个圈子回来。。。