Interconnect

The input fabric merges the SMC’s own initiators, filters the system AXI input and splits traffic between the SMC window and the rest of the system. The local fabric connects the traffic for the SMC window to the CPU front port and the SMC register islands, and the output fabric remaps and filters the traffic that leaves the SMC.

The input paths are shown in Figure 1, the local resource connections in Figure 2, and the outbound path in Figure 3. The three figures share the notation of the SEP fabric figures. Crossbars are rectangles, muxes and demuxes are trapezoids with the wide side towards the many ports, address remaps and rebases are hexagons and traffic filters are octagons. Green boxes are converters: address-width, data-width, ID-width and protocol conversion. Thick lines are AXI4 and thin lines AXI-Lite; every AXI data path is 64 bits wide unless a converter narrows it. The labels give the address and ID widths where they change, and the port badges mark where a path crosses the module boundary.

Figure 1 has the six inputs of smc_input_fabric along the top and its four outputs along the bottom. The CPU MMIO and JTAG ports have their IDs widened to 4 bits and the log engine’s AXI-Lite port is converted to AXI4. Each of the four SMC-internal initiators then passes its own alias remap; the four remaps share one table of eight regions with a 4 KiB granule. The input mux merges them, widens the ID to 6 bits and registers every channel. The demux behind it sends addresses inside the SMC window, at either the local or the global base and REGION_SIZE long, to the local_in initiator of the local fabric with the address truncated to 32 bits, and every other address to the output fabric. The system AXI input passes the inbound traffic filter, whose clock can be gated while the port is idle. The system and SEP inputs then each pass a region demux: the SMC window continues to the local fabric, truncated to 32 bits, and every other address receives DECERR. The SEP input is not filtered.

Figure 2 shows smc_local_fabric in the upper left, the smc_internal_regs island on the right and the smc_peripherals island along the bottom. The three initiators arrive from the input fabric. Each is rebased onto the local base: the offset within REGION_SIZE is kept and the upper address bits are replaced by those of LOCAL_BASE, so a request for the global window reaches the same register as one for the local window. The local crossbar u_smc_local_xbar connects every initiator to every target, widens the ID to 8 bits, registers every port and answers unmapped addresses with DECERR, as do the internal CSR and peripheral crossbars. Its targets, in port order, are the CPU cluster front port, the data accelerator control port, the internal CSR crossbar, the peripheral crossbar and the CLA register window of the DFD block, which is reached over APB. The converters in front of the last three belong to smc_local_xbar. In the peripheral island, the AVSBus, I2C, UART and I3C register ports cross to the peripheral clock, the DTP CSR window is rebased to zero, and the eFuse registers have a second AXI-Lite port for JTAG access. The last peripheral crossbar target leaves the SMC as the AXI-Lite extension port.

Figure 3 follows a request from the input fabric to the system AXI output. The route demux selects by address. The 8 MiB M-mode window at 0x0100_0000 and the 8 MiB Xvisor window at 0x0180_0000, each above either the local or the global SMC base, go through their output remaps; every other address goes straight through. Each output remap divides its window into eight 1 MiB regions and replaces address bits [55:20] with the region’s offset. Each path also sets the AxUSER source ID (Table 8). The output mux merges the three paths and widens the ID to 8 bits. The dashed outline marks the stage that the NO_ADDR_REMAP parameter removes: smc_config_pkg clears it, so the remap stage is present, and setting it leaves only an ID converter from 6 to 8 bits, without the source ID override. The outbound traffic filter passes traffic that matches no entry.

The fabric modules take parameters for the number of inbound and outbound filter entries, filter pipelining, the outstanding-transaction limit of the output fabric remap path, alias address remap enablement, and the M-mode and Xvisor remap region bases.

The parameters of smc_fabric are listed in smc_fabric.

The parameters of smc_output_fabric are listed in smc_output_fabric.

Further outstanding-transaction limits are fixed by package constants rather than module parameters (Table 1).

These limits set the buffering depth of the fabric. The AXI4 limits bound the outstanding high-performance traffic, while the AXI4-Lite limits bound outstanding transactions to peripherals and configuration registers.

The SMC fabric implements two separate networks optimized for different traffic types (Table 2).

Both networks use 64-bit data bus width for consistent data handling. The CPU cluster connects to the fabric through AXI4 (high-bandwidth data path) and AXI4-Lite (MMIO) interfaces; internally, the cluster uses a TileLink bus that is protocol-bridged at the cluster boundary.

Table 3 lists the common AXI signal widths shared across all AXI4 fabric interfaces.

The AXI transaction ID width varies at each fabric stage because crossbars and multiplexers prepend additional bits to distinguish the originating port. Table 4 lists the ID width at each point in the fabric.

Some internal paths also use a 32-bit data width for AXI4-Lite peripheral access, with corresponding STRB_WIDTH of 4 bits.

The SMC fabric supports multiple traffic sources (managers) and destinations (subordinates), providing flexible routing with security enforcement.

