maehne

The assignment operator just implements the copy operation when you want to assign the value of a variable to another one of the same type. By default, C++ generates a copy constructor and assignment operator, which will simply use member-wise assignment. This usually won't be enough if you use internally pointers and dynamic memory allocation. The sc_fifo uses the assignment operation to copy the value passed into its input into the internal buffer of the FIFO. Have a look to the Doulos FAQ on SystemC to know more about how to use user-defined data types with SystemC channels: http://www.doulos.com/knowhow/systemc/faq/#q1 For examples how to implement correctly the copy constructor and assignment operation, have a look into a good C++ book or the C++ FAQ. Here are some helpful URLs: http://www.isocpp.org/ http://www.cplusplus.com http://www.parashift.com/c++-faq/

sc_fifo_in and sc_fifo_out are already specialized ports to be connected to an sc_fifo. So, you don't need to put them as a template argument to sc_port<IF>. Regarding what kind of operations a user-defined type has to support to be communicated through an sc_fifo, have a look to clause 6.23.3 in the freely available IEEE Std 1666-2011. Basically, the output stream operator<<, an assignment operator=, and a default constructor have to be defined for that it can work.

For the macros, which are part of the official IEEE Std 1666-2011, the index of this freely available LRM is your friend: Look for all upper-case identifiers starting with either SC_ or TLM_. If they are a macro and not a constant, it is indicated in the index. If you need all macros defined by an implementation of SystemC and TLM, probably a "grep #define" on the sources is your best option.

Assertions in SystemC are not so powerful as they are in SystemVerilog. The assert condition is tested instantaneously and does not allow to express any time constraints. Still, they are very useful to test invariants inside your design. If you use the sc_assert macro of SystemC, you will get the context reported from which the assertion was triggered. Please note that this will terminate the simulation as it is considered to be of fatal severity. Use the SC_REPORT_* macros to generate messages with other severity levels. SCV mainly adds support for randomization and transaction tracing to SystemC. The verification working group is working towards the release of an updated version, which is compatible with the current version of the SystemC standard and modern C++ compilers. Work has started to bring the UVM to the SystemC world. First results were presented by the European FP7 project VERDI at FDL 2013 and the ESCUG meeting, which both took place this September in Paris: http://www.ecsi.org/fdl/program#verdi http://www.ti.uni-tuebingen.de/ESCUGM28-Paris-2013.1570.0.html

Well, as Sumit said, currently, analog simulators use primarily double for their calculations. However, SystemC is compatible with all plain old data types of C++, which also includes long double that has potentially a higher precision than double. Therefore, I would appreciate if Impulse would also support this data type.

Your question is more C++ than SystemC-related. I suggest you to read a good introduction book to C++! Your class decimal is not default constructible, as you have defined a constructor, which takes 4 arguments. Either provide a also default destructor without any arguments or provide default values to all four of its current arguments. In your module seprate_digit, you should also initialize all member variables via the initializer list of the constructor to give names to the ports in, clk, and d as well as maybe initialize you dtmp.

A quick fix should be to use the c_str() member function of std::string in the new call. This converts the std::string into \0-terminated C string returned as a const char*, which is convertible to an sc_module_name. If C++ doesn't do it automatically, a static_cast<sc_core::sc_module_name>(moduleName.c_str()) should do the trick. Regarding dynamic allocations of modules in SystemC, please have a look to sc_vector, which has been added to IEEE Std 1666-2011 and is available in SystemC 2.3. Rational and hints for its usage are available on: sc_vector: A flexible container for modules, ports and ... - Eda-Stds.org https://complex.offis.de/documents/doc_details/29-scvector-and-the-ieee-p1666-2011-systemc-standard

Hello Thomas, Thanks for implementing these very useful new features into Impulse. With each new revision you plug in gets more useful! Other people in my group have also started to work with it and find it already very handy. Regards, Torsten

Hello Sumit, Once Impulse is installed in Eclipse, you should be able to open any VCD file from the Project Explorer. If not, maybe some other editor is already associated with the file type. Then, right click on the file and Open With -> Impulse Viewer should do the trick. For DAT files, you have to explicitly specify the Impulse Viewer as Editor in the Eclipse Preferences under General -> Editors -> File Associations. Regards, Torsten

