AMS Attribute Negotiation and Cluster Scheduling

How to Read This Lesson

AMS scheduling is easier if you stop imagining a free-running C++ loop. Think of each TDF module as declaring timing attributes. The AMS kernel uses those declarations to build a schedule that can synchronize with SystemC discrete-event time.

Source and LRM Trail

Use Docs/LRMs/SystemC_AMS_2_0_LRM.pdf for TDF modules, attributes, rates, delays, timesteps, converter ports, and synchronization behavior. Use the existing AMS lessons for TDF, dynamic TDF, LSF, ELN, and converter-port context.

The TDF Attribute Lifecycle

A TDF module typically has three important callbacks:

void set_attributes();
void initialize();
void processing();

Read them this way:

• set_attributes() declares timing and rate contracts.
• initialize() prepares state after the schedule is known.
• processing() performs the repeated sample-level computation.

The important point is that attributes are not casual configuration variables. They shape the static schedule.

Rates, Delays, and Timesteps

Rate tells the scheduler how many samples move per activation. Delay tells it how many samples of history exist on a port. Timestep tells it the time distance represented by samples.

Example shape:

SCA_TDF_MODULE(Fir) {
  sca_tdf::sca_in<double> in;
  sca_tdf::sca_out<double> out;
 
  SCA_CTOR(Fir) {}
 
  void set_attributes() override {
    in.set_rate(1);
    out.set_rate(1);
    out.set_timestep(10.0, sc_core::SC_NS);
  }
 
  void processing() override {
    out.write(0.5 * in.read());
  }
};

The module does not call wait(10, SC_NS) inside processing(). The timestep is part of the AMS schedule.

Converter Ports Are Synchronization Boundaries

Converter ports connect AMS timing to SystemC discrete-event timing. This is where many bugs hide.

When DE code writes a value that feeds AMS, the AMS side samples that value according to its own schedule and converter rules. When AMS writes back to DE, the result becomes visible through scheduled synchronization points.

The useful review question is: at exactly which simulation times can this value cross the boundary?

Static vs Dynamic TDF

Static TDF builds a schedule from fixed attributes. Dynamic TDF lets a module influence its next activation time, which is powerful for reactive models such as PWM, event-driven analog behavior, and variable-rate systems.

Use dynamic TDF only when the model really needs it. Static schedules are easier to reason about and usually faster.

Review Checklist

• Are rates and timesteps documented in engineering units?
• Does every delay have a modeling reason?
• Are converter-port boundary times understood?
• Is dynamic TDF used only for genuinely dynamic timing?
• Does the AMS detail answer the platform question, or is it slowing a model that only needed a DE approximation?