Overview:
This is a general “how to ‘properly’ design an agent” question.
In a lot of the UVM training material I’ve seen, they say not to pass the driver’s transaction to a predictor for ‘processing’ but instead, pass what the monitor sees driven on the bus interface, but they don’t show examples of it in practice.
I assume it’s because the interface could be configured for something like error injection, meaning the driver’s transaction doesn’t match what actually went on the bus. Unfortunately, this requires a dual-monitor concept (one for the incoming data, one for the outgoing data). Most drivers I’ve seen send transactions to the interface which simply outputs the transaction data. Most monitors I see capture ‘incoming’ data as transactions and don’t pay attention to ‘outgoing’ data. I’m thinking of buses that have separate write and read channels…
Questions:
-
For ‘best practices’, is every monitor supposed to implement this dual-monitor concept, one for what’s driven and one for what’s received?
-
In it usually done this way or is it more common to add control fields to the transaction that the interface uses to enable error injection, etc. Thus, the transaction always matches what’s on the bus and the dual-monitor concept is un-necessary.
-
Is it only applicable to some busses or protocols? E.g., ones with separate write channels or not. What busses/protocols would be examples of using dual-monitor vs. not?
Thanks for the help in understanding this.