Scenario generation profiling

EdmondCote · **Joined:** Tue Aug 11, 2009 1:40 pm **Posts:** 1

Hi all,

I raised this issue with our AE last week, but would like to hear if any members of the community have run into a similar problem.

The problem I am facing is that when profiling my environment, I find that an inordinate amount of time (between 60-80% of total simulation) is spent inside "function int unsigned vmm_scenario::get_max_length();".

I profiled the constraints in my transaction class, and they don't appear to be the issue. Just in case, I moved all complex constraints to procedural code in the post_randomize functional in case their solution space was too large.

If you notice below, I constrain the length of the scenario to 1, making it essentially an atomic generator. That is arguably the most difficult constraint to solve, but it is responsible for that huge overhead?

Does anyone have suggestions as to how to debug further? Note that I did profile my constraints, however, there might (?) be a bug where the profiler does not break out the time spent solving the different constraints. Also, it if matters, there are 24 of these scenario generators running in parallel.

Thanks in advance,

Edmond

Code:

#  vmm_scenario_valid : constraint_mode = ON (/import/vcs-release/vcsC-2009.06-5/etc/rvm/vmm.sv:6544)
    (  scenario_kind  >=  0  ) ;
    (  scenario_kind  <  (  (  next_scenario_kind  ==  0  )  ?  1  :  next_scenario_kind  )  ) ;
    (  length  >=  0  ) ;
    (  length  <=  max_length  ) ;
    (  repeated  >=  0  ) ;
    solve  scenario_kind  before  length  hard ;

#  repetition : constraint_mode = ON  (/import/vcs-release/vcsC-2009.06-5/etc/rvm/vmm.sv:6556)
    (  repeated  ==  0  ) ;

#  clx_tr_scenario_valid : constraint_mode = ON (/[...]/tr.sv:266)
    (  items.size()  ==  length  ) ;
    solve  length  before  items.size()  hard ;

#  scenario_c : constraint_mode = ON (/[...]/tr.sv:262)
    (  length  ==  1  ) ;
    (  repeated  ==  0  ) ;

    foreach (items[i19])
    {
        (  items[ i19 ].src  ==  src  ) ;
        (  items[ i19 ].port  ==  port  ) ;
        (  items[ i19 ].burst_length  ==  global.[...].burstLength  ) ;
        (  items[ i19 ].inter_pkt_delay  ==  global.[...].interPktDelay  ) ;
        (  items[ i19 ].ack_delay  ==  global.[...].ackDelay  ) ;
    }

#  burst_length_c : constraint_mode = ON (/[...]/tr.sv:196)
    (  items[0].burst_length  ==  items[0].global.[...].burstLength  ) ;

#  inter_pkt_delay_c : constraint_mode = ON (/[...]/tr.sv:204)
    (  items[0].inter_pkt_delay  ==  items[0].global.[...].interPktDelay  ) ;

#  ack_delay_c : constraint_mode = ON (/[...]/tr.sv:212)
    (  items[0].ack_delay  ==  items[0].global.[...].ackDelay  ) ;

prashanth_s · **Joined:** Mon Jun 15, 2009 2:51 am **Posts:** 2

vmm_scenario::get_max_length() may not consume huge amount of time (unless it is called huge number of times)

function int unsigned vmm_scenario::get_max_length();
return this.max_length;
endfunction: get_max_length

Moving complex constraints which can be solved procedurally to post_randomize() is a good thing..
Also, keeping the length as less as possible, but without compromizing the functionality is recommended.
Constraining length to 1 typically reduces the overhead since no of constraints to be solved in parallel at a time, gets reduced.

In your case, probably the best thing is to take out just one scenario generator with the scenario, generate N scenarios of length 1 and check if the time taken is comparable to the atomic generator (you can randomize the same transaction in an atomic generator as well.). Then you can try increasing the length of the scenario and compare the overhead.

Scenario generation profiling

Who is online