TCM versus TCM race conditoin

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;

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?

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

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.

Hi,

 More info:

After enabling trace sequence this is the log:

...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.

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.

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?

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.