Difference between `ovm_do_with & `apply_send_with

OVM
1

Hi

I have created a sequence & a scenario which consists of ovm_do_with & apply_send_with calls along with set_config_int like:

Sequence:
repeat(k)
begin
set_config_int(“*”,“ENABLE”,1);
ovm_do_with(trans1,addr ==laddr); set_config_int("*","ENABLE",0); ovm_do_with(trans2,addr ==laddr);
end

Scenario:
repeat(k)
begin
set_config_int(“*”,“ENABLE”,1);
apply_send_with(trans1,trans1.addr ==laddr); set_config_int("*","ENABLE",0); apply_send_with(trans2,trans2.addr ==laddr);
end

My intention here is to use the Inline Constraint capability to constraint the “addr” field of each transaction with a local “laddr” value only when ENABLE is set to “1”.
When ENABLE is set to “0”, the addr value is dafault value.

This is checked by Driver (using the get_config_int for ENABLE in the run phase) on whether to use the constrained addr value or use the default addr value before driving the transaction onto the bus.

Here my issue is “SEQUENCE” is working as per my expectation (ENABLE–>1 ==> use the laddr vaue for trans1;ENABLE–>0==>use the default value for trans2) but “SCENARIO” is NOT working as expected.

In case of scenario, my first set_config_int for ENABLE with value “1” is always overrided by the following set_config_int for ENABLE with value “0”.

Hence always ENABLE is "0’ for both trans1 & trans2 ==> using default value for addr.

Can anyone explain why this is happening?:confused:

Interesting part is, If I add a delay between the set_config_int call & `apply_send_with call, it works FINE as expected.:o

Scenario:
repeat(k)
begin
set_config_int(“*”,“ENABLE”,1);
apply_send_with(trans1,trans1.addr ==laddr); #1; set_config_int("*","ENABLE",0); apply_send_with(trans2,trans2.addr ==laddr);
#1;
end

Thanks in advance.:D

TVAR

2

Hi TVAR,

This sounds like a synchronisation issue to me. I have listed a some possible causes below:

Are you calling get_config_int in the driver before getting the sequence/scenario item? (In other words, are you trying to get ENABLE before it has been set).

Have you set the length of the request fifo in the scenario driver to a value greater than 1? Since `apply_send_with does not wait for a response from the driver, this would overwrite the value of ENABLE before the driver could read it.

There are also differences in the semantics between scenarios and sequences that may be causing the different behaviour, e.g. ovm_do includes a #0 delay (to sync. with the sequencer) while with apply_send_with, there is a #0 delay when the driver calls get_next_item (to allow arbitration).

If you are still having problems, perhaps you could post a bit more code?

Regards,
Dave

3

Hi Dave

thanks for your comments.

Please find my answers below:

Are you calling get_config_int in the driver before getting the sequence/scenario item? (In other words, are you trying to get ENABLE before it has been set).

NO…first I am getting the item & then looking for get_config_int as follows:

**

get_next_item(this_trans);
get_config_int(“ENABLE”,enable_driver);

**

