Jump to content

Search the Community

Showing results for tags 'bug'.



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-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 4 results

  1. I think I just found a bug at the file sc_trace_file_base.cpp on version 2.3.2. It was recommended to me to report it here.The problem is at the function set_time_unit, line 193, where you can read that the parameters of the function are v and tu: void sc_trace_file_base::set_time_unit( double v, sc_time_unit tu ) As you can see, there are no restriction for the use of value v. On the code I was working at, the value was 0.5, and that is ok for SystemC 2.3.1a. However, at 2.3.2, any value of v that it is not a multiple of 10 will make the function fail in an internal assertion because trace_unit_fs = v * unit_to_fs(tu): trace_unit_fs = static_cast<unit_type>(v * unit_to_fs(tu)); Then, at the line 213, fs_unit_to_str is called: ss << fs_unit_to_str(trace_unit_fs) And in fs_unit_to_str: it:std::string sc_trace_file_base::fs_unit_to_str(sc_trace_file_base::unit_type tu) { switch (tu) { case UINT64_C(1): return "1 fs"; case UINT64_C(10): return "10 fs"; case UINT64_C(100): return "100 fs"; case UINT64_C(1000): return "1 ps"; case UINT64_C(10000): return "10 ps"; case UINT64_C(100000): return "100 ps"; case UINT64_C(1000000): return "1 ns"; case UINT64_C(10000000): return "10 ns"; case UINT64_C(100000000): return "100 ns"; case UINT64_C(1000000000): return "1 us"; case UINT64_C(10000000000): return "10 us"; case UINT64_C(100000000000): return "100 us"; case UINT64_C(1000000000000): return "1 ms"; case UINT64_C(10000000000000): return "10 ms"; case UINT64_C(100000000000000): return "100 ms"; case UINT64_C(1000000000000000): return "1 sec"; case UINT64_C(10000000000000000): return "10 sec"; case UINT64_C(100000000000000000): return "100 sec"; default: sc_assert(0); return ""; } } If the variable v is different of a multiple of 10, the function fs_unit_to_str will necessarily fail. For v = 0.5, it will always get to the default and sc_assert(0) will be activated. This function should receive the value of unit_to_fs(tu) as a parameter, or change the way this block of code works altogether. Could someone confirm if this is a bug indeed, and propose a fix for that? Thank you very much.
  2. The regression suite, files systemc-regressions-2.3.1a/tests/systemc/datatypes/fx/constructors/array.cpp systemc-regressions-2.3.1a/tests/systemc/datatypes/fx/fast_constructors/array.cpp systemc-regressions-2.3.1a/tests/systemc/datatypes/misc/test02/test02.cpp invoke undefined behaviour by converting out-of-range doubles to unsigned integers directly. This is undefined in the C++ standard See http://stackoverflow.com/a/4752947/1763356 for further information. This happens multiple most prominently in the code sc_fxval *b = new sc_fxval[4]; b[0] = (ushort)-1; for (i = 1; i < 4; ++i) b[i] = (ushort)(b[i-1] * i * -1); where negative doubles are converted to unsigned shorts, because sc_fxval only has conversions to double. It is unclear whether the test is correct and sc_fxval wrong, or vice-versa. If the later, one can avoid undefined behaviour by indirecting through a sufficiently large signed type. sc_fxval *b = new sc_fxval[4]; b[0] = (ushort)-1; for (i = 1; i < 4; ++i) b[i] = (ushort)(int64)(b[i-1] * i * -1); I was caught by this issue when testing a build of SystemC for AArch64, as part of a port I am making. As an aside, how (and where) should I attempt to upstream my port when it is ready?
  3. Hi all, I think I have located a bug in the uvm_tlm2_generic_payload class and I would like to file it. I did follow the instructions in this document: http://accellera.org/images/community/uvm/Reporting_bugs_enhancement_requests_UVM_Apr2014.pdf Is this still the recommended way of filing a bug? /JSA
  4. Hello, I am using the uvm_heartbeat object in my test bench and found that it always watches for all objection activity under the context component. By definition, it should only watch for the list of components registered to it. I found this when registering only one component to watch (my interrupt handler) and even after the component had no activity long after several heartbeat windows, a fatal HBFAIL message was not issued. Digging into the source code, I can see that the heartbeat keeps track of which components are registered by populating an associative array, like this: function void set_heartbeat (uvm_event e, ref uvm_component comps[$]); uvm_object c; foreach(comps[i]) begin c = comps[i]; if(!m_cb.cnt.exists(c)) // <-- This is the code to track... m_cb.cnt[c]=0; // <-- which components are registered if(!m_cb.last_trigger.exists(c)) m_cb.last_trigger[c]=0; end if(e==null && m_event==null) return; start(e); endfunction Skipping forward to the uvm_heartbeat_callback class, a counter is incremented every time a component raises or lowers an objection. When a component isn't found in the "cnt" associative array, it should have ignored it, but instead it sets a new index and sets the value to 0: virtual function void raised (uvm_objection objection, uvm_object obj, uvm_object source_obj, string description, int count); if(obj == target) begin if(!cnt.exists(source_obj)) cnt[source_obj] = 0; // <-- this is the bug cnt[source_obj] = cnt[source_obj]+1; // <-- BTW: isn't cnt[source_obj]++ faster? last_trigger[source_obj] = $realtime; end endfunction Instead, the code should have been written like this: virtual function void raised (uvm_objection objection, uvm_object obj, uvm_object source_obj, string description, int count); if(obj == target) begin if(!cnt.exists(source_obj)) return; // <-- bug fix cnt[source_obj]++; // <-- (seems like it should be faster) last_trigger[source_obj] = $realtime; end endfunction I have tried this change in my workspace and it works well. Thank you, David
×