Jump to content
NickIlieskou

Combining SystemC with SystemC AMS

Recommended Posts

I have a question which probably is quite stupid. I developed a Software in the Loop framework in SytemC. This framework is supposed to call in specific discrete time instants some modules to execute. For instance suppose we have module A and B. Module A has to be executed every 10 ms and Module B every 20 ms. The execution order has to be first A and then B when both modules have to be executed. 

I am able to do that by having a coordinator module triggered by a clock of 10 ms. Every module ( module A, B and scheduler) are related with an event. Module A and B they look like this: 

 

while(1){

Wait(ev_mod_i)

{

...

trigger_ev_coordinator

}}

 

The coordinator which knows the frequency of each module will notify the correct event to trigger the corresponding module. So for instance for t=10ms the coordinator will be triggered by the clock and it will trigger event_mod_A. Then for t=20ms it will trigger event_mod_A, after module A is finished coordinator will trigger event_mod_B. After module B is also finished, the coordinator will wait for the next clock tick e.t.c 

 

Now i would like to insert an AMS model into my system. The desired MoC is continuous TDF. However I can't use statements like event.notify(zerotime) or wait(ev_i) in TDF according to the AMS manual. Moreover TDF modules include a time step by which they are executed. This is something that is not fully desired because i can't find a way to control the TDF modules. Could you please give me any ideas on how I can embed a TDF model into a SystemC framework and at the same time to be able to control when the model has to be executed for a specific clock tick?  Probably by doing this I am ruining the whole concept of continuous TDF MoC. If this is right do you have any alternative ideas? Thanks in advance. 

 

 

Share this post


Link to post
Share on other sites

I have a question which probably is quite stupid. I developed a Software in the Loop framework in SytemC. This framework is supposed to call in specific discrete time instants some modules to execute. For instance suppose we have module A and B. Module A has to be executed every 10 ms and Module B every 20 ms. The execution order has to be first A and then B when both modules have to be executed. 

I am able to do that by having a coordinator module triggered by a clock of 10 ms. Every module ( module A, B and scheduler) are related with an event. Module A and B they look like this: 

 

while(1){

Wait(ev_mod_i)

{

...

trigger_ev_coordinator

}}

 

The coordinator which knows the frequency of each module will notify the correct event to trigger the corresponding module. So for instance for t=10ms the coordinator will be triggered by the clock and it will trigger event_mod_A. Then for t=20ms it will trigger event_mod_A, after module A is finished coordinator will trigger event_mod_B. After module B is also finished, the coordinator will wait for the next clock tick e.t.c 

 

Now i would like to insert an AMS model into my system. The desired MoC is continuous TDF. However I can't use statements like event.notify(zerotime) or wait(ev_i) in TDF according to the AMS manual. Moreover TDF modules include a time step by which they are executed. This is something that is not fully desired because i can't find a way to control the TDF modules. Could you please give me any ideas on how I can embed a TDF model into a SystemC framework and at the same time to be able to control when the model has to be executed for a specific clock tick?  Probably by doing this I am ruining the whole concept of continuous TDF MoC. If this is right do you have any alternative ideas? Thanks in advance. 

Hello Sir,

Of course you could interace SystemC and SystemC. No issues at all. However,

the description that you have provided, is not very clear about what exactly you

are trying to achieve, and the control sequence.

Share this post


Link to post
Share on other sites

The SystemC AMS TDF model of computation follows the well known data flow semantics, which means that the module is activated (i.e. the SystemC AMS processing() callback is called) as soon as the samples are available at the input port(s). After this computation, the results are immediately available at the TDF output ports (assuming you write to output ports).

This means the SystemC AMS modules simply compute the signal as soon as TDF samples come in, and pass them after performing some signal processing to the output.

 

In SystemC AMS 2.0 we introduced the concept of "Dynamic TDF" which allows additional activation of the TDF module's processing() method as soon as discrete-events come in via the converter input ports (sca_tdf::sca_de::sca_in or sca_tdf::sc_in), but this concept should only be used to make reactive systems. I advice *not* to apply this in combination with your coordinator module.

 

Unfortunately your example of module A and B is incomplete (e.g. are module A and B connected?) to give good guidance. But the use of this coordinator module really sounds like overhead to the system simulation, as it is only meant to synchronize the execution of module A and B. Guess this is an artificial module to drive simulation only? This type of modules should be avoided. Architecture design in SystemC and SystemC AMS should represent the system by modules which are really available in the system.

Instead, you could implement this example using SystemC AMS only, where module A has a fixed time step of 10ms, and module B a time step of 20ms. You can connect them via a port with a rate of 2, which means module A is called twice, before module B is called. This gives you the right execution schedule. Furthermore, by following this approach, you basically skip the native SystemC discrete event semantics, and simulation even gets much more efficient.

Share this post


Link to post
Share on other sites

@Martin Barnasconi

 

First of all thank you for your answer. Though I still have some questions: 

