For a while I have been annoyed that UVM is inconsistent in the way responses are passed back through the sequencer, but maybe I am missing something obvious?
Let me try to explain my problem
I have highly pipelined agent - where the driver must drive transactions back to back - without waiting for response data.
but when that data comes it must be passed back to the sequence that initiated the transaction.
un fortunately the responses come out of order!
A way of doing this, is by using the get_response() in the sequence.
unfortunately the monitor does not have access to the response FIFO in the sequencer, so the put() must be called from the driver.
and this is where I find that UVM is inconsistent at best.
The UVM methodology has a clear boundary between driver and monitor tasks.
the driver drives transactions on the pins,
the monitor convert from pin wiggles into transactions.
the monitor also passes the transactions on to a scoreboard and any other subscriber that needs the info - except the sequence!
that has to come from the driver.
so now I am forced to make the driver a subscriber of my monitor to be able to pass it to the correct sequence.
I want to note here that I have N sequences that starts items on my sequencer in parallel!
is there a better way of doing this?
if UVM where to be consistent - there should be a build in tlm port in the driver - where the monitor could get the items and then the monitor would do the response matching and the put to the sequence response fifo!
As you mentioned, the response is passed from driver using item_done(rsp)/put(rsp) and sequencer fetches those using get_response(rsp).
Monitor fetches trans on pin level and it does transfer of the trans to SB/subscriber based on need.
But, rsp and req of the driver are two different entities and they are not same. Monitor implements run_phase to compose “req” transaction, and the driver sends “rsp” which contains modified sequence_item properties to sequence via sequencer which may be used by sequence. So, its not duty of sequencer to send those to monitor.
Also, the rsp are out of order due to arbitration and processing of multiple sequence items in parallel.
You can make use of TLM analysis port “rsp_port” "of the driver to get the responses into your desired component.
m_driver.rsp_port.connect(m_sequencer.rsp_export);
I think there is a misunderstanding,
I never asked for the sequencer to send anything to the monitor, IMO it would make more sense if the monitor used the put(), not the driver.
because now you need to get pin level transactions from monitor to driver.
which is contradicting the purpose of the driver!
an example is a memory read.
the driver, drives the request - the monitor records the reponse data.
now this is passed to the driver to match with the request - copy the underlying ID using set_id_info() and the passed to the sequencer using put()
a more natural way,(and more uvm like) would have been the driver sends a request,
and forwards the item to the monitor (which will already record the request from the pins),
the monitor copies the underlying id using set_id_info().
when the response comes it adds it to the original request and send it to the sequencer using put.
now we have separated the behavior of monitor/driver - such that they are uni-directional.
driver send stuff downstream - monitor sends stuff upstream.
Anyway I don’t think that UVM currently allows for this.
I was just looking for an alternate way than my 1st described way