Alias remapping translates local SMC addresses to global system addresses, decoupling software-visible addresses from physical assignments. This simplifies integration and software portability, letting local agents access resources consistently across different SoC mappings.

The alias remap logic organizes eight independently configurable regions, each specifying an input address range, a remap offset for translation, and an AxCACHE value that replaces the transaction’s own on a hit. This enables:

At reset, remap logic defaults to transparent mapping (no remap), using the local alias base address (0xC000_0000) for local resources until programmed. The Programmer’s Guide gives the aperture programming sequence.

Every outbound SMC request carries a source ID in AxUSER. The SMC outbound filter (Section 4.2) and the filters in front of other targets in the system match on it, together with address and NS, to decide what the request may reach.

The output remaps change that source ID. A request to a remap window is translated through the window’s programmed regions and leaves with the window’s source ID instead of the SMC’s:

The remaps are useful when the system integrates such a processor, for example an application processor (AP) running machine-mode firmware and the Xvisor hypervisor. SMC firmware can then reach memory the AP firmware owns through the M-mode window, or memory it shares with the hypervisor through the Xvisor window, and every filter treats the request as one from that software. A system without such a processor has no use for them.

M-mode and Xvisor name the other processor’s software, not SMC privilege modes: SMC firmware runs in machine mode whichever window it uses. The address window alone selects the remap and the source ID; the privilege mode of the issuing SMC hart does not, and AxPROT, including NS, passes unchanged.

Figure 4 shows the decode that both filters implement. Their places in the fabric are in Figure 1 and Figure 3.

The figure draws primitive logic with gate symbols and keeps labelled boxes for comparisons and larger blocks. The upper part of Figure 4 is one traffic_filter, instantiated for every entry on each of the AW and AR channels. The entry hits when all five conditions on the left hold, which the AND gate with the extended input bar combines; the source ID and burst conditions are each an OR of two terms. Its permission bit, ANDed with the channel’s valid, is evaluated separately. The lower part is one channel of axi_filter_wrap. A priority encoder picks the lowest-numbered entry that hits, a 16:1 mux selects that entry’s permission bit, and the inverted bit requests a block. When no entry hits, the next mux takes BLOCK_BY_DEFAULT instead. The last mux forces the block bit to 0 when filter_skip_i is set; filter_skip_i is tied low in both SMC instances. Group ID matching is not built into either instance. The block bit steers the transaction through a demux either to the filtered output or to an error responder that returns DECERR.

Inbound filtering protects SMC resources from unauthorized external access by evaluating three dimensions of each transaction:

The default filter configuration varies by chiplet type. Most SMC instances default to blocking all external transactions until access policies are configured. The Programmer’s Guide gives the filter programming rules.

The inbound filter interface provides 16 independent filter instances, each configurable with its own address ranges, source ID matching, and protection attribute policies.

The outbound filter uses explicit matching entries to allow or block SMC-initiated requests. Unmatched requests pass because this instance uses BLOCK_BY_DEFAULT = 0. An allow entry is therefore not an allowlist: denying traffic requires a matching entry whose read or write permission is clear.

Address, source ID, and NS matching select an entry. The filter does not infer software privilege or grant broader access to a higher privilege mode.

All outbound traffic, after passing through any output remap, is subject to outbound filtering enforcement based on address, security attributes (NS), and source ID. The outbound filters use the same register structure as inbound filters.

The SMC fabric implements two types of protection-based filtering mechanisms to enforce security policies based on AXI protection attributes:

The SMC fabric routing logic determines how transactions reach their intended destinations, supporting both local SMC resources and remote system components. Local resources can be addressed using either their global address or a local alias address.

The GLOBAL_BASE, LOCAL_BASE, and REGION_SIZE CSRs describe the SMC aperture. REGION_SIZE resets to 0x0100_0000 (16 MiB), and firmware may reprogram it during early boot to match the chiplet address assignment.

The SMC input fabric’s local/global split is sized by the same REGION_SIZE CSR used by SMU-level routing and SEP-to-SMC decode, so the internal local-alias window and the chiplet-facing global aperture stay the same size by construction. A REGION_SIZE of zero collapses both windows and routes SMC CPU accesses to its own resources out through the output fabric.

After global-aperture reconfiguration, software may use global addresses for accesses that leave the local SMC view. Global address derivation requires the chiplet-global aperture base, which firmware reads from the GLOBAL_BASE CSR described above.

SMC outbound traffic serves dual purposes: accessing shared system services and extending the SMC’s private domain across the system.

For resources that another processor’s software owns or shares, such as shared memory, traffic passes through that software’s output remap (Section 3.2). For private memory or memory-mapped I/O resources, traffic bypasses the remaps and goes directly to the system NoC, reducing latency.

Each outbound transaction carries a source ID naming the software it acts for, set by its traffic path (Table 8). A transaction that hits an alias remap region carries that region’s AxCACHE value; any other keeps the AxCACHE its initiator issued.

Register offsets are relative to the block base in the subsystem memory map. The detailed map below defines each register and its fields.