Jump to content

Connecting AMS and TLM through discrete-event


Recommended Posts

Hi,

I've built an AMS system that works fine on a testbench. Now instead of driving the input signals for my system from the testbench I got a TLM processing model that should drive the inputs and read the outputs of the AMS system. In the user guide there is the discrete-event signals seem to be the element of choice.

I connect my TLM based peripherals through the sc_core::sc_signal that gets written/read within a SC_THREAD thats being run periodically. For my AMS modules I use `sca_tdf::sca_de::sca_in/out`. Interconnecting these seems to be no problem. The compiler doesnt throw me any errors or warnings regarding that and the executable seems to get to reach sc_start(). But it doesnt seem to progress the simulation time.

The terminal output looks like this after I added a few print statements withtin my TLM and AMS modules:


        SystemC 2.3.3-Accellera --- Apr 27 2021 15:41:26
        Copyright (c) 1996-2018 by all Contributors,
        ALL RIGHTS RESERVED


        SystemC AMS extensions 2.3.0-COSEDA Release date: 20200312 2138 
        Copyright (c) 2010-2014  by Fraunhofer-Gesellschaft IIS/EAS
        Copyright (c) 2015-2020  by COSEDA Technologies GmbH
        Licensed under the Apache License, Version 2.0


sim started 

Info: SystemC-AMS: 
	4 SystemC-AMS modules instantiated
	1 SystemC-AMS views created
	4 SystemC-AMS synchronization objects/solvers instantiated


Info: SystemC-AMS: 
	1 dataflow clusters instantiated
	  cluster 0:
		4 dataflow modules/solver, contains e.g. module: src_1
		4 elements in schedule list,  
		100 ms cluster period, 
		ratio to lowest:  1              e.g. module: src_1
		ratio to highest: 1 sample time  e.g. module: src_1
		1 connections to SystemC de, 1 connections from SystemC de

heater @ 0.000000 = E6476D00
system @ 0.000000 = 1.000000
sink_1 @ 0 s: 0
sensor @ 0.000000 = E6476D00
^C

The "sim started" is a print after at the sc_start() in my sc_main(). The prints with "heater", "system", "sink_1" and "sensor" are within my AMS modules (they're all TDF MoC). The prints of my TLM modules are never reached. I am not quite sure if I missed out on how to properly interconnect the AMS-TLM layers with each other or if there might be another issue there that I am not aware of. Each of the models works independently as I expect it.

I set all the modules to 100 ms, and the SC_THREADS run at 100 ms aswell, so synchronization shouldnt be an issue.

Is there anything that needs attention when interconnecting TLM and AMS models?

 

Thanks in advance

Link to post
Share on other sites

Alright, I managed to debug it a bit better and understand what was happening.

Long story short, It was an issue the the TLM side way faster than the AMS model was calculating. And the issue I had was actually the TLM waiting and thus not progressing simulation. After fixing this the other issue was the time scales being off a bit.

 

Link to post
Share on other sites
Quote

Is there anything that needs attention when interconnecting TLM and AMS models?

Your approach to connect he SystemC/TLM world with the SystemC-AMS is correct: to cross the discrete-event / TDF MoC boundary, dedicated converter ports are available for this, called sca_tdf::sca_de::sca_in/out, as explained in section 2.4 of the SystemC-AMS user's guide.

Special attention is required to understand when digital discrete-event samples are (made) available in the TDF context. In the case of fixed TDF timesteps, a signal change at an input port of type sca_tdf::sca_de::sca_in is not immediately picked-up by the TDF model, since it runs on its own time step (set by set_timestep), which means the value will be used at the next TDF time step. In case you expect immediate action in the TDF model, then you need to make use of the dynamic timestep feature in SystemC-AMS, by using the SystemC-AMS TDF method request_next_activation in a change_attributes callback. This is explained in section 2.4.3.

Note that when using dynamic timestep in a TDF module, you need to make sure other TDF modules in the same TDF cluster support dynamic timesteps, as explained in section 2.1.2. This means all other connected modules should "opt-in" to indicate that they support dynamic timesteps by explicitly calling the method accept_attribute_changes.

Link to post
Share on other sites
  • 2 weeks later...

Thank you very much for this additional Information.

Yes, I've used sca_tdf::sca_de::sca_in/out to connect a sc_signal from a TLM module to a AMS module!

Its good to know that there is a dynamic timestep feature for immediate callbacks in the TDF modules.

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...