Jump to content

mastrick

Members
  • Content Count

    48
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by mastrick


  1. I believe the UVM intent of 

    Quote

    REG1.add_hdl_path_slice("IP.REG.regout", 16,16);

    is to associate the (whole) signal "IP.REG.regout" with the 16 bits starting at offset 16 of the data in the reg model.  The start and offset do not affect the signal, and so you do need to provide the bit range as you show to associate a slice of the signal with a slice of the internal data.  I agree the documentation does not make that clear, and I have filed a Mantis to improve that documentation.


  2. Thank you for posting Chintan.  I see the 1800.2-2017 standard says in "8.3.1.4.1 set_inst_override_by_type and set_inst_override_by_name":

    Quote

    When the factory processes instance overrides, the instance queue is processed in order of override
    registrations and the first override match prevails. Thus, more specific overrides should be registered first,
    followed by more general overrides.

    That says to me that when you gave your original commands to override master_base_seq twice with different override types, the first one should be applied, just as you saw.  The set_type_override variations include a "replace" argument that controls whether the new or the older override has priority, so it can work either way.


  3. When you set the default_sequence in uvm_config_db, you specify the phase in which the driver will start the sequence.  Just with that specification, you can run the sequence in any phase.

    get_starting_phase() and set_starting_phase() refer to a phase that will be objected to by the automatic phase objection feature of uvm_sequence.  The default value for that starting_phase is the phase in which the sequence gets started (what you specified to the uvm_config_db).  


  4. Strangely enough, we have just encountered this issue for the first time today.  Thanks Robert for posting!

    In our case, the nested class does not use the field macros but rather calls uvm_report_info directly.  We use nested class in this case because this class is used as a replacement class in the test, and to allow us to compile all tests in one executable without conflict, we require such classes to be nested within the test class that uses it.

    Guess I'll file a mantis to see if the implementation can tolerate such usage.


  5. Thanks for the suggestion, David.  The situation that caused us to consider this question was that we had a verification component modeling an external interface to our ASIC, so it had its own clock, not shared with the rest of the design.  There is a possibility that clock is not running, which we wanted to model, but when the clock did not run, our drive through the clocking block never happened.  In real circuitry, even though the clock is not running, the asynchronous reset (applied to the external component also) would ensure that the external data was driven to a known value.  This made us consider that often our verification components act as if they are synchronously reset but they may not be in real life, and one can imagine scenarios where a bug could escape.

     

    So your example implies that a non-blockjng assignment to DATA would change the value on DATA and not be treated as another driver to be resolved on DATA.  If so, can you say why the internal assignment behaves differently from a non-blocking assignment from outside the interface of the form m_if_instance.DATA <= value?


  6. Our uvm_driver derivatives push values into the RTL via clocking blocks in interfaces.  This updates the signals synchronously as we typically want, but is there a recommended way to add an asynchronous update of the signal to model a change that could occur when asynchronous reset is applied?  We see that if we just assign to the signal at the interface level (not the clocking block level), we get a conflict between both assignments.  


  7. The +uvm_set_default_sequence is applied at the time that +uvm_set_config_int is applied, which seems consistent.  This is before run_phase, which is why your code overrides the command line value.  What do you think about making your code check whether there is an existing setting first?

    task run_phase(uvm_phase phase);
    
       if (!uvm_config_db #(uvm_object_wrapper)::exists(null, "uvm_test_top.my_sequencer.main_phase", "default_sequence"))
          uvm_config_db #(uvm_object_wrapper)::set(null, "uvm_test_top.my_sequencer.main_phase", "default_sequence", seq_b::type_id::get());
       sequencer.start_phase_sequence(phase);
    endtask: run_phase
    

  8. It is very easy to assign one of your interfaces into a different domain that is completely independent from the original domain (the only points of synchronization will be the beginning and end of the run_phase).  Simply create a new domain and use uvm_component::set_domain() to associate it with the component.

       uvm_domain new_domain = new ;

       root_of_interface.set_domain(new_domain); // default is to apply this to all lower levels of hierarchy

     

    If you do not want these two domains to be completely independent, but instead act as if they were in the same domain with the exception that one can jump back to pre_reset without the other, then you need to synchronize the domains.

        domain1.sync(domain2) ;

     

    We find the phase jump to be more convenient than the virtual sequence because the virtual sequence has to be implemented by the testbench integrator taking into account each component, while the phase behavior can be specified by the component implementor and used as-is by the testbench integrator.  With either approach, the components must respond appropriately to a midsim reset.  We recommend the components have a monitor of the reset signal and clear all status appropriately based on that.  Any sequences that should be stopped must be taken care of.  Sequence behavior is the biggest gotcha of the current phase jumping as it terminates abruptly any sequences started from a phase task or via default_sequence in the config_db.  If you already have midsim reset working ok with one domain, you are probably OK there.


  9. I think you want to remove the *. at the front of your "set" path, i.e.

    uvm_config_db#(uvm_object_wrapper)::set(this,"env.cfg_agt.cfg_sqr.main_phase",

    "default_sequence",

    chpp_config_sequence::type_id::get());

    as env is already in the context of "this". If that still does not work, turning on the config trace messages will show you what the sequencer is looking for when it queries for default_sequence in the uvm base layer.

×
×
  • Create New...