Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by maehne

  1. First, make sure that you are proficient in C++ as SystemC is a C++ library, which makes extensively use of advanced C++ features! Then, read a good introductory book on SystemC. I am personally not familiar with the SystemC Primer so cannot judge it. I found the book "SystemC from the Ground Up" by David C. Black, Jack Donovan et al. very helpful to learn SystemC.
  2. Newer compiler versions usually are accompanied by a newer implementation of the standard library. This newer version might have been optimised to reduce side-effects when including a standard header, i.e., to only include definitions that are mandated by the standard and to reduce as much as possible the inclusion of other headers, which are only needed for the implementation of its functions. Another thing, which might affect you is that newer compilers might use a newer C++ standard by default, e.g., C++'14 or C++'11. SystemC 2.3.2 already contains functions, which make use of C++'11/14 fea
  3. The compilation issue, which you describe is not a platform-dependent issue. I guess that you are compiling the SystemC AMS 2.1 PoC against the later released SystemC 2.3.2 PoC implementation. The latter contains many bug fixes and clean-ups, one of which is according to the RELEASENOTES: The memset() and memcpy() are defined in the header <cstring>. This means that the issue can be easily fixed by adding "#include <cstring>" in line 41 of systemc-ams-2.1/src/scams/impl/predefined_moc/tdf/sca_tdf_ct_ltf_nd_proxy.cpp: #include "scams/impl/predefined_moc/tdf/sca_tdf_ct_lt
  4. As my quotes from the LRM show: It is not forbidden, but strongly discouraged. Therefore, a SystemC implementation may issue a warning if the module hierarchical is not respected, but it is not required to do so. The proof-of-concept implementation of SystemC currently doesn't do this.
  5. It is correct that your SystemC application compiles and runs correct if you leave the default entry point at main() and provide yourself only sc_main(). This is by design, as you can read up in clauses 4.2 and 4.3 of IEEE Std 1666-2011. Subclause 4.3.2 states: The SystemC library provides a main() function, which calls sc_elab_and_sim(), and which in turn then calls the sc_main(), which you have to provide to set up your model and control elaboration and simulation.
  6. Yes, in SystemC AMS, as in other analog/mixed-signal simulators, good precision usually requires the setting of a small enough simulation time step. As a rule of thumb, you should set the time step in a cluster of connected TDF/ELN/LSF modules such that the signal with the highest occurring spectral frequencies is sampled with at least 5 to 10 samples per period of the highest frequency for moderate accuracy and about 20 samples per period for good accuracy. Does your configured module time step respect this with respect to the cut-off frequency and selected input signal? For best simulat
  7. I totally agree that it would be great if the example code from the "SystemC: from the ground up" book would be made available again on the internet. It is best to ask @David Black for that as he is one of the authors of the book. By the way, the second edition of the book has its own homepage: http://scftgu.com/ Unfortunately, it doesn't provide an archive with the example code sources either.
  8. I suggest that you read in IEEE Std 1666-2011 the introduction to the socket concept in clause 10.4 and then the rules for: multi-sockets in clause tlm_base_initiator_socket and tlm_base_target_socket in clause 13.2.4 of. ports in clause 5.12.4 exports in clause 5.13.4 Initiator sockets are derived from a port for interface method calls on the forward path and has an export for interface method calls on the backward path. For target sockets it is vice versa. Therefore, when you bind() sockets, the bind actually happens on the port and export. That's why th
  9. I guess you tried comparing traces in "impulse". In that case, you need to make sure that you have obtained the correct license. You need to unlock the "analyze" variant of impulse.
  10. Your arguments for foreign model reuse are valid and this is recognised by the people behind the modeling language definitions and simulators. That's why basically all common simulation tools provide some API to control the simulation programmatically from a foreign process including some means for data exchange (for stimuli and monitoring). Also, these tools usually provide a way to import foreign functions (usually at least those following the C calling conventions). By these ways, you can implement the synchronisation and data exchange mechanism between your models according to your needs.
  11. The output exposes a misconception you have about the semantics of sc_start(). Once you call sc_start(), you completely hand over control to the DE simulation kernel of SystemC to process all events, which are created by the SC_METHODs and SC_THREADs. Execution of sc_main() only continues *after* sc_start() returns because there are no events to process anymore. Because you don't call dont_initialize() after registering your SC_METHODs, they get executed right after start of simulation at 0 ns. Your request method then notifies the event with a 20 ns delay, which triggers your reply method at
  12. If you use the Makefile provided along the simple_fifo example, it should get compiled with debug symbols. On the console, you should see that the .cpp files get compiled with the "-g" switch. To actually make use of the debugging symbols, you have to execute the example in a debugger such as gdb (as Roman already pointed out). By the way, "make -d" does not influence which flags are passed to the C++ compiler. It just makes the output of make itself more verbose.
  13. Well, SystemC and SystemC AMS are just C++ libraries, which define the functions and classes that form a domain-specific language suitable for modeling complex digital and mixed-signal systems at a high level of abstraction based on different models of computation (e.g. Discrete Event, Timed Data Flow, Electrical Linear Networks, Linear Signal Flow) as well as their simulation using the embedded simulation kernel. As they are C++ libraries, it is straightforward to wrap any SystemC (AMS) model into a custom C function (or set of C functions), which respects the specific API that you need to in
  14. I am happy I could help and that you can now use the SystemC and SystemC AMS libraries on Visual Studio!
  15. Even though the INSTALL instructions for the SystemC AMS PoC mentions only Visual C++ 8.0/9.0 as well as SystemC 2.2, I would recommend you that you to try to build against the most recent release of SystemC 2.3.2 using either Visual Studio 2015 or 2013. Recent Visual Studio versions should still be able to open and convert the old provided solution files. Compared to SystemC 2.3.0, SystemC 2.3.2 fixed many errors, among them an issue with the sc_event_or_list type mentioned in your error log. Recent Visual Studio version are much more conformant to the ISO/IEC C++ standard. As I am using
  16. Do you provide a proper definition of "void sc_main(int argc, char* argv[])" in your application as entry point for your simulation? Have you made sure to not have a function main() defined at the same time? In the latter case you would need to call explicitly sc_elab_and_sim(argc, argv) to hand over control to SystemC for elaboration and simulation (which will include a call to sc_main()). Confer to IEEE Std 1666-2011 clause 4.3 for details.
  17. Maybe you could share what was the cause and how you fixed the issue?
  18. You don't seem to be familiar enough with the concept of discrete event driven simulation. Simulation stops once all events have been processed by the processes of your system or the simulation end time has been reached. If you want your simulation to continue, you have to modify your stimuli process(es) so that they keep generating stimuli as long as you wish. Again, I recommend you to read a good introductory book on SystemC before continuing with your modelling efforts!
  19. @David Black hinted you to the right solution: Look up in a good book on C++ how to properly initialise member variables in a constructor! For resources, check out this site. As an additional hint: instead of initialising your local member variables sc_fifo_e::a and sc_fifo_array::q, you are declaring local variables in their respective constructors with the same name as your member variables. These shadow the member variables and are destroyed once execution leaves the constructor: class sc_fifo_e { sc_fifo_e() : a(10) // member variables need to be initialised in order of de
  20. David is right about the wrong declaration of your matrix. However, your code has several issues related purely to C++ and not SystemC: Your local variables m, n in constructor sc_fifo_array shadow the member variables m, n. Decide at which scope you need your matrix and drop the other pair. I would recommend to declare m and n as constants and assign their values upon declaration or in the constructor's member variables initialization list. I would recommend to not use raw memory allocation for your matrix. It will be a hassle to ensure that it gets correctly deallocated. In
  21. Your description and code snippet does not provide enough context for an external person to understand your intent. Please, provide more context and possibly a sketch of you system architecture so that the code snippet can be correctly interpreted. What do you mean by "to change the values of my ports"? If each layer differs from the previous, what is a point to use a loop instead of a simple to understand sequence of statements? Do you really need to expose the reader to so much details (i.e. 26 layers) to describe your problem? Try to reduce your example and enhance it with en
  22. Your example code uses many features, which have been deprecated for good reasons already in IEEE Std 1666-2005. The Accellera proof-of-concept implementation SystemC 2.3.2 of IEEE Std 1666-2011 continued the effort to improve the code quality and facilitate the maintenance of the implementation by removing long-deprecated features and improve the compatibility with modern C++ compilers and coding techniques. I recommend that you familiarise yourself with the "Modern C++" concepts introduced by C++'11, '14, and '17 and start to modernise your SystemC models. Following are some hints to get you
  23. Then, you have to express the vectors as an appropriate data type, which fulfils the conditions for the template parameter T of the port/bound signal (cf. to clause 6.4.3 of IEEE Std 1666-2011), i.e., the data type needs to implement the equality operator==, stream operator<<, and assignment operator= as well as a default constructor. E.g., you could try to use a suitable data type from the Eigen library.
  24. This kind of functionality needs to be implemented by your VCD trace file viewer. E.g., the impulse plug-in for Eclipse available from toem.de seems to offer this kind of functionality in its "analyze" variant.
  25. The compilation command is correct except for the SystemC AMS version. You also have to check that you have chosen the appropriate lib directory for your target platform (e.g., "linux" signifies a 32-bit i686 Linux platform, "linux64" a 64-bit x86_64 Linux platform). You can try to adapt the following Makefile snippet as a starting point: # Compiler and linker flags SYSTEMC_ARCHITECTURE?=linux SYSTEMC_INCLUDE_DIRS?=-I/<directory_path_to_SystemC_2.3.0>/include –I<directory_path_to_SystemC_AMS 2.1>/include SYSTEMC_LIBRARY_DIRS?=–L/<directory_path_to_SystemC_2.3.0>/li
  • Create New...