In reply to TingWang:
I’m used to the following:
a) driver (configures to master or slave)
b) monitor (does nothing but watching bus; it doesn’t know/care if driver is master or slave)
Master-driver example would be: I2C or SPI initiating a transaction.
Slave-driver example would be: responding to a I2C or SPI transaction.
The monitor is used in all cases, and is the only thing used in cases where one is monitoring a bus internal to the DUV.
An example would be:
One has built block-level testbenches for blocks A, B, and C. Complete with predictors for each.
One then builds a chip from blocks A, B, C. There are busses internal to the chip that go between A/B/C. One needs monitors on those internal busses (and the monitor is neither master nor slave, since master is driven by RTL, as well as slave).
But I think we are just differing on how to partition the functionality.