maehne

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.

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>/lib-${SYSTEMC_ARCHITECTURE} -L/<directory_path_to_SystemC_AMS 2.1>/lib-${SYSTEMC_ARCHITECTURE} CXXFLAGS=-g -Wall -I. $(SYSTEMC_INCLUDE_DIRS) LDFLAGS=$(SYSTEMC_LIBRARY_DIRS) # List of all ecutables to be compiled EXECUTABLES = sim01_tb sim02_tb # .PHONY targets don't generate files .PHONY: all clean # Default targets all: $(EXECUTABLES) # Rules defining the targets and their dependencies and how to generate # the first from the latter. # 1st example can be directly compiled, as it only depends on one # CPP file and the headers of th source and the sink, which also # include their implementation. sim01_tb: sim01_tb.cpp source.h sink.h $(CXX) $(CXXFLAGS) $(LDFLAGS) -o $@ $< -lsystemc-ams -lsystemc | c++filt # 2nd example is constituted of two CPP implementation files, which have # to be first compiled to object files before being linked. For # big models, this is preferable, as the object files can be selectively # updated after individual modifications. sim02_tb: sim02_tb.o my_module.o $(CXX) $(CXXFLAGS) $(LDFLAGS) -o $@ $^ -lsystemc-ams -lsystemc | c++filt # GNU make knows how to compile a CPP file using compiler $(CXX) and # the flags $(CXXFLAGS). sim02_tb.o: sim02_tb.cpp source.h my_module.h sink.h my_module.o: my_module.cpp my_module.h # Clean rule to delete temporary and generated files clean: rm -rf *~ *.o *.dat *.vcd *.dSYM $(EXECUTABLES) It compiles two test benches sim01_tb and sim02_tb.

impulse is a good trace file viewer for visualising the results of simulation runs of SystemC models. "scv" hints that this format is not part of the TLM standard, but part of the SystemC Verification (SCV) library, which you can also download from the Accellera website: http://accellera.org/downloads/standards/systemc The SCV tar ball contains in the docs/ directory several PDF documents, which outline the use of transaction recording. As you can guess from their publication dates in 2003, this mechanism predates TLM-2.0. As I never used that API myself, I cannot provide further insight/guidance.

If you insist to instantiate 16 separate ports to transfer each array element separately from each other, you will also have to write/read the elements in your code one after another using, e.g., a loop over the array. From a simulation point of view, all writes will happen at the same time.

You might find the following thread helpful to address your needs:

The compiler has difficulties to decide which overload of the assignment operator it should use. You can help him by doing a static_cast<bool>(myint[7]).

Signals constitute the communication channels between your models. However, in almost all cases, you should avoid to read/write them directly. Signals are meant to be bound to ports, which constitute the interface of your modules. The read() and write() member functions of the ports are the primary functions to reading a value from the port or writing a value into it, respectively. As you can see from the class definitions of the ports in the SystemC LRM and SystemC AMS LRM, the ports do provide depending on their input/output direction overloads, which allow them to be used in most cases like a regular variable for reading and writing: sc_core::sc_in<int> de_in; sc_core::sc_out<int> de_out; sca_tdf::sca_in<double> tdf_in; sca_tdf::sca_out<double> tdf_out; ... void my_proc() { int ivar; double dvar; ivar = de_in; de_out = ivar; dvar = tdf_in; tdf_out = dvar; } Though, using the read() and write() member functions of the ports is the recommended practice as this makes it explicit that you are accessing a port instead of a variable. As this questions touches very basic concepts of SystemC (AMS), I recommend you to read a good introductory text on SystemC and SystemC AMS.

As SystemC is just a C++ library, you can pass in and out information to your model by many different means. Command line arguments are just one option. Another simple way is using the standard input, output, and error streams. You can also use sockets and named pipes. The interface to your outside world should be also properly represented in your SystemC model, e.g., by dedicated stimuli and monitor modules, which open up the required communication channels to the outside world and handle then the synchronisation. In its most simple form, you can just use blocking reads and writes to your communication channel. You may also need to cease execution to the SystemC kernel to advance simulation time using wait(). What you are asking for seems quite standard for many co-simulation scenarios and there have been many papers about this.

It is hard to guess a reason for the segmentation fault from the information that you provide. Have you tested that your simulation works properly if you convert the time range, which you passed in us/ms/sec to ns? You should also check out the core dump in the debugger. It contains a stack trace so that you can check at which point in the execution the segfault was provoked. Of course, the segfault might have occurred in some internal/standard library function, but in many cases the cause for it happened in user code. Therefore, you will have to step up stack frame per stack frame until you reached the code you have written. While doing this, examine the arguments and local variables of the current function. They might give you a hint what is going on.

