Best way to communicate a control signal from a monitor to the scoreboard

[wavy]

Hello,

I am new to UVM and am looking for a good way to send a control signal from the monitor to the scoreboard. Based on signals in the monitor virtual interface to DUT, I need to disable and flush the scoreboard or re-enable the scoreboard. The disable/re-enable signal is asynchronous the the transactions going from the monitor to the scoreboard.

This seems like a good use for an event, but I can' find an example of how to do this. I also thought of an analysis port sending the 1 signal to the scoreboard.

Thanks,

Wavy

[phuynh]

Hi Wavy,

Using the analysis port to send a message to the scoreboard is a better way to do it; it is explicit and more flexible.

Phu

[Erling]

This seems like a good use for an event, but I can' find an example of how to do this. I also thought of an analysis port sending the 1 signal to the scoreboard.

An event seems to be a good choice in this case, especially if there is no data to communicate with the signal change. I would use an uvm_event and not a plain event, though. That way you'll be able to extend it, get hold of the event name, which may be practical for debug prints etc, and there will be only one synchronization object allocated for the event.

Events can be dealt with in much the same way as ports. If you wanted to use an analysis port, you would usually declare it public in the monitor, new it in the constructor and have the environment connect phase connect the port to a public analysis imp in the scoreboard, and that imp must have been new'ed already by the scoreboard. The procedure for an event is similar; you would declare the event public in the monitor, new it in the constructor (or new it with an initializer or assign some other event allocated elsewhere to it), and then, in the connect phase, have the environment assign the event to a public scoreboard event. In other words, the connect of ports corresponds to assignment of events, and the event is new'ed by the event source only, i.e there isn't a new operation in both ends as is the case with a port connection.

Apropos extending events; if you choose to use uvm_event, you may want extend it with a wait method taking a timeout and perhaps a severity parameter. This is a nice thing to have, because if your scoreboard just sits there forever waiting for the event, and the designer checks in a mistake and the event never happens, he will come back to you and say the testbench didn't the detect the problem. If you know that certain things shall always happen after a reasonable time after applying some stimuli, you could post events when things are completed or whatever, and await them in sequences with a timeout before proceeding with the scenario. That way the testbench would not hang silently forever, but may point the designer in the right direction.

Erling