Jump to content

Search the Community

Showing results for tags 'Register Layer'.

  • 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
    • SA-EDI Standard Discussion
    • 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 5 results

  1. In our DUT, we have two separate independent physical interfaces (APB & I2C) (active 1 at a time) through which all registers can can be accessed, Also in our register model, we created two reg_maps, one for each APB & I2C. Now through testcase, we want only one physical interface at a time, to be subjected to default uvm sequences (i.e. uvm_reg_access_seq, uvm_reg_bit_bash_seq,etc) but it is not possible as uvm_sequence will get all the maps using get_maps(); So without over-riding the default uvm_reg_access_seq, is it possible to achieve such type of configuration in test
  2. I am trying to run the uvm builtin register sequences. I seem to have broken our usage of them in porting code from a previous project. Q1: In the past, we've started them as default sequences. Is there any way to have an error/warning appear if a 'set', such as the below, is never utilized (or 'get'-ed)? uvm_config_db#(uvm_object_wrapper)::set(this, "*.m_reg_agent.m_seq_reg.main_phase", "default_sequence", uvm_builtin_reg_test_seq::type_id::get()); I've added uvm_top.print_topology(); and uvm_config_db::dump(); and it seems the ::set should be working, but nothing is star
  3. In the UVM register model, if you create a register or a field which is wider than the bus width there is no way to control what order the multiple bus operations occur to update the register/field value. In my case I was using BIG_ENDIAN addressing and the register model would always write the largest address first. My design spec required that the largest address be written last. I searched in vain for a way to change this but ended up overriding the 'do_bus_write' function in 'uvm_reg_map'. If you've run into a similar issue, here's my workaround. reversed_reg_order_map.sv `ifndef __RE
  4. A Register Layer read (using the built-in frontdoor) proceeds as follows: uvm_reg::read -> uvm_reg::XreadX -> uvm_reg::do_read -> uvm_reg_map::do_read -> uvm_reg_map::do_bus_read If a read request (bus_req) is expected to be completed by a completely separate read reponse (bus_rsp), the following code is executed within uvm_reg_map::do_bus_read: if (adapter.provides_responses) begin uvm_sequence_item bus_rsp; … rw.parent.get_base_response(bus_rsp); adapter.bus2reg(bus_rsp,rw_access); end The problem is that since tr
  5. I've run into the following issue using the built-in UVM register tests. The built-in UVM register tests (seem to) start R/W-ing immediately after top-level reset is released. This was fine, initially. See attached image "Capture". We now have some delay between the release of top-level reset and the actual reset going to the register block. This is resulting in a read occurring before reset to the rtl regblock is released, and causes the test to hang. See attached image "Capture2". Without modifying the built-in register tests/sequences, how would anyone suggest that we cleanly
×
×
  • Create New...