Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Portland, OR

knhan930's Achievements


Member (1/2)



  1. Philipp, Thank you for the quick reply. The reason I mention about the concatenation operator is that I have a workaround that removed the random result error after replacing the concatenation operator of sc_biguint to arithmetic equations. For example, after I changed the code from code A, z = (f[3]) ? (a == (sc_biguint<1>(1), sc_biguint<width>(0))) : (f[4]) ? (a == (sc_biguint<1>(0), sc_biguint<width>)) : 0; to code B, z = (f[3]) ? (a == (1 << width)) : (f[4]) ? (a == 0) : 0; , the random result error was disappeared. The source code with code A showed random error after 6000+ iterations with unchanged input values like this: ... Iteration #: 6446 Input: 011001001110111101100010, Output: 000110100000100011100011 <= correct results Iteration #: 6447 Input: 011001001110111101100010, Output: 000110100000100101011011 <= wrong results from 6447 loops Iteration #: 6448 Input: 011001001110111101100010, Output: 000110100000100101001011 <= another wrong results Iteration #: 6449 Input: 011001001110111101100010, Output: 000110100000100101001011 <= wrong Iteration #: 6450 Input: 011001001110111101100010, Output: 000110100000100011100011 <= wrong Iteration #: 6451 Input: 011001001110111101100010, Output: 000110100000100110101011 <= wrong ... In this code, please note that the efficiency of sc_biguint<1>(1) is not the issue at this post, because it's simply translated from another source code by scripts and directives. Now code B shows no error from the output, and it does not have any valgrind nor purify error messages as well, while code A has errors. Although valgrind and purify might have a false positive, this error case shows that there is something wrong with the concatenation operator. Please correct me if there is something I missed. Thank you.
  2. Another issue I have is that I have a simple C++ code that uses only SystemC datatypes from SystemC library like below. #include "systemc.h" int main() { sc_uint<8> a, b; sc_uint<9> z; z = a + b; } It’s working with SystemC 2.2.0, but there is a link error with SystemC 2.3.0. I used the general compile command with GCC 4.2.2: % g++ -I$SYSTEMC/include test.cpp –L$SYSTEMC/lib-linux64 -lsystemc …/systemc-2.3.0/lib-linux64/libsystemc.so: undefined reference to `sc_main' collect2: ld returned 1 exit status I wonder if SystemC 2.3.0 disables to use main() at all, which was ok with SystemC 2.2.0. It may cause the compatibility issue, so I would like to know how to remove the link error. Thank you.
  3. I had a problem with a SystemC code, which generated correct results but began to produce random results after thousands of iterations. Both SystemC 2.2.0 and 2.3.0 showed the same error. What I found is that the main culprit of this error came from the concatenation operation, which was reported both by Valgrind and Purify that there were memory leaks. Let me share some testcases with these symptoms. 1. sc_uint, sc_int datatypes #include "systemc.h" int sc_main(int argc, char* argv[]) { sc_uint<4> a, b; sc_uint<8> c, z1; bool z2; a = 0x5; b = 0x3; c = 0x11; z1 = (a, b ) - c; // memory leak z2 = ((a, b ) == c); // memory leak } In this testcase, memory leak came from both z1 and z2 lines. 2. sc_biguint, sc_bigint datatypes #include "systemc.h" int sc_main(int argc, char* argv[]) { sc_biguint<4> a, b; sc_biguint<8> c; sc_biguint<8> z1, z3; bool z2; a = 0x5; b = 0x3; c = 0x11; z1 = (a, b ) - c; // memory leak z2 = ((a, b ) == c); // memory leak z3 = (a, b ); // memory leak } With sc_biguint datatype, z1, z2 and z3 lines have memory leak. Especially z3 line caused random results after iterations. So, I would like to know if it’s known issues with SystemC 2.2.0 and 2.3.0, and if there is any bug patch plan with SystemC 2.3.x or any applicable workarounds. Thank you.
  • Create New...