Jump to content

Search the Community

Showing results for tags 'uvm_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 2 results

  1. Hi Team , import uvm_pkg::*; class hello extends uvm_transaction; rand bit [31:0]b1; rand bit [31:0]b2; `uvm_object_utils_begin(hello) `uvm_field_int(b1, UVM_PACK) `uvm_field_int(b2, UVM_PACK) `uvm_object_utils_end function new(string name = ""); super.new(name); endfunction endclass typedef struct {rand int s; rand int s3;}ss; class par extends uvm_transaction; function new(string name = ""); super.new(name); endfunction rand bit [31:0]s1; rand bit [31:0]s2; ss se; rand hello h1; endclass class par1 extends par; `uvm_object_utils_begin(par1) `uvm_field_int(s2, UVM_PACK) `uvm_field_int(s1, UVM_PACK) `uvm_field_int(se.s, UVM_PACK) `uvm_field_object(h1, UVM_PACK) `uvm_field_int(h1.b1, UVM_PACK) `uvm_field_int(h1.b2, UVM_PACK) `uvm_object_utils_end function new(string name = ""); super.new(name); endfunction endclass module top; par1 p; bit [7:0]que[]; initial begin p = par1::type_id::create("p"); p.randomize(); p.pack_bytes(que); //p.s1 = 3; p.s2 = 4; $display("%h, %h", p.s1, p.s2); //que = {p}; $display("%p", que); //$display("%p", p); //que = p; //que = {<<8{new(p)}}; end endmodule I want to pack in form of bits in below format que = {<<8{p.s2, p.s1, p.se.s, h1.b1, b2}} How do i achieve this..?? // que = {<<8{p.s2, p.s1, p.se.s}} //this one is working using uvm field macros. but when i add h1.b1 and h1.b2 which are sub class variables it is not working. How do i acheive this.?
  2. 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 read/write access and I don't supply a user frontdoor sequence. these methods aimed at splitting the high level object uvm_reg_item into as many uvm_bus_reg_op as need on the real bus. part of their role is to compute bus lane "byte enable" based on length and base address for a UVM_REG and length, base address and field offset in the reg for a UVM_FIELD The "uvm_reg_map::do_bus_read/do_bus_write" code extract I'm interested in here given here below with focus on bus byte enable (rw_access.byte_en) computation: task uvm_reg_map::do_bus_write (uvm_reg_item rw, uvm_sequencer_base sequencer, uvm_reg_adapter adapter); [...] uvm_reg_byte_en_t byte_en = -1; // <= here the default value of byte_en is set to 'all ones' [...] foreach (rw.value[val_idx]) begin: foreach_value [...] /* calculate byte_enables */ if (rw.element_kind == UVM_FIELD) begin // <= here byte_en is re-computed for UVM_FIELD only, not for UVM_REG [...] end [...] foreach(addrs[i]) begin: foreach_addr [...] uvm_reg_bus_op rw_access; [...] if (rw.element_kind == UVM_FIELD) begin // <= here the slice of the computed byte_en corresponding to // the current bus address is applied to the bus (rw_access.byte_en) // for UVM_FIELD only, not for UVM_REG for (int z=0;z<bus_width;z++) rw_access.byte_en[z] = byte_en[curr_byte+z]; end [...] rw_access.byte_en = byte_en; // <= here for UVM_REG, the default 'all ones' byte_en value is applied // and for UVM_REG, the correct value of rw_access.byte_en assigned above is // erroneously overwritten [...] end: foreach_addr [...] end: foreach_value endtask: do_bus_write But the extract of code here-below shows two issues: for a read/write to a UVM_REG, the byte_en is hard coded to "all ones" which seems incorrect to me in at least 2 cases: if the bus is 4-Byte wide, a register R1 to write is 1-Byte wide and at address 1 and another register R0 is also 1-Byte wide and located at address 0, then trying to write R1, will also write R0. if the bus is 4-Byte wide, a register R0 to write is 6-Byte wide and at address 0 and another register R1 is 1-Byte wide and located at address 6, then trying to write R0, will also write R1. for a read/write to a UVM_FIELD, there's a complex computation of byte_en for the whole field , then another computation to extract the correct bus byte enable from the whole field byte_enable. Those 2 computations seems correct to me but the last assignemnt "rw_access.byte_en = byte_en;" breaks everything by systematically setting the same bus byte enables value. For a field spanning several bus addresses this is correct/acceptable for the first bus access but this incorrect for the other bus accesses. Any feedback welcome, thank you Jordan
  • Create New...