maehne

The necessary sample delay to specify on a TDF port to resolve a cyclic dependency does only depend on the rates assigned to the ports, which are part of the loop. Therefore, the time step has not an impact on the schedulability of your TDF cluster. However, the time step has an important impact on the dynamic behaviour of your system, as the loop delay varies with the time step. Note also that your time step should usually at least a factor of 10 to 20 smaller than the smallest time constant in your TDF model to ensure a good accuracy. Regarding the download problems: Apparently, there was a power outage, which affected the download servers. Please, try again.

The SystemC AMS 2.0 standard specifies that the solution of a SS or LTF equation will be repeated for the last non-zero time step if the current TDF time step becomes zero. For this to happen, you need to use also Dynamic TDF features, which you must explicitly activate (accept_attribute_changes, does_attribute_changes, etc.). Do you use them? What time step have you assigned to your TDF cluster? There were some restrictions in earlier 2.0 versions of the Fraunhofer SystemC-AMS proof-of-concept implementation regarding the zero-time-stepping. Do you use the latest version from the Fraunhofer website? Its hard to give any further suggestions without some more context and ideally a minimal self-contained example exposing the problem.

Indeed, you can use an sca_lsf::sca_source to generate your constant reference signal. However, you have to use the initial_value and offset parameters instead of the amplitude: sca_lsf::sca_source Vref("Vref", Vref_, Vref_); You don't have to provide all arguments to the sca_lsf::sca_source constructor, as they are defaulted to zero. For more details, see clause 4.2.1.12.2 of the SystemC AMS 2.0 LRM.

Implementing purely derivative behavior is numerically problematic as the time-derivative of a signal at a certain point of time depends also on the future evolution of the signal. So, the best you can get is an approximation based on the past solution points. This alone may already explain your observation of "very strange values, ranging from 0 to -1.59561833143e+47". However, in addition, you have neglected that your stimuli signal is not continuous, but changing discretely: you provide it via a DE signal, which gets sampled with a time step that is equal to the time step that you assigned to the ELN circuit or connected TDF cluster. I agree, using an sca_lsf::sca_dot primitive may be the more straightforward way to implement derivative behavior. However, you will probably encounter the same problems. For good convergence, both, ELN and LSF models, require more constraints in form of other primitives (like the resistor suggested by Sumit) to "slow down" the reaction of the system. Therefore, also implementing the derivative as an LTF equation G(s) = s in the context of a TDF module is usually not working well. In that case calculating the difference quotient m = (current_val - last_val) / t_step may provide you with a first approximation for the derivative. However, be a aware that this works best for smooth continuous signals. Any noise present on the signal will get considerably amplified.

Hello Thomas, Thank you for these good news! I will give this new feature a try in the coming days. Regards, Torsten