Your point 1) to 4) should typically be implemented in your sc_main(). Note that you can pass into sc_main() command line arguments in the same way as you can do in plain C into main() via the argc and argv parameters. This would allow you to set up your simulation differently according to the passed parameters. Note, you don't need to call sc_main() multiple times to just change the value of a signal. An sc_signal has a write() member function, which you can call from sc_main() to update the signal's value and then continue simulation by calling again sc_start(). However, using this approach for anything but the most simple stimuli (e.g., for generating the truth table of a combinatoric circuit) becomes very tedious. Instead, stimuli should be generated from some dedicated stimuli process. Note that a TDF module is usually the best and most performant choice for generating an arbitrary stimuli for a ELN/LSF model. Regarding your planned use of the SystemC AMS model as a shared library: Please note that the SystemC simulation kernel of the Accellera proof-of-concept implementation cannot be restarted once simulation has been finished with sc_stop(). This is a long standing issue caused by the fact that certain allocated resources by the kernel are only freed once the whole OS process executing the SystemC kernel has been terminated. As long as your shared library will stay in memory, this is not the case. Therefore, you won't be able to do another elaboration and simulation. I suggest that you have a look at a good introduction book on SystemC (e.g. "SystemC from the Ground Up") and the SystemC AMS User's Guide to learn more about how to set up test benches in SystemC.

Without a minimal self-contained example exposing your problem, it is hard to give an answer to your question. Did you set besides the data pointer also the data length correctly in your instance of the TLM generic payload? By the way, in C++ and SystemC, you should not use malloc() and free() to allocate/deallocate raw memory, Instead, you should prefer to use an appropriate container or C++'s new/delete operators as a last resort.

Your problem description is a bit contradictory: If you would call your SystemC application as a new process from a really extern C program, there should be no problem as you describe it. However, if you actually mean that you have implemented your own main() function and linked it together with your SystemC application (i.e., sc_main() which instantiates your SystemC model), then you are not allowed to directly call sc_main() from the main() function! Instead, you have to call sc_elab_and_sim(argc, argv) to start elaboration and simulation of your SystemC model. After some preparations, sc_elab_and_sim() hands over control to sc_main(). See clause 4.3 of IEEE Std 1666-2011 for more details. A minimum complete example exposing just your problem would help to give a better answer.

For what it is worth, there are several open-source tools developed by academia available, which translate SystemC RTL descriptions to Verilog and vice versa: SC2V: https://opencores.org/project,sc2v GSC: https://opencores.org/project,gsc SysC2Ver: http://sysc2ver.sourceforge.net Verilator: https://www.veripool.org/wiki/verilator Verilog2C++: http://verilog2cpp.sourceforge.net ... and probably others, which can be found through a web search. The development of most of these projects was not very active over the past years, but as they are open-source, you're free to pick them up. Otherwise, I fully agree with David's statement that it is not the task of Accellera to develop such tools and also not in the commercial interest of EDA tool vendors, as it is in an area, where they can differentiate themselves most from their competition. For academia and industry there might be some interest for open-source tools as a base for custom tooling, which has to fulfil very particular needs.

How to initialise your memory content from a file is very HLS tool-specific. Check its documentation! They may or may not support it. Maybe, you'll have to use a specific IP block provided by your tool vendor.

Dynamic memory allocation in behavioural description is indeed not synthesizable, as there is no sensible mapping to digital hardware. You will have to use static memory allocation instead. Check the SystemC Synthesis Subset and the documentation of your HLS toolchain for details on how to write proper synthesizable code in SystemC.

I think you have a misconception about SystemC. It is just a library on top of the C++ language, which helps you to describe the structure and behaviour of your hardware and software system. What will be considered as hardware and what as software depends on the language elements you use: An SC_MODULE with ports will or sockets will be considered as hardware due to the semantics associated to the used classes. A header or CPP file as well as as generic functions, classes, or structs do not have any particular semantic attached to it, which would qualify them from the beginning as hardware. They only have the semantics, which are imposed by the ISO C++ standard. Grouping parameters describing different aspects of your systems in structs is a good approach. I use it for any module, which has several parameters, which interdepend from each other. I usually default initialise all members to form a sensible parameter set. The user then may alter these parameters before passing the whole struct as argument to the module's constructor. It is in the constructor, where I do consistency checks between the parameters to ensure that the module gets properly configured. If you have different sets of parameters for different use cases of your module (e.g., system-level parameters during the top-down design phase and back-annotated device-level data for bottom-up verification), they can be grouped into separate structs. Overload-resolution can then automatically choose the appropriate constructor, which derives internal secondary parameters, which are then actually used in the behavioural description of your module. To describe properties of whole systems, you may group these module parameter structs into bigger structures, to pass a single struct to your top-level module. To get better tooling support, you may consider to have a look to the SystemC CCI standard, which is currently in the public review phase: Though, I think it is a good idea that you get first familiar with C++ itself and the foundations of SystemC before continuing to model a complex system. A good book on SystemC is, e.g., "SystemC from the Ground Up" by David C. Black, Jack Donovan, et al.

