Jump to content

Philipp A Hartmann

Members
  • Posts

    537
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Philipp A Hartmann

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. Hi Jens, There is none. According to the 1666-2011 standard (5.2.3), every module (at least in the most derived class) requires an sc_module_name parameter: As you have correctly described, the building of the hierarchy fails when creating the sc_module_name object inside the initialisation list. This is one of the reasons, the above restriction exists. I won't comment on the strong coupling you introduced between your XML-based "configuration/setup" mechanism and the model(s) itself. If you want to keep that scheme, you can introduce a static create function and make the constructor protected. Something like: static my_module* // or something like std::unique_ptr<my_module> create( pugi::xml_node node ) { return new my_module( node, node->attribute("name").value() ); } protected: ///Constructor my_module ( pugi::xml_node *node ///< xml node pointer , sc_core::sc_module_name ///< name (no need to give a parameter name) ) : // sc_module() <- explicit call not needed ... { ... } Hope that helps, Philipp
  17. It's hard to say anything about this except for: Check your compiler/toolchain setup, the library directories and the build settings in general.
  18. It seems as if the problem is with your "64-bit application", not with the SystemC library itself. The message says, the module were of type 'x64', while your current target is 'x86'. Please ckeck. Also note that SystemC on 64-bit Windows is not really tested. You should see an awful lot of compiler warnings and most of them are not known to be ignorable. /Philipp
  19. There is no sleep in SystemC. If you refer to POSIX sleep, /* #include <unistd.h> */ unsigned int sleep(unsigned int seconds); then no, it is not the same thing. wait( sc_time ) refers to the simulation time, while sleep refers to the host's system time./Philipp
  20. See sections 10.1 Introduction to TLM-2.0 – Background 17.1.1 TLM-1 Message passing interface and analysis ports – Put, get, peek, and transport interfaces – Description of the IEEE 1666-2011 SystemC Standard. Greetings from Oldenburg, Philipp
  21. Your solution is correct. That's why my example said "untested". Sorry. /Philipp
  22. I'm afraid there is no builtin way to do this. You can't just trace the value returned from ch_a_fix.to_double() as this is returned as a temporary double (and you can only trace persistent objects). You may need to use a helper process doing the translation. Something like (untested): double ch_a_fix_tr; void update_ch_a_fix() { ch_a_fix_tr = ch_a_fix.to_double(); } // in constructor ... SC_METHOD(update_ch_a_fix); sensitive << ch_a_fix; and then trace ch_a_fix_tr instead.Of course, you can wrap all of this in a helper class and implement your own sc_trace_fixed_as_double function based on it. hth, Philipp
  23. Amit, both cases are valid simulation runs, as the internal scheduling (i.e. the order, in which processes are evaluated) is implementation-defined. You need to ensure within your models, that there is no (implicit) dependency on any particluar ordering of processes within a single evaluation phase. Otherwise, you may see unexpected behaviour due to things like the event cancellation example, you quoted from the standard. Greetings from Oldenburg, Philipp
  24. There has been a discussion on tracing all signals (and ports) in a design in this forum before, see http://forums.accellera.org/topic/138-why-sc-object-menber-function-trace-deprecated/ Short answer: sc_object::trace is not part of the IEEE 1666 SystemC standard and won't work the way you expect. Secondly, sc_simcontext is also not part of the standard. You should not use it within your designs. To traverse the SystemC object hierarchy, use the sc_get_top_level_objects() and [sc_object::get_child_objects()[/i] functions. An example can be found in the thread linked above. Greetings from Oldenburg, Philipp
  25. As a general remark: You should push your HLS vendor to bundle SystemC 2.3.0 with their next release. It should be no problem, since there are very few changes that affect synthesisable code (or rather the synthesis of the models) in the first place. Secondly, there are some nice features for synthesis as well, like async_reset_signal_is (or even sc_vector, but this may be more difficult to support). Why bother? As I said in my previous post(s), you can silence the warnings originating from SystemC by using the -isystem switch:$ g++ -Wall -isystem ${SYSTEMC_HOME}/include ...If you insist to change the SystemC 2.2.0 implementation in that area, you can compare the differences in the sysc/datatypes directory between 2.2.0 and 2.3.0. This will show (in addition to quite some "real" bugfixes) the required changes to silence the operator precedence warnings. hth, Philipp
×
×
  • Create New...