Electronics Guide

Processor Core Architectures

The processor core forms the computational heart of any embedded architecture. Modern embedded processors predominantly use RISC (reduced instruction set computing) architectures, with the Arm architecture holding the largest share because of its power efficiency and broad ecosystem. The Arm Cortex-M series targets microcontroller applications with deterministic interrupt response, Cortex-A cores power application processors running full operating systems, and Cortex-R cores serve real-time, high-reliability roles such as storage controllers and automotive safety systems.

Within a single family the span is wide. The smallest Cortex-M cores are deliberately tiny, omit caches entirely, and execute from on-chip flash at tens of megahertz, while larger members add floating-point units, caches, and vector extensions for signal processing and machine learning inference. Application-class cores add memory management, superscalar issue, deeper pipelines, and multi-core cache coherency, and they typically run at clock rates an order of magnitude higher.

Alternative architectures serve specialized niches. RISC-V offers an open-standard alternative that is gaining rapid traction in custom implementations, and configurable cores such as Cadence Tensilica Xtensa allow customer-defined instruction extensions. MIPS-based parts remain in service in networking equipment and consumer electronics, although MIPS Technologies has redirected its own product line to RISC-V. Eight-bit and sixteen-bit architectures such as the 8051 derivatives, AVR, and PIC families also persist where cost, legacy tooling, or extremely low standby current dominate the decision.

Comparing cores requires attention to more than clock frequency. Pipeline depth, branch handling, cache organization, memory interface width, and the presence of hardware divide, floating-point, or vector units all shape delivered performance. Benchmarks such as CoreMark provide a rough ranking, but real workloads that stall on flash wait states or memory bandwidth often behave quite differently from benchmark loops that fit entirely in cache.

Memory Architectures

Embedded memory systems must balance capacity, speed, power consumption, and cost within tight constraints. Harvard architectures, which separate instruction and data memory paths, enable simultaneous instruction fetch and data access, improving throughput for computation-intensive applications. The modified Harvard architectures common in modern MCUs preserve this benefit while still allowing data to be read from program memory, for example to access constant tables stored in flash.

On-chip memory includes tightly coupled memory (TCM) for deterministic access, caches for general acceleration, and scratchpad memory under explicit software control. Because embedded flash rarely keeps pace with the core clock, designers rely on prefetch buffers, flash accelerators, or execution from RAM to avoid wait states. Systems that outgrow on-chip memory add external DRAM or serial flash, at the cost of extra pins, board area, and less predictable latency; execute-in-place from quad or octal SPI flash is a common compromise.

Memory protection units (MPU) and memory management units (MMU) provide isolation between software components, which is essential for safety-critical systems and multitasking environments. An MMU supports virtual memory and address translation, as required by Linux-class operating systems, while a lighter-weight MPU enforces region-based access permissions without translation and therefore without the timing variability of a translation lookaside buffer. The memory systems category treats these subjects in greater depth.

Bus and Interconnect Structures

The on-chip interconnect determines how processors, memories, and peripherals communicate within an embedded system. Simple microcontrollers may use a straightforward shared bus, while complex SoCs employ network-on-chip (NoC) architectures to manage communication among dozens of IP blocks concurrently.

Arm's AMBA (Advanced Microcontroller Bus Architecture) family dominates SoC interconnects, helped by the fact that Arm publishes the specifications free of charge. AXI (Advanced eXtensible Interface) provides high-bandwidth, high-frequency connections with independent address, read, and write channels and support for outstanding and out-of-order transactions. AXI4-Lite trims the protocol down for simple register interfaces, and AXI4-Stream carries unidirectional data flows such as those between signal-processing blocks. AHB (Advanced High-performance Bus) is the protocol most widely used with Cortex-M designs, and APB (Advanced Peripheral Bus) serves low-bandwidth, low-power peripherals. The AMBA 5 generation adds the Coherent Hub Interface (CHI), a packet-based protocol for cache-coherent multi-core systems.

Interconnect choices have measurable consequences. Arbitration policy determines which master wins contention and therefore the worst-case latency seen by a real-time task. Bus width and clock ratio set the ceiling on sustained bandwidth. Bridges between clock or power domains add latency and require careful reset sequencing. Many performance problems that appear to be processor limitations turn out, on inspection, to be interconnect or memory bottlenecks.

Interrupts, DMA, and Deterministic Response

Embedded architectures are judged as much by their response to events as by their raw throughput. Vectored interrupt controllers, such as the nested vectored interrupt controller (NVIC) in Cortex-M devices, dispatch directly to a handler address, stack a subset of registers in hardware, and support configurable priority levels with preemption. Tail-chaining between back-to-back interrupts and handling of late-arriving higher-priority requests reduce the overhead that would otherwise accumulate during bursts of activity.

