UVM end of test

UVM
, ,
1

Hi All,
What is the best way to end test case in UVM? I just send DUT configuration from my sequence.Depends on my configuration my driver drives the data,So it differs from test to test .I cant hard code the delay in my test. Because it varies from test to test.

2

In reply to kranthi445:

The UVM uses the objection mechanism to stop a test. This mechanism has to be implemented. If you do not so, the simulation stucks at time 0.

3

In reply to chr_sue:

If i do it immediately after seq.start my testcase ends after DUT configuration, By that time my driver wouldnt have started driving data.

4

In reply to kranthi445:
What defines the end of a test is very design specific. Once you have the definition, we can show you the best way to implement that in UVM. Without knowing more, I can only say the two most popular ways it:

  • Define your sequences so they block the sequence is finished. Sometimes this means not calling item_done until the driver is finished sending all the data. You can also add a dummy sequence if the driver can’t do that.
  • Put the objection in the scoreboard when there are no more outstanding items to compare. This may require a timeout if there is a problem - you don’t want the test running forever.
5

In reply to dave_59:

Thanks Dave.

I start configuration sequence in my test. Once the configuration is set driver starts driving the data. So my test ends immediately after my configuration is done, i need to delay it till my driver drives complete data and scoreboard compares it

my DUT is more similar to SPI example in Verification academy. In this example also i observed that tests are delayed by 100 ns after seq ends(Correct me if i am wrong)

6

In reply to kranthi445:

In reply to dave_59:
Thanks Dave.
I start configuration sequence in my test. Once the configuration is set driver starts driving the data. So my test ends immediately after my configuration is done, i need to delay it till my driver drives complete data and scoreboard compares it
my DUT is more similar to SPI example in Verification academy. In this example also i observed that tests are delayed by 100 ns after seq ends(Correct me if i am wrong)

I usually use a method name “Inactivity Monitor” which means: I monitor the interface signals to make sure there is no traffic anymore and wait more few time (a watchdog timer starts to count) before actually drop objection then simulation is finished.

7

In reply to cuonghl:

Thanks Chris for the answer.

I have one doubt, will it work if i want to do back to back transfers with delay between them.

8

In reply to kranthi445:

In reply to cuonghl:
Thanks Chris for the answer.
I have one doubt, will it work if i want to do back to back transfers with delay between them.

Yes, it will work, of course. Here is the suggestion flow:

  • Set up a watchdog timer with specified value (such as xxx clock cycles, it can be configured by plusarg or config_db)
  • If you see a transaction in interface, you reset the watchdog timer to count from begining, otherwise the watchdog will count down.

The simulation will be finished if the watchdog timer expired (count from xxx cyle to zero).
I think that is very common way to handle your case.

9

In reply to kranthi445:

In reply to cuonghl:
I have one doubt, will it work if i want to do back to back transfers with delay between them.

If you are following the UVM approach it works always fine. My understanding is your configuarion sequence should be followed by an operational sequence. The driver is active until the protocol in your driver has been completed and sends item_done back to the sequencer. This will generate the next sequence item.
Finally you do not need things like a watchdog mechanism. This makes your life only complicated.

10

In reply to dave_59:

In reply to kranthi445:
What defines the end of a test is very design specific. Once you have the definition, we can show you the best way to implement that in UVM. Without knowing more, I can only say the two most popular ways it:

  • Define your sequences so they block the sequence is finished. Sometimes this means not calling item_done until the driver is finished sending all the data. You can also add a dummy sequence if the driver can’t do that.

Hi Dave,
I do not understand how the end of test is different for each design (may be it is my ignorance). For any block/testbench you send a bunch of transactions and you wait for them to come out of the DUT or you timeout.
Also, can you please explain in a bit more detail, possibly with a code snippet of your 1st approach
Thanks
Madhu