• Content count

  • Joined

  • Last visited

About ralph.goergen

  • Rank
    Advanced Member

Recent Profile Visitors

319 profile views
  1. Hi. AFAIK, there is nothing like that. In TLM1 communication is based on fifos. In TLM2 it is sockets and transport calls. This is a big difference. TLM2 is conceptually different and not just a slight improvement over TLM1. What you need is a channel that does the conversion from fifo content to payload and transport calls. This is not straightforward and not possible in a generic way. Greetings
  2. Hi. Using -isystem is OK to specify includes. But the path you give it should point to your SystemC installation. Are the SystemC header files in the idrectory you specified? libs/systemc-2.3.1a/include This is alocal path relative to the location where you do the compiler call. Greetings Ralph
  3. Dear Yosri, There are so many issues in your code that it is very hard to discuss and fix it in this forum. Please start with learning some basics about SystemC and C++ first. The following tutorial (I mentioned this already earlier) is good as a starting point: https://www.doulos.com/knowhow/systemc/tutorial/ Many people like the following book to learn more: http://www.springer.com/de/book/9780387699578 For more general C++, you can find hundrefs of books and tutorials in the internet. Greetings Ralph
  4. Hi. You can find a good starting point for SystemC at: https://www.doulos.com/knowhow/systemc/tutorial/ In general: in the sc_main function, you should first instantiate your modules and bind the ports. Then you should call sc_start. And, you should not call the process methods explicitly. Greetings Ralph
  5. Hi makiso, Please write down all the indexes (values of j) that will be considered in your nested loop (or use cout to print them). The you will see that you do not go through your array. Or consider using sc_vector and the vector based binding facilities to avoid this problem. Greetings Ralph
  6. Hi. You cannot have C-style arrays of SystemC objects. This includes ports, modules, and *signals*. Use sc_vector instead. BTW: I think it should be possible to drop an sc_vector in an sc_vector to realize two dimensions. Greetings Ralph
  7. Hi. Ameya is right. See SystemC LRM (ieee1666) Section 5.2.15: [...] it is associated with the most recently created process instance [...] I.e.: ONE process created most recently before calling dont_initialize is not execute. BTW: No process is executed in the constructor. But all processes, that are not marked as dont_initialize, are evaluated once at simulation start. Greetings Ralph
  8. Hi Sumit. what you are doing here is a hierarchical module. foo is a member, i.e. a submodule of bar. They should not have the same name. If you want bar to be derived from foo, then derive bar from foo instead of sc_module. Then, you instantiation will work. If you want foo to be a submodule of bar, let the derivation as is but fix your initializer lists. You need to forward the name argument to the base class constructor in every class derived from sc_module, i.e. in bar as well. Furthermore, the submodule foo should not have the same name as its parent bar. // constructor Bar(sc_core::sc_module_name name) : sc_module(name) // forward name to base class constructor , foo("foo") // name submodule foo 'foo' { ... Or use the SC_CTOR macro that handles this for you. Greetings Ralph
  9. OK. Thanks. I now saw that there is a comparable guard expression in the sc_cor_pthread.cpp file. But I think changing this needs some more care and investigation. I forward this to the developer community. Greetings Ralph
  10. Hi, You have to forward the module name to the base class constructor: foo(sc_core::sc_module_name name) : sc_module(name) {} Or use SC_CTOR instead. Greetings Ralph
  11. Hi. There seems to be a problem with the '#if defined' expressions. MSYS gcc and clang define _WIN32, and in combination with using pthreads, SC_USE_PTHREADS is defined as well. Could you please evaluate possible fixes? E.g. adding '!defined(SC_USE_PTHREADS)' in line 33 of sc_cor_fiber.h? And could you please try with the public review version of SystemC 2.3.2 as well (http://www.accellera.org/downloads/drafts-review)? If this works, I can try to forward the issue to the SystemC developer working group. Greetings Ralph
  12. Hi. Did you set the time resolution? I think it defaults to pico seconds. See sc_set_time_resolution in the SystemC LRM (IEEE 1666) for details. Greetings Ralph
  13. How about using delta cycles? Their main reason is to bring determinism into concurrent systems. When you notify the event for the next delta cycle with e.notify(sc_core::SC_ZERO_TIME), then it will definitely see all transactions that happened in this delty cycle. Greetings Ralph
  14. Dear S. Hard to tell exactly from what you posted. Often this error appears when the compiler does not identify the first identifier given in a declaration as the name of a type. Maybe, the compiler does not see the declaration of class sc_vector. What version of SystemC are you using? Can you check if all your include and using statements are correct? Or use the fully quallified name 'sc_core::sc_vector'? One more issue: sc_vector is meant to contain objects derived from sc_object and not pointers (this is one of the advantages over std::vector). So you should do sc_vector<reg>. But I am not sure if this causes the error here. Greetings Ralph
  15. Yes you can. If you do not have a chance to update your compiler, you can still use one of the two methods mentioned in the IEEE1666 SystemC LRM Section 8.5.5: A creator function object or a member function. Both solutions are not as compact as the Lambda solution, but they do not require any C++11 feature.