Direct memory access (DMA) engines move data between peripherals and memory without processor intervention. This lowers energy per transferred byte, removes per-sample interrupt overhead, and lets the core remain in a low-power state while a converter or serial port streams into a buffer. Descriptor-based and scatter-gather DMA extend the idea to chained transfers that require no software attention until a block completes.

Predictable timing depends on the whole architecture, not on the core alone. Caches complicate worst-case execution time analysis because hit and miss latencies differ substantially, so designers lock critical code into cache ways, place interrupt handlers in tightly coupled memory, or select cores without caches when deadlines are tight. Hardware timers with capture and compare units, watchdogs, and clock sources of specified accuracy complete the architectural support for time-critical behavior. The real-time operating systems category examines how software exploits these mechanisms.

Performance versus Power

Embedded architects must balance computational performance against power consumption. Dynamic power rises linearly with clock frequency and with the square of supply voltage. Because a lower operating frequency often permits a lower voltage, scaling both together reduces dynamic power far more than frequency scaling alone. Architectural techniques such as clock gating, separate power domains, retention modes, and dynamic voltage and frequency scaling (DVFS) allow systems to match power consumption to instantaneous workload demand.

Duty cycle usually matters more than peak efficiency. A sensor node that wakes for a few milliseconds each second spends most of its energy budget in sleep leakage and in the cost of waking up, so architectures for such products are evaluated on standby current, wake-up latency, and the amount of state retained. Finishing work quickly and returning to sleep, sometimes called race-to-idle, can beat running slowly and continuously whenever static power is significant.

Architecture selection itself involves power trade-offs. A hardware accelerator may complete a task far more efficiently than a general-purpose processor, yet it adds silicon area, verification effort, and design risk. The right answer depends on the energy budget, the volume, and the flexibility required for future updates. These questions are treated further in the power management category.

Flexibility versus Efficiency

General-purpose processors offer maximum flexibility through software programmability but sacrifice efficiency compared with dedicated hardware. ASICs provide the highest efficiency for fixed functions but cannot be changed after manufacture. FPGAs occupy a middle ground, offering hardware-level parallelism with post-manufacturing reconfigurability at the cost of higher power and higher per-unit price than an equivalent ASIC.

Modern embedded architectures often combine these approaches. A single SoC may pair application processors for complex software with fixed-function accelerators for intensive algorithms and programmable logic for interfaces that must adapt to changing standards. Deciding what belongs in hardware and what belongs in software is the central question of hardware-software co-design, and the decision is easier to change early than late.

Development Cost, Volume, and Lifetime

Each implementation technology distributes cost differently over time. An ASIC concentrates expense at the front in mask sets, verification, and engineering effort; this nonrecurring cost must be amortized across the production run, after which the per-unit cost is low. An FPGA inverts the profile, with modest development cost and a substantially higher price per device. The crossover volume therefore depends on the process node chosen, since mask and design costs climb steeply at advanced nodes, and an architecture that is economical at millions of units may be indefensible at thousands.

Product lifetime is an equally practical constraint. Industrial, medical, and automotive programs frequently require component availability for a decade or more, which favors suppliers that publish longevity commitments. Second sources, pin-compatible families that allow memory or peripheral upgrades, and toolchains that will still build the project years later all deserve weight alongside the purely technical criteria.

Integration versus Modularity

Higher integration reduces system cost, size, and power by combining multiple functions on a single chip. It also shortens critical signal paths and eliminates board-level interfaces that would otherwise need protection and matching. However, a highly integrated device rarely fits every requirement equally well, and schedules sometimes favor proven discrete components over a new part that must be qualified from scratch. Integration level affects component selection, printed circuit board complexity, thermal design, and the ease with which a system can later be upgraded or repaired.

Semiconductor Process Considerations

The semiconductor manufacturing process constrains what an embedded architecture can achieve. Smaller process nodes raise transistor density and lower the energy required for each switching event, but they also increase static leakage as a share of total power and raise mask and design costs steeply. FinFET and gate-all-around transistor structures restored much of the electrostatic control lost by planar devices at small geometries, yet the economics still keep most embedded designs on mature nodes.

Embedded flash is a further consideration. Reliable on-chip flash becomes difficult and expensive below roughly the 28-nanometer generation, which is one reason microcontrollers cluster on mature processes while application processors that boot from external memory move to leading-edge nodes. Alternative embedded non-volatile technologies, chiefly magnetoresistive RAM, have entered foundry production to extend on-chip storage to finer geometries, with resistive RAM less mature.

