Calling uvmc_connect depending on UVM configuration values obtained with uvmc_commands

UVM
,
1

UVMC-commands (like uvmc_wait_for_phase) can only be called in a SystemC thread.
It would be interesting to wait for the build-phase to complete before getting some UVM configuration values and depending on them decide whether a connection should take place via uvmc_connect or not.
For example:

SC_MODULE(sc_top)
  my_model_type my_model;
  SC_CTOR(sc_top) : my_model("my_model", sc_core::sc_time(10, sc_core::SC_NS)) 
    {
      SC_THREAD(wait_for_uvm_phases);
    }
  void wait_for_uvm_phases()
    {
      wait(SC_ZERO_TIME);
      UVMC_INFO("SC_TOP",(string("Waiting for build to finish")).c_str(),UVM_HIGH,"");    
      uvmc_wait_for_phase("build", UVM_PHASE_DONE);
      UVMC_INFO("SC_TOP",(string("Build phase ended")).c_str(),UVM_MEDIUM,"");
      // Get a configuration int from the test to see if the analysis port should be connected
      if (<pseudo-code to get int from UVM config_db and compare with 1>) {
         uvmc_connect(*my_model.m_analysis_port, "my_model_ap");
      }
    }

However, when running it I receive a simulation error that claims that a SystemC-quickthread accessed protected stack guard memory. uvmc_common seems to be involved. Is what I am trying to do even theoretically possible? If so, do I need to “split” the uvmc_connect in port generation in the static part (SC_CTOR) and binding (thread)?

2

In reply to jmartinl:

jmartinl,

Actually, to answer your question of whether theoretically possible, it is not.

The reason is that proxy ports which, are SC primitive channels, are created
underneath uvmc_connect<>() to bind with the explicitly passed in ones. And SystemC
primitive channels can only be created at construction time which is too early
for what you’re asking for. Additionally the time at which those ports must
be bound to their peers must also be construction time.

All of this said, I do agree that this would be a nice capability.

The only way I could see around this would be to have the proxy channels
not derive from primitive channels somehow but yet still qualify to
bind to TLM passed in ports. I don’t see an easy way to do that at present
but I’m open to ideas.

– johnS