I want to model a command-completion type agent. This is what I have:
Two separate command interfaces with different signals ( and hence different items), but only one corresponding completion interface.
Each cmd. interface has a output valid signal, and an input ready signal. Cmds could be driven in parallel on both cmd interfaces, but only one cmd. will be accepted at a time i.e. both interfaces could drive their cmds by asserting valid simultaneously, but only one would get a ready signal back. Also, there is a common completion interface, to drive back the corresponding completion for either of the cmds, and cpl’s could be issued out of order.
I am guessing there would be some kind of a selector bit to distinguish which of the command interface the completion interface is responding to. You can use this signal to model the driver.
If you are using 2 different agents you have to synchronize them with your completion interface.
But I do not understand why you are using 3 different agents, 2 for driving and 1 for completion.
You can model this with one agent. But it depends on what the procedure is in the DUT to accept the cmd. Does this happen randomly?
I don’t know if I clearly understand the problem. Let’s see.
Two separate command interfaces with different signals ( and hence different items)
…
Each cmd. interface has a output valid signal, and an input ready signal.
…
both interfaces could drive their cmds by asserting valid simultaneously, but only one would get a ready signal back
As it seems to me you have two independent interfaces there. For each interface, the item is just done (i.e. successfully driven on driver OR successfully captured on monitor) when the ready signal is set.
Now, what exactly is that completion interface?
there is a common completion interface, to drive back the corresponding completion for either of the cmds
Are you talking about sending a RSP(response) item back to the sequencer? Corresponding to the REQ(request) item issued before?
Or is it like a third interface?