Jump to content

Search the Community

Showing results for tags 'UVM RAL'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • 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, CRAVE, FC4SC)
    • 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 Discussion
  • SystemRDL
    • SystemRDL Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • Commercial Announcements
    • Announcements


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

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL












Found 3 results

  1. I'm trying to declare a memory like this: class some_mem extends uvm_mem; function new(string name = "some_mem"); super.new(name, 2 ** 24, 8, "RO"); endfunction endfunction Later on, I'm trying to add this memory to an address map that was created like this: default_map = create_map("some_map", 0, 4, UVM_NO_ENDIAN); By using the default value for the byte_addressing argument I want each address to represent a one byte location. The problem I'm seeing is that the uvm_reg_map_info associated with this memory shows an end address of 32'03ff_ffff and a stride of 4, instead of 32'00ff_ffff and a stride of 1. I've narrowed it down to the function uvm_reg_map::get_physical_address(...), at line 1378 of uvm_reg_map.svh: int multiplier = m_byte_addressing ? bus_width : 1; I guess this should be the other way around: int multiplier = m_byte_addressing ? 1: bus_width; Even better would be to use: int multiplier = get_addr_unit_bytes();
  2. I found that UVM register model use semaphore to avoid conflicts, and this may cause some problems: (1) when one sequence is writing some registers, and at the mean time, a UVM_BACK_DOOR is reading some registers, conflict happened. I found that the uvm_back_door reading is stoped.( in m_atomic.get(1) ) (2)another scenario: when config the registers using uvm register model in one sequence, one on fly reset happened, so I need to kill the sequence. and then uvm_do_on this sequence again. One problem came up, the second sequence will stop at the same writing register as the first sequence. I guess it also because the semaphore problems. I hope that someone will help me to solve this problems. Thanks.
  3. Hi, I have a doubt related to UVM 's RAL with compared to OVM's RGM. The OVM's RGM seems to have only two sets of registers i.e., the actual ones belonging to DUT and the other belonging to the register model(testbench side regs to mimic duts regs). But the UVM's RAL has three sets namely 1) DUT's regs as usual and 2)Mirror registers 3)Desired value registers, the 2) and 3) are part of the testbench i.e., register model side. Why is this kind of implementation has been adopted in UVM RAL where as we could accomplish our tasks with the 2 sets as is in RGM. Can any one please enlighten me regarding the advantages or usecases related to this? Thanks In advance.
  • Create New...