AMS API and Model-of-Computation Field Guide

How to Read This Lesson

AMS is easiest when you group names by model of computation. TDF names describe sampled-time data flow. LSF names describe linear signal-flow equations. ELN names describe electrical conservative networks. Converter names tell you where AMS time meets SystemC discrete-event time.

Standard and source context

Use Docs/LRMs/SystemC_AMS_2_0_LRM.pdf. This repository currently has the AMS LRM locally, but no checked-out AMS source tree, so this guide focuses on standard API coverage and modeling meaning.

TDF Timing and Scheduling

sca_tdf, sca_tdf::sca_module, sca_tdf::sca_in, sca_tdf::sca_out, sca_tdf::sca_signal, sca_time, set_timestep, set_rate, set_delay, initialize, set_attributes, and processing are the core TDF vocabulary.

sca_module_method, sca_delay, sca_sampling, sca_multirate, sca_multirate_fmt, sca_parameter, sca_parameter_base, sca_port, sca_interface, sca_signal_if, sca_prim_channel, sca_out_base, and sca_node_if are supporting API names around module callbacks, attributes, ports, and channel-like structure.

Read set_attributes as a contract declaration, not normal runtime code. The kernel uses rates, delays, and timesteps to build a static schedule. The schedule is then synchronized to SystemC time at converter boundaries.

sca_default_interpolator, sca_decimation, and related rate-conversion ideas appear when sampling rates differ. Use them carefully: rate conversion is a modeling decision, not just an API call to silence a scheduler error.

Converter and DE Boundary Names

sca_de_source, sca_de_sink, sca_de_mux, sca_de_demux, sca_de_gain, sca_de_c, sca_de_l, sca_de_r, sca_de_isource, sca_de_vsink, sca_de_vsource, sca_de_isink, sca_de_rswitch, and converter-port concepts describe the bridge between discrete-event SystemC and AMS domains.

Shorter component-style names such as sca_mux, sca_demux, sca_isink, sca_info, sca_rswitch, sca_vccs, sca_vcvs, and sca_transmission_line appear in the same ecosystem. Read them by signal-flow role: source, sink, selector, diagnostic, switch, controlled source, or transmission line.

TDF primitive names such as sca_tdf_in, sca_tdf_out, sca_tdf_signal, sca_tdf_source, sca_tdf_sink, sca_tdf_mux, sca_tdf_demux, sca_tdf_gain, sca_tdf_c, sca_tdf_l, sca_tdf_r, sca_tdf_isink, sca_tdf_isource, sca_tdf_vsink, sca_tdf_vsource, sca_tdf_rswitch, sca_tdf_sc_in, sca_tdf_sc_out, sca_tdf_out_ct_cut, sca_tdf_out_dt_cut, and sca_tdf_solver tell you the exact boundary between sampled TDF behavior, DE converter ports, and analog-style primitive blocks.

The boundary question is always timing: when is a DE value sampled by AMS, and when does an AMS result become visible to DE? If that answer is vague, the model may be correct-looking but timing-ambiguous.

LSF Names

LSF models mathematical signal-flow equations. Look for integrators, gains, adders, transfer functions, and source/sink components. sca_lsf names are best reviewed by drawing the equation graph beside the C++ instances.

sca_lsf_in, sca_lsf_out, sca_lsf_signal, sca_lsf_solver, sca_ltf_zp, sca_ss, and sca_matrix are LSF-specific or solver-adjacent names. They point to linear equations, transfer functions, state-space representation, and matrix solving rather than event scheduling.

If a block is really an algorithm with sample timing, TDF may be clearer. If it is a continuous-time linear relation, LSF often communicates the intent better.

ELN Names

ELN models electrical networks. Names such as sca_eln, sca_r, sca_c, sca_l, sca_vsource, sca_isource, controlled sources like sca_cccs and sca_ccvs, and node/terminal concepts describe conservative electrical relationships.

sca_eln_solver, sca_gyrator, sca_ideal_transformer, sca_nullor, and related ELN primitives are physical-network modeling terms. If those names show up, draw the circuit graph before reading the C++ syntax.

Use ELN when current, voltage, and network topology matter. Do not force ELN into a fast VP just because it feels more physically accurate; the right abstraction is the one that answers the design question.

AC and Noise Analysis Names

sca_ac_f, sca_ac_delay, sca_ac_ltf_nd, sca_ac_ltf_zp, sca_ac_ss, sca_ac_scale, sca_ac_format, sca_ac_fmt, sca_ac_is_running, and sca_ac_noise_is_running belong to small-signal AC and noise analysis support.

sca_noise_format, sca_noise_fmt, sca_information_mask, sca_information_on, sca_information_off, and sca_max_time are analysis, diagnostics, and limit-control vocabulary. They do not replace model equations; they control how analysis and reporting are configured.

The mental model is different from transient simulation. You are asking for frequency-domain behavior around a linearized system, not stepping through every time sample. Keep that distinction visible in lesson notes and code reviews.

Proxy and Vector Utility Names

sca_assign_from_proxy, sca_assign_to_proxy, sca_create_vector, sca_ct_proxy, sca_ct_vector_proxy, and sca_cut_policy are utility-level names you may see while reading API implementation or generated documentation.

sca_release, sca_is_prerelease, sca_copyright, and sca_copyright_string are version/distribution names. They help diagnose library identity but do not change model semantics.

sca_version, sca_version_major, sca_version_minor, and sca_version_originator are the same kind of version metadata. sca_traceable_object, sca_trace_variable, and sca_trace_mode_base are tracing vocabulary for making AMS quantities visible during debug.

Treat these as support machinery. They are useful for understanding how the library presents natural C++ syntax, but most model authors should stay focused on modules, ports, attributes, and physical meaning.

AMS Review Checklist

• Which model of computation is being used: TDF, LSF, ELN, or DE?
• Where are rates, timesteps, and delays declared?
• Are converter boundary times understood?
• Is AC/noise analysis being used for the right kind of question?
• Does the model include more analog detail than the platform actually needs?