Jump to content

Search the Community

Showing results for tags 'uvm_reg'.

  • 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)
    • 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 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












  1. Hi there IPXACT needs to capture array of registers properly in a design. Currently there is only one tag ''spirit:dim" to represent an array of registers. This does not enable us to capture an array of register effectively. Consider the following cases: 1. An array of registers can be one dimensional with each element offset by offset address 0x10. 2. An Array of multidimensional registers something like this: register_1[0][0] -> 0x0 register_1[0][1] -> 0x4 register_1[1][0] -> 0x10 register_1[1][1] -> 0x14 ... likewise Is there any way to capture jus
  2. Hi, I have an issue where teh DUT returns an X for register read but the reg2bus still sees it as a 0. When I was going over the uvm_reg_bus_op struct the type for data is uvm_reg_data_t which is only 2-state. Is there a way to override this argument to support 3/4-state? Maybe uvm_reg_data_logic_t? Please let me know. Thanks in advance! Vignesh
  3. I have observed a register access synchronization issue in one of my simulations and want to raise this in this forum in order to get feedback if this is a bug or a misusage in some way. In the verification environment there are two register sequences running in parallel. One sequence is doing the DUT configuration and the other one is a noise sequence which switches between the different programming agents and produces some read traffic on all the programming interfaces. The issue I have observed is that the programming sequence is doing a write to a register (AHB SEQ in the image b
  4. Hi, While debugging a prediction error returned by "Bit Bashing Test Sequence", I came to read the uvm_reg_map::do_bus_read/do_bus_write methods which seems incorrect when it comes to computing the "byte enable" for the bus accesses (ie data member "byte_en" of the object of type uvm_bus_reg_op created by those functions) I'm explain the issue that I think I found here-below, can you please give me your feedback (Am i wrong or not?) My understanding about "uvm_reg_map::do_bus_read/do_bus_write" methods about is that these methods are called when I request a frontdoor rea
  5. We ran across an issue when updating registers containing W1C fields. Specifically, if any field of the CSR requires an update, then calling the parent register's update() results in all W1C fields being written with 1. Example: register CTL has field GO with access type W1C in bit 31. It has field CMD with access type RW in bits 3:0. Both fields have reset value of 0. So, coming out of reset, we do: CTL.CMD.set(2); CTL.update(); The actual transfer goes out with data of 32'h8000_0002. Nobody asked for bit 31, but there it is. The issue appears to be with uvm_reg_field method Xupdate
  6. Looking for suggestions on the best approach to modeling something akin the following. value1 and value0 are implemented as value_reg[31:0] in RTL. The value actually stored in this register is always whatever you wrote to it. However, what you read back, and what HW sees when it looks at this register depends on the value of value_mode. When value_mode == DIRECT, you'll read back the whatever value is physically stored in value_reg[15:0] as value0 and value_reg[31:16] as value1. When value_mode == MULT, you'll read back a computed value instead. Let quotient == value_reg[15:0
  7. In my test sequence, some fields of a register are changed frequently and others are keep previous value. I wrote the code like below, register.fieldY.set(value) register.update(status) // first update ... other code regsiter.fieldY.set(new_value) register.update(status) // second update The first update was processed but the second update was not seen in the system bus. I digged into UVM manual and implementation, and found out that 'update' function doesn't update mirrored value. By change, new_value was same to reset value of fieldY. So at that time the second update was call
  8. There are many threads/virtual sequences in the test that will initiate register transactions through a shared register model/bus agent. I want to give specific sequences higher priority so they will complete more quickly even when the bus is fully utilized. I tried set_arbitration(SEQ_ARB_STRICT_FIFO) on the bus sequencer, but now see this fatal message from it on the first transaction: [sEQDEFPRI] Sequence default_parent_seq has illegal priority: -1 I thought that if priority is not specified, it should default to a value like 100 and thus behave the same way as SEQ_ARB_FIFO (the de
  9. Hi, We are using snps ralgen to generate the regmodel. It appears that the ralgen creates only the default map. We would like to have 2 maps for 2 separated if masters. Is there an online example for such case? A post gen script can do one of the following 2 options: 1. add another instance of uvm_reg_map and copy/clone the ready map after finished build 2. add another instance of uvm_reg_map, and duplicate any map1.add_reg and map1.add_submap to map2 Which is preferable? Thanks! Elihai
  10. Hello , I have a scenario as below , In the dut , there is a set of registers which acts as control register for different instances of same IP inside dut. There is a control register which controls the set of registers to decide which instance of IP it needs to wr/rd . I am thinking of creating a reg block for the set of registers and instantiate as per the IP instance number. But I am not sure how the reg wr/rd of each block as per the control register IP selection . Please comment on this problem . Thanks
  11. 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
  12. 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
  13. Is there any particular reason why uvm_reg doesn't have an associated post_predict function or post_predict callbacks defined? A use model could be, for example, to check bus responses of register accesses. This is an aspect that applies to the whole register and not an individual field.
  14. Hi, In rtl design, I have a wire [3:0] d signal. It's assigned with 4 signals declared as reg type. So my question is when I try to add hdl path slice for d what should I do? I tried to add each of the four signals as slices, then in the test backdoor write to d has problem, I can't seem to pass wdata well. Ex: env. rm. d. write(...UVM_BACKDOOR) doesn't work. The d is a register naming which I create a uvm reg for it. Any input is appreciated.
  15. I added a new register to a register block, but didn't add it to the map. When I try to read it in my test I get a null pointer access in: uvm-1.2c/src/reg/uvm_reg.svh, line 2624 The bug is that get_local_map returns a null pointer and rw.map is null because it wasn't specified in the read method. But the uvm_error macro references rw.map.get_full_name() when rw.map is null.
  16. Hi there A register can have different RTL implementation based on access_mode. ie., When a register REG_1 is read in backdoor, actual HDLPATH of the register would point to 'top.abc.dout'. When a register REG_1 is written in backdoor, actual HDLPATH of the register would point to 'top.abc.dout_temp' We want to program different hdlpaths to REG_1 based on access mode (READ or WRITE). Does UVM_REG provide ready-made hookups or methods like add_hdl_path_slice() methods to setup different hdlpaths to READ/WRITE backdoor access? (Inside the DPI based backdoor access itself?) I ch
  17. Dear all, I'd like to access a register via multiple physical interfaces (bfm). Is it possible to set 2 different sequencers to the registers with same address? I have read this is a known issue from this forum. Could anybody give me a good example? I'm looking for a solution that there is no problem in prediction as well as write/read of UVM_REG. Thanks & Regards,
  18. Hello All, New here. I am wondering if there is a way to make uvm_reg_block to dump the current values of all the registers in that block to a log file? If not a built-in method, then does anybody have a snippet I could borrow. Thank you!
  19. Hi there From the UVM users guide, a register read access can be executed as reg_model.BLK1.REG_FILE1.REG_1.read(status, rdata); But this mandates us to know the hierarchy of the register instantiation. ie., 'reg_model.BLK1.REG_FILE1' needs to be known to execute a read on register 'REG_1'. Is it possible to perform read/write access based on address instead of this hierarchy? Something like: generic_uvm_read (.address(0x0), rdata); In otherwords, we need not even know the register type or register instantiation hierarchy to issue a read access to that register.
  20. Hi there I couldn't find enough information about capturing whitebox information with respect to a register defined in IP-XACT standard. Could this be done somehow? The closest that could be found was WHITEBOX information with respect to models.(not registers) Though the register definition can be captured in IP-XACT XML, there isn't proper way to capture RTL implementation of a register in IP-XACT. Capturing RTL implementation of a register in IP-XACT XML would enable us to stitch UVM_REG backdoor access. (without vendorExtensions) We feel the urge/need to enhance IP-XACT standard
  21. While playing with UVM_REG we noticed that the behavior of uvm_reg_map::get_reg_by_offset() is inconsistent. Here's a code example of what I mean: class some_block extends uvm_reg_block; some_reg my_reg; virtual function build(); // ... default_map.add_reg(my_reg, 'h10); endfunction endclass some_block my_block = new(); my_block.default_map.set_base_addr('h100); offset = my_block.my_reg.get_offset(); // offset will be 'h10 my_reg = my_block.default_map.get_reg_by_offset(offset); // my_reg will be null my_reg = my_block.default_map.get_reg_by_offset(offset + 'h100); // my r
  22. Hi , I have a top register model. in that some address part is defined as memory. ( ex :- 0x0,4,8 ,c registers address then 0x10 memory then 0x20,0x24,0x28 ... registers) I have another register model , which has all the registers which fit the space defined as memory in top register model. (ex: 0x10,0x14,0x18,0x1c as registers) could you please suggest me how to map them . Regards, Pavan.
  23. is there a way to set_rights of uvm reg for a specific map ? (like uvm_field) if no why not ? an alternative would be: reg.get_fields(field_q) foreach(field_q[i]) field_q[i].set_rights("RO") but why not allow modification of reg access directly ?
  24. One aspect that was not covered in the UVM Basics series posted by Cadence in May 2012 was the register layer (aka UVM_REG). In this new video series we are giving an overview of the concepts, components and applications of the UVM register layer. The new video series is broken up into twelve clips: Introduction Testbench Integration Adapter Predictor & Auto Predict Register Model & Generation IP-XACT Register Model Classes Register API & Sequences Access Policies Frontdoor & Backdoor Predefined Sequences Demonstration You are now registered for success! (sorry, bad pun
  • Create New...