Error: The current timestep becomes zero

[Mr Alfabet]

I'm getting this error when I'm trying to compile:

 

+ msg 0x0098ce50 "The current timestep becomes zero due the time distance between the time reached by the last execution has been reached the time of the current module activation (see LRM) for: pp_1.sca_ss_0 ltf time ... char *

 

This refers to the LRM for explanation, but I can't seem to find any. Can someone point me in the right direction what I should be looking at to solve this problem?

From what I understand from the error message itself: The module is activated twice in the same point in simulation time, causing my state space equations to go haywire due to a timestep of 0. Am I correct in thinking this?

 

A bit of background: I have two modules with state space equation systems depending on each other. I solved a previous 'unschedulable' problem by using

 

void set_attributes() {
T_out.set_delay(1);
}

 

in one of the modules.

equation for module 1:

dA/dt = f(A,

equation for module 2:

dB/dt = f(A,

[maehne]

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.

[Mr Alfabet]

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.

I'm not using dynamic TDF.

I have a timestep of 2.0 seconds.

I believe I'm using version 1.0, the download link for version 2.0 beta 2 results in a 404 error, and i had some problems installing version 2.0 beta1. Maybe I better try that first.

 

I've been trying to recreate the problem with a small example, but it doesn't result in the same error. I'll post back when I've got more.

[Mr Alfabet]

I reduced my timestep to 1 second, and now it seems to compile. Apparently the delay I put on the cyclic dependency (1) was too small for this timestep.

[dakupoto]

I'm not using dynamic TDF.

I have a timestep of 2.0 seconds.

I believe I'm using version 1.0, the download link for version 2.0 beta 2 results in a 404 error, and i had some problems installing version 2.0 beta1. Maybe I better try that first.

 

I've been trying to recreate the problem with a small example, but it doesn't result in the same error. I'll post back when I've got more.

 

IN the first message you mention two modules dependent on each

other.Please check if you are running into some sort of a deadlock

issue. In addition, you mention above that you have not been able

to re-create the problem with your test example. Please check very

carefully what you are doing differently for your test example -- that

might be the clue to your initial problem. Hope that helps.

[maehne]

I reduced my timestep to 1 second, and now it seems to compile. Apparently the delay I put on the cyclic dependency (1) was too small for this timestep.

 

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.

[Mr Alfabet]

The link provided on this page: http://systemc-ams.eas.iis.fraunhofer.de/ still doesn't work. I'm running version 2.0 beta1 right now, downloaded from here: http://www.eas.iis.fraunhofer.de/en/business_areas/microelectronic_systems/system_development/download_form/download_library.html?status=200

On this page: http://www.accellera.org/downloads/standards/systemc/accept_license/accepted_download?item_key=28d415e4d10167a088616b7a4ed72279ab4c3ac4

i downloaded systemc 2.3.1, but there is no AMS version to download there accept for a 1.0 dating back to 2010.

[Martin Barnasconi]

For the SystemC AMS proof-of-concept version 2.0 beta, you should follow this link

http://www.eas.iis.fraunhofer.de/en/business_areas/microelectronic_systems/system_development/open_source.html

 

In the section "highlights" you can download SystemC AMS after filling in the form.