Search the Community

Hi, I have 2 suggestions for the current SystemC reference implementation. I started to use pandantic compiling option for my project and this throws many warnings in SystemC headers. Altough it's annoying but there many simple fixes for unused variables. For base classes where you don't use the proposed parameter like here (one random example) ../systemc-lib/src/tlm_core/tlm_2/tlm_generic_payload/tlm_gp.h:349:57: warning: unused parameter 'ext' [-Wunused-parameter] template <typename T> void clear_extension(const T* ext) you can simply switch to this one template <typename T> void clear_extension(const T* /*ext*/) If you want I can do a pushRequest for this on github. But maybe you are not interested in this, than you could at least make it easy for users of CMake to not print them, if they compile their code. The simplest approach for this is to change the CMakelists.txt in src from ... target_include_directories(systemc PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>) .... to target_include_directories(systemc PRIVATE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}> PUBLIC INTERFACE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>) kind regards

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.

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

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?

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

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