1) Let's suppose I have three TDF modules connected to each other with a timestep=10ms. So module A is giving input to module B and module B output is module C input. Apart these modules I have 2 more isolated SystemC modules that are sensitive to a clock with a Period equal of 10ms as well. In such an example the SystemC scheduler will always execute the TDF modules first and then the two SystemC modules. I guess I cannot change this order of execution. For instance can I do something so that the SystemC modules are executed first and then the TDF modules? 

 

2) I know that TDF modules update the values of their signals instantly. For instance if I have a TDF module A giving input to another TDF module B, then if A changes its output at time instant t then module B will see this change in time X. On the other hand in simple SystemC modules this is not the case. More specifically if A and B were SystemC modules, B would see the change in the signal at the time instant t+1. What can I do to make the SystemC signals behave like the AMS signals, except using zero_time notifications? 

 

@dakupoto, Martin Barnasconi

I apologize for the insufficient description of my problem in my previous post. It is quite difficult to explain exactly what I am trying to do. Probably it would take some A4 pages to explain, so maybe it is much better if I try to ask precise questions. Thanks both of you for posting an answer. 

Share this post


Link to post
Share on other sites

1) A TDF cluster (in this case formed by modules A, B and C) runs dependently from any other part in the system. This other part can be another (not connected) TDF cluster or any other SystemC module which is executed following discrete-event semantics. Looking from an analog perspective on the matter, this is correct: the analog part is "always active" (assuming there is supply voltage - often we do not model this in system level models). As such, there is no dependency between the TDF cluster(s) and SystemC modules, and the execution order is then implementation defined. In the end, you define that both the TDF cluster as well as the SystemC modules need to be active each 10ms, and this will happen. If you would look at the results in a waveform viewer, you will not notice the difference, because you are not interested which samples are written to the screen (or file) first, as long as the samples appear at the right place in time.

 

2) Here you touch on one of the fundamental differences between SystemC AMS TDF modules using data flow semantics, and regular SystemC modules which work under a discrete-event regime. Due to the evaluate/update mechanism in the SystemC kernel, is it simply not possible using SystemC modules to write a value and read the value in the same simulation cycle. When using SystemC AMS TDF models, they will form a TDF cluster which defines the execution order, and this cluster can be computed prior to simulation. This means the signal values in the whole cluster are computed and thus known for each time step. In a pure SystemC topology however, there does not exists such dependency graph, and therefore the signal values through the system only propagate after each evaluate/update cycle. This effect is part of the discrete-event semantics and cannot be altered.

Share this post


Link to post
Share on other sites

I just have a (possibly unhelpful) comment - you don't have to use primitive channels with evaluate/update semantics in SystemC. You can use your own channel with immediate notify, or you can write a "systemc program" which is really C++ and has no use of time or deltas. Whether that helps with the original problem I don't know :-)

 

regards

Alan

Share this post


Link to post
Share on other sites

@Martin 

 

1) I understand your point. However in my case it is important to know or to be able to manipulate the order of execution. That is because the TDF cluster and the the SystemC modules at some point they operate on the same global variables. I understand that this is out of the scope of SystemC however it would be really nice if I could change the execution order by using a functionality of SystemC like wait. In other words if I define a TDF cluster and an isolated SystemC module with the same time step the execution order will be as you said implementation defined.  Can I do something to change this order? For instance use events or wait statements. Unfortunately I know that I cannot use wait statements with TDF modules but I ask just to be sure that I do not have any alternatives. 

 

2) That was a very clear answer. Thanks for answering my questions :) 

 

@Alan

 

I have thought about implementing a pure C++ communication in some parts of my system. However I haven't thought of making my own channels with immediate notify, which sounds a really nice idea. Thanks for sharing your thoughts.

Share this post


Link to post
Share on other sites

@Alan

 

I have one more naive question. I should use a channel if and only if I want to simulate the medium of data transmission. In case of an ideal medium, where no data are lost or I have no extra delays in the transmission there is no reason for a channel right? 

Share this post


Link to post
Share on other sites

In SystemC, the word "channel" simply means "something that implements an interface" and so can be bound to ports.

 

In that sense, a "channel" doesn't have to be a means of communication. For instance you could have a RAM model that implemented an interface with read and write functions.

 

The extra things you get in SystemC, beyond C++, are the ability to make your system modular with modules and ports; and threads (processes), events and time.

 

Ports are templated with interfaces (classes derived from sc_interface)  which specify that the thing bound to the port must provide the required functions.

 

If you look at TLM2, for instance, ports are bound to exports, and the modules with the exports implement the functions that the modules with the ports require. In the original SystemC usage, both an initiator and a target are "a channel" in the sense that they implement an interface.

 

What I'm trying to say is that you don't have to really think about channels at all. You can simply think in terms of interfaces, classes that implement those interfaces, and ports and exports that promote modularity by (in a sense) acting as special pointers with strong type checking.

 

Of course in the SystemC library there are some built-in primitive channels, which have the special feature that they follow evaluate-update semantics. But that's just a special case of the more general concept of implementing an interface and accessing implemented methods remotely via ports/exports.

 

So if you don't need the features that ports/exports/modules give you, you don't have to use them.

 

Which is a long way of saying "yes" to your question :-)

 

The main disadvantage of using immediate notify is non-deterministic behaviour.

 

regards

Alan

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...