Jump to content

Search the Community

Showing results for tags 'uvm_config_db'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Verification (UVM-SystemC, SCV)
    • SystemC CCI (Configuration, Control & Inspection)
    • SystemC Datatypes
  • UVM (Universal Verification Methodology)
    • UVM (IEEE 1800.2) - Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • UVM Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM (Pre-IEEE) Methodology and BCL Forum
  • Portable Stimulus
    • Portable Stimulus Discussion
    • Portable Stimulus 2.0 Public Review Feedback
  • IP Security
    • IP Security Assurance Whitepaper Discussion
  • IP-XACT
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • Commercial Announcements
    • Announcements

Categories

  • SystemC
  • UVM
  • UCIS
  • IEEE 1735/IP Encryption

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation


Company

Found 8 results

  1. c4brian and I have messaged a bunch about ways to share data and access between elements in SV/UVM code. I put common functions/tasks/constants into a package, which I think is standard. I realize that absolute dot notation of accessing elements (i.e. variable12 = smthgA.smthgB.smthgC.variableXYZ;) is frowned upon as it is not good for reuse. So, the UVM presents the uvm_config_db to facilitate reuse and simplify connectivity across a hierarchy.**1 Many folks have (including c4brian, I believe) commented that they don't like how verbose it is to ::get from the config db
  2. Hi All, It seems that there is a problem for automatically updating components fields registered with uvm_field_* macros. It works fine if the field is of type int, but it fails if the field is of type enum. Do I miss something? (I tested this code with both UVM 1.1-d and UVM 1.2) class hs_driver extends uvm_driver #(hs_packet); hs_type_t driver_type; int my_param = 10; `uvm_component_utils_begin (hs_driver) `uvm_field_enum (hs_type_t, driver_type, UVM_ALL_ON) `uvm_field_int (my_param, UVM_ALL_ON) `uvm_component_utils_end [...] endclass: hs_drive
  3. Hi, all - When using uvm_config_db#(...)::set(...) from a top-module, is there any difference between using set-context=null and inst_name "*" and using set-context=uvm_root::get(), and inst_name "*"? top-module examples: uvm_config_db#(virtual dut_if)::set(null, "*", "vif", dif); uvm_config_db#(virtual dut_if)::set(uvm_root::get(),, "*", "vif", dif); Of course, per the UVM Class Reference, setting a context to null means that the inst_name provides the complete scope and "*" means any scope. Setting the context to uvm_top (returned by uvm_root::get()) and indicating "*" any scop
  4. Hi, I have a question when I use uvm_config_db for interface connection. Generally, I know we use set() and get() function of "uvm_config_db" when we connect interface instance with virtual interface. As I know, uvm_config_db#(virtual aaa_intf)::set() is described inside top testbench module. And uvm_config_db#(virtual aaa_intf)::get() is some phase of inside class. What I want to do is to move set() function into some phase of class. Is it possible? If possible, which phase can I use not to be no problem in topology? Could you give me an example? I generally descirbes
  5. In the env, there is such uvm_config_db::set(): for (int i = 0; i < host_num; i++) begin inst_name = $sformatf("*.v_seq.slv_seq[%0d]", i); uvm_config_db#(uvm_event)::set(uvm_root::get(), inst_name, "evt", env.subenv[i].slv_agt.slv_mon.evt); end in the slv_seq, there is such uvm_config_db::get(): if(!uvm_config_db#(uvm_event)::get(null, this.get_full_name(), "evt", evt)) `uvm_fatal("NOEVT",{"evt must be set for: ",get_full_name(),".evt"}); When I use +UVM_CONFIG_DB_TRACE, I found such message: UVM_INFO /EDA_Tools/synopsys/vcs1209/etc/uvm-1.1/uvm-1.1d/sr
  6. When agents are configured, I typically see something like this: uvm_config_db#(int)::set(this,"testbenchA.masterA_hostB.agentpink","is_active",UVM_ACTIVE); Isn't UVM_ACTIVE of type bit? I see it 'described' here in an enum and given a default value. src/base/uvm_object_globals.svh: typedef enum bit { UVM_PASSIVE=0, UVM_ACTIVE=1 } uvm_active_passive_enum; So shouldn't the uvm_config_db line not be: uvm_config_db#(int)::set(this,"testbenchA.masterA_hostB.agentpink","is_active",UVM_ACTIVE); but instead be: uvm_config_db#(bit)::set(this,"testbenchA.masterA_hostB.agentpink",
  7. Hi all, Usually we use uvm_config_db::set from the higher hierarchy module and uvm_config_db::get in the lower hierarchy module, Can we use uvm_config_db::set and uvm_config_db::get from the opposite direction? Regards mrforever
  8. Hi, all, I met one problem when i configure sub-sequencers of virtual sequencer using uvm_config_db. Here are the codes and VCS reports: -------codes------- class my_subenv extends uvm_env; ... function void build_phase(uvm_phase phase); ... v_sqr = vsequencer::type_id::create($sformatf("v_sqr%0d", subenv_ID), this); // configuration, set default_sequence as the virtual sequencer uvm_config_db#(uvm_object_wrapper)::set(this, "v_sqr.run_phase", "default_sequence", vsequence::type_id::get()); ... endfunction : build_phase function void connect_p
×
×
  • Create New...