Global_stop_request() & $finish

Hi,

We have a testbench that has a number of files containing global_stop_request(). Is there a way to know which file executed the global_stop_request() without placing a print statement just prior to it?

The verilog $finish task does actually print the line number and file name along with time where it stopped. However, global_stop_request() does not.

Thanks in advance

Kal

Kal,

What do you plan to do with this information once you knowit? Print it?

If you put a

ovm_report_info("STOP","Stop requested by nnnnnn",OVM_NONE,`__FILE__,`__LINE__);

you will get all the information you need about who requested the stop.

Dave

Hi Kal,
It is surprising that both the popular *M methodologies didn’t pay enough attention to this tiny-yet-useful piece of info. I’ve seen customers pulling their hairs over “where from the exit is called” in the past. It would have been ideal if the global_stop_request had this provision. A quick idea as a fix:

Edit ovm_root.sv

function void global_stop_request(string file_info = `__FILE__,
   int line_num = `__LINE__);
  ovm_root top;
  top = ovm_root::get();
  ovm_report_info("global_stop_request called from file %s at line %0d",
                  file_info, line_num);
  top.stop_request();
endfunction

Now if you leave this as-is it will be of no use, instead, wherever you invoke global_stop_request, pass __FILE__, and LINE.

I believe this should work for you. I tried it in $OVM/examples (tried 2 of them), somehow they were not calling the correct global_stop_request (one called the depreciated ovm_component::global_stop_request, the other straight away finished), so didn’t validate this idea.

Will appreciate if you can confirm whether this worked for you.

Regards
Srini, CVC
www.cvcblr.com

Kal/Sri,

I am not exactly sure why are there multiple globla_stop_request() calls in one TB. Ideally after test case checks for wait_for_end test case conditions, it applies global_stop_request.

There should not be any other call to global_stop_request.

Can anybody let me know where I am wrong?

Ashish

Kal/Sri,
I am not exactly sure why are there multiple globla_stop_request() calls in one TB. Ideally after test case checks for wait_for_end test case conditions, it applies global_stop_request.
There should not be any other call to global_stop_request.
Can anybody let me know where I am wrong?
Ashish

Where can I find more info on how to do wait_for_end?

Anyway, I still feel global_stop_request() or ovm_top.stop_request() is incomplete as they lack the printing of line number and file where they started executing.

Kal

You might want to take a look at objection utility which can help you co-ordinate end-of-simulation in more orderly and clean way.
http://www.ovmworld.org/contributions-details.php?id=48&keywords=An_OVM_Objection_mechanism_package

Yes, I agree with Jigar.

Use Objection Mechanism in OVM Contributors link. It is basically some mechanism which tells that you have been expecting certain things but it is not achieved at the end of the test. This is wait_for_end conditions.

Ashish

You might want to take a look at objection utility which can help you co-ordinate end-of-simulation in more orderly and clean way.

Hi Jigar,

The OVM Objection Mechanism is not working correctly with Questasim tool, Only Cadence Tool users can use that package currently.

Kal,
What do you plan to do with this information once you knowit? Print it?
If you put a

ovm_report_info("STOP","Stop requested by nnnnnn",OVM_NONE,`__FILE__,`__LINE__);

you will get all the information you need about who requested the stop.
Dave

Are the defines __FILE__,LINE built in defines or do I need to specify them explicitly?

I tried the command and it did not work. The error comes up as follows

[HTML]`FILE: not a recognized directive or macro [2.7.3][16.3.1][16(IEEE)].[/HTML]

I wish atleast one of the following suggestions are takenup by OVM developers.

  1. Make global_stop_request() print out the line number and filename where it got executed.

  2. A function as follows that would print out the line number, filename where it finished similar to the $finish statement in verilog. We have ovm_report_fatal but having a function ovm_report_finish wouldn’t hurt OVM package.

    ovm_report_finish (string id, string message, int verbosity_level=300,string filename=“”, int line=0)

Regards
Kal

Are the defines __FILE__,LINE built in defines or do I need to specify them explicitly?
I tried the command and it did not work. The error comes up as follows
[HTML]`FILE: not a recognized directive or macro [2.7.3][16.3.1][16(IEEE)].[/HTML]

It is part of SV P1800-2009, guess was not part of 2005 LRM. Perhaps your tool doesn’t support it yet? I know VCS & Questa support them.

Srini

FYI: Macros __FILE__ and LINE are not defined in OVM and/or SystemVerilog language. These macros may be simulator specific proprietary implementation and may make your code simulator dependent.

FYI: Macros __FILE__ and LINE are not defined in OVM and/or SystemVerilog language. These macros may be simulator specific proprietary implementation and may make your code simulator dependent.

Well not anymore. The new revision of SV LRM, P1800-2009 adds them, see: section 22.13. Agreed it is still a draft, but I believe all major vendors are working actively to support constructs from that already. For instance we are working actively on upgrading our SVA hanbook as 2nd edition with all the boatload of SVA constructs. All 3 major vendors are helping us review the same.

Regards
Srini

srini,

Thanks for correcting me.

BTW, yet anothernew feature in 1800-2009 added after __FILE__ and LINE is default macro arguments. This makes __FILE__ and LINE useful as defaults for macro arguments since they are evaluated in the place where the top-level macro is invoked. This was added fairly late in the LRM, so I don’t expect it to be implemented in any current tools.

An interesting discussion.

ovm_report_fatal calls $finish, so I’m not sure what you would expect ovm_report_finish() to do that ovm_report_fatal does not already do. (As a partial answer to my own question, I suppose a FATAL message sounds like an abnormal termination, whereas FINISH looks like things shut down nicely). Besides calling $finish is there other functionality you would like to see?

Another thing to note is that global_stop_request does not necessarily shut down the testbench. It causes all the stop() tasks in components that have enable_stop_interrupt set to 1 to be called. Any of those tasks can block for any length of time (bounded by global_stop_timeout). Only when the last one unblocks will the testbench shutdown. Would it be useful to know the file/line of where global_stop_request() is called, even it it does not immediately result in the termination of the testbench?

– Mark

An interesting discussion.
ovm_report_fatal calls $finish, so I’m not sure what you would expect ovm_report_finish() to do that ovm_report_fatal does not already do. (As a partial answer to my own question, I suppose a FATAL message sounds like an abnormal termination, whereas FINISH looks like things shut down nicely). Besides calling $finish is there other functionality you would like to see?
Another thing to note is that global_stop_request does not necessarily shut down the testbench. It causes all the stop() tasks in components that have enable_stop_interrupt set to 1 to be called. Any of those tasks can block for any length of time (bounded by global_stop_timeout). Only when the last one unblocks will the testbench shutdown. Would it be useful to know the file/line of where global_stop_request() is called, even it it does not immediately result in the termination of the testbench?
– Mark

I wish ovm_report_finish to do the same job as $finish, that is print the line number and file name where it started besides providing the same features as ovm_report_info.

[HTML]ovm_report_info (string id, string message, int verbosity, string filename, int line)[/HTML]

It would certainly help to know file/line of where global_stop_request() is called, even it it does not immediately result in the termination of the testbench because we know what file and which line called global_stop_request. If it is a premature global_stop_request() or if the global_stop_request() was inside a decision control structure like ‘if’ or ‘case’, it would be really helpful to know where to start debug.

Rgds
Kal

Hi Kal,

Your suggestion for global stop request sounds good.

FYI - Paradigm Works contributed to OVM World an objection mechanism that works with both Cadence and Mentor simulators. Click on this link for more information/download.

http://www.ovmworld.org/contributions-details.php?id=46&keywords=PW_Shutdown_Manager_(Objection_Mechanism