UVM for ESL DUT verification

[mivan]

Hello all,

 

How would one go about leveraging UVM for ES level DUT verification? Most of the stuff from RTL still applies but how do we

correctly use the driver and monitor if the DUT does not have signals, but has TLM ports/sockets. The UVM states that one agent

should be used per interface, but the problem on the ESL is that there are no signals so how do we monitor TLM ports/sockets with

the monitor, while the driver stimulates the DUT? How do we connect ports/exports to the driver, monitor and the DUT simultaneously?

A solution without using analysis ports would be great. I've included an image for easier reference.

 

I guess that on ES level the monitor and driver are redundant, but then the sequencer would have to send packets to a checker and the

DUT simultaneously, which would require either two ports or an analysis port. Another option would be to keep everything the same as

in the image and have two ports, one from the driver to the DUT, and one from the driver to the monitor and send packets simultaneously.

Please state your thoughts on this.

 

[David Black]

NOTE: In the following, I am assuming a SystemC ES level model. Also, I do not presume to discuss how SystemVerilog and SystemC interoperate as that is the task of the MLWG. In fact, whether not any or all components are in one language domain or the other is somewhat independent of this discussion.
 
Seems to me that TLM simplifies the driver and monitor because:
 
1. The driver is supposed to deliver transactions. If it is connected as an initiator to an ES level DUT, then the job of the driver is to translate the sequence item into DUT transactions, which might be 1:1. If it is connected as a target to the ES level DUT, then it's responsibility is to supply the response with directions from the sequence item, and possibly deliver a sequence item response back to the sequencer.
 
2. The monitor should simply snatch copies of the transactions.
 
The one problem I see is that with RTL, the SystemVerilog interface can be monitored and driven fairly easily, but for transactions it may be the "TLM interface" needs to be a TLM module that provides two TLM sockets. One TLM initiator socket for the monitor, and a separate socket (initiator or target depending on the DUT side). This ES-interface would be essentially transparent between the driver and DUT, while invisibly grabbing copies of transactions to deliver for the monitor. The driver and monitor could simply implement the base protocol (if AT).

 

 

Details of any bus specific aspects would probably need to be handled in the interface; although, we could have a debate on whether to push that to the driver. However, pushing it to the driver would complicate matters more than probably necessary.
 
I imagine there will situations where the TLM monitor/driver pair are connected to sc_signal<T>'s since not all TLM activity is restricted to sockets. For example, interrupts or reset. This would be a more traditional monitor/driver connection, but still should involve a TLM interface module.

[mivan]

Thank you David for the thorough reply.

[tudor.timi]

I've done some work on the topic and for the TLM interface David is describing we basically had an interconnect component that sent the item flowing through it out an analysis port connected to the monitor. The initiator socket was connected to the DUT and the target socket to the driver. You just have to take care when you send the item through the aport (basically when the protocol steps are over).