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


  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Synthesizable Subset v1.4 Public Review
    • SystemC Verification (UVM-SystemC, SCV)
  • UVM (Universal Verification Methodology)
    • UVM 1.2 Public Review
    • Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • Simulator Specific Issues
    • UVM Commercial Announcements
  • Portable Stimulus
    • Portable Stimulus Discussion
    • 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


  • Community Calendar

Found 4 results

  1. Hi all, This is my first SystemC/SystemC-AMS code, so please ignore any bad coding that might exist. I wanted to design a PLL just to test SystemC-AMS. The code is available at: https://github.com/americodias/systemc-ams_pll It is working, but I had to change the signals UP and DN from sc_signal<bool> to sc_signal<unsigned char>. If I use bool I get the following linking problem: Undefined symbols for architecture x86_64: "sca_tdf::sca_de::sca_in<bool>::bind(sc_core::sc_port_b<sc_core::sc_signal_in_if<bool> >&)", referenced from: vtable for sca_tdf::sc_in<bool> in main.cpp.o "sca_tdf::sca_de::sca_in<bool>::trace(sc_core::sc_trace_file*) const", referenced from: vtable for sca_tdf::sc_in<bool> in main.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Using "sc_bit" also fix the problem, but this type is deprecated. I am using SystemC 2.3.1 and SystemC-AMS 2.1. Thanks in advance. PS: The issue seems to be on the chargepump ams module when I use "sca_tdf::sc_in<bool>" do declare UP and DN. Américo
  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. 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
  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