In our testbench, I am seeing a case where we need a driver + monitor in our agent but not the sequencer/sequences.
The driver does not drive any data to the DUT but it is needed to react on the interface (e.g. flow control).
The monitor is used to collect the data and send to scoreboard.
Since no data is driven to the DUT, there are no sequences nor any sequencers.
I am curious if it normal to have agents without sequencers as many documents don’t talk about this case.
In case, you do not intend to drive any Data to the DUT, what is the purpose of having a driver.
Instead, you can replace the driver with an object directly extended from component and ensure it responds to the DUT.
As per my knowledge, I doubt if you can have a driver without sequencer.
In reply to verif_learner:
I do not know your application, but in most casess a reactive agent is reacting with a certain sequence on the request from the DUT.
How does your reaction look like?
In reply to chr_sue:
Ashith, chr_sue,
The driver does drive DUT signal though not any data per-se.
The driver control the flow control or back pressure on the interface.
Currently, the driver randomly selects the window where it should flow control.
In future, the randomization intervals may come from config objects.
As you can see, there is no sequence item that the driver needs to use.
In reply to verif_learner:
What do you men with ‘control the flow control or back pressure’. Does it observe something or provides actions.
If it acts it needs instruction how to do this and maybe it need certain data.
Could you please explain or show a code fragment.
In reply to chr_sue:
Hi, i too have a similar doubt, my monitor is monitoring certain frames of data and on the basis of this, i wanted to generate an interrupt. so for this i could trigger events in monitor and wait for it in a driver. so my drivers’s soul purpose is to drive the interrupt signal based on monitors reception. in this case its not necessary to have a sequencer, know?!
is there any other way if this cannot be used?
In reply to adharshh:
I have a different understanding of the interrupt. The interrupt itself comes out the DUT and can be recognized by the driver. The driver sends bach a response to the sequencer/sequence. The sequence running on the sequencer will be locked/stopped and the sequencer can execute an interrupt sequence. After completing this the operational sequence can continue.
In reply to chr_sue:
i am trying to develop a VIP for uart, So uart VIP after receptions of frames, it should mimic the rtl and raise some kind of interrupt signal right. So for this scenario, can my previous thread be valid?
In reply to adharshh:
Back to your first question. Your sequencer/driver connection is bidirectional. You can put back a response to the sequencer/sequence and decide which sequence should be started.
You can start a secific sequence which will cause an interrupt. Or you can start a sequence which perform an interrupt routine. There is no question running a driver without a sequencer.
In reply to chr_sue:
The scenario i am working is neither of the two u pointed. my Uart rtl is transmitting some frame to my VIP. say its working in fifo mode and the interrupt trigger is configured at say on receiving 4 frames.
Here my VIP will be having a receiver agent, the frames are sampled by my receiver agent monitor and after getting all the four frames, now i wish to assert an interrupt. which i am intending to drive using event triggering. i will trigger an event in my monitor after completing my reception and and in my driver i will be waiting for this event to occur. as soon as i get the event triggered in monitor, i will drive interrupt_out from my VIP as 1.
In reply to adharshh:
It’s confusing to me what you are aying. I understood you are developing UART VIP with master and slave functionality. In the verification scenario your DUT is either a master or a slave. If the DUT is a master your VIP has to be configured as slave and vica versa. But you’ll not use the master and slave functionality at the same time. Correct?
In reply to chr_sue:
So, here’s my thing.
UART signals-tx_out,rx_in and an interrupt(int_o). DUT Register configurations will be done separately using some other master VIP (like APB,Wishbone…etc). As of me, i am left with uart signals and my uart VIP will take care of this. UART as we know can also work in a full duplex manner. Please let me know, when u say master/Slave-DUT, does that mean that the uart will be either transmitting or receiving frames(like halfduplex way?).
In reply to adharshh:
Mabe master/slave is not correct. What I mean is the transmit and receive mode. Full or have duplex does not matter.
In reply to chr_sue:
so what i consider is that the uart can both transmit and receive at the same time.,
So in my VIP i am creating two agents. one agent drives frames onto the tx_out line to the DUT and whatever the DUT is transmitting , i will make use of the receiver agent monitor to sample the frames and extract data… So as the Specification implies , on receiveing a set of frames i need to raise an interrupt. so since this interrupt i am talking about is generated because of the frames i received in my VIP by the receiver agent, i will use some events(triggered in the monitor) and the triggered events are waited for in the receiver agent driver.and the rx_driver will drive the interrupts into the interface!
so as u can see i didnt take a sequencer or have any sequences for the driver. Is this way a fine way to do it?
In reply to adharshh:
OK, I understood. I have 2 recommendations:
(1) go ahead as you are describing. UVM does not force you to be compliant.
(2) rework your architecture, having only 1 agent driving the transmir line and observing the transmit and receive line. Then the interrupt line is in the same agent. I do not see any need for 2 agents.
In reply to chr_sue:
My requirement would be as such, it should be in a configurable way of acting as a transmitter only, receiver only or with both transmitter and receiver parts. that’s y i thought of having them as separate agents.
In reply to adharshh:
This requirement is met also with 1 agent. This simplifies your testbench when supporting additional interfaces like WB.