Home > Community > Forums > Functional Verification > TCM versus TCM race conditoin

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 TCM versus TCM race conditoin 

Last post Sun, May 23 2010 9:35 PM by lalit123. 8 replies.
Started by lalit123 20 May 2010 11:20 PM. Topic has 8 replies and 2648 views
Page 1 of 1 (9 items)
Sort Posts:
  • Thu, May 20 2010 11:20 PM

    • lalit123
    • Not Ranked
    • Joined on Mon, May 17 2010
    • Posts 6
    • Points 75
    TCM versus TCM race conditoin Reply

    Hi,

    This is regarding a race condition (happens at different seed) in one of my sim between 2 different TCMs.

     The scenario is something like this:

    The test is implented as a subsequence which contains a do action in its body() @driver.clock {..., the driver.clock is connected to bfm clock as follows:

    event a_clock is rise ('clk_from_vhd_tb') @sim;

    on a_clock {emit driver.clock};

    where driver is the one associated with original sequence.

     In bfm there is a TCM called execute_items()... which is started in its run() is also{... block.

    The issue:

    In few seeds it is seen that when execute_items() is started there is a garbage struct which is generated.

    The bfm interaction mode is PULL_MODE. As per my understanding of get_next_item(), the call is blocked unless a "do" action is seen this avoiding any garbage struct generation.

    Thanks in advance for any help.

    • Post Points: 20
  • Fri, May 21 2010 1:01 AM

    • StephenH
    • Top 25 Contributor
    • Joined on Tue, Sep 2 2008
    • Bristol, Avon
    • Posts 278
    • Points 4,450
    Re: TCM versus TCM race conditoin Reply

    Could you explain what you mean by "garbage struct"? Are you certain that no other sequence is being run first and generating something that you do not expect? I ask, because you said your test is a subsequence, which implies that it's not the MAIN sequence.
    If this isn't your own eVC, check whether any special sequences are initiated before MAIN body() is called. For example, in some of the Cadence eVCs, a special initialisation sequence is run from MAIN's pre_body() in order to do any standard setup stuff before the test sequence kicks off.

    You could try using the "trace sequence" command to see the flow of the sequences; indeed if you're using NCSim with Specman then "trace sequence transactions" will put the sequences and the items into the waveforms.

    As an aside, you should be using simple_ports to connect to RTL signals, they give you a performance boost compared to tick-accesses. Here's an example based on your clock:

    clk_p : in simple_port of bit is instance;
    keep clk_p.hdl_path() == "clk_from_tb";
    event a_clock is rise(clk_p$)@sim;

    Steve Hobbs / Applications Engineer / Cadence Functional Verification
    Filed under:
    • Post Points: 20
  • Fri, May 21 2010 1:30 AM

    • lalit123
    • Not Ranked
    • Joined on Mon, May 17 2010
    • Posts 6
    • Points 75
    Re: TCM versus TCM race conditoin Reply

    Hello StephenH,

    Thanks for you reply.

    It is my own testbench compling with eRM. So I guess there is no special sequence(s) that could have been initiated. The MAIN body() is empty and is:

    extend MAIN dcephy_pkt_sequence {
    --commented out code

    };

    The TCM execute_item() is started in run() is also {... block of bfm which has following code:

    while TRUE {

     seq_item = driver.get_next_item();

    drive_pkt(seq_item);    --Another TCM which does actual driving.

    emit driver.item_done

    };

    execute_item() runs on a clock on which driver.clock is emitted. In sub-sequence's body(), do action is called.

    What I suspect is before this do action the start execute_item() TCM generates a struct packet defined. Which I reffered here as garbage.

    Is this the correct understanding? How do I avoid this as I dont see this garbage packet getting generated in 2-3 seeds?

    • Post Points: 20
  • Fri, May 21 2010 1:31 AM

    • lalit123
    • Not Ranked
    • Joined on Mon, May 17 2010
    • Posts 6
    • Points 75
    Re: TCM versus TCM race conditoin Reply

    Yes indeed my code is as you mentioned. I just wrote to make it simple.

    • Post Points: 5
  • Fri, May 21 2010 2:26 AM

    • StephenH
    • Top 25 Contributor
    • Joined on Tue, Sep 2 2008
    • Bristol, Avon
    • Posts 278
    • Points 4,450
    Re: TCM versus TCM race conditoin Reply

    In your BFM, do you wait for the reset to finish before starting into execute_items()?

    I don't see where get_next_item() could be getting any struct from, unless you do have some sequence that's running.

    Did you use the trace command to see what sequences run, just to sure that only your empty MAIN is run?

    Are you sure that pre_body() and post_body() are not sending anything to the BFM?

    execute_items() won't itself generate a struct unless you explicitly "gen" one yourself.

    Steve Hobbs / Applications Engineer / Cadence Functional Verification
    • Post Points: 20
  • Fri, May 21 2010 2:30 AM

    • lalit123
    • Not Ranked
    • Joined on Mon, May 17 2010
    • Posts 6
    • Points 75
    Re: TCM versus TCM race conditoin Reply

    Hi,

     More info:

    After enabling trace sequence this is the log:

    17ns, Entered start_tb()183ns, asserting reset350ns, de-asserting reset[850] dcephy_pkt_driver_u-@7: SEQ(0) MAIN dcephy_pkt_sequence-@99: Executing default body() method: doing 7 sequences[850] dcephy_pkt_driver_u-@7: SEQ(1) SIMPLE dcephy_pkt_sequence-@100 created850ns, inside Execute_items()[850] dcephy_pkt_driver_u-@7: SEQ(2) dcephy_pkt_s-@102 created850ns, Got nxt item passing to driver850ns, driving pkt850ns, Pkt driven. Waiting for 1 cycle917ns, Emitting item_done event

    ...Which comes before do action is called. Looks like pkt of SIMPLE kind is being generated.

     Could you please explain what actually is going on? In my case the SIMPLE kind is empty.

    • Post Points: 20
  • Fri, May 21 2010 2:34 AM

    • lalit123
    • Not Ranked
    • Joined on Mon, May 17 2010
    • Posts 6
    • Points 75
    Re: TCM versus TCM race conditoin Reply

    Yes, the reset TCM is actually CALLED not STARTED and runs on a much faster clock. The log from trace sequence might shed some light on this.

    • Post Points: 5
  • Fri, May 21 2010 3:40 AM

    • StephenH
    • Top 25 Contributor
    • Joined on Tue, Sep 2 2008
    • Bristol, Avon
    • Posts 278
    • Points 4,450
    Re: TCM versus TCM race conditoin Reply

    I'm a bit confused, as you said your MAIN sequence was empty, yet the trace log shows it's starting a SIMPLE sequence.

    Have you tried setting a breakpoint on the body() of MAIN and SIMPLE dcephy_pkt_sequence, to be sure that you're not executing some code that you were not expecting?

    Again, without seeing your code it's hard to diagnose, but are you certain that no pre_body() or post_body() methods are sending any items to the BFM?

    Steve Hobbs / Applications Engineer / Cadence Functional Verification
    • Post Points: 20
  • Sun, May 23 2010 9:35 PM

    • lalit123
    • Not Ranked
    • Joined on Mon, May 17 2010
    • Posts 6
    • Points 75
    Re: TCM versus TCM race conditoin Reply

    Ok... this is how the code looks like:

    sequence my_seq_sequence using

    item = my_item_s,

    created_kind = my_item_kind_t,

    created_driver = my_item_driver_u;

    extend MAIN my_seq_sequence {

    --  body() @driver.clock is only {};

     };

    extend SIMPLE my_seq_sequence {

      body() @driver.clock is only {

      outf("SIMPLE\n");

      };

    extend RANDOM my_seq_sequence {

      body() @driver.clock is only {

      outf("RANDOM\n");

      };

    This I guess will definitely be generating the sequence. What should be done to avoid starting any other sequence than the ones in the sub-sequneces.

    • Post Points: 5
Page 1 of 1 (9 items)
Sort Posts:
Started by lalit123 at 20 May 2010 11:20 PM. Topic has 8 replies.