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 Public Review
  • UVM (Universal Verification Methodology)
    • Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM 1.2 Public Review
  • Portable Stimulus
    • Portable Stimulus 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

Calendars

  • Community Calendar

Found 3 results

  1. 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?
  2. How to file a bug?

    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
  3. 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
×