Philipp A Hartmann

I don't know the details of the OVP build system. You should probably consult the documentation provided by Imperas on how to add additional compiler and linker flags to the build. Why don't you just check what happens to the g++ call if you set the SYSTEMC_CXX_FLAGS variable? /Philipp

Mehmet, "SYSTEMC_CXX_FLAGS" is a variable used in your local build scripts/Makefiles? Can you post the resulting compiler/linker calls? When building the SystemC library, you need to run the configure script first. When invoking this script, you can pass several options to it. One of these options is "--disable-async-updates". See INSTALL file in the SystemC package for more information. Greetings from Oldenburg, Philipp

As Alan said, you can't initialize a class member within the body of the class definition in C++ (not SystemC specific). You need to write a constructor instead. Something like: template <sc_switch FIXPT> class abc { sc_fxcast_switch fxc; sc_fxcast_context fxc_context; // members sc_fixed<....> a, b, c; public: // default constructor abc() : fxc(FIXPT) , fxc_context(fxc) {} // ... }; Greetings from Oldenburg, Philipp

Rajesh, Not necessarily. But this depends on your requirements and the rest of your interconnect model. I'd suggest that you do some experiments on your own. We can just guess, what your goals and constraints are. In case of persisting problems, you can post the relevant parts of your model and ask again. Greetings from Oldenburg, Philipp

Rajesh, You can use a tlm_utils::eq_with_cb_and_phase (see 1666-2011, 16.3). Since the extension is already stored within the transaction payload, it is sufficient to insert the payload itself: // PEQ member of module "MyModule" tlm_utils::peq_with_cb_and_phase<MyModule> m_peq; // callback member function (assuming base protocol) void peq_callback( tlm::tlm_generic_payload&, const tlm::tlm_phase& ); // in constructor: reqister callback for PEQ SC_CTOR(MyModule) : m_peq( "peq", this, &MyModule::peq_callback ) // , ... { /* ... */ } // in nb_transport_fw, gp = current transaction payload // memory management, extension handling, ... m_peq.notify( gp, phase, delay ); // insert into PEQ // PEQ callback void MyModule::peq_callback( tlm::tlm_generic_payload& gp, const tlm::tlm_phase& phase ) { // extract extension from payload // ... } Greetings from Oldenburg, Philipp

Generally speaking, a segmentation fault (and other related errors) occur within a user-space program when you try to access memory you are not supposed to access. This is not specific to SystemC. Instead of going into detail here, I recommend reading the Wikipedia article about segfaults at https://en.wikipedia.org/wiki/Segmentation_fault /Philipp

