..
 # SPDX-FileCopyrightText: <text>Copyright 2026 Arm Limited and/or its
 # affiliates <open-source-office@arm.com></text>
 #
 # SPDX-License-Identifier: MIT

.. _rd-aspen_design_smcf:

==========================================
System Monitoring Control Framework (SMCF)
==========================================

System Monitoring Control Framework overview
============================================

The System Monitoring Control Framework (SMCF) manages on-chip sensors and
monitors. It provides a uniform software interface for controlling different
monitor types and reduces software overhead for sampling and data collection.

SMCF enables coordinated sampling across multiple monitors. Triggers can
originate inside or outside SMCF. The number of supported monitors is
configurable. SMCF also simplifies data collection by combining data from
multiple monitors in a single location or by writing data to a memory-mapped
address that the monitoring agent can access.

SMCF manages sensors, tracks activity counters, and observes system data that
changes over time. It consists of two components: the Monitor Group Interface
(MGI) and the Monitor Local Interface (MLI). Each data source, referred to as a
monitor, connects to an MLI. Monitor data widths range from 1 bit to 64 bits.
Multiple MLIs connect to a single MGI. The MGI exposes the software interface
and applies functions to its group of monitors.

For a complete description of the System Monitoring Control Framework
architecture, programming model, and registers, see the
:link_subs:`smcf-den0108`.

SMCF configuration
==================

Automotive systems integrate multiple on-die monitors to support safety
requirements. Examples include temperature sensors, hot-spot profilers, voltage
monitors, voltage droop detectors, process monitors, delay monitors, and digital
event counters. RD-Aspen FVP demonstrates how SMCF integrates these monitors in
an automotive context.

RD-Aspen FVP implements the following SMCF components:

- One MGI in the SMD Expansion subsystem with one connected MLI
- One MGI per AP cluster in the DSU-120AE, each with one connected MLI

In the current RD-Aspen FVP implementation, all MLIs connect to dummy data
sources. These sources return random values when sampled. All MGIs
support optional periodic sampling and DMA-based delivery of sample data.

The MLI connected to the SMD Expansion MGI models a sensor interface. The MLIs
connected to the MGIs in the AP clusters model Activity Monitoring Unit (AMU)
counter interfaces.

All MGIs route interrupts to SI CL0. These interrupts signal either the
availability of new sample data or an MGI error.

SMCF software flow
==================

SI CL0 manages SMCF and receives measurement data. During startup, SI CL0
firmware configures all MGIs with the same settings:

- Periodic sampling mode with a period of 8,000,000 ``REFCLK`` cycles
- DMA data writes to RAM, with one dedicated memory region per MGI

After configuration, the firmware waits for the PD_SYSTOP power domain to
transition to ON. When this transition occurs, SCP firmware starts sampling on
all MGIs.

When an MGI generates a new sample, it writes the data to RAM using DMA. The MGI
then raises an interrupt. SI CL0 firmware handles the interrupt and logs the
received data samples when logging is enabled.

For information about enabling SMCF data logging, see
:ref:`rd-aspen_design_smcf_validation`.