Jump to content

Search the Community

Showing results for tags 'UVM 1.2 Public Review'.

More search options

  • 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)
  • UVM (Universal Verification Methodology)
    • UVM 2017 - Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • UVM Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM (Pre-IEEE) Methodology and BCL Forum
    • UVM 1.2 Public Review
  • Portable Stimulus
    • Portable Stimulus Pre-Release Discussion
    • Portable Stimulus 1.0
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • 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 8 results

  1. I discovered this issue when multiple sequences attempted to perform a lock() at the same time (not at all uncommon at the beginning of time when all sequences are launched). In 1.1d, the grant_queued_locks() function has a loop with the following comment: // Grant the lock request and remove it from the queue. // This is a loop to handle multiple back-to-back locks. // Since each entry is deleted, i remains constant This loop is missing in 1.2. In fact, the whole function looks to have been re-written entirely. To start, I noted that if I simply replaced the 1.2 code with the 1.1d code, the test passes. In 1.2, the second begin block in grant_queued_locks() starts out like this: // now move all is_blocked() into lock_list begin uvm_sequence_request leading_lock_reqs[$],blocked_seqs[$],not_blocked_seqs[$]; int q1[$]; int b=arb_sequence_q.size(); // index for first non-LOCK request q1 = arb_sequence_q.find_first_index(item) with (item.request!=SEQ_TYPE_LOCK); if(q1.size()) b=q1[0]; if(b!=0) begin // at least one lock leading_lock_reqs = arb_sequence_q[0:b-1]; // set of locks; arb_sequence[b] is the first req!=SEQ_TYPE_LOCK Note the variable 'b'. It starts out as being the size of a queue, but then changes to an index in the arb_sequence_q variable. If that index happens to be 0, then the 'at least one lock' if statement won't be true. This is a real issue. I'm going to try to find a patch that fixes it, but unless somebody here has an objection, I'll be submitting it to the Mantis page shortly.
  2. Hi , I would like to exchange the thoughts on built in sequences for register verification supports only accessing the valid registers. Why should we not also expect to put some transaction other than valid address so to verify that bus should not hang ? This is good thing and I think every verification engineer does himself in his verification setup. So I considered an important part this may be added to default UVM reg test seq library. As per my understanding this can be achieved in two ways: 1. Adding dummy register for invalid address range. --> so in this case built-in reg_test sequences will pick them up for access 2. Manually make the bus transaction by providing invalid address. 3. Better way(Suggestion) --> In the register layer it should calculate the lowest and highest offset and if user enables the invalid address check (either from CONFIG_DB or CONFIG_FILE) it should create the transaction in the invalid range. For 1 & 2 I have made the setup which is basically user effort. For point 3. I expect your views to make efforts further. Please suggest any better way if figured out !! Great Many Thanks for your replies. Please correct me if my assumptions/expectations are incorrect. Thanks, Karandeep

    problem in if statement

    gud mng all, In my systemverilog code, i have used if statement for giving different values to PWDATA in post randamization function. but only the first value is taken. i.e 32'hff300. but the select value is changing, but it does not get the PWDATA value. i am attaching the code here. pls help me to find me the error class my_seq_item_apb extends uvm_sequence_item; rand bit [15:0] PADDR; rand bit [31:0] PWDATA; rand bit [1:0] mem_select; rand bit [5:0] select; constraint PADDR_mem { PADDR inside { 16'h00, 16'h04,16'h08, 16'h0c,16'h10, 16'h14,16'h18, 16'h1c,16'h20,16'h24, 16'h28,16'h2c, 16'h30,16'h34, 16'h38,16'h3c, 16'h40,16'h44, 16'h48,16'h4c,16'h50, 16'h54,16'h58, 16'h5c,16'h60, 16'h64,16'h68, 16'h6c,16'h70 }; if(mem_select==2'b00) { PADDR inside{16'h20,16'h24, 16'h28, 16'h30,16'h34} }; else if (mem_select==2'b01) { PADDR inside {16'h20,16'h4C, 16'h3C, 16'h58,16'h5C} }; else if (mem_select==2'b10) { PADDR inside {16'h20,16'h60, 16'h64, 16'h6C,16'h70} }; else if (mem_select==2'b11) { PADDR inside {16'h20,16'h38, 16'h50, 16'h44,16'h48} }; } `uvm_object_utils_begin(my_seq_item_apb) `uvm_field_int(PADDR, UVM_ALL_ON) `uvm_field_int(PWDATA, UVM_ALL_ON) `uvm_field_int(PRDATA, UVM_ALL_ON) `uvm_field_int(mem_select, UVM_ALL_ON) `uvm_field_int(PWRITE, UVM_ALL_ON) `uvm_object_utils_end function new (string name = "my_seq_item_apb"); super.new(name); endfunction : new function void post_randomize(); if (PADDR == 16'h20) PWDATA[0] = 1'b1; else if (PADDR == 16'h30 | PADDR ==16'h44 | PADDR ==16'h58 | PADDR ==16'h6c) begin if (select==6'b000000 | 6'b110001 | 6'b110010 | 6'b110011 | 6'b110100) begin PWDATA[31:12] = 32'hff300; end else if(select == 6'b000001 | 6'b110101 | 6'b110111 | 6'b111000 | 6'b111001) begin PWDATA[31:12] = 32'hff380; end else if(select == 6'b000010 | 6'b111011 | 6'b111100 | 6'b111101) begin PWDATA[31:12] = 32'hff340; end else if(select == 6'b000011) begin PWDATA[31:12] = 32'hff3c0; end else if(select == 6'b000100) begin PWDATA[31:12] = 32'hff301; end else if(select == 6'b000101) begin PWDATA[31:12] = 32'hff381; end else if(select == 6'b000110) begin PWDATA[31:12] = 32'hff341; end else if(select == 6'b000111) begin PWDATA[31:12] = 32'hff3c1; end else if(select == 6'b001000) begin PWDATA[31:12] = 32'hff302; end else if(select == 6'b001001) begin PWDATA[31:12] = 32'hff382; end else if(select == 6'b001010) begin PWDATA[31:12] = 32'hff342; end else if(select == 6'b001011) begin PWDATA[31:12] = 32'hff3c2; end else if(select == 6'b001100) begin PWDATA[31:12] = 32'hff308; end else if(select == 6'b001101) begin PWDATA[31:12] = 32'hff388; end else if(select == 6'b001110) begin PWDATA[31:12] = 32'hff348; end else if(select == 6'b001111) begin PWDATA[31:12] = 32'hff3c8; end else if(select == 6'b010000) begin PWDATA[31:12] = 32'hff309; end else if(select == 6'b010001) begin PWDATA[31:12] = 32'hff389; end else if(select == 6'b010010) begin PWDATA[31:12] = 32'hff349; end else if(select == 6'b010011) begin PWDATA[31:12] = 32'hff3c9; end else if(select == 6'b010100) begin PWDATA[31:12] = 32'hff30a; end else if(select == 6'b010101) begin PWDATA[31:12] = 32'hff38a; end else if(select == 6'b010110) begin PWDATA[31:12] = 32'hff34a; end else if(select == 6'b010111) begin PWDATA[31:12] = 32'hff3ca; end else if(select == 6'b011000) begin PWDATA[31:12] = 32'hff310; end else if(select == 6'b011001) begin PWDATA[31:12] = 32'hff350; end else if(select == 6'b011010) begin PWDATA[31:12] = 32'hff390; end else if(select == 6'b011011) begin PWDATA[31:12] = 32'hff3c9; end else if(select == 6'b11100) begin PWDATA[31:12] = 32'hff3d0; end else if(select == 5'b011101) begin PWDATA[31:12] = 32'hff312; end else if(select == 6'b011110) begin PWDATA[31:12] = 32'hff352; end else if(select == 6'b011111) begin PWDATA[31:12] = 32'hff392; end else if (select==6'b10000) begin PWDATA[31:12] = 32'hff3d2; end else if(select == 6'b100001) begin PWDATA[31:12] = 32'hff311; end else if(select == 6'b100010 | 6'b101011 | 6'b101100 | 6'b101101 |6'b101111 | 6'b110000) begin PWDATA[31:12] = 32'hff351; end else if(select == 6'b100011 | 6'b100111 | 6'b101000 | 6'b101001 | 6'b101010) begin PWDATA[31:12] = 32'hff391; end else if(select == 6'b100100 | 6'b100101 | 6'b100110 ) begin PWDATA[31:12] = 32'hff3d1; end else begin PWDATA[31:12] = 32'hff392; end end else if (PADDR == 16'h34 | PADDR ==16'h48 | PADDR ==16'h5c | PADDR ==16'h70) PWDATA[0] = 1'b1; endfunction
  4. I can see that the uvm_heartbeat hasn't been updated to fix this bug: http://forums.accellera.org/topic/1256-bug-uvm-heartbeat-does-not-respect-the-comps-list
  5. Martin Barnasconi

    UVM and reserved keywords in C++

    Hello all, As you may know, the Universal Verification Methodology is currently being "ported" to SystemC/C++ to better faciliate system-level and HW/SW co-verification centric use cases. However, we noticed that the UVM SystemVerilog standard/API uses some methods which are keywords [1] in C++. For example: delete method in uvm_callbacks, uvm_queue, uvm_pool, etc catch method in uvm_report_catcher register method in uvm_factory This means that future implementations of UVM in other languages cannot adhere to the same method names, and users are confronted with these as soon as they switch from one language to another. I would highly appreciate if the UVM standardization team is willing to reconsider some of the method names, as part of the planned IEEE standardization, faciliating a better unification of the UVM API across languages. Thanks, Martin [1] http://en.cppreference.com/w/cpp/keyword
  6. The C code under src/dpi has various issues which should be improved if the reference implementation forms part of the standard. Duplicate code There is significant duplication of code in the uvm_hdl_*.c files (almost 50% duplicate code). This is clearly below the quality one would expect from an industry standard. Since the interface to the simulators use IEEE standards (VPI, DPI and VHPI) it should be possible to have a single implementation that works on any standards compliant simulator. If simulator specific workarounds are required they should be minimised. Inconsistent Features The features provided by the different implementations are not consistent. For example, VCS doesn't provide a part-select, and Questa doesn't support VHPI. The part-select capability is a useful feature and possible using standards compliant calls. Overall, rather than splitting out (and duplicating) this code into separate files for different simulators, there should be a single reference implementation. Features that depend on standards should be conditionally compiled based on the interfaces available, not the simulator itself (for example #ifdef VHPI_AVAILABLE rather than #ifdef VCSMX). Any simulator specific workarounds should be avoided if possible, with the aim of eliminating them completely. There are also various style/best practice issues with the C code - for example including a .cc inside an extern "c" block (as mentioned previously). I'm happy to contribute patches to assist with any improvements. Thanks, Chris
  7. It would be nice if uvm_in_order_comparator was extended from a common base class. Doing that would allow users to write pure virtual methods in the base class and extend those methods in the parameterized classes as required. This would simplify the handling of the comparators in environments, as implementing this approach allows working on a group of comparator objects as objects derived from the same class. As it stands now, differently typed comparator objects are treated as distinct classes without a common parent. This methodology is proposed in Dave Rich's paper here: http://go.mentor.com/yin-and-yang