Process selection also affects analog performance. Older nodes often provide better analog device characteristics and higher supply-voltage headroom, so mixed-signal designs must weigh process implications for digital and analog circuits together. Some products resolve the tension by partitioning functions across separate dies fabricated on different processes and combining them in one package.

Packaging and Physical Integration

Modern embedded architectures extend beyond the silicon die to advanced packaging. Multi-chip modules (MCM), system-in-package (SiP), and chiplet approaches combine multiple dies in a single package, enabling integration of components manufactured on different processes; a radio die, a mature-node analog die, and a leading-edge digital die can share one substrate. Package selection affects thermal resistance, signal integrity, pin count, and manufacturability, while 2.5D interposers and 3D die stacking shorten interconnect length and raise the bandwidth available between dies.

Physical constraints reach back into architectural choices. Ball pitch and layer count determine how many high-speed interfaces a board can reasonably escape from the package. Thermal limits may cap sustained clock frequency well below the silicon capability. For sealed or potted assemblies, junction temperature and power dissipation often bound the architecture more tightly than any computational requirement.

Heterogeneous Computing

Embedded architectures increasingly combine diverse processing elements to match each workload. A single SoC may include application processors, real-time cores, GPU cores, neural processing units (NPUs), and fixed-function accelerators for video or cryptography. A common arrangement runs a rich operating system on the application cores while a companion real-time core handles deterministic control, with the two communicating through shared memory and mailbox interrupts under frameworks such as OpenAMP.

Heterogeneity moves complexity into software. Partitioning tasks, maintaining coherency between engines with different views of memory, coordinating boot order and power states, and debugging across cores that do not share a single trace timeline all demand tooling and discipline that homogeneous designs do not require.

RISC-V and Open Architectures

The RISC-V open instruction set architecture is reshaping embedded design by allowing custom processor implementations without paying an architecture licensing fee. The specification defines a compact base integer instruction set with optional standard extensions for multiplication, atomic operations, floating point, compressed instructions, and vectors, so implementers can build only what an application requires. The ISA is royalty-free, although commercial core implementations are still licensed like any other silicon IP.

Fragmentation is the natural risk of such freedom, and ratified profiles are the response. A profile fixes a required set of extensions so that operating systems and toolchains can ship portable binaries rather than per-vendor builds; RISC-V International ratified the RVA23 application-processor profile in October 2024. Designers may still add custom instructions for a specific workload, accepting the compiler and maintenance burden that private extensions carry.

Security-Oriented Architectures

Connected products have made security an architectural requirement rather than a late addition. Hardware roots of trust anchor secure boot so that each stage verifies the signature of the next. Trusted execution environments such as Arm TrustZone partition the system into secure and non-secure worlds. Cryptographic accelerators, true random number generators, protected key storage, and physical unclonable functions (PUFs) supply the primitives, while debug port locking, memory protection, and countermeasures against side-channel and fault-injection attacks defend the implementation.

These features carry costs in area, boot time, and development complexity, and they constrain the update mechanism for the life of the product. Regulatory pressure and customer security requirements now push such capabilities into even modest devices. The security and cryptography category covers the subject in detail.

Safety and Certification Requirements

Regulated domains constrain architecture from the outset. IEC 61508 provides the general industrial framework for functional safety and defines safety integrity levels (SIL). ISO 26262 adapts that framework to road vehicles and classifies risk using automotive safety integrity levels A through D. In civil aviation, RTCA DO-254 gives design assurance guidance for airborne electronic hardware, and DO-178C covers the accompanying software. Medical device software follows IEC 62304 within the broader risk-management process.

These standards shape hardware decisions directly. They favor devices with published safety documentation and diagnostic coverage figures, error-correcting memory, lockstep processor cores, built-in self-test, and independent watchdog and clock monitoring. Choosing a component without such evidence can force an expensive argument later in certification, so the functional safety standards that apply should be identified before the architecture is fixed.

Practical Selection Criteria

A disciplined selection compares candidates on concrete figures rather than impressions: sustained throughput on a representative workload, worst-case interrupt latency, memory footprint for both code and data, average and standby current across the expected duty cycle, and the mix and count of peripheral interfaces. Environmental limits such as operating temperature range and supply-voltage tolerance rule out many parts immediately.

Non-technical factors decide as often as technical ones. Toolchain maturity, debug and trace capability, availability of drivers and middleware, the quality of documentation, evaluation-board availability, supply lead times, and stated longevity all affect schedule and risk. Building an early prototype on a development board remains the most reliable way to test an architectural assumption before it becomes expensive to revisit.