Jump to content


  • Content Count

  • Joined

  • Last visited

  1. We have some different use-cases where SystemC models have to be created dynamically during application life time. According to our understanding, this is not officially supported. Our workaround is based on creating a new instance of sc_core::sc_simcontext and assign the instance to sc_default_global_context and sc_curr_simcontext. When having several instance in parallel, sc_curr_simcontext is assigned with the proper simcontext instance prior SystemC method invocations. The risk with this workaround is that sc_curr_simcontext is not mentioned in the documentation and might just disappear during further enhancements of SystemC. Class sc_simcontext is already listed as deprecated features. What do you suggest in our case to minimize the risk of not being compatible with upcoming versions of SystemC ? I would also like to point out that with the current workaround, unit testing can easily being achieved by using some of the common unit test frameworks available. They use to create different instances of the class under test when running the unit tests of a test suite. I think that other users might appreciate to perform not only model testing but perform tests on a finer granularity as well.
  2. In README file of systemc 2.3.0, Windows 7 SP1, Microsoft Visual C++ 2010 (10.0) is listed as "has been well tested". On the other hand, in src/sysc/packages/boost/config/compiler/visualc.hpp: // last known and checked version is 1400 (VC9): #if (_MSC_VER > 1500) # if defined(SC_BOOST_ASSERT_CONFIG) # error "Unknown compiler version - please run the configure tests and report the results" # else # pragma message("Unknown compiler version - please run the configure tests and report the results") # endif #endif So which one is correct? I actually see many people are using systemc under MSVC2010. So I guess the warning/error from visualc.hpp should be ignored?
  3. No problem. I know there will be errors since I manually triggered it by "link 32 bits SystemC.lib with 64bits unit-test-projec". I just want to see what is the look of the error message. I finally fixed my project so it now links well with the 64bits SystemC.lib. Thanks again.
  4. Thanks a lot. That make sense. I also find that my self-build 64-bits systemc.lib can work with my unit-test-64bits-systemc-project. So the previous problem should be in the details of my target project (somehow large). :-) Yes I misunderstood the error message, in my unit test to link 32 bits SystemC.lib with 64bits unit-test-project, what I get is actually another error :-) SystemC.lib(sc_simcontext.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'.
  5. hi, I tried to re-target the SystemC.lib to 64-bits windows system. What I did is, (1) Downloaded systemc-2.3.0 and extract it. (2) Opened the C++ project in systemc 2.3.0\....\msvc80\SystemC (within my Visual Studio 2005) (according to INSTALL: installation notes for Windows) (3) New x64 solution/project and copy project setting from Win32 (according to http://msdn.microsoft.com/en-us/library/9yb4317s(VS.80).aspx). (4) Build the new library within the x64 projects. In this way I can actually get new SystemC.lib from msvc80\SystemC\x64\Release(or Debug). Unfortunately when I link this SystemC.lib with other 64bits binaries for a final 64bits EXE I got below error message: SystemC.lib(sc_time.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' So I think the systemc.lib what I built is still 32bits. I checked the content of SystemC.vcproj and see it is somehow simple. Anyway I just want to know if others have similar experiences. Thanks.