I would like to add that the TDF model of computation of SystemC AMS has semantics very close to Simulink. It is multirate capable and allows you to express sample delays, which are an integer multiple of the sampling period, directly on the input/output port of each module. Also its multi rate capabilities facilitate the modeling of DSP algorithms in SystemC. In addition, the model execution is accelerated due to the static scheduling of the execution of TDF modules' processing member function in a cluster of connected modules. Therefore, I suggest you to have a look on the SystemC AMS User's Guide available from <http://www.accellera.org/>, whether it may fulfill your needs better.

Hello Alireza, How about having separate processes to read from the individual FIFOs, which are only sensitive to the clock and the respective data_written() event? Then you are sure from where the data is coming? The order in which processes, which are sensitive to any event triggered at a specific point in time, are activated to execute is not deterministic. So you cannot do any assumptions on the activation order. Regards, Torsten

Hello Andrey, Thanks for reporting the bug! I will open an issue in the Language Working Group's bug tracker so that it will get fixed for the next proof-of-concept release. Regards, Torsten

This is not a SystemC-specific question. In C++, the data type bool has either the value "true" or "false", which are by definition converted to 1 or 0, respectively, when the boolean value is converted to an integer. Inversely, a non-zero integer value is always converted to true and a zero value converted to false. This relation between boolean values and integers allows for an optimal implementation of conditional statements using the conditional jump statement from the instruction set of a common microprocessor. Therefore, the impact of an implicit conversion between integer and booleans should usually not be noticeable in the execution performance of a program. "true" and "false" communicate much better your intent than some magical numerical constant.

Your solution is way too complicated and obfuscates your intent. Try instead the following implementation of function1: void function1(){ if ((count.read() >= 1) && (count.read() <= 50)) { FIFO_we.write(true); } else { FIFO_we.write(false); } } Your decision criteria doesn't show why you would want to use sc_ufixed instead of a plain integer type or sc_int<N> / sc_uint<N>.

Hello, the code you have written won't compile, because: - sc_ufixed does not provide a to_bool() member function as the sc_logic and bit select classes do. - you should use the read() member function of the sc_in port to access the sc_ufixed() value. However, your approach to use an SC_METHOD sensitive to the input port is correct. You will have to define a criteria, when your sc_ufixed value should be considered as true and when not. All fixed point data types provide is_neg() and is_zero() member functions, which might be suitable candidates for a conversion to bool depending on your truth criteria. A one bit sc_ufixed value doesn't make really sense or did you mean an sc_uint value? The SystemC datatypes are described in detail in chapter 7 of the IEEE Std 1666-2011, which you can download for free by following the link on www.accellera.org. Regards, Torsten

Hello Milind, your dummy_src won't work as you're mixing in it DE and TDF semantics! In the context of TDF module, you are not at all allowed to call sc_core::wait()! Instead of the while loop in your processing() callback, use something like: if (infile >> val) { output.write(val); } else { output.write(0.0); } The time distance between the output samples is defined by the module timestep, which you specified in set_attributes(). Regards, Torsten

Hello Milind, you cannot directly assign the stimuli values from a file to a TDF signal. You will have to implement a source module, which opens and reads the file using, e.g., the standard <fstream> library. If the time step between the samples is constant in the file, you can simply set the source's output port time step to that value and then read the next stimuli value from within the processing() callback and write it to the output port. If the time step varies, you can either use the new Dynamic TDF features or you can generate the stimuli by implementing a DE source (SC_MODULE), which has an SC_THREAD, which alway waits for the next time step after it has written the last value. The DE signal can be then connected via a TDF converter port of type sca_tdf::sca_de::sca_in<double> to your TDF model. You can extend both approaches to implement, e.g., interpolation between two samples. You might also want to have a look to the TU Vienna SystemC AMS Building Block library available from: http://www.systemc-ams.org/BB_library.html Regards, Torsten

This is only partially true. You can use blocking calls in an SC_METHOD, however, then your simulation won't advance. Sometimes, this is exactly what you would like to achieve with a blocking call, e.g., to synchronize your simulation with other operating system processes.

