Jump to content
avot

Building a TDF module library

Recommended Posts

Hello,

 

I am a beginner in SystemC-AMS. So I started using the User Guide (very good document) and tutorials about C++ found on the web.

 

I am able to run simulation using a set of TDF modules connected together. Everything works perfectly.

 

I have a question regarding the coding style: since I have the same module (sin_src from User Guide) implemented twice in the same cluster, I set the timeStep in only one of the two module instance using the following code:

 

---- sin_src.hpp ----

 private:
    sca_core::sca_time *tm; // cluster time step

 

---- sin_src.cpp ----

void sin_src::setTimeStep(sca_core::sca_time *tm ) {  // My method
  this->tm = tm;
}

void sin_src::set_attributes() {
  if( tm!=NULL ) {
    set_timestep(*tm);
  }
}

 

---- end ----

 

Then I am able to set the time step only on the relevant sin_src instance, everything works well, no technical problem. Reason for this implementation is I don't want to mix behavioural parameters passed to the constructor (gain, amplitude) and simulation specific parameters (time step). This is purely arbitrary.

 

My question is : Is there a kind of cookbook defining some "good practices" in order to build a reusable and sharable library of SystemC-AMS modules ?

 

Best regards,

 

Grégoire.

Share this post


Link to post
Share on other sites

Indeed, a source module is a good place to assign the TDF time step. I agree with your preference to not mix behavioural and simulation-specific parameters. However, your approach of adding a setTimeStep member function to the module is unnecessarily complicated and prone to errors due to the use of raw pointers, which don't guarantee the lifetime of the pointed-to object. I suggest that you use the set_timestep() member function provided by all classes inheriting from sca_core::sca_module (this also includes all TDF modules). This member function specifies the module time step, which is equal to the port time step when the port has a rate of one. In contrast to port time steps, which have to be assigned in the context of set_attributes (to guarantee that the port has been already bound to a TDF signal), the module time step can be assigned anytime between construction of the module itself and the call of its set_attributes member function.

Share this post


Link to post
Share on other sites

One of the unique features of SystemC-AMS is the propagation of the time-step properties, as documented in the user guide section 2.1.3. I expect you have already seen this section.

This means it is not mandatory to specify the time step for each TDF module, but only specify this at one place in the TDF cluster (this is the computed execution schedule of the set of connected TDF modules). The most common place is to do this in the test bench, for example as the input source of the system.

 

Of course you can assign time steps to each TDF module, but then it is very important to get it consistent in the entire TDF cluster. In a single-rate system this is rather easy, but as soon as you start with multi-rate systems, the execution (firing) of each TDF module and its TDF port time steps could differ. Therefore I would advice to rely on the time step propagation approach, because it will match TDF module time step and port time steps.

 

This story also explains that (especially in multi-rate systems) that the time step is not something global, but something that belongs to a TDF module and port. That's why TDF modules and ports have the set_timestep methods, and we did not define this time step definition as global simulator function. As such, one can argue the time step properties belong to the TDF module, and thus can be included in the parameter object which is passed as constructor argument.

Share this post


Link to post
Share on other sites

Thank you Torsten and Martin.

 

Martin, I fully agree your explanation, this is clearly explained in the User Guide.

 

Torsten, I remember I did this test, I set timeStep globally for the module, not for a port, and got an error when function set_timeStep() is called outside the set_attributes(). But maybe I missed something, I will try again.

 

Best regards,

 

Grégoire.

Share this post


Link to post
Share on other sites

Hello Torsten,

 

You are right, I can call function set_timestep() on a module instance, not on a port on a module instance.

 

Best regards,

 

Grégoire.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×