用uvm验证半双工的通信模块，怎样划分driver和monitor的职能比较好
我的理解是，一般来说，驱动dut的东西放在driver里，监测dut的东西放在monitor里。
但一次iic通信，比如master收信，要先发送再接收，而且数据都在sda这根线上。
如果严格按driver和monitor区分的话，势必driver和monitor都要数scl，判断目前的收发状态，很麻烦，感觉好好的一次通信硬生生地拆成了两部分来做。
相反，如果把收发的过程全放在driver里，写代码会方便很多，但这似乎违反了driver和monitor的划分准则。
想问下这种情况下大家一般会怎样划分driver和monitor?
以发数据就是driver为原则。
那可以把monitor的工作合并到driver里，也就是driver既发数据也收数据吗?
检测放到monitor比较好
3#的做法比较正确。
我补充一下，driver和monitor是功能层面的划分，代码上完全可以统一，只是在使用中定义一下，比如config或者工厂模式，如果编程能力不太强，分开也未尝不可，但对概念的理解不可死板。
3楼的方法，降低了uvc的重用性。在passive mode下，bfm/driver被disable，monitor就无法得到数据，使得uvc无法被使用。
我的想法是，尽量不要将二者合一。如果你非常确定利用monitor可以将数据传给bfm//driver的话，可以试着用monitor来接收。
UVM的手册中似乎没有说到passive模式下，agent中driver被disable，monitor就不能用了的说法啊，这理论没见过啊！
代码合一，并不代表例化的是一个部件啊，完全是两个部件，不存在上面的说法吧！
这是uvm的一个基本原则。
passive模式下，bfm/driver应该是不存在的，不仅仅是被disable。
passive的意思是该uvc对总线的transaction没有响应，这个和slave不是一个意思： slave是可以响应请求的。
假设你的uvc用在top level，只是监测总线上数据和协议的正确性，你为什么要用到driver?
此时的监测任务就是monitor的，和driver以及DUT没有关系。
从testbench的角度，一个简单的monitor也使得结构更加清楚。
所以，不要让monitor依赖于driver的信息。
呃，不好意思打断一下，我感觉6#有点跑题了。
如果单单是监测的话，那肯定要放在monitor里，我也知道。
我这里的问题是，比方说UVM搭的iic master，发8个bit数据，要收1个bit的ack，并且我想要的效果是收到ack为低的情况下，再发下8个bit数据。
如果发8个bit数据用driver发，收1个bit ack用monitor监测，那势必driver和monitor之间必须有数据交互，否则driver不知道ack的值。
我想问的是，像这样收1个bit的ack和发8个bit数据属于一个不可拆分的原子过程，那收1个bit的ack能否放到driver里去收呢?因为我觉得，如果可以的话，似乎违反了driver只发不收的原则。
我并不是说，想无缘无故地把monitor的工作全放到driver里，或者把driver的工作全放到monitor里……
sequencer里面的sequence只负责TLM级任务的处理，主要是transaction的产生。而driver是pin wiggle的主要component。所以属于一个transaction里面的pin wiggle都应该包括在driver里面，不论是input or output.
谢谢！看来我对UVM的理解还很肤浅！
保持结构，繁冗的枝叶可以单独择出来