Hi,
I have a scenario where I have to make UVM agent only to drive data to memory while control signals (write_enable and write_address) are given by DUT. These control signals are generated as per an algorithm. I am thinking to model DUT behavior in the system Verilog interface (to generate write_enable) and use in the driver run task. When data comes to the driver through sequencer_item_port, the driver will wait for this write_enable of the interface and then drive data. The write_enable generated in interface is also used to capture data in monitor (It is expected that this agent will become passive later). Is this approach anything against UVM methodology? Am I missing any useful features of UVM to achieve this?
In reply to santhoshr30:
You have not described your situation very clearly. First you say the write_enable is given by the DUT. (I assume that means the DUT is driving the write_enable) And then you say you need to generate the write_enable in the SystemVerilog interface. And is the memory part of the BFM, or in another agent. You may want to look at : Sequences/Slave | Verification Academy
Hi Dave,
My requirement is that the memory data agent should put data on the same clock edge when the RTL (DUT) generate write enable. Since there is no flexibility to provide data on a later clock edges, I am mimicking DUT functionality in interface. Hence the interface also generates write enables as DUT and these are used by driver and monitor. My thoughts behind choosing interface for this are:
1. The monitor also should know when to capture the data (especially when the agent is passive).
2. Similarly the driver should know when to drive the data.
3. Since both the driver and monitor dependent on write enable, I have chosen interface to generate this.
4. By mimicking DUT behavior, I am not relying on write enable generated by DUT. Hence there is a scope to detect misbehavior of DUT for write enable also.
5. The interface works in active region same as DUT and hence there wouldn’t be any possibility for race condition.
My understanding is that “slave sequence” link suggested by you doesn’t work for this requirement as I have to respond on the same clock edge. Please comment.
It sounds confusing and dangerous what you are describing regarding the write enable. In reasonable cases the write_enable will be genearted by the testbench (master functionality).
The slave is normally responding on a control signal, i.e first the control signal comes and afterwards data are put on the bus. Maybe you have to work on both clock edges. Master is synchronized on the rising edge and the slave on the falling edge.
How about using the respond option from driver. Like you can start the sequenceItem from your sequence, and wait for driver respond transaction.
When DUT write_enable become high, driver will create a respond ans send it to corrsponding sequence. After that the sequence will randomize the transaction and send to driver.