Search the Community

While I'm wearing my Valgrind hat, memcheck detects a few issues in the regression tests tlm/bus_dmi systemc/misc/user_guide/chpt4.4 systemc/datatypes/misc/concat/test07 I haven't looked at the first two. For the last one, here is a cut down version that reproduces the first error. #include "systemc.h" #include "valgrind/memcheck.h" void checkout( const sc_unsigned* actual_p, const sc_unsigned* expected_p ) { cout << *actual_p <<" " << *expected_p << endl; cout <<"another line" << endl; } int sc_main(int argc, char* argv[]) { int high_i = 64; int low_i = 30; sc_int_base high_int(high_i); sc_int_base low_int(low_i); sc_signed low_signed(low_i); low_int = "0x0000000000000000"; low_signed = "0x0000000000000000"; high_int = "0xffffffffffffffff"; cout << endl << dec << "[" << high_i << "," << low_i << "]:" << endl; cout << hex << " int " << (high_int,low_int) << " <- ( " << high_int << " , " << low_int << " )" << endl; const sc_unsigned* actual_p = &(high_int,low_signed).value(); { int i; std::vector<int> bits(actual_p->nbits/32+1); VALGRIND_GET_VBITS(actual_p->digit,bits.data(),actual_p->nbits/8+1); std::cout << "actual bits "; for (auto b : bits) { std::cout << b << " "; } std::cout << std::endl; } const sc_unsigned* expected_p = &(high_int,low_int).value(); if ( *actual_p != *expected_p ) { checkout(actual_p, expected_p); cout << "!!! ERROR (high_int,low_signed):" << endl; cout << " expected: " << hex << *expected_p << endl; cout << " actual: " << hex << *actual_p << endl; cout << " diff mask: " << hex << ((high_int,low_int) ^ (high_int,low_signed)) << endl; } cout << "Program completed" << endl; return 0; } A couple of things to note: I hacked the definition of sc_unsigned to make digit and nbits public so that I could access them directly. This won't compile without that change. I've added a print of Valgrind's vbits (which tells which bits have been initialized and which are uninitialized). The output is as follows 64,30]: int 3fffffffffffffffc0000000 <- ( ffffffffffffffff , 00000000 ) actual bits c0000000 0 0 ==6726== Conditional jump or move depends on uninitialised value(s) ==6726== at 0x4A1081B: sc_dt::vec_cmp(int, unsigned int const*, int, unsigned int const*) (src/sysc/datatypes/int/sc_nbutils.h:427) ==6726== by 0x4A2B106: sc_dt::vec_skip_and_cmp(int, unsigned int const*, int, unsigned int const*) (src/sysc/datatypes/int/sc_nbutils.h:500) ==6726== by 0x4A37DE0: sc_dt::compare_unsigned(int, int, int, unsigned int const*, int, int, int, unsigned int const*, int, int) (src/sysc/datatypes/int/sc_unsigned.cpp:2026) ==6726== by 0x4A37D57: sc_dt::operator==(sc_dt::sc_unsigned const&, sc_dt::sc_unsigned const&) (src/sysc/datatypes/int/sc_unsigned.cpp:1719) ==6726== by 0x4A3BEAC: sc_dt::operator!=(sc_dt::sc_unsigned const&, sc_dt::sc_unsigned const&) (src/sysc/datatypes/int/sc_nbcommon.inc:1930) ==6726== by 0x2059E3: sc_main (small.cpp:97) ==6726== by 0x4A4C579: sc_elab_and_sim (src/sysc/kernel/sc_main_main.cpp:89) ==6726== by 0x4A4C3E1: main (src/sysc/kernel/sc_main.cpp:36) ==6726== Uninitialised value was created by a heap allocation ==6726== at 0x4853224: operator new[](unsigned long) (vg_replace_malloc.c:477) ==6726== by 0x4A419DA: sc_core::sc_byte_heap::initialize(unsigned long) (src/sysc/utils/sc_temporary.h:96) ==6726== by 0x4A41406: sc_core::sc_byte_heap::sc_byte_heap(unsigned long) (src/sysc/utils/sc_temporary.h:114) ==6726== by 0x4A40C94: __cxx_global_var_init (src/sysc/datatypes/misc/sc_concatref.cpp:55) ==6726== by 0x4A40D48: _GLOBAL__sub_I_sc_concatref.cpp (sc_concatref.cpp:0) ==6726== by 0x400D2FC: ??? (in /libexec/ld-elf.so.1) ==6726== by 0x400C03C: ??? (in /libexec/ld-elf.so.1) ==6726== by 0x40098C8: ??? (in /libexec/ld-elf.so.1) The first nibble of the vbits is 'c', meaning that the top two bits are uninitialized. That makes some sense as the value is '3fff..' which has the inverse pattern, 0011 binary. Interestingly, this is one case where Valgrind detects an error that ASAN does not - ASAN has only byte level granularity, so it cannot detect cases where only part of a byte is uninitialized. That is as far as I've gotten so far. No idea yet if the issue is in 'operator,' or in 'value()'.

Hi all, In the context of a very large hardware design simulated in SystemC, we faced some issues with the large footprint of our simulator. After deep and long memory profiling we identified a potential large memory optimization by removing the unique names of each sc_object. To assess the footprint saving coming from this optimization, we tweaked the Accellera kernel implementation to remove unique name generation for objects having an automatically generated name (such as signals) and also we removed the check for name uniqueness. The results were good, in the sense that we were able to save around 17 percent of the total memory footprint for a simulation counting more 3.000.000 of sc_objects. So my questions are the following ones. Why does the SystemC standard requires (page 124) that "Each sc_object shall have a unique hierarchical name reflecting its position in the object hierarchy" ? I guess this is only for debug purposes, right ? Would it be possible to have a runtime option allowing the Accellera kernel implementation to disable this "debugging" feature for in "production" simulators ? Thank you for any answers and comments you may have on this topic, ----- Manu PS: this work has been recently published at under the title "Speed And Accuracy Dilemma In NoC Simulation: What about Memory Impact?" and will be available soon.

Hi all, I am using an LSF module consisting of a gain and integrator blocks only for calculating input and output energy of a simple ELN module. When I try to simulate a long period of time I notice that the physical memory used by the process continues to increase up to the point that the simulation is stopped due to the following exception: Error: (E549) uncaught exception: std::bad_alloc In file: ../../../../src/sysc/kernel/sc_except.cpp:98 In process: sca_implementation_0.cluster_process_0 That is probably due to the fact that there is no more free physical memory on my machine. I noticed that commenting the LSF module the simulation goes on till the end. Why LSF uses so much memory, more than ELN for example? I used LSF only because I needed the integrator block to integrate the power over time, so can I use the other MoCs to perform the same computation? Maybe by using TDF and some numerical integration method? Thanks much! Alessandro