Stats

  • Locked Locked
  • Replies 4
  • Subscribers 64
  • Views 16245
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

pre_body() and post_body() from virt-seq

archive

Hi there,

I implemented my objection handling "raise_objection" in pre_body() and "drop_objection" in post_body() so I don't have to worry about the test stopping during some sequence. When I "do" my sequences from a sve virtual_seq, the pre_body() and post_body() functions are not called whereas when I "do" my sequences from the MAIN eVC sequence, both are called.

Is this intended behaviour?

My workaround currently is calling pre_body() as first statement in body() itself and post_body at the very end.
The fact that calling them works tells me, that they are present.

Shouldn't they be called automatically by the virtual sequence before and after the body() section?

greetings


Originally posted in cdnusers.org by SomeDude

  • Hi Dude,

    To be on the safe side, did you declare your virtual sequence driver with the sequence-macro to create the sequence infrastructure, or if you didn't, did you let your sequence like-inherit from any_sequence?

    Regards,
    Hilmar


    Originally posted in cdnusers.org by Hilmar

  • Hi,

    I believe pre_body() is called only when you start your sequence using start_sequence(), which is not so common.
    So if you're "DO"ing your sequence - it won't work.
    However, if I remember correctly- MAIN sequences are started automatically with "start_sequence()" so pre_body() should work for themt, but as for other sequence kinds - you might want to look into the pre_do() tcm.

    Hope this help :-)

    Yaron


    Originally posted in cdnusers.org by thinkverification

  • Hi,

    In this case i you can implement the objection mechanism by raising the TEST_DONE objection from the virtual sequence pre_body() and dropping it from the virtual sequence post_body().

    Hope this will help to you.

    --
    Regards,
    Gaurav Patel
    ASIC Engineer
    eInfochips.
    www.einfochips.com


    Originally posted in cdnusers.org by er_gauravpatel

  • Thx for the help guys!

    Posted By Hilmar on 2/05/2008 5:23 AM

    To be on the safe side, did you declare your virtual sequence driver with the sequence-macro to create the sequence infrastructure, or if you didn't, did you let your sequence like-inherit from any_sequence?
    I used the macro.

    Posted By thinkverification on 2/05/2008 6:45 AM

    I believe pre_body() is called only when you start your sequence using start_sequence(), which is not so common.
    So if you're "DO"ing your sequence - it won't work.
    However, if I remember correctly- MAIN sequences are started automatically with "start_sequence()" so pre_body() should work for themt, but as for other sequence kinds - you might want to look into the pre_do() tcm.
    thx for the tip, I scavanged around in some older documents we had and found the mid_do() and post_do() hooks. Using those I now raise and drop objections in the driver itself. I think pre_do() is done before the pointers are connected. I failed to find this whole pre_do/mid_do/post_do in the latest documents though, only in some 4.something version.

    Posted By er_gauravpatel on 2/05/2008 10:39 AM

    In this case i you can implement the objection mechanism by raising the TEST_DONE objection from the virtual sequence pre_body() and dropping it from the virtual sequence post_body().
    That was already implemented and didn't fully do it. As soon as the virtual sequence was finished, the test stopped, but the subsequences were not fully done yet. The stimulus was done, but the collecting agents were not completely done. As result, scoreboards were still full and the dut wasn't done digesting the input. Hence I also put objections into the collecting agents that once they found some data stream they keep the objection it up till they are done as well.

    greetings


    Originally posted in cdnusers.org by SomeDude

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.