Thanks for the background information on your use case. Your justification for using sc_uint_base is sound for me.

By the way, Visual Studio 2013 already has some support for C++'11 including Lambdas: https://msdn.microsoft.com/en-us/library/hh567368.aspx

You can find the requested example in the above cited clause 5.5.6 of IEEE Std 1666-2011.

You can use sc_bind() for this purpose, which is described in clause 5.5.6 of IEEE Std 1666-2011. Though, you might need to use sc_spawn instead of SC_THREAD to register your process with the SystemC kernel. If your compiler supports C++'11, you can also use a Lambda function instead of sc_bind(). Cf. to the Doulos white paper "What C++11 means to SystemC?" by David C. Black for details.

You can use sc_bind() for this purpose, which is described in clause 5.5.6 of IEEE Std 1666-2011. Though, you might need to use sc_spawn instead of SC_THREAD to register your process with the SystemC kernel. If your compiler supports C++'11, you can also use a Lambda function instead of sc_bind(). Cf. to the Doulos white paper "What C++11 means to SystemC?" by David C. Black for details.

I don't see any issue from the point of the LRM. From a methodology perspective, I think it depends on the abstraction level and use case you are targeting. On the side of modules representing actual hardware, I would probably prefer to have a port type stating clearly the width to have the compiler statically check for me the correct binding of ports and interfaces. For stimuli generators and monitors, a more generic base type is OK for me. Where it then interfaces with HW modules, I would insert a small adaptor. You may also consider to have a channel, which can bind to sc_int<W> and sc_int_base, and which then checks at elaboration time that the widths on all bound ports match.

Your Qt5 GUI and the SystemC model should run in separate threads. Access to shared state will have to be protected using the appropriate synchronisation primitives of your threading library. IEEE Std 1666-2011 provides some facilities to control the execution of a SystemC model, see, e.g., this nice presentation by John Ainsley at DATE 2012 on the "IEEE Std 1666-2011: The New SystemC Standard" from slide 17 onwards. The presentation also explains how to implement interactions between SystemC and OS threads using async_request_update() (slide 36 and onwards). There was also an interesting discussion on async_request_update in an older SystemC forum thread, which also includes an example by David C. Black. David also developed an interesting demonstrator showing some advanced techniques in SystemC.

Some comments to your code snippets: Prefer to #include "systemc" instead of "systemc.h" to avoid namespace pollution. You'll then have to prefix SystemC symbols with the appropriate namespace prefix (recommended in most cases, especially headers). In the context of functions and implementation files, you can selectively import symbols from the SystemC namespaces with appropriate using statements. Consider also to put your own classes, functions, typedefs and other declarations and definitions in a dedicated namespace to facilitate future code reuse! #include "iomanip" -> #include <iomanip> (because it is a system header) Initialization of global variables should not happen in the header file, but in the .cpp implementation file! To this end, you have to inp_image as extern. Try to avoid using preprocessor macros as much as possible! They are only rarely needed in C++. Your NBITS*() macros could be replaced by inline functions, which are optionally templatized to an arbitrary argument type T. Starting from C++'11, you could even declare them as constexpr, so that a compiler may evaluate them already at compile time. If your tool supports C++'11+, you may also declare your constants as constexpr.

From a quick glance into your source files, I see: Your headers are missing #include guards. You don't include SPPS.h in your header SPPS48.h, but your members M1, M2, and M3 are of type SPPS, which you define in SPPS.h I recommend that you don't use the header <systemc.h>, as it seriously pollutes your public namespace. Use header <systemc> instead and import only the symbols in your current namespace, which you actually use. Your constructor allocates manually memory for the members M1, M2, and M3 using "new", but lacks a destructor, which would release the objects using "delete". Anyway, this is not considered "Modern C++". Instead of raw pointers to objects of type SPPS, use a smart pointer. In your case, std::unique_ptr is probably the appropriate choice. All members of your SC_MODULE are exposed to public. This may be good for debugging, but it is better to only expose those members, which constitute the public interface of your module (i.e., at least the input/output ports, constructor, and destructor). Your SC_METHODs and SC_THREADs don't need to be public. Your approach to generate a clock signal in sc_main() is tedious the most. A clk signal of type sc_core::sc_clock is a more comfortable solution. To generate more comfortably complex stimuli, I recommend that you implement them in an own stimuli module. Therein, you can register an SC_THREAD, which performs the stimuli generation and which can easily wait for delays or event before proceeding to the next stimulus. In the same way a monitor for your output signal can be implemented. I repeat my recommendation to learn first the basics of modern C++ and to read a good book on SystemC to get more efficient in your modelling attempts!