Jump to content

Search the Community

Showing results for tags 'uvm_reg_field'.

  • 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. Hi, I wanted to use the field.mirror() task provided in the uvm_reg_field class to check only a particular field. However, I see that the field.mirror() task is just calling the parent register mirror task. Hence the entire register is read and compared which I didn't intend to do. I tried this in my sequence and I see the above mentioned behavior. This looks like a serious bug. Can you please confirm this. Regards, Shreyas
  2. Hi all, I found a possible bug in the UVM register layer. It is in file uvm_reg_field.svh at line 728-730: // Assume that the entire field is enabled if (!be[0]) return; This causing a problem in a specific corner case. The following conditions need to met: - You have a bus in your env with byte enable feature, for example APB - You have a register in your design which have a register field which crossing a byte enable border, for example in a 16 bit register there is a 16 bit width field - In your env you monitor all your register accesses and the env calls the predict() function of the UVM register layer - You do a write access with byte enable 2'b10 or 2'b01 In the above described scenario the following will happen: - In case of byte enable 2b'01: In the DUT only the LSB byte will be written but in the register layer the whole field will be updated - In case of 2b'10: In the DUT the MSB byte will be written but in the register layer the register field will not be updated at all In both cases the contents of the register in the RTL and in the UVM register layer will be different. I think UVM should not assume that the entire register field is enabled or not. It should check if the entire field enabled or just part of it. I think it is a bug in the UVM package. Can you please confirm this is a bug? If so, is this bug known for the developers? If not, how can I open a bug report for it in Mantis? Regards, David
  3. 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 called, m_mirrored and m_desired were same. That was the reason of no bus transaction. I tried below codes, and they updated my register properly. register.fieldY.set(value) register.write(register.get(), status) register.fieldY.set(value) register.update(status) register.predict(register.get(), status) However, they look like strange for me. Why I need to set desired value explicit by getting their internal desired value? Are my solutions wrong? Are there better ways in this case?
  • Create New...