Jump to content

maehne

Members
  • Content count

    217
  • Joined

  • Last visited

  • Days Won

    27

maehne last won the day on May 16

maehne had the most liked content!

2 Followers

About maehne

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Burgdorf, Switzerland

Recent Profile Visitors

1,210 profile views
  1. Let me be clear: You don't need to provide -DSCV_DISABLE_USING_NAMESPACES during the compilation of the SCV library itself. You only pass -DSCV_DISABLE_USING_NAMESPACES once you compile your application and link it to the SCV library.
  2. Hello Sumit, Do you mean that you specified -DSCV_DISABLE_USING_NAMESPACES explicitly when compiling the SCV library itself? The preprocessor definition SCV_DISABLE_USING_NAMESPACES is only meant for use in user applications, i.e., you need to pass when compiling your own code. See the RELEASENOTES section 2 for details. When we first prepared the SCV 2.0.1release, we didn't want to import the std namespace by default, but it caused too much trouble with existing code bases, which lead to this ugly method to opt out of it.
  3. maehne

    system c beginner

    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.
  4. 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 features. If this is not the default C++ version for your compiler, you must make sure that SystemC AMS and your models get compiled with the same compiler flags, i.e., also against the same C++ version. Regarding your simple SystemC AMS example: You will have to provide more information, i.e., a minimum self-contained code example plus the compiler messages so that we may help you.
  5. 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_ltf_nd_proxy.h" #include "scams/impl/core/sca_simcontext.h" #include "scams/impl/solver/util/sparse_library/linear_analog_solver.h" #include <cstring> // needed for memcpy() and memset() namespace sca_tdf { namespace sca_implementation { If you still have compilation errors, add the std:: namespace prefix to the calls of memset() and memcpy(). This issue will go away once COSEDA releases a new version of the SystemC AMS PoC, which does not rely anymore on the implicit inclusion of <cstring>, i.e., has been tested agains SystemC 2.3.2.
  6. 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.
  7. maehne

    define sc_main in VS 2017

    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.
  8. 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 simulation performance, you module srcs and sample should be connected via TDF ports and TDF signals and not via TDF<->DE converter ports and DE signals. Then, you can profit from the fact that the srcs and sample module will end up in the same static TDF schedule, which is executed by the SystemC AMS simulation kernel. I would also recommend that you don't include the SystemC/SystemC-AMS headers using <systemc.h> and <systemc-ams.h> as this pollutes the public namespace. Instead, prefer the recommended headers <systemc> and <systemc-ams>.
  9. maehne

    User Guide for systemc 2.3.2

    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.
  10. 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 16.1.4.4 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 the constraints on usage for ports and exports apply. For sc_port the following paragraph is relevant: For sc_export it is: Therefore, your example may not generate an error during compilation and elaboration, but may still disrespect the normal discipline of the module hierarchy.
  11. maehne

    How to compare VCD files

    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.
  12. maehne

    C-API for SC-AMS

    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. SystemC (AMS) only differs that the models are already written in C++, which provides even less friction to interact with the C APIs of other simulators. However, you have to keep in mind the simulation semantics of these models, which are imposed by the embedded simulation kernel during simulation. You have to make sure that you don't interfere with them through your API use in a way that disturbs the model execution. To that end, you should read up on the elaboration and simulation semantics of SystemC (AMS) in the respective LRMs. You will see there that both language standards define dedicated callbacks, which allow you to take action during all phases of elaboration and simulation, which facilitate the coupling of SystemC models with other simulators/modeling languages. You either have to implement the interface yourself or use the EDA tool vendor-specific solutions, which have been available for years, e.g., QuestaSim is capable to mixed SystemC/VHDL/SystemVerilog models. Another example is the SystemC AMS IDE COSIDE, which provides tool couplings to all major HDL simulators as well as to MATLAB/Simulink, dSPACE, and ngspice. For simple cases like you describe with your C application, which shall provide stimuli to your TDF model, you often get away with doing model synchronisation/data exchange via blocking read/write calls from within your SC_METHODs, SC_THREADs, or TDF processing() callbacks on some communication channel to your foreign model executed by another simulator. In the simplest case, this could be your stdin/stdout streams. Other popular options would be named pipes, sockets, or some some RPC API. The choice will largely depend on the modeling language/simulation tool, which you have on the other side. If they provide the possibility to import foreign C functions, they usually support all mentioned options. I think you might find interesting the technology demonstrator, which was presented by David C. Black at DVCon 2013 as part of the "Increasing Productivity with SystemC in Complex System Design and Verification" tutorial and made available on GitHub a while back: https://github.com/dcblack/technology_demonstrator You might also find other videos interesting, which are available from the Accellera website: http://videos.accellera.org/videos.html
  13. maehne

    When exactly events are created?

    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 20 ns. You notify from sc_main has no effect as you don't hand over control to the simulation kernel. Your message "MWE created" gets executed after the simulation finished. To generate stimuli for your model, it is common practice to create a custom module with SC_THREAD(s) that generate the stimuli. You may also do some monitoring from this thread. Conceptually cleaner is to separate stimuli generation and monitoring into separate modules. From your modeling goals, it seems that you could benefit from using Transaction Level Modeling (TLM), which is part of the IEEE Std 1666-2011. However, I suggest that you get first a bit more familiar with the basic concepts of SystemC and TLM by reading a good introductory book on SystemC(/TLM), e.g., SystemC from the ground up. There also some good introductory presentations, which you can find in the archives of the different SystemC User Groups.
  14. maehne

    Using Debug mode.

    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.
  15. maehne

    C-API for SC-AMS

    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 integrate it into your top-level model. You just have to limit yourself to the basic C datatypes in the function interface and to declare the functions as extern "C". From these C functions, you will have to set up the model and control its execution by providing stimuli and feeding the SystemC models reactions back to your external model. You may also implement a custom primitive channel as a co-simulation bridge to another model running in a different simulator. To facilitate synchronisation in such scenarios, IEEE Std 1666-2011 provides async_request_update() (see clause 5.15.6). That said, the main purpose of SystemC (AMS) is create virtual prototypes of entire complex SoCs early on in their design process to enable, e.g., architecture exploration, Hw/Sw partitioning, and early firmware development. This virtual prototype serves as a kind of golden reference during refinement. Therefore, your SystemC virtual prototype usually "sits on top", i.e., refined component models executed in external simulators are usually embedded via a module wrapper, which provides the SystemC interface for communication and makes use of the C API of the external simulator to communicate with the foreign model. Given that, I don't see much need for any additional dedicated C API. What are you missing?
×