inidication of all sequence done

[wilsony]

I'm looking for a flag/indication of all sequences are done, and testbench is entertaining drain time for all outstanding transactions/packets to exit DUT. The usage of this flag/indication is release all backpressure from testbench slave model.

i.e. the slave model backpressure the DUT's output throughout simulation, but stop backpressuring when testbench reaches drain time.

Whats the best way to do so?

Thanks!

[janick]

The detailed mechanism will depend on how you start your sequences, but that's what the main_phase objection is for.

Once it is dropped, the schedule moves into the drain time and you can then instruct your slave model to stop applying back-pressure.

[wilsony]

Thanks Janick for the reply.

There are 2 points you raised that caught my interest:

1) main_phase (vs run_phase)

2) "the schedule moves into the drain time"

let me explain:

1) if all sequences start on main_phase, I'm happy. My slave model can do the following in shutdown_phase:

a) stop applying backpressure, then

raise_objection, wait for some drain time, then drop_objection, or

c) set_drain_time for this shutdown phase

however.. due to the "flexibility" of uvm, run_phase could be used to start sequence instead of main_phase. As testbench env developer, I'll need to create an env flexible enough to handle both cases (seq starts from main_phase or run_phase) .

That brings me to the second point:

2) "the schedule moves into the drain time": how can slave model detects such condition, regardless of sequences started on main_phase or run_phase. Also, slave model needs the "ultimate" drain time. i.e. not the case if drain time started, but new sequence reset the drain time.

Any suggestions are welcomed. Thanks!

[IChip]

As i known, every sequence has a variable called starting_phase, in which a sequence is started.

I'm not sure this could hep. Maybe you can try to use this variable to indicate sequence is started from main_phase or from run_phase.

[janick]

As testbench env developer, I'll need to create an env flexible enough to handle both cases (seq starts from main_phase or run_phase)

As a testbench environment developer, you are the one deciding how/when sequences are started. So you decide on one overall test phasing strategy to go through the lifecycle of a test and go with it. As a VIP developer, you would be correct and need to be able to handle both cases (actually, you need to handle any cases, hence why VIPs should not be phase-aware).

So that answers your second question: the slaves DOES NOT detect the transition to the shutdown phase. Rather, your environment (once it reaches the shutdown phase) instructs the slave to stop applying back pressure.

[wilsony]

testbench env developer, vip developer...we still want to build a clean and reusable dv env.

Let's say I'm VIP developer, is there a clean solution to this real problem?

[mastrick]

One clean solution is for the VIP developer to provide sequences/tasks but not to start any of them. The env developer then starts the desired sequences/tasks in the desired phases.

[wilsony]

VIP developer defines a task for env developer to call seems reasonable. One note: in this case, task is not used to _start_ the sequence, more for _stop_ the sequence.

It would be nice to have a global indication (main_phase/shutdown_phase is perfect for it, if there's no run_phase to complicate the matter): all you components out there, we are entering quiesce time... do whatever you need to do now.

[janick]

all you components out there, we are entering quiesce time... do whatever you need to do now.

But that is an *environment* task, not a component task. For example, a bus master would not do anything different during the shutdown period. In fact, it has to operate 100% normally because the shutdown period may involved reading some registers or DMA channels.

[mastrick]

We take a middle ground for our internal IP. Some of the associated sequences have an "ending_phase" config value (so the value can be controlled from the environment) and upon an event emitted by the associated sequencer when phase_ready_to_end, a sequence will terminate itself gracefully. The environment is fully in charge of determining when the quiesce time begins, but the IP does its own cleanup.

[wilsony]

Thanks mastrick.

I ended doing something similar. Environment creates a "my_env" class. Inside there's a flag "start_quiesce" which is controlled by env. Any internal IP out there can grab this class from uvm_resource_db if needed, and implement its all code during quiesce time.