Mike, there are several functions in SystemC to access/traverse the object hierarchy and analyze the individual elements: sc_get_toplevel_objects() sc_object::get_parent_object() sc_object::get_child_objects() sc_object::kind() (or C++'s dynamic_cast) sc_port_base::get_interface() You can find a description of their functionality in IEEE 1666-2011. See the following thread for some ideas: http://forums.accellera.org/topic/129-extract-structural-information-from-systemc/ Greetings from Oldenburg, Philipp

Thanks for letting me know, that the download link is somewhat broken. I tried to fix it and it seems to be working here now. The link to the details page is https://complex.offis.de/documents/doc_details/29. In this presentation, several examples for "custom creator functions" are given. Personally, I prefer the variant of using sc_bind in combination with a local member function: // creator function (member function of surrounding block) subblock* request_scheduler_m::create_subblock( const char* nm, size_t idx ) { // call constructor with other parameters subblock* sub_p = new subblock(nm, param_1, param_2); return sub_p; } // initialize vector with custom creator subblock_vec.init( N, sc_bind( &request_scheduler_m::create_subblock, this, sc_unnamed::_1, sc_unnamed::_2 ) ); Using this variant of a creator, you can easily "store" and/or prepare the values of the module parameters within member variables of the surrounding module. Greetings from Oldenburg, Philipp

Thomas, Implicitly, it has. Accellera Systems Initiative can not relicense the code (e.g. removing the choice of venue clause), because it does not own the full copyright. Obtaining permission from all past contributors is (close to) impossible. SCV? Anyways, as I said: Feel free to contribute packaging infrastructure. The means of distribution can still be discussed separately. A lot of things are not available in the "official" Debian/Ubuntu package repositories (Adobe products, Skype, Mendeley, Opera, Steam, …) and still by providing prebuilt packages they are quite easily installable. /Philipp

If this is related to your "bare metal" question elsethread, you definitely ask for QT on ARM, not for a specific OS. The closest thing related to "QT on ARM" implementation, I'm aware of, is included in the "old stable" version of Guile (http://www.gnu.org/software/guile/). In http://git.savannah.gnu.org/gitweb/?p=guile.git;a=tree;f=qt;h=c98346f9299df235964738dbf4b87da9806c9f52;hb=72e4a3b1df86fdfca752221716c3e3f5573ff6a5, there is "md/arm.{h,s}", which may be a good starting point. When I had a closer look several years back, I think this has not been fully integrated in the QT package there. So there is probably still some work left, especially for including it in the build system and the architecture detection, etc. Maybe you can contact the original author to learn something about the status of the port. hth, Philipp

Samyak, in general, I like that you use istream and getline to read in the text file. This is a well-proven pattern in C++. Some remarks below. Why not use an std::vector here? You can't know in advance, how many lines are in the file, do you? std::vector< sc_bv<32> > Mem; Mem.reserve(256); // we expect at least 256 entries You should probably start at zero here. Otherwise, your first entry in Mem is not read from the file. You need to check the array bounds as well, otherwise you'll run into a stack overflow. while( i<256 && getline(mem_1,line) ) { Mem[i] = line.c_str(); i++; } Or you can use an std::vector and just read whatever is in the file. You can still check, if a sufficient number of lines have been read. while( getline(mem_1,line) ) { Mem.push_back( line.c_str() ); // append new bitvector } if( Mem.size() < 256 ) // error In both of the above examples, your original error has been fixed as well. You can't construct an sc_bv from an std::string, but you can construct it from a plain C-style string. You can obtain an equivalent C-style string from an std::string via the member function c_str(). Greetings from Oldenburg, Philipp

Thomas, this topic has been discussed several times in the past, both outside and inside of OSCI/ASI. Unfortunately, there's not much we can do. OSCI and ASI don't require a copyright transfer for contributions. Instead, contributions are usually made under the terms of the "SystemC Open Source License Agreement". And since the bits and pieces within the SystemC code base came from a wide variety of sources in the past ~15 years, it would take a huge effort to relicense the proof-of-concept implementation in the future. Or it may not be possible at all. Given that, I don't expect much further "progress" on this issue, especially as it doesn't solve a "real" problem. If you want to help users to easily install SystemC/TLM on Linux distributions, aligned with the distributions' package management, feel free to contribute the required RPM/DEB infrastructure under an appropriate open-source license to allow its inclusion in the proof-of-concept implementation. Together with some documentation, this could already solve most of the perceived incovenience. Greetings from Oldenburg, Philipp

Martin, obviously, this shouldn't happen. I don't have a working Clang environment running on windows, so I can't reproduce the issue for now. My guess would be, that the exception handling (combined with the process switching) works differently when using clang on Cygwin. Can you check, whether clang uses SJLJ exceptions and if the corresponding preprocessor switches are correctly matched in src/sysc/kernel/sc_cor_fiber.{h,cpp}? Last, but not least, a detailed report on the SystemC regressions using Clang on Windows would be appreciated. Preferably send the results directly to the LWG reflector (or post them here). Greetings from Oldenburg, Philipp

Sonali, it is not a bug. SystemC (more precisely libtool, which is used by SystemC 2.3.0) does not set up anything with respect to the dynamic linker paths (which can be modified e.g. by setting the LD_LIBRARY_PATH variable). The current implementation has been tested and is working as expected on a variety of platforms. Unless you come up with a clear, reproducible demonstration of any misbehaviour, I don't see the issue in the implementation and would suspect your local environment. In fact, it is expected to configure the linker correctly, also for your modified SystemC library. During the installation process, libtool explains the situation quite clearly: ---------------------------------------------------------------------- Libraries have been installed in: ... If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- As you can see, setting LD_LIBRARY_PATH explicitly is one of the expected solutions to resolve the dynamic linking. Greetings from Oldenburg, Philipp

Nizamudheen, your example works as expected on my Debian GNU/Linux system: EXT_A:1 EXT_B:2 EXT_B:2 EXT_A:1 As you can see, both extensions have the same ID across both libraries, which is what I would expect. I suspect that on your platform/toolchain the symbol resolution and initialization is different, especially for the implicitly loaded library libsc.so. You need to consult the corresponding documentation for more information, maybe you need to use RTLD_NOW and RTDL_GLOBAL (or equivalents) to properly initialize the extension libraries. Greetings from Oldenburg, Philipp

The delayed signal member function (part of global/local "watching") has been deprecated during the standardization of SystemC already for 1666-2005 and is dropped since SystemC 2.2. See http://www.doulos.com/knowhow/systemc/deprecated/ for some more information. Greetings from Oldenburg, Philipp

Nizamudheen, generally speaking, the second case should be solved by suggested fix as well. On the other hand, when you duplicate classes/functions (with global/static variables) in several .so files, there be dragons. In order to avoid symbol duplication (and therefore the risk of chosing the "wrong" implementation after loading the .so files), you should move shared extensions to common libraries as well. As I said, this holds for all class/function duplicates across .so files. You shall not use global/static variables in such cases, as the toolchain/implementation is not required to diagnose these kind of errors (see One Definition Rule). Greetings from Oldenburg, Philipp

Nizamudheen, your analysis is correct. You've implicitly entered C++'s undefined behaviour land by adding several copies of the following function (including its local static variable) to your final executable, one from each .so file using TLM extensions: // Helper function: inline unsigned int max_num_extensions(bool increment=false) { static unsigned int max_num = 0; if (increment) ++max_num; return max_num; } The proposed solution to move the implementation of all extensions to a common base library may help. But this will still heavily depend on your C++ toolchain/implementation. The "correct" solution would be to move the implementation of (at least) the function above itself to an .so file. Sometime last year, we have briefly discussed in the LWG to start moving parts of the TLM implementation from the headers to the (SystemC) pre-built library. This would help to solve this issue as well. In fact, your use case is a strong motivation for this. Greetings from Oldenburg, Philipp

Sonali, Yes, but with the correct parameters, based on configure.in (here the path to the config/ directory for aclocal). You need to run configure before running make. But you probably did, otherwise there would have been no Makefile in your new objdir. ;-) To me, it looks like your libtool script is broken. Please check the line 2089 of your libtool script. Maybe there is some variable not or incorrectly set. One explanation would have been the "wrong" call to aclocal in an earlier run. Hope that helps, Philipp

I'm not aware of a (real) bug in the autotools setup of SystemC 2.3.0. If you want/need to regenerate the autotools files, the easiest solution is to run "autoreconf": [pah@yab:~/scm/code/osci/systemc]$ autoreconf -v -i autoreconf2.50: Entering directory `.' autoreconf2.50: configure.in: not using Gettext autoreconf2.50: running: aclocal -I config autoreconf2.50: configure.in: tracing autoreconf2.50: running: libtoolize --copy autoreconf2.50: running: /usr/bin/autoconf autoreconf2.50: configure.in: not using Autoheader autoreconf2.50: running: automake --add-missing --copy --no-force autoreconf2.50: Leaving directory `.' Most importantly, note the call to "aclocal" above, which adds the "config" subdirectory (with the required ax_pthread.m4) to the search path. This should solve your pthreads "issue" during the build. Greetings from Oldenburg, Philipp

Hi Giovanni, I don't fully understand the modelling intent here. What is the relation between SIZE and N? What do you mean by "whose value is incremented"? Do the two socket arrays each share the same memory segment? If you have one socket and one "memory" bundled together, I would suggest to build (or use an existing) TLM-2 memory module, which already provides the required transport implementation. Then you can use an array of memory modules, instead of arrays of sockets and memories. Your requirements may vary, of course. From a source code perspective, you should definitely use sc_vector (SystemC 2.3.0) here. First remark: If you want to distinguish the incoming socket within your b_transport function, you should use a simple_target_socket_tagged<MyModule>. Within your constructor, you already pass the index to the register_b_transport function, which is only supported by the tagged sockets. Following the example from https://complex.offis.de/documents/doc_details/29, your module would look like: template<unsigned int N_TARGETS> SC_MODULE( MyModule ){ enum { SIZE = 100 }; int mem[size]; //should I implement it has a matrix mem[N*2][size]? read below typedef tlm_utils::simple_target_socket_tagged<MyModule> socket_type; sc_core::sc_vector< socket_type > multiple_socket; sc_core::sc_vector< socket_type > multiple_socket2; ..... } The constructor would then look like: SC_CTOR(MyModule) : multiple_socket("socket") , multiple_socket2("socket2") // these names are not very descriptive... { // initialise sockets with sizes and "custom creator" multiple_sockets.init ( N, sc_bind( &MyModule::create_socket, this, 0, _1, _2 ) ); multiple_sockets2.init( N, sc_bind( &MyModule::create_socket, this, 1, _1, _2 ) ); } // custom creator function (first parameter is the "socket vector number") socket_type* create_socket( int vec_no, const char* nm, size_t idx ) { socket_type* socket_p = new socket_type(nm); int tag = (idx*2)+vec_no; // store vector number in LSB of tag socket_p->register_b_transport( this, &MyModule::b_transport, tag ); return socket_p; } Now, you can distinguish the incoming socket by the unique "tag", passed to the b_transport function. The b_transport function could look like the following: void b_transport( ..., int id ) { int vec_no = id%2; int vec_idx = id/2; // do whatever you need with your memories, related to vec_no and vec_idx } Since I haven't fully understood your intent, it's hard to comment on the "correct" implementation of the memory arrays. Greetings from Oldenburg, Philipp

You can use the sc_elab_and_sim function (see Section 4.3.2 in 1666-2011): int main(int argc, char* argv[]) { // legacy code here int scresult = sc_core::sc_elab_and_sim( argc, argv ); // process systemC output with the legacy code } // still needed for SystemC part: int sc_main(int argc, char* argv[]) { // instantiate/initial SystemC modules // SystemC code sc_start(sim_time); sc_stop(); } Passing information between the legacy part and the SystemC part can then be done via a singleton class or by any other C++ means that fits your needs. Greetings from Oldenburg, Philipp

Pablo, This should just work as is. Here you should use the posedge/negedge functions: if(port_vec[clk_id]->posedge()) //or like this: port_vec[clk_id]->pos() This is equivalent to: if( port_vec[clk_id]->event() && port_vec[clk_id]->read() ) Greetings from Oldenburg, Philipp

In order to use sc_spawn and dynamic processes in general with the Accellera SystemC implementation, please define SC_INCLUDE_DYNAMIC_PROCESSES before including SystemC: #define SC_INCLUDE_DYNAMIC_PROCESSES #include <systemc> // or <systemc.h> hth, Philipp

The easiest solution is to use an sc_vector of ports (new in SystemC 2.3). Here is a simple example: SC_MODULE( module ) { // vector of ports sc_core::sc_vector< sc_core::sc_in<int> > in_vec; module( sc_core::sc_module_name, unsigned n_in ) : in_vec( "in_vec" ) // set name prefix { // delayed initialisation of port vector in_vec.init( n_in ); } }; For some more examples and features of sc_vector, have a look at the SystemC 2011 New Features presentation (part of SystemC 2.3.0 download archive), and/or the IEEE 1666-2011 standard, section 8.5. Greetings from Oldenburg, Philipp