The equation setup error occurs because the inductor Ls acts also as a current source during DC operation point calculation so that you have two conflicting current sources in the same branch (there's no current flowing through the vsink branch). The problem can be solved by specifying that the initial linked flux phi0 is undefined by assigning sca_util::SCA_UNDEFINED to Ls->phi0 (confer to SystemC AMS LRM 2.0, clause 4.3.1.8.1 for details). Please note that your rlc module lacks a destructor, which deletes the instantiated sub-modules.

Well, it depends on the context in which you want to use this thermal model, i.e., what kind of other components shall connect to it. Heat flow can be modeled in ELN, LSF, and TDF MoCs: Using ELN, you can build an equivalent electrical network, where the electric potential is equivalent to the temperature and the current to the heat flow (attention: this gives a system where the product of the effort and flow quantities is not the power, as the heat flow is already of dimension power). Resistors model then heat dissipation and capacitors heat storage. Using LSF, you can build the equivalent state space equation describing the heat flow using the provided block diagram primitives as a structural model. Using TDF, you can directly create the state space equation system using an instance of the sca_tdf::sca_ss class as a solver, which is parameterized by matrices of type sca_util::sca_matrix, which provide the coefficients of the ODE and a stimuli vector and state vector of type sca_util::sca_vector. If you already have the ODE and don't require energy conserving interconnections of your thermal model, TDF may be the most straightforward implementation road. However, if you need to interconnect thermal models through heat links to more complex thermal networks, then you should think about doing it with ELN by encapsulating sub-networks of the ELN primitives into SC_MODULEs, which represent your individual elements of your heat flow network. In the latter case, TDF will still play an important role to provide the stimuli to the thermal network. Personally, I would not use the LSF MoC for your application: The expressiveness of the LSF primitives is limited and leads to a relatively cumbersome usage, e.g., requiring you to cascade adders if you want to add up more than two quantities. For more details of using TDF, ELN, and LSF, please confer to the SystemC AMS User's Guide. For specific questions, you can use the forum.

You are welcome.

How many threads are actually instantiated per core? I guess more than one as 64 different sc_threads doesn't sound like too much. What SystemC version are you using? I strongly suggest you to use the most recent version SystemC 2.3.1, which includes numerous fixes, which might be also relevant to your case, e.g., SystemC 2.3.1 Releasenotes: For what Windows platform are compiling SystemC and your NoC model? 32 bit or 64 bit? Especially, on a 32 bit platform, you might run out of memory soon, as each sc_thread gets allocated its own stack and process memory size is limited to 2 GiB. These two blog postings contain more information: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx You can set the stack size of a spawned sc_thread using set_stack_size() in the module's constructor (see clause 5.2.16 in IEEE Std 1666-2011). You can also override the default stack size of each sc_thread during the configure phase of the SystemC library using SC_OVERRIDE_DEFAULT_STACK_SIZE=<size> (see SystemC INSTALL file).

This information is still not sufficient to debug the problem. It seems that you have used one of the examples coming with the SystemC proof-of-concept implementation as a starting point for your own model. Does the original model work with your SystemC setup? sc_cor_fiber is an implementation detail related to the implementation of SystemC processes of type SC_THREAD on windows. Do you follow the rules for registering the SC_THREADs in your modules' constructor? Do you actually do wait() calls in your SC_THREAD instances? Do you instantiate an unusual big amount of SC_THREADs? Do you use a lot of stack memory in your threads? These questions are merely poking into the fog and no one on this forum will have time to debug a big model of yours. Therefore, I suggest that you proceed methodologically: Start from a model that is actually working and then progressively introduce you modifications to see when it breaks. This may allow you to locate the problem. Your approach of big bang testing is making things unnecessarily difficult. Test first the individual module's functionality separately.

The error you observed happens in the process switching of the discrete event simulation kernel of SystemC and thus probably not specific to the SystemC AMS extensions. You don't provide enough context so that anyone could help you to resolve the problem, as you just show where the program stopped inside the SystemC kernel, but you don't provide any information about your model that you try to execute on top of the SystemC kernel, and which is most likely the source of the problem. Try to observe, what part of your model was last executed before the error occurs and analyze that context for anomalies. If that doesn't help, you can try to reduce progressively your model as much as possible so that it still exposes the problem. Then, analyze what is left.

Based on the error message, Incisive seems to be only able to connect Verilog signals to Discrete Event ports of a wrapped SystemC module, i.e., of type sc_core::sc_in<T> or sc_core::sc_out<T>. You will have to wrap your SystemC-AMS TDF model accordingly. It may already suffice to use TDF converter ports of type sca_tdf::sca_de::sca_in<T> or sca_tdf::sca_de::sca_out<T> instead of pure TDF ports of type sca_tdf::sca_in<T> or sca_tdf::sca_out<T>. They ensure the sampling of DE signals to TDF samples and vice versa. If that doesn't fix the error, you will have to further wrap the TDF model into a SC_MODULE having only SystemC ports of type sc_core::sc_in<T> or sc_core::sc_out<T>.

You're using the C compiler driver gcc to compile C++ code. Therefore, the C++ standard library is not linked to your program leading to the linker error. You have to compile with g++. The default make rules use CC and CXX environment variables to respectively select the C and C++ compiler. As far as I remember, the SystemC configure script sets both environment variables for compiler selection (CC and CXX) to g++.

Hello Thomas, Thank you for your quick feedbackI I'm looking very much forward to the evolution of Impulse. Your Javascript based approach to create post-processed signals looks very promising! I will be happy to test it once it becomes available. I guess that with SamplesIterator(time) or SamplesIterator(frequency), you will be able to access the time or frequency, respectively, associated to the sampled input signal? How will you deal with signals, for which not for all time points samples are available? I guess these Javascript snippets can be added by editing the configuration file created by Impulse for each trace file? Will you register that configuration file with Eclipse as a Javascript file? Regards, Torsten

Hello Thomas, In our daily work with Impulse, we have also identified some need to to basic processing on the signals shown in Impulse. I'm aware that this could become arbitrarily complex, but what would be already helpful is to be able to add, subtract, multiply, divide two selected signals and create a result signal from it (which ideally could be used in another +, -, *, / operation). I see two frequent use cases: - subtract: to display the information of differential signals, which information is not encoded in the absolute value (as the absolute values are often subject to offset errors), but in the difference of the two signals. - multiply: to calculate power by multiplying current and voltage. It would be even more general, if you could add such a "post-processing signal" to your signal list and then specify the formula in a dialog using common mathematical notation with the signal names as parameters to the operands. Then, you could also add more evolved mathematical functions (trigonometric, integration over time, differentiation). I can understand if such a feature may go beyond the scope you intent for Impulse. There are also workarounds like post-processing the tabular trace files and generating a new one, with the new "post-processing" signals, which could then be displayed by Impulse. Regards, Torsten

Hello Thomas, I gathered more experience with your Impulse plug-in over the past months: When grouping analog signals using "Combine" in the Edit dialog, different axes are used and I have to specify manually a common range. Would it be possible to automatically propose a valid range covering the full extend of all signals. E.g., I have a signal s1 with values from -0.2 to 1.3 and another signal s2 with values from -4.3 to 0.9, the proposed range would be -4.3 to 1.3. I think this would make the feature much more user-friendly. You could suppress drawing of multiple axes in that case. Regarding cursor handling: - Would it be possible not to change the cursor position if you click accidentally into the Impulse drawing pane, when you have been working in another application and you want to bring Eclipse back to the foreground? Maybe it would be more user-friendly to have to drag the cursors explicitly to the new position instead of just clicking to avoid accidental movements of the cursor. - When I use cursors to do measurements, I would like to easily zoom-in around the cursor. Currently, Impulse doesn't seem to use the selected cursor as the center for a zoom. What would be also useful is an automatic zoom to the region, which contains all created cursors with some margin left and right. A range zoom tool could be also very handy, where you select the range with a click, drag+hold and release click to the selected x-range. - When you add a new cursor, it is always added at x position zero and at least on my Eclipse version not visible. Instead, I have to open the "Show Cursor Details" pane to select the newly added cursor to move it there, where I want to have the new cursor. Maybe adding the new cursor to the middle of the current zoom range would be more convenient. I think it would be also convenient to open the "Show Cursor Details" pane automatically when you add the second cursor. The signal grouping functionality seems to have a bug: If I have 4 signals s1, s2, s3, and s4 and I want s1 and s2 be plotter in one pane and s3 and s4 in a separate pane by selecting first s1 and s2 and selecting "Combine" in the Edit dialog and then *separately* selecting first s3 and s4 and selecting "Combine" in the Edit dialog, all four signals s1 to s4 are plotted in one single pane. It is nice that Impulse can plot also small signal analyses of amplitude and angle against the frequency. However, the usefulness of this feature is still limited, as the x-axis can still not be set to log10 scale (which I judge more frequently used than a logarithmic plot with octaves). One small annoying thing is that Impulse is not registered as a possible editor for .dat files. I understand your concerns that too many programs use the .dat extensions, but currently I have to register "Impulse" together with "Text Editor" manually for *.dat files in each Eclipse workspace (I use separate workspaces to group source projects specific to "real" projects such a project with some industrial partner or a project for a specific training). Would it be possible to register Impulse at least as a secondary editor for .dat files? The "*.tab" file extension is non-standard and won't be adopted by SystemC-AMS users, who have to use also other tools. Even better would be some global configuration dialog for Impulse, where these and other preferences could be configured system-wide. Thanks again for all the work you have already invested into Impulse! It has more and more replaced our former favorite tools gtkwave and gaw. Regards, Torsten

Have you actually clicked on one of the two underlined download links on the referenced page? You should be requested to register (purely for statistical reasons) and then be provided with a page to download SystemC-AMS 1.0.1 and 2.0beta1.

Yes, but it will be a considerable effort to build and validate this model. Additionally, its simulation performance in terms of precision and speed may not be satisfying.

A transistor is a non-linear device. The Electrical Linear Network (ELN) model of computation (MoC), which is part of SystemC AMS 1.0 is limited to linear circuits with some additions: switching is allowed and R, C, and I values can be modulated via TDF and DE signals. Though, you have to be very careful when using switching and modulated R, C, I primitives, as the linear differential equation solver may not be able to converge to a solution or the solution will become very time-step dependent. The ELN MoC is entirely primitive-based. It does not give you the possibility to define your own primitives like a BSIM transistor model. What you could do is to assemble a macro model constituted from R, C, and I primitives as well as commanded voltage/current sources to implement a transistor model for a certain operation point. This may be sufficient for your application. You could extend this macro model with voltage sinks and current sinks to measure relevant voltages as input to a TDF module, which may then adjust the R, C, I, gain, and transconductance values in your ELN model so that your macro model can adjust to changing operation point. However, be aware that this constitutes a feedback loop through TDF, which requires to assign a 1-time-step delay. Thus, the solution will become heavily dependent on the chosen time step for the TDF cluster, in which you would use your BSIM macro model. Performance may degrade considerably because you may be obliged to choose very small time step to keep the numerical/dynamic error low enough for your application. If you need to model just a non-linear circuit, you should ask yourself whether SystemC-AMS is the right tool: SPICE or a VHDL-AMS/Verilog-AMS simulator are much more capable in modeling/simulating non-linear energy conserving systems. The strengths of SystemC AMS/TLM is rather on higher levels of abstraction: the system level used for virtual prototyping of embedded AMS Hw/Sw systems---especially in early phases of the design. In these cases, you can often idealize your component models, i.e., using non-linear data flow models (TDF) and only linear circuit/block diagram models. For more information, please, have a look into Section 7 "Modeling strategies" of the SystemC AMS extensions User's Guide, which is part of the OSCI SystemC AMS extensions 1.0 standard available from the Accellera website. You may be also interested in the DVCon 2014 tutorial on SystemC AMS 2.0, which video recording can be watched after a free registration on: http://www.accellera.org/resources/videos/amsnextwave

The compiler error tells you that the sc_signal<T> implementation is trying to call a default constructor T() for the type passed as template argument. Your cdma_data struct does not provide a default constructor (taking no arguments). Your data structure has also to fulfill other requirements to be compatible with sc_core::sc_signal: For details, please, cf. to IEEE Std 1666-2011 clause 6.4.3.

It is true that accessing a TDF converter input port will interrupt the execution of the TDF cluster to advance the SystemC time to the point in time at which the DE signal should be sampled using a SystemC wait(time) call. In addition, SystemC-AMS, will perform a wait() at the end of each TDF cluster execution period (i.e., after it has terminated executing the schedule of processing() methods) to synchronize the TDF cluster execution with the progress of the SystemC time. This is necessary to ensure a controlling of the SystemC AMS execution through the standard sc_start() command. Therefore, the SC_THREAD of the DE bit_src will be run each 200 ms, as it is an independent DE process.

Hello Thomas, Nice to hear about this evolution of features in Impulse! We are using this plugin more and more at LIP6, e.g., in SystemC trainings, where the attendees do their exercises in an Eclipse IDE. I will give the new features a try in the coming days and will provide feedback if necessary. Cheers, Torsten

Indeed, rollback is very difficult to realize in SystemC. It would require user's to follow very strict coding guidelines, which will be hard to check by the SystemC kernel and can thus easily silently broken by user's. However, you need rollback capability in SystemC only if your home-grown simulator is to be considered the co-simulation master, which imposes the timing constraints on the discrete-event simulation kernel of SystemC. If you make SystemC the master, things will get easier. With IEEE Std 1666-2011, new functions were introduced to facilitate co-simulation by allowing to query the state of the simulation kernel, including the time point of the next event. In addition the simulation control has been improved. Future versions of the SystemC standard may enable even finer interactions with the different elaboration and simulation phases using additional callbacks, as presented by Philipp A. Hartmann from OFFIS at the ESCUG 2013 meeting: "Modelling, simulation, and advanced tracing for extra-functional properties in SystemC/TLM". There has been much work on co-simulation with SystemC, which you can dig up via a web search. Note, SystemC AMS does sidestep the problem by using a synchronous-data-flow-based synchronization mechanism for interaction with SystemC and disallowing any back-stepping (only zero time steps have been allowed since SystemC AMS 2.0 for relaxation).

Besides a typo in the last code snippet (tdf_some -> tdf_some_module), your code is correct. You can directly bind a TDF port to another TDF port of the same kind. In addition, a TDF input port can be directly bound to a TDF output port. These port to port bindings constitute a kind of indirection to enable you to cross the design hierarchy levels. However, in the end, there has to be always exactly one TDF signal bound inside the chain of port-to-port and port-to-signal bindings from any TDF output port to the TDF input ports. The port binding rules are well described in the Section 2.3.3 of the SystemC AMS User's Guide. For reference, the exact port binding rules are defined in clause 4.1.2 of the SystemC AMS 2.0 LRM.

Think of isinks and vsinks as current meters and voltage meters. Like in reality, you have to connect them, respectively, in series to the branch, in which you want to measure the current, in parallel to the branch, across which you want to measure the voltage. So in your case, you have to connect the vsinks in parallel to the resistors. The reinitialization of your equation system error likely stems from the fact that you chose a resistance value of zero (i.e., you short circuited two nodes) for both resistors. In consequence, the current through the voltage source cannot be determined by the solver of the ELN MoC.