Jump to content

Search the Community

Showing results for tags 'recording'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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 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 Security
    • IP Security Assurance Whitepaper Discussion
  • IP-XACT
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • Commercial Announcements
    • Announcements

Categories

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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation


Company

Found 2 results

  1. Hello all, Today, I ended up in a situation where the transaction boxes in Cadence Simvision will not at the exact time where they were supposed to be. This resulted in a drift of the boxes represented in the waves. On looking closer, the box begin time happened only at 1ns resolution, whereas my agent package's resolution and even the default simulation timescale was 1ns/1ps. So I expected the boxes' begin times to be possible at 1ps resolution (not 1ns). Here are the prints from the uvm_info debug statements in my agent monitor: UVM_INFO @2832.523ns ch0_TX_QEC_OUT: after end_tr of micro_tr :DEBUG_TR UVM_INFO @2832.523ns ch0_TX_QEC_OUT: before begin_tr of micro_tr :DEBUG_TR UVM_INFO @2832.523ns ch0_TX_QEC_OUT: after begin_tr of micro_tr :DEBUG_TR UVM_INFO @2833.540ns ch0_TX_QEC_OUT: after wait for slave_cb :DEBUG_TR UVM_INFO @2833.540ns ch0_TX_QEC_OUT: before write of micro_tr :DEBUG_TR UVM_INFO @2833.540ns ch0_TX_QEC_OUT: before end_tr of micro_tr :DEBUG_TR UVM_INFO @2833.540ns ch0_TX_QEC_OUT: after end_tr of micro_tr :DEBUG_TR UVM_INFO @2833.540ns ch0_TX_QEC_OUT: before begin_tr of micro_tr :DEBUG_TR The attached figure shows how it looks in waves. When I then printed tr_micro.print() I saw that the begin_time and end_time variables in there had lost the precision in picoseconds! So I start grepping UVM source code to see how the begin_time was assigned, and I find this: function integer uvm_transaction::m_begin_tr (time begin_time=0, integer parent_handle=0); time tmp_time = (begin_time == 0) ? $realtime : begin_time; uvm_recorder parent_recorder; I believe the bug is wherever in UVM the $realtime is assigned to a time type variable. If the time type is refactored to realtime type, this issue will be fixed. With the clock period of 1.018ns, I expected each transaction box to be 1.018ns wide. But with this loss of precision in begin_time and end_time, the transaction recording happens incorrectly and shows grossly wrong transaction representation in the waves. This is highlighted with the fact that the clock period (1.018ns) is close to the timescale step of 1ns. Here is a minimal SystemVerilog example that shows the information loss in time when $realtime value is assigned to a time variable: `timescale 1ns/1ps module top; //In uvm_transaction.svh (UVM 1.2), we have: // // // function integer uvm_transaction::m_begin_tr (time begin_time=0, // integer parent_handle=0); // time tmp_time = (begin_time == 0) ? $realtime : begin_time; // // .. // //This example shows how when $realtime is assign to tmp_time of //type time, all the precision is lost. So above is as good as //assigning the time from $time instead of $realtime. // function void print_now(); realtime nowr; time now; begin nowr = $realtime; now = $realtime; // "now" loses the 1ps resolution compared to "nowr" $display("time: %t, realtime: %t", now, nowr); end endfunction : print_now initial begin $timeformat(-9, 3, " ns", 11); // units, precision, suffix_string, minimum_field_width print_now(); // -> time: 0.000 ns, realtime: 0.000 ns #1.1; print_now(); // -> time: 1.000 ns, realtime: 1.100 ns #1.23; print_now(); // -> time: 2.000 ns, realtime: 2.330 ns #1.456; print_now(); // -> time: 4.000 ns, realtime: 3.786 ns $finish; end endmodule : top
  2. I am using QuestaSim 10.3a_1 and try to record a dynamic array in the sequence item. But it doesn't show in the waveform window. When I try to fix the array size and use uvm_field_sarray_int to record it, it works well and data show as expected in the waveform windows. My code: # sequence item parameter int P_BIT_DEPTH = 10; rand int unsigned data_len; rand bit unsigned [P_BIT_DEPTH-1:0] data []; ... `uvm_field_array_int(data, UVM_ALL_ON+UVM_UNSIGNED) `uvm_field_int (data_len, UVM_ALL_ON+UVM_UNSIGNED) ... constraint c_data_size { data.size() == data_len; }; constraint c_data_size_order { solve data_len before data; }; # Sequence body task start_item(req); if (! req.randomize() with { data_len == 2; }) `uvm_error(tID, "Can't randomize ingress packet") finish_item(req); req.sprintf() always prints the right information, no matter data is dynamic or static array.
×
×
  • Create New...