Have you set the length of the request fifo in the scenario driver to a value greater than 1? Since `apply_send_with does not wait for a response from the driver, this would overwrite the value of ENABLE before the driver could read it.

**I don’t have any request FIFO as I am using the get_next_item() call for pulling the transaction item.

Please clarify me on this.**

Please find some code details & help me in this regard.

In my sequence’s run task body:

**

repeat(k)
begin
set_config_int(“*”,“ENABLE”,1);
ovm_do_with(trans1,addr ==laddr); set_config_int("*","ENABLE",0); ovm_do_with(trans2,addr ==laddr);
end

**

In my scenario’s run task body:

**

repeat(k)
begin
set_config_int(“*”,“ENABLE”,1);
apply_send_with(trans1,trans1.addr ==laddr); set_config_int("*","ENABLE",0); apply_send_with(trans2,trans2.addr ==laddr);
end

**

In my scenario_driver/sequence_driver:

**

get_next_item(this_trans);
get_config_int(“ENABLE”,enable_driver);
if(enable_driver == 0)
this_trans.addr = default_addr;
//else it will be the constrained value by Inline constraint i.e this_trans.addr is used
//Now apply this_trans to my pin level interface of DUT through task calls

**

Here my issue is “SEQUENCE” is working as per my expectation.
ENABLE–>1 ==> use the laddr vaue for trans1;
ENABLE–>0==>use the default value for trans2.

but “SCENARIO” is NOT working as expected.

In case of scenario, my first set_config_int for ENABLE with value “1” is always overrided by the following set_config_int for ENABLE with value “0”.

Hence always ENABLE is "0’ for both trans1 & trans2 ==> using default value for addr.

NOTE: Default value for enable_driver is “0”.

Am I clear enough?

TVAR

4

Hi TVAR,

I don’t have any request FIFO as I am using the get_next_item() call for pulling the transaction item.
Please clarify me on this.

It is possible to connect a request-response channel between a scenario driver and its controller, but you have said you are not doing this.

I have tried a simple example following the approach that you have outlined and it works OK for me. The call to get_config works the same for both sequence and scenario driver so I get alternating default and randomized addresses, even if I remove all wait statements from the scenario driver.

I am posting my example in case that gives you any clues as to unexpected behavior of your code.

Regards,
Dave

5

Hi Dave,

As far as I have compared, only difference between my code & yours is the #10 inside the forever loop in run task of the sequence driver/scenario driver and the way your are getting the next item from sequencer.

I don’t have any delay inside the un task of the sequence driver/scenario driver.

Why we need #10 inside forever loop in run task of driver?

I have used

seq_item_prod_if.get_next_item(item);

to get next item for sequence driver.

I have used

get_next_item(item);

to get next item for scenario driver.

Still am not getting the desired behavior from my code:(

Am using QuestaSim 6.3g

Please note that am using set/get_config_string for setting a feature ON/OFF inside the driver from the sequence/scenario.

Driver changes some fields of the transaction item if the feature is ON else leave as it is.

As an example I have showed with set/get_config_int.

TVAR

6

Hi TVAR,

I don’t have any delay inside the un task of the sequence driver/scenario driver.
Why we need #10 inside forever loop in run task of driver?

What is your driver actually driving? The #10 in my driver was there to represent a delay between applying successive stimulus items to a DUT. If you don’t have a delay in your sequence/scenario or your driver (e.g. waiting for a DUT response) then your entire stimulus is going to be produced and sent in zero time. Is this what you intended?

Incidentally, I still get the expected behaviour (alternating default and randomized values) in my example if I comment out the delays in the drivers - all of the sequences and scenarios are then produced at 0 and 500 time steps respectively.

I get the same results on both IUS 8.1 and Questa 6.3g so I do not know of any other reason why your example is not working correctly?

Regards,
Dave

7

Hi Dave,

Thanks for looking into my code.

What is your driver actually driving?

My driver is driving a sequence item from the sequences/scenarios interface onto the BFM’s tasks. Just by calling the BFM’s internal tasks with sequence item as task argument. These BFM internal tasks will drive the DUT’s pin level signals.

The #10 in my driver was there to represent a delay between applying successive stimulus items to a DUT. If you don’t have a delay in your sequence/scenario or your driver (e.g. waiting for a DUT response) then your entire stimulus is going to be produced and sent in zero time. Is this what you intended?

Yes…Am expecting that.

Further I have noticed the following differences in my environment behavior.

In case of Sequence approach,

Sequence
repeat(k)
begin
set_config_int(“*”,“ENABLE”,1);
ovm_do_with(trans1,addr ==laddr); set_config_int("*","ENABLE",0); ovm_do_with(trans2,addr ==laddr);
end

the seq_item_prod_if.get_next_item(item) call in the sequence driver

gets the transaction item “trans1” for the first ovm_do_with call before my second ovm_do_with call using “trans2”.

But In case of scenario approach,

Scenario
repeat(k)
begin
set_config_int(“*”,“ENABLE”,1);
apply_send_with(trans1,trans1.addr ==laddr); set_config_int("*","ENABLE",0); apply_send_with(trans2,trans2.addr ==laddr);
end

the get_next_item(trans_item); call in the scenario driver get the transaction item “trans1” for my first apply_send_with call ONLY AFTER my second apply_send_with call using “trans2”.

Hence my second config setting for ENABLE as ‘0’ got assigned for both my transactions - trans1 & trans2.

How can the my scenario goes to the second apply_send_with call using "trans2" before completing my first apply_send_with call using “trans1” (scenario driver havn’t pulled the sequence item “trans1” using the get_next_item() call) ???

Thanks & Regards
TVAR