Dear All,
i have been running a lengthy simulation for quite some time now. I send in a very large amount of data, let the DUT process this data and output the contents. One interface agent drives data in and the other is in passive mode and uses the monitor to send objects to a subscriber that outputs files.
To complete the picture, a comparison of the output is done out with UVM. Its not important why the comparison is done this way for the point of this question.
At present i need to add a # wait in my test to allow the simulation to run and wait for the output data to be picked up by the monitor. I have looked at other blogs and options from the likes of Tudor but i am still a little stuck on my options.
I am not running a scoreboard and even if i was i am not certain of the drain time to allow for data to process. If i was to use the drain time would this mean i need to raise and drop objections in my monitor? I am making the assumption that drain time is the maximum amount of time to wait when there are no objections raised before finishing the simulation. So i would have to estimate when i think output data will appear, or thinking of some way to detect what the last piece of data is.
Can anyone advise an alternative method? I don’t like putting time in my tests because at the moment it is a finger in the air time.
Thanks!
You’re correct, drain time is the amount of time the simulation will still run after all objections have been dropped. A drain time is set to allow for the DUT to process the last piece of stimulus you sent it. The flow is like this:
- raise objection
- drive stimulus
- drop ojection
- wait for drain time
- stop
You set the drain time based on knowledge about the DUT. You should be able to know about how long it takes for a last packet/transaction/operation/etc. to finish, either from the specification or from talking to your designers.
You don’t need to start raising objections inside your monitor, you could just raise a big objection before you start your sequence (on the active agent) and drop it after.
P.S. Thanks for reading my blog! :)
In reply to Tudor Timi:
Ahh the man himself! The blog is good, very informative!
Yes i understand the premise of objections, where and when to raise and drop them. At the moment i have objections in the sequences used in my test and inside the test as well.
I have also set a drain time, but i suspect i will have to play about with this value to get it right. Do you know the default units? Are these simulator dependent or can i specify e.g. 20ms?
task block_E_base_test_vc::run_phase(uvm_phase phase);
phase.phase_done.set_drain_time(this, 50ms);
endtask
I guess the problem i have is that my test only contains sequences for the driving interface, the output interfaces have nothing in the test to control it.
If i set a drain time then i need my output interface monitor to raise an objection when it is capturing data on the bus for the drain time to make sense and keep the test running. Otherwise the test will end because there are no raised objections.
In reply to Phill_Ferg:
Ideally you should only have to raise an objection in your top level test, and possibly in your scoreboard. It is important to keep the number of times you raise an lower objections to a minimum as there is a lot of overhead in that protocol.
The value passed to set_drain_time will use the timescale of whatever the UVM package was compiled with -it does not matter what your code was compiled with. Unless you can guarantee that they both have the same timescale, you should not use a time literal
This is a Verilog gotcha that the UVM developers should have dealt with, but have not fixed yet.
In reply to dave_59:
Let’s do a little thought experiment. Let’s say that you do implement objections on your output interface’s monitor. Let’s also say that you set a drain time of value 5 (whatever units, this isn’t important). What would happen if you finish your stimulus, drop your test objections and the DUT would want to do some output activity in 10 time units? Well, let’s draw it:
1 2 3 4 5 6 7 8 9 10
- x - x - x - x - x - x - x - x - x - x -
^ ^ ^
| | |
stimulus drain output
ends time mon
here elapsed would
here raise obj here
Let’s say that the stimulus ends at time 2 (a silly number, but it’s easier to draw). This means that the drain time would elapse at time 7 and the simulation would just stop there. You wouldn’t even get to catch the output transaction that starts at 10, even though the monitor raises objections. What I’m trying to show here is that having objections on the other interface won’t mean that you don’t have to think about a reasonable value for your drain time. And if you already know how big to set your drain time to avoid the situation I described above, you don’t even need to add objections to the output monitor.
In reply to Tudor Timi:
Dave,
agreed - i don’t have objections in every sequence, but i have found that it useful to have them in a few top level sequences that are forked in the top level test. It ensures that all of the stimulus is applied.
Good information on the set_drain_time timescale. That begs the question - where do i find out what the UVM package was compiled with? I am using questa 10.3d so i am using the pre-complied code with the simulator.
Tudor,
great example! I do fundamentally agree with you. I do need to set a reasonable value for my drain time. In my case it will be a really big number that is related to processing latency(see below) or a smaller number that is related to period of activity on my output bus if i use an objection in a monitor.
This falls in line with Daves comments on the overheads of objections. Ideally i do not want my monitor to raise objections.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
- x - x - x - x - x - x - x - x - x - x - x - x - x - x - x - x - x - x - x - x -
^ ^ ^ ^ ^ ^ ^
| | | | | | |
stimulus output output output output final |
ends output |
drain time
elapsed
In reply to Phill_Ferg:
One last point from me and I will forever hold my peace. Even though it isn’t recommended to start raising objections like crazy, if this is your only viable option, I’d say you could take the performance hit and just do it. One measly monitor raising objections shouldn’t slow your simulation down too much. Guidelines aren’t “one size fits all” rules, I always consider their merits on the task at hand.