maehne

The application, which you want to model, will certainly profit from using the AMS extensions in the right places. In fact, there have been several attempts to enhance even further the modeling capabilities of the SystemC AMS extensions to more directly support the modeling of multiphysyical systems including non-linear behaviour. It was the topic of my PhD thesis and work continued in the European H-INCEPTION project. Publications regarding SystemC-AMS can be found, e.g., here, here, and here. Also, COSEDA Technologies provides some solutions in their commercial offerings. If you should requi

You are welcome! In general, simulation performance improves with increasing the level of abstraction of your system model. Also the choice of the model(s) of computation, i.e., the solver(s), which execute(s) your model. For DSP applications, the TDF MoC is particularly well suited. The static scheduling employed for calling the processing() member functions of the connected TDF modules in the right order ensures a high performance. Due to its multi-rate capability, it is also easy to, e.g., use coarser time steps for processing the samples in the base band part than for the samples in the HF

@HTP: Your member variables ctrl_frame and temp_sig are of type myStruct_t and sc_lv<6>, respectively, which only hold data like ordinary variables. You cannot use such variables as a signal/channel. Only the latter can be bound to ports. Your sc_fifo_out<myStruct_t> out_fifo needs to be bound to a member variable of type sc_fifo<myStruct_t>. That type implement the interface used by the sc_fifo_out<myStruct_t> port and acts as a channel implementing the FIFO behaviour. You still seem to struggle with the basic concepts of SystemC. Therefore, I recommend you to rea

The LSF and ELN MoCs are limited to modeling (switched) linear dynamic behaviour. The underlying solver cannot cope with non-linearity. This limitation was done on purpose to enable higher simulation performance for the abstract models required on system level at the cost of precision. There is no possibility to write your own LSF/ELN primitives. That said, LSF and ELN MoCs offer modulated LSF/ELN primitives (e.g., sca_lsf::sca_tdf::sca_source or sca_lsf::sca_tdf::sca_gain), which parameters are controlled by either a Discrete Event (DE) SystemC signal or a TDF signal. If you want to continuou

I suggest to first try launching your SystemC-AMS application under control of `gdb` from the command line to ensure seeing all error messages. My experience with IDEs is, that they sometimes do not show all relevant text of error messages making people look for the source of the problem in the wrong places.

SystemC 2.3.3 and later already support QuickThreads on aarch64! Maybe you just need to update your SystemC version? If you should encounter problems on this platform, feel free to report them on this forum. Using SystemC on aarch64 is probably not yet very widespread. So, we welcome any feedback!

Thanks @Guillaume Audeon for reporting the issue and proposing a possible fix! I have forwarded it to the SystemC LWG. Could you be a bit more specific, with which SystemC version you are observing the segmentation fault on CentOS 7? Did you observe it with the latest official release tar ball of SystemC 2.3.3 or with the HEAD from the official SystemC Git repository?

You are apparently not debugging the compiled executable, but the C++ source file `main.cpp`. Check the manual of Eclipse CDT on how to configure the IDE for debugging a built program. If I remember correctly (haven't used Eclipse) for some time, it should suffice to right-click on the executable in the project navigator pane and select from the context menu "Execute and debug program" or something similar.

I cannot reproduce your problem. I copied your source code to files and build it. The comparator-pdf.vcd file generated by the executable contained the following three traces for v_p, v_n, and z, which match my expectations from inspecting your code:

You are welcome @omaima!

For analogue signal traces, the tabular trace file format is better suited. Creating them is very similar to VCD trace files. You just need to use sca_util::sca_create_tabular_trace_file() and sca_util::sca_close_tabular_trace_file() to respectively open/close these trace files. The typical file extension is ".dat". These trace files can be easily imported in gnuplot, Octave, MATLAB, Excel, and other mathematical tools for plotting / post-processing. Check out IEEE Std. 1666.1-2016 clause 9.1 for details. Tracing is also discussed in Section 6.2 of the SystemC AMS User's Guide.

The cause for the empty VCD file is probably due that you call at the end the wrong closing function sca_close_tabular_trace_file(tfp_vcd) instead of the correct one sca_close_vcd_trace_file(tfp_vcd). As Martin Barnasconi wrote, VCD files are not well suited for tracing TDF, LSF, and ELN signals, because these signals tend to change at each time step. VCD is best suited for discrete event signals.

Maybe your application or one of the libraries it is using creates sc_time objects by initialising some global or static constants/variables?

Any multidimensional array can be mapped to linear storage and thus a one-dimensional array. C/C++ uses row-major order. If your 2d array deviates from that, you need to adjust ist explicitly.

Your approach is also valid. You simply cannot profit with this approach from the infrastructure provided by SystemC, e.g., tracing the communication between the nodes. Whether this may pose a problem in the future is up to you to decide.