ARC processor cores ICACHE D-CACHE SRAM architecture

ARC processor cores ICACHE D-CACHE SRAM architecture

 Synopsys ARC processor cores feature a highly configurable and modular internal memory architecture. Instead of a one-size-fits-all approach, they allow system-on-chip (SoC) designers to choose between—or combine—traditional hardware-managed caches (ICACHE/DCACHE) and software-managed Closely Coupled Memories (SRAM/CCM). [1, 2, 3]

The architecture breaks down across its internal memory structures as follows:

1. Instruction Cache (ICACHE) & Data Cache (DCACHE)

The L1 caches in ARC cores provide traditional, transparent hardware-managed acceleration for main memory accesses. [1]

• Configurability: Caches are fully scalable based on the core family. For example, the embedded ARC EM family typically allows sizes from 2 KB to 32 KB, while the high-performance ARC HS family scales from 4 KB up to 64 KB per cache. [1, 2, 3, 4]
• Cache Line & Geometry: Typically organized as multi-way set-associative (often 2-way or 4-way) to balance performance against silicon area.
• Coherency & Snooping: High-end multi-core ARC processors include a hardware-managed System Coherency Unit (SCU). This implements data cache snooping to maintain hardware I/O and inter-core coherency across symmetric multiprocessing (SMP) workloads without software intervention. [1, 2, 3]
• Control: Caches feature dedicated auxiliary registers that let software explicitly trigger line-locking, invalidation, and flushing. [1]

2. Closely Coupled Memory (CCM) / Internal SRAM

For applications requiring strict real-time determinism (such as automotive control, radar processing, or audio DSP), ARC architectures support CCM, which are dedicated blocks of on-chip SRAM. [1, 2]

• ICCM (Instruction CCM): Dedicated SRAM mapped directly into the processor's instruction fetch stage. It bypasses the ICACHE entirely, ensuring single-cycle instruction execution without the risk of unpredictable cache misses.
• DCCM (Data CCM): Dedicated SRAM mapped directly into the load/store data pipeline. It ensures single-cycle read/write access to critical variables, stacks, or interrupt vectors.
• Banked Architecture: In superscalar or advanced ARC configurations (like the HS series), the DCCM is heavily banked. This allows parallel 64-bit loads/stores and handles unaligned memory accesses across banks in a single cycle without stalling the pipeline. [1]

3. XY Memory Architecture (DSP Extensions)

For ARC cores configured with DSP or vector extensions (such as the EMxD or VPX processors), the SRAM architecture splits into specialized XY Memories. These are dual-banked, highly localized internal SRAM blocks that enable the execution unit to fetch two distinct data operands simultaneously in a single cycle, maximizing MAC (Multiply-Accumulate) throughput. [1]

Summary: Cache vs. CCM Implementation

In an ARC core, designers often choose a hybrid strategy based on the layout below:

Memory Component	Control Mechanism	Primary Purpose	Latency
ICACHE / DCACHE	Hardware-managed (Tags/LRU)	Speeds up generic code & large OS (e.g., Linux) workloads.	Dynamic (Single-cycle hit, multi-cycle miss)
ICCM / DCCM (SRAM)	Software-mapped (Fixed Address)	Guarantees exact timing for real-time interrupts and loops.	Guaranteed Single-Cycle

Are you designing for a deterministic, real-time application (which would heavily favor an ICCM/DCCM SRAM configuration) or an operating system environment like Linux (which relies heavily on ICACHE/DCACHE)? I can help you weigh the silicon area vs. latency trade-offs for either setup.

 

What's the bus between ARC core and L1 caches , ICCM, DCCM,？

Dedicated buses, or general buses like AHB, how the multi-core share the CCM?

 

 The connection between the ARC core and its closely coupled memories follows a strict hierarchy designed to maximize performance and minimize latency.

1. The Core to L1 Cache, ICCM, and DCCM Bus Architecture

The connection between the ARC CPU execution pipeline and its internal L1 structures (ICACHE, DCACHE, ICCM, DCCM) uses highly optimized, dedicated, proprietary buses, not general-purpose system buses like AHB or AXI.

General system buses like AHB or AXI add multi-cycle arbitration, routing, and protocol overhead. To achieve guaranteed single-cycle execution, the internal paths must be direct and integrated tightly into the CPU pipeline phases:

• Instruction Path: The CPU fetch unit connects to the ICCM and ICACHE via a dedicated internal instruction fetch bus. If the target address falls within the fixed ICCM memory map, the ICCM responds in 1 cycle. If it falls outside, the ICACHE controller handles the lookup.
• Data Path: The CPU Load/Store Unit (LSU) connects to the DCCM and DCACHE via a dedicated internal data bus. For advanced ARC cores (like the HS series), this data path is 64-bit or 128-bit wide and heavily banked to allow simultaneous multi-operand access without pipeline stalls.
• Where AHB/AXI Fits: System buses like AHB or AXI are only used downstream of the L1 subsystem. They handle cache misses (connecting the L1 cache controller to L2 cache or system DDR) or route non-cacheable/external peripheral accesses.

---

2. How Multi-Core Systems Share Closely Coupled Memory (CCM)

By architectural definition, Closely Coupled Memory (CCM) is local, private, and dedicated to an individual processor core's pipeline. It is intentionally placed inside the core's timing boundary to ensure single-cycle access.

Because of this layout, multi-core ARC clusters handle CCM access and sharing using specific structural rules:

• Private by Default: Core 0 cannot natively read or write to Core 1's ICCM/DCCM using single-cycle execution paths. Each core has its own independent address space mapping for its local CCM.
• The Slave Port/Backdoor Access: To allow multi-core communication or DMA transfers, Synopsys includes an optional External Slave Interface Port (or "backdoor" port) on each core's CCM controller. This port connects the local CCM outward to the cluster's internal fabric (such as the AXI/APB system fabric or an internal Mesh/Ring routing structure).
• Remote Access Penalty: If Core 0 needs to share data residing in Core 1's DCCM, it must send a transaction over the system bus/fabric. This transaction enters through Core 1's external slave port. This access is not single-cycle; it is subject to system bus arbitration and stalls if Core 1's own pipeline is actively using its DCCM at that exact moment.
• Hardware Coherency Mapping: Local CCMs are excluded from the automated hardware data cache coherency protocol (handled by the System Coherency Unit / SCU). The SCU only snoops and manages the hardware DCACHE. Any multi-core data sharing through CCM spaces must be explicitly managed by software using inter-processor interrupts (IPIs), semaphores, or software-driven memory barriers.

Are you designing a symmetric multi-processing (SMP) system where cores need to dynamically share heavily threaded workloads, or an asymmetric multi-processing (AMP) layout where each core executes a completely isolated, dedicated task out of its own CCM? I can provide the specific registers or bus topology for either setup.