In reply to cgales:
You should NEVER have any interface or other type of monitor connected to a sequencer or virtual sequencer. A sequence should only generate stimulus based on random generation or a response received from the connected driver.
Hi cgales,
Does this mean that a response should only be received from the driver?
Can you explain further what are the disadvantages of having interface or monitor connected to a sequencer? I have that kind of architecture before, and it works fine. I don’t know maybe it only works in my situation but not in general situations. So that’s why I want to know what could be the disadvantages of that.
Regarding using a driver to pass the response to a sequencer, the disadvantage I see here is that the code to sample the response should be present on both the driver and the monitor… For example, let’s say the protocol is SPI. For a read command, the monitor needs to sample the read data, while the driver also needs to sample the read data. So you need to write two codes for sampling the read data… Managing two sets of codes can be time consuming. Usually these two codes are not identical since the driver and the monitor operates differently. So you cannot create one function for the sampling of read data then use it in both the driver and the monitor.
Kindly advice what could be the disadvantages of using a monitor to pass the response to the sequencer.
Regards,
Reuben