Dear Milind, SystemC AMS 1.0 doesn't offer a possibility to initialize the initial value of a DE signal of type sc_core::sc_signal<T> through a TDF converter output port of type sca_tdf::sca_de::sca_out<T>. This missing functionality has been added in SystemC AMS 2.0 with the sca_tdf::sca_de::sca_out<T>::initialize_de_signal() member function. In SystemC AMS 1.0, you will have to initialize the sc_core::sc_signal<T> directly from your top cell using the channels initialize() member function. Regarding the your sc_clock initialization problem, you're are using a deprecated pre-SystemC 2.0 version of the sc_clock constructor, which still accepts an integer argument without an associated time unit and then interprets that integer value as a multiple of the sc_core::sc_set_time_resolution(). Don't do this! Instead, replace: clk1("clk1",10, 0.5, true) with clk1("clk1",10, sc_core::SC_MS, 0.5) Please check clause 6.7 on sc_clock in IEEE Std 1666-2005 for more information on the sc_clock's constructors. An sc_clock has no knowledge at all of the time step, you assign to a TDF cluster. Indeed, SystemC has no particular knowledge about semantics of SystemC AMS. SystemC AMS has been just defined in a way that it's enhancements can be implemented and executed within the constraints and semantics defined by the SystemC standard. SystemC AMS thus doesn't need to modify the SystemC simulation kernel. That said, please be aware of the limitations of the DE<->TDF synchronization semantics, which are defined the LRM and also discussed more clearly in the SystemC AMS User's Guide. A TDF cluster is always executed at delta cycle 0 of a given SystemC time and will sample the value of a DE signal, which is valid at that time. Any value written to a DE signal via a TDF converter output port, will become valid for the DE side at delta cycle 1. I also have some concerns regarding your A2D_top_level::start_logic() thread: You probably don't want to call sc_stop() from within it, as you will force the end of the simulation after just 40 ms, whereas you initially started the simulation for 1.5 s. Instead, just wait indefinitely long using wait() without any arguments. Regards, Torsten

Hello Milind, The error message regarding the delay is caused by your calls to sca_tdf::sca_de::sca_out<T>.initialize() in the a2d_nbit::initialize() callback. By simply removing the two initialize() callbacks in this callback, the error will disappear. The reason is the semantical difference between initialize() of a TDF (converter) port and that of a DE port. The initialize() of sc_core::sc_in<T>, sc_core::sc_out<T>, and sc_core::sc_inout<T> will set the initial value of the sc_core::sc_signal<T> bound to the port. The initialize() of sca_tdf::sca_in<T>, sca_tdf::sca_out<T>, sca_tdf::sca_de::sca_in<T>, sca_tdf::sca_de::sca_out<T> will initialize the delay samples of the port. By default, a TDF port has a delay of zero! Therefore, you are not allowed to call initialize on these kind of ports in the context of the TDF module's initialize() callback. Once you specify a sample delay of n samples on a TDF ports in the module's set_attributes() callback, you can initialize the delay samples with id 0 to n-1 using initialize(val, id). For more information, have a look in the SystemC AMS User's Guide and the SystemC and SystemC AMS LRMs. Regards, Torsten

Hello, Why don't you try to start your SystemC model directly under the control of gdb. If then, the program segfaults, you can do a back trace using the command "bt" to see the call stack. The cause of the segfault is in most cases located in the last function being called that was implemented by you. Watch out for pointers being accessed without verifying, whether they point to valid addresses. Regards, Torsten

The converter ports sca_tdf::sca_de::sca_in<T> and sca_tdf::sca_de::sca_out<T> have to be bound to DE signals of type sc_core::sc_signal<T> (cf. to Figure 2.20 in section 2.3.3 in the SystemC AMS User's Guide).

A TDF signal (as well as TDF ports) can be declared in an SC_MODULE given that they're purely used for a structural description, i.e. interconnection of TDF submodules and binding of their ports to some ports of the parent module (port-to-port binding). I suggest you to have a look into the SystemC AMS User's Guide, which describes the binding rules quite well. Ralph very well pointed out the source of your compiler problems. Regards, Torsten

Looking into the src/datatypes subdirectories, I see that the SystemC datatypes aren't header-only. Therefore, you won't be able to simply include the subheaders. You will have to at least compile the datatype C++ implementation files into a separate library. I write all this under the assumption, that there is no unexpected dependency to other SystemC parts, which might complicate factorizing out the datatypes from the whole SystemC source code.

You can use sc_dt::sc_lv_base for this purpose, which takes the width of the vector as constructor argument. However, it does not allow further resizing once the object has been created. For more information, have a look to the IEEE Std 1666-2011, clause 7.9.4.