Jump to content

Philipp A Hartmann

Members
  • Content Count

    535
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Philipp A Hartmann

  1. In addition to Thorsten's comments, your main problem is that you call the processes directly instead of invoking sc_start. You should never call process functions manually. They are scheduled by the kernel during the simulation instead. Here's a cleaned up version of your sc_main: int sc_main(int /*argc*/, char* /*argv*/[]) { sc_signal<double> force_main("force main"); sc_signal<double> area_main("area_main"); stimuli_pressure_mech S("stimuli_pressure_mech"); S.force_out(force_main); S.area_out(area_main); pass_on_impulse PI("pass_on_impulse"); PI
  2. You can check out the example Makefiles in the installation (examples/build-unix/Makefile.{config,rules} and e.g. examples/sysc/simple_bus/Makefile) as a starting point. The files in examples/build-unix are reasonably generic, and you may "just" need to adjust the settings in Makefile.config. In the project's Makefile itself, you then set the PROJECT variable and your SRCS (to point to your source files). Admittedly, documentation could be better (as usual), but you can ask here, if you have further questions. The CMake support included in SystemC 2.3.2 is still experimental and is mostl
  3. Hi Matthias, IIRC, KPNs require that inputs are available on all incoming connections for an actor to fire. In your model, you already consume tokens from some inputs while being then blocked at others. This can be the reason that you don't see the deadlock in your model. But of course, you can also have deadlocks under this approach. Maybe you can trigger it by just switching the order of some of the read statements in your multi-input actors. As a general solution, you need to use a similar pattern as recently discussed in the following thread: Here's an example fo
  4. Hi Patrick, You can use every Copyable/CopyAssignable type with sc_fifo or tlm_fifo, as entries are always copied in and out of the fifo slots. There is no special support for e.g. move-only types, yet. It might be a nice to explore options to add such support in order to reduce the cost for passing complex types through fifos. So yes, you can pass std::shared_ptr and std::vector, but e.g. not std::unique_ptr. Greetings from Duisburg, Philipp
  5. The model you describe is not "just" a passthrough model though, as you assume that tokens can be both intercepted (other processes reading from incoming_fifo) and injected (other processes than B writing to outgoing_fifo). From my experience, it is very difficult to design robust models with multiple readers and writers for FIFOs, at least without higher-level synchronization orchestrating the accesses somehow. That said, let's assume these arbitrary FIFO accesses are needed and OK for your use case. I would suggest to indeed use the non-blocking APIs to do the forwarding: while( tr
  6. When you use MSVC 2015/2017, did you make sure to use SystemC 2.3.2? Earlier SystemC versions did not support such recent versions of MSVC. When you say "regression tests", do you mean the SystemC regression test suite? If so, please check the accompanying README_windows.txt for any steps you might have missed. If this still doesn't help, please post some more details on what exact errors you see. Greetings from Duisburg, Philipp
  7. Ok, now I understand your concern: It's also about stack-allocated variables in your threads that are not cleaned up at the end of the simulation, as their stacks are not unwound and dynamic process stacks may not even be explicitly deallocated. I'm not sure, if these cases qualify as real memory leaks, though. Small comment: instead of throwing an (non-standard) sc_halt object, you can simply call : h.kill(SC_INCLUDE_DESCENDANTS); // also kills all child processes There is currently no way to obtain (or kill) all running processes in the simulation, but you can roll your own fun
  8. If you invert the logic and add a function add_initiator to the interconnect, temporarily storing the pointer to the to-be-connected initiator socket (and maybe a name, although this can be derived from the given socket or its parent), you can complete the binding and target socket creation in the interconnect's before_end_of_elaboration hook. Sockets instantiated in this function will be placed correctly in the hierarchy and this approach is fully standards-compliant.
  9. Starting with SystemC 2.3.2, the MSVC project files shipped with the package use the DLL-based runtime library. Therefore it is not necessary (instead rather harmful) to select the statically linked runtime library in your application. Secondly, you should not set the SC_SIGNAL_WRITE_CHECK environment variable to DISABLE (unrelated to your current issue, but suggested in the video above). More instructions on using MSVC with SystemC can be found in the INSTALL file shipped with the proof-of-concept simulator. Hope that helps, Philipp
  10. As said above, for the TLM-2.0 interconnect case, you can just use multi sockets on don't add additional sockets to the interconnect model at all. My question hasn't been on the "surrounding side", but on the usage of the sockets inside the interconnect and the cpu/mem/uart models. Thes modules actually have to make use of the "injected sockets", which likely requires some additional hacks. How does the memory handle a second "tgt()" socket during simulation? How does the CPU suddenly leverage a second initiator?
  11. While most of the things in the referenced discussion still hold, we slightly extended the "thread cleanup" in the recently released SystemC 2.3.2. Can you please try, if the behavior improves when using the new version? Thanks, Philipp
  12. To me, this approach still looks backwards. If you need to finalize things in the model after the configuration is complete (e.g. spawning threads, etc), you can use the before_end_of_elaboration hook. You can even do the instantiation itself there, if needed, by just storing the pointer to the master and doing both instantiation and process spawning during before_end_of_elaboration. Adding emplace_back to sc_vector would just reduce the boilerplate of the delayed instantiation of structural members. But there are already ways to achieve all of this without any changes to the languag
  13. Both versions are non-portable, as the SystemC simcontext is not part of the standard either. I am even surprised that the hierarchy_push/pop functions are not restricted (as they should be). So the first solution might in fact break in future versions of SystemC as you shall not mess with the object hierarchy stack yourself. Whether or not the "hierarchy scope guard" can be extended to become a standardized solution will likely require some discussions first, especially how to avoid breaking the object hierarchy. Certainly, this internal hierarchy stack is not something to arbitraril
  14. Recommended practice is to put SC_HAS_PROCESS within the scope of the module itself: SC_MODULE(Module) { SC_HAS_PROCESS(Module); // ... }; Hope that helps, Philipp
  15. Hi Ameya, thanks for testing the 2.3.2 public review release! You mentioned, that you saw 15 errors when running the regressions on your platform? Would it be possible to share the list of failing tests and your platform/compiler versions? As you may have seen, I have opened a new topic about your C++ standard question here: Thanks for the analysis and the reporting of the issue. I have prepared a fix for the 2.3.2 final release which avoids the need for the synthesis of the ..._FILTER variable in test script. Instead, the optional filter is substituted directly from with
  16. Hi Ameya, you're right: The SystemC 2.3.2 release selects a particular C++ standard to build upon and enforces consistency of this selection between the model and the library at link-time. Users can override the detection by setting the SC_CPLUSPLUS macro at build time to a (usually earlier) C++ version, as documented in the RELEASENOTES and INSTALL files of the SystemC 2.3.2 public review release. RELEASENOTES: 5) Initial support for C++11/14 =============================== This package includes an initial implementation of the C++11/14 proposal, presented at DVCon Europe
  17. In the SystemC 2.3.2 review thread Ameya Vikram Singh (@AmeyaVS) reported the following observation: I'll open a separate topic to discuss the details.
  18. Hi Jonas, for now, this is a known leak (as stacks from statically created processes are currently deliberately not deleted) and allocations from sc_core::sc_cor_pkg_*::create should be suppressed. (Dynamically created threads are not affected, so it is not a "real" leak). Greetings from Duisburg, Philipp
  19. I'm afraid, we need a more detailed analysis / debugging from someone, who has access to such a platform. Otherwise, we can just disable QuickThreads on Cygwin again and select Pthreads consistently instead. @Ralph: Can you try hunting this down in a debugger? Thanks, Philipp
  20. You need to add the preprocessor symbol SC_INCLUDE_DYNAMIC_PROCESSES to your build setup to enable sc_bind in SystemC, e.g. on the compilar command-line: -DSC_INCLUDE_DYNAMIC_PROCESSES. hth, Philipp
  21. You can use a custom "creator" to initialize elements of a vector with custom constructor parameters - here the inner vector. Something like this (assuming you have lambda support available): auto element_creator = [](const char* nm, size_t) // optional, depending on the "real" value type { return new sca_module(nm); }; size_t inner_size = 42; // adjust for your needs, could also be a vector of sizes element.init( outer_size, [&](const char* nm, size_t) { return new sc_vector<sca_module>( nm, inner_size, element_creator ); } ); If you don't have lambdas in you
  22. Hi VanTeo, to me, the following line looks suspicious: You said, SCI_func inherits from sc_module, but you pass in a string constant to its constructor from the derived SCI class. This will disrupt the SystemC object hierarchy, as the corresponding sc_module_name argument will be destroyed too early. If you want to use the SC_CTOR macro, you should add a protected default constructor to the SCI_func base class, allowing to take the name from the current top of the naming stack. See IEEE 1666-2011, section 5.3.3 for more details about passing sc_module_name arguments through the
  23. You need to define the preprocessor symbol "SC_INCLUDE_DYNAMIC_PROCESSES" before including SystemC, when you use the TLM-2.0 convenience sockets. The preferred way to do this is to add it to your compiler command-line switches ("-DSC_INCLUDE_DYNAMIC_PROCESSES"). hth, Philipp
  24. The function to set attributes for TDF MoC elaboration is called set_attributes() (plural form). You should be able to find such an error quite quickly by either adding simple debugging messages ("printf-debugging") or by using a proper debugger. Greetings from Oldenburg, Philipp
  25. Usually it is better to start a new topic in this forum, when there is a new question. Secondly, you should always provide the detailed error message given by the compiler. It is not entirely clear to me, what you are trying to achieve, because you do not show the all relevant parts of the code. Irrespectively of any tracing, you always need to connect the ports through appropriate channels (TDF or SystemC signals in your case). Last, but not least, a wild guess regarding the compiler error: In case you've copied the code directly to the browser and depending on your comp
×
×
  • Create New...