I have a master and slave style protocol, where the communication is full duplex with different wires.
That means master can send data and in parallel it can receive data from slave. And of course the slave can send data based on master request, together with its other data sending. Usually in normal mode slave constantly measures and sends data to master.
May question is how to model Slave using UVM.
I want to use 1 agent to keep my code simple. But the issue is driver- sequence communication.
When my UVC is slave, than UVC should sends it data and in parallel it should track the master. And if master sends request slave should know this in parallel.
I think this cannot be done this using REQ, RSP mechanism, like make slave2master as REQ and master2slave as RSP.
But this will not work because when sequence sends REQ at the same time master may send frame i.e. driver should send RSP to sequence, interrupting REQ. Which is wrong in point of the protocol
You should run in the drivers run_phase 2 processes in a fork/join, 1 for driving the data to the slave and the 2nd to receive the data coming from the slave.
I think it wont work
assume driver got the data from the slave while driving the data.
Than how driver can send that data to sequence?
RSP will not work as REQ still in process and takes time to finish.
Which scenario do you have? Is it in-order, pipelined or out-of-order.
If you are driving some thing then the rsp you are observing is initiated by a privious drive and not fron the actual one.
But the thing is in my case there is a req i.e. Sequence->driver and in parallel I need Driver->Sequence communication.
In UVM way only RSP carries transaction from Driver->Sequence, but this does not work for my case. Because RSP is a response of previous REQ, which means first REQ and than RSP. I need in parallel
Other option can be that monitor tracks the slave and when slave has some info to send, monitor generates transaction and broadcast by analyses port.
And sequence get that info from that analyses port.
How do you get a rsp earlier than the req was sent? Sounds a little bit magic.
BTW you cannot send transaction from a monitor to a sequence through an analysis port. But you can sent it to the sequencer. Finally this is complicated compared to the solution with sequencer/driver.
You can use analysis ports only with components, existing permanently. A sequence has a limited lifetime.
How do you get a rsp without a req? How is this working?
The drivers run_phase should look like this:
task run_phase (uvm_phase phase);
fork
forever begin
seq_item_port.get(req);
// dive the req
end
forever begin
// collect your rsp
seq_item_port.put(rsp);
end
join
endtask
Your code looks interesting.
And how to be when req is done, but rsp is still not.
Imagine the case driver service the req and send seq_item_port.put(rsp) to tell the sequence that req is done.
And than driver cannot collect rsp any more.
May I ask you please share how looks like the code in sequence?
I expect again in the sequence 2 parallel process - 1 send Req and another gets RSP.
And I agree about sequence stuff, that’s why I need forum opinion.
task body();
start_item(req);
req.randomize(); // naybe you have to add constraints
finish_item(req);
get_response(rsp);
endtask
Maintaining the driver code is just easy.
Working with req and rsp means there is always a rsp belonging to a certain req. This defined by the seq_item_id.
How this is working in your environemnt I do not know.
Well I think in the sequence the rsp always comes after req. It is not possible to have get_responce(rsp) than finish_item(req). It is not supported by UVM.
So that means driver cannot send data to sequence, it can only respond to sequence requests.
Now I am thinking to update sequencer which can take transactions from driver and send to sequence in separate analyses port.
I believe I did not fully understand what your requirements are. Could you please share some more information, a drawing or some structural code through my email christoph@christoph-suehnel.de
