33 IoT System-on-Chip Architecture
Max the Microcontroller was showing the team something amazing under a magnifying glass. “See this tiny chip? It’s smaller than your fingernail, but it has EVERYTHING inside!”
Sammy the Sensor was amazed. “Everything? Like what?”
Max pointed to different parts: “There’s my brain (the CPU), my memory (like a tiny notebook), a radio for talking wirelessly, special math helpers that calculate things super fast, and even a power manager that decides how to use Bella’s energy wisely!”
Lila the LED asked, “Why put everything on one chip instead of separate pieces?”
Max explained, “Imagine if your school had the classroom, gym, library, and cafeteria all in separate buildings across town. You’d waste so much time and energy walking between them! But when everything is in ONE building, you can get to any room quickly and save energy. That’s exactly what a System-on-Chip does – everything is close together, so signals travel fast and use less power.”
Bella the Battery added, “And the special math helpers are my favorites! When Max needs to do complex calculations, they finish the job 100 times faster than if Max tried to do it alone. Less time working means less of my energy used!”
The lesson: A System-on-Chip is like a miniature city on a fingernail – everything a smart device needs is packed together, saving space, power, and cost!
33.1 Learning Objectives
By the end of this chapter, you will be able to:
- Analyze SoC Architecture: Examine internal block diagrams of IoT System-on-Chip designs including CPU cores, RF subsystems, DSP accelerators, and power management subsystems
- Quantify Hardware Accelerator Savings: Calculate the power savings from dedicated DSP blocks (FFT, CORDIC, MAC) versus software implementations on general-purpose CPUs
- Compare Commercial and Research SoCs: Contrast general-purpose commercial IoT SoCs with ultra-low-power research designs across power, capability, and cost dimensions
- Evaluate Die Area Tradeoffs: Assess how silicon area allocation among radio, memory, CPU, and accelerators impacts chip cost and capability
33.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- MCU vs MPU Selection: Understanding the fundamental differences between microcontrollers and microprocessors
- Power Management and Interfaces: Familiarity with power modes, GPIO, and sensor interfacing
33.3 Under the Hood: IoT System-on-Chip (SoC) Architecture
When you buy an ESP32 module or a TI CC2650, you’re getting a complete System-on-Chip (SoC)—a single integrated circuit containing all the components needed for a complete IoT system. Understanding what’s inside these chips helps you make better hardware selections and optimize your designs.
IoT SoC high-level block diagram: This diagram shows the major functional blocks integrated on a single chip—processing core, memory, wireless communication, sensors, and power management—illustrating how modern IoT devices achieve complete system functionality in minimal footprint.
The block diagram above illustrates the architectural organization of a typical IoT SoC. Each major subsystem (processing, communication, sensing, power) is integrated on the same die, enabling compact designs, low power consumption, and cost-effective manufacturing. The following sections explore these subsystems in detail.
Analogy: Think of a SoC like a complete kitchen appliance factory on a single chip:
- Traditional approach (discrete components): Separate factory buildings for different tasks—one for motors, one for electronics, one for packaging—all connected by trucks (wires)
- SoC approach: Everything under one roof—all machines integrated, sharing power and communication efficiently
Why SoCs dominate IoT:
| Discrete Components | System-on-Chip (SoC) |
|---|---|
| Multiple chips needed | Single chip solution |
| More PCB space required | Compact design |
| Higher power (chip-to-chip communication) | Lower power (on-chip buses) |
| Complex assembly | Simple integration |
| $10-50 total cost | $2-10 complete solution |
The key insight: Modern IoT SoCs pack incredible capability into chips smaller than your fingernail—CPU, memory, radio, sensors, and power management all integrated.
33.4 Commercial IoT SoC Examples
Modern IoT modules you can buy today integrate sophisticated SoC designs. The following figure shows the internal architecture of a typical IoT SoC, revealing the complexity hidden within these tiny chips:
IoT SoC internal architecture: This detailed view shows the complex subsystems integrated on a single chip—CPU with cache hierarchy, memory controllers, RF transceiver with baseband processing, sensor interfaces, power management, and clocking—all interconnected via high-speed buses to create a complete wireless sensor platform.
This cross-section reveals the sophisticated architecture required for even “simple” IoT devices. Key observations include the dedicated RF subsystem for wireless communication, specialized DSP blocks for signal processing, and power management circuitry that enables battery operation—all packed into a chip smaller than your fingernail.
Key Architecture Insights:
| Component | Purpose | Power Optimization |
|---|---|---|
| Main ARM M3 | Application processing | Can be powered down during sleep |
| RF ARM M0 | Radio stack processing | Dedicated core, efficient for BLE/Zigbee |
| Sensor Controller | Autonomous sensing | Operates at 24kHz, wakes main CPU only when needed |
| AES Accelerator | Hardware encryption | 100x faster than software, saves power |
| DC-DC Converter | Power regulation | 80%+ efficiency vs 50% for LDO |
33.5 Research-Grade Ultra-Low-Power IoT SoC
To understand what’s possible with advanced IoT chip design, let’s examine a research SoC that achieves 6.45µW total system power—enough to run entirely from harvested RF energy:
Key Concepts
- SoC (System on Chip): A single integrated circuit combining CPU, radio transceivers, memory interfaces, DSP, and security elements — enabling complete IoT subsystems in a package smaller than a fingernail
- Heterogeneous Computing: SoC architecture using multiple specialized processor types (application CPU, DSP for signal processing, NPU for ML inference) each optimized for its specific workload type
- DMA (Direct Memory Access): A hardware controller transferring data between peripherals and memory without CPU involvement, allowing the processor to sleep or handle other tasks during bulk data transfers
- Secure Enclave: A hardware-isolated execution environment storing cryptographic keys and executing security-sensitive code protected from the main application processor — critical for IoT device identity
- NPU (Neural Processing Unit): A specialized processor core optimized for matrix multiplication enabling ML inference directly on the IoT device for anomaly detection and sensor fusion without cloud connectivity
- RF Front-End Module (FEM): Integrated power amplifier, low-noise amplifier, and RF switch providing the antenna interface for wireless SoCs, determining transmit power and receive sensitivity
- Power Management IC (PMIC): A dedicated chip managing multiple voltage regulators, battery charging, fuel gauging, and power sequencing for SoC subsystems, often integrated into modern IoT SoCs
33.6 Why These Components? Design Trade-offs
33.6.1 Dedicated DSP Accelerators
Instead of using the main CPU for signal processing (which wastes power), dedicated hardware performs common operations:
| Accelerator | Function | Power Savings |
|---|---|---|
| CORDIC | Sin/cos/atan calculations | 50-100x vs software |
| MAC | Multiply-accumulate for filters | 20x vs software |
| FFT | 16-point spectrum analysis | 100x vs software |
| FIR | 4-channel filtering | 30x vs software |
Example: Computing a 16-point FFT:
- Software on MSP430: ~10,000 cycles, CPU active at 500µA, runs for 10ms → 5 µJ
- Hardware FFT: ~50 cycles, accelerator active at 100µA, runs for 50µs → 0.005 µJ (1000x less energy!)
33.6.2 Asymmetric Radio Architecture
Traditional radios use the same circuitry for transmit and receive, but IoT has asymmetric communication patterns:
Why asymmetric?
- Sensor node TX: Simple, power-efficient UWB transmitter (no complex modulation)
- Sensor node RX: Ultra-simple wake-up receiver (just detects presence of signal)
- Gateway does the hard work: Complex receivers and high-power transmitters (wall-powered)
33.6.3 Energy Harvesting with MPPT
The boost converter includes Maximum Power Point Tracking (MPPT)—an algorithm that continuously adjusts load impedance to extract maximum power from solar cells:
| Solar Condition | Without MPPT | With MPPT | Improvement |
|---|---|---|---|
| Full sun | 80µW | 95µW | +19% |
| Partial shade | 20µW | 35µW | +75% |
| Indoor lighting | 2µW | 5µW | +150% |
The MPPT boost converter alone makes the difference between a working device and a dead device under indoor lighting!
Let’s calculate how much energy a 2cm² solar cell with MPPT can harvest over one year in different environments, assuming our 6.45µW IoT SoC.
Indoor office environment (200 lux, ~12 hours/day usable light):
\[P_{\text{harvested}} = 5\text{ µW} \times 12\text{ hours/day} = 60\text{ µWh/day}\]
\[E_{\text{annual}} = 60\text{ µWh/day} \times 365\text{ days} = 21,900\text{ µWh} = 0.022\text{ Wh}\]
SoC energy budget: 6.45µW × 24 hours = 154.8 µWh/day = 56.5 Wh/year
\[\text{Energy ratio} = \frac{60\text{ µWh/day}}{154.8\text{ µWh/day}} = 0.39 \text{ (only 39% of needs met)}\]
Outdoor partial shade (8 hours full sun at 95µW, 4 hours partial at 35µW):
\[E_{\text{daily}} = (95\text{ µW} \times 8\text{ h}) + (35\text{ µW} \times 4\text{ h}) = 900\text{ µWh/day}\]
\[\text{Energy ratio} = \frac{900\text{ µWh/day}}{154.8\text{ µWh/day}} = 5.8 \text{ (580% surplus!)}\]
Conclusion: With MPPT, outdoor sensors can be truly battery-free. Indoor sensors need energy-aware duty cycling (wake every 10-30 seconds instead of continuously) or a small rechargeable backup (100 mAh supercapacitor = 360 Wh buffer).
33.7 Physical Implementation: Die Photo Analysis
Real IoT SoCs look like this under a microscope (the 6.45µW chip die photo):
Die Dimensions: 3.78mm x 3.57mm = 13.5 mm² total area
33.8 Extreme Miniaturization: Ant-Sized Radio Systems
Modern IoT research has pushed miniaturization to extraordinary limits. The following figure shows digital circuits from an ant-sized radio—a complete wireless sensor platform small enough to fit on the back of an insect:
Ultra-Miniaturized IoT Systems: This die photo captures the digital circuitry of a complete wireless sensor platform measuring just 1.9mm x 1.5mm (2.85 mm²)—smaller than a grain of rice and 4.7x smaller than the 6.45µW research SoC described above. The entire system includes an 8-bit CPU, 64-byte SRAM (for minimal code/data), radio transmitter, sensor interfaces, and energy harvesting circuitry. This represents the absolute limit of IoT miniaturization: when assembled with antenna and solar cell, the complete sensor weighs <10 milligrams—light enough to attach to insects for tracking studies or deploy as dust-sized environmental monitors. The dense digital logic (visible as regular rectangular patterns) contrasts with custom analog/RF blocks (curved/triangular shapes). Power budget: The entire system runs on <50µW harvested from a 2mm² solar cell—enough to sample sensors and transmit 1-byte packets every 10 seconds. This technology enables applications impossible with conventional IoT: tracking individual bees in a hive, monitoring structural vibrations at millimeter scale, or deploying thousands of sensors from aircraft for wildfire detection. The key enabling technologies are ultra-low-power digital design (sub-threshold operation at 0.5V), energy-aware protocols (transmit-only, no receiver), and 3D integration (stacking dies to reduce footprint).
Area Breakdown (approximate from die photo):
| Block | Area (mm²) | Percentage | Notes |
|---|---|---|---|
| Radios | 3.5 | 26% | UWB TX + Wake-up RX |
| Power Management | 2.0 | 15% | Boost converter + MPPT |
| Memory (DMEM) | 2.5 | 19% | 8KB total data memory |
| DSP Accelerators | 2.0 | 15% | FFT, FIR, CORDIC, MAC |
| Analog Front End | 1.5 | 11% | 4-ch AFE + ADC |
| CPU + Control | 1.5 | 11% | MSP430 + LCU |
| I/O Pads | 0.5 | 4% | Bond pads around edge |
Key Observations:
- Radio dominates: Even at this ultra-low power, RF circuits take 26% of die area
- Memory is expensive: 8KB of on-chip SRAM takes 19% of area
- Processing is cheap: The entire MSP430 CPU takes only 11% of area
- Power management matters: 15% dedicated to efficient energy harvesting
Let’s calculate the silicon cost for this 13.5mm² research SoC. At advanced 65nm process (typical for research chips), wafer costs are ~$3,000 per 300mm wafer with 70,000mm² usable area.
\[\text{Dies per wafer} = \frac{70,000\text{ mm}^2}{13.5\text{ mm}^2} \approx 5,185\text{ dies}\]
\[\text{Cost per good die (70\% yield)} = \frac{\$3,000}{5,185 \times 0.70} = \$0.83\]
Now let’s break down the cost by component based on area allocation:
- Radio (3.5mm², 26%): $0.83 × 0.26 = $0.22 (most expensive single block)
- Memory (2.5mm², 19%): $0.83 × 0.19 = $0.16 (8KB of SRAM)
- Power Management (2.0mm², 15%): $0.83 × 0.15 = $0.12
- DSP Accelerators (2.0mm², 15%): $0.83 × 0.15 = $0.12
- CPU + Control (1.5mm², 11%): $0.83 × 0.11 = $0.09 (cheapest!)
Key insight: The CPU costs only $0.09, while the radio costs $0.22—wireless capability adds 2.4× more silicon cost than processing. This explains why Wi-Fi modules cost $3-5 while basic MCUs cost $0.50-1.00.
In the research SoC, 8KB of SRAM occupies 2.5mm² (19% of the chip). At typical fab costs of $0.10-0.50 per mm², this memory alone costs $0.25-1.25 per chip!
Practical implications:
- Code must be highly optimized to fit in limited memory
- External flash/RAM adds cost, power, and board space
- This is why ESP32 (520KB RAM) costs $5 while basic ATtiny (512 bytes) costs $0.50
- Memory architecture drives both chip cost and application capability
33.9 Comparing Commercial vs Research SoCs
| Metric | TI CC2650 (Commercial) | Research 6.45µW SoC |
|---|---|---|
| Total Power | ~1mW typical | 6.45µW |
| CPU | ARM Cortex-M3 @ 48MHz | MSP430 @ low MHz |
| Memory | 128KB Flash + 20KB RAM | 8KB total |
| Radio | BLE 4.2 / Zigbee | UWB TX + Wake-up RX |
| ADC | 12-bit 200ksps | 8-bit |
| Energy Harvesting | External | Integrated MPPT |
| Use Case | General-purpose IoT | Battery-free sensors |
| Cost | ~$3 in volume | Research prototype |
The trade-off: Commercial SoCs prioritize flexibility and ease of use; research SoCs push efficiency limits for specialized applications like battery-free sensors.
33.10 Knowledge Check
33.11 Worked Example: SoC Selection for Smart Beehive Monitor
Scenario: A beekeeping cooperative wants to deploy 200 smart hive monitors that measure temperature, humidity, weight, and acoustic signatures (bee buzzing frequency indicates colony health). Data uploads every 15 minutes via LoRaWAN to a gateway 3 km away. Each monitor must run 2 years on a single 18650 lithium cell (3,400 mAh at 3.7V = 12.58 Wh).
Requirements:
- Sensors: temperature (I2C), humidity (I2C), load cell (ADC, 24-bit for 0.1 g resolution), MEMS microphone (I2S)
- Processing: 256-point FFT on audio samples (bee frequency analysis, 200-500 Hz band)
- Communication: LoRaWAN Class A (uplink-only, low power)
- Budget per unit: < $15 for SoC + radio module
- Battery life target: 2 years (730 days)
Candidate SoCs evaluated:
| Feature | ESP32-S3 | nRF52840 | STM32WL55 | TI CC1352R |
|---|---|---|---|---|
| CPU | Xtensa LX7 dual-core 240 MHz | ARM Cortex-M4 64 MHz | ARM Cortex-M4 48 MHz | ARM Cortex-M4F 48 MHz |
| RAM | 512 KB | 256 KB | 256 KB | 256 KB + 80 KB |
| ADC | 12-bit | 12-bit | 12-bit | 12-bit |
| I2S | Yes | Yes (via I2S) | No | No |
| Hardware FFT | No | No | No | No |
| LoRa radio | External (SX1276) | External (SX1276) | Integrated | Integrated (sub-GHz) |
| Deep sleep | 10 uA | 0.4 uA | 1.4 uA | 0.8 uA |
| Active current | 68 mA (240 MHz) | 4.6 mA (64 MHz) | 3.3 mA (48 MHz) | 5.5 mA (48 MHz) |
| Module cost | $3.50 + $4 radio | $6 + $4 radio | $8 (integrated) | $7 (integrated) |
| Total unit cost | $7.50 | $10.00 | $8.00 | $7.00 |
Step 1: Eliminate candidates that fail hard requirements
- ESP32-S3: 10 uA deep sleep is 25x higher than nRF52840. Over 2 years of 99.7% sleep time, this alone consumes 10 uA x 17,520 hours = 175 mAh – acceptable but tight.
- STM32WL55 and TI CC1352R: No I2S interface for the MEMS microphone. Would require an external I2S codec ($2 + board space) or software PDM decoding (CPU-intensive).
- nRF52840: Has I2S and 0.4 uA deep sleep, but requires external LoRa module (adds $4 and board space).
Step 2: Calculate power budget for each viable candidate
Using the duty cycle: wake every 15 minutes, sample sensors (2 seconds), record 1 second audio, compute FFT (50 ms on M4, 5 ms on ESP32), transmit LoRaWAN (1.5 seconds at 14 dBm).
STM32WL55 (with external I2S codec):
- Deep sleep: 1.4 uA x 8,755 hours = 12.3 mAh/year
- Sensor wake (96 times/day x 2 s): 3.3 mA x 0.053 h/day x 365 = 7.1 mAh/year
- Audio + FFT (96 times/day x 1.05 s): 5 mA x 0.028 h/day x 365 = 5.1 mAh/year
- LoRa TX (96 times/day x 1.5 s): 35 mA x 0.04 h/day x 365 = 51.1 mAh/year
- Annual total: 75.6 mAh/year. 2-year total: 151 mAh (4.4% of 3,400 mAh)
nRF52840 + SX1276:
- Deep sleep: 0.4 uA + 1 uA (SX1276 sleep) = 1.4 uA x 8,755 hours = 12.3 mAh/year
- Sensor wake: 4.6 mA x 0.053 h/day x 365 = 8.9 mAh/year
- Audio + FFT: 6 mA x 0.028 h/day x 365 = 6.1 mAh/year
- LoRa TX: 40 mA x 0.04 h/day x 365 = 58.4 mAh/year
- Annual total: 85.7 mAh/year. 2-year total: 171 mAh (5.0% of 3,400 mAh)
Step 3: Decision
| Criterion | STM32WL55 | nRF52840 + SX1276 | Winner |
|---|---|---|---|
| 2-year energy | 151 mAh (4.4%) | 171 mAh (5.0%) | STM32WL55 |
| Unit cost | $8 + $2 codec = $10 | $6 + $4 radio = $10 | Tie |
| Board complexity | Integrated radio, external codec | External radio module | STM32WL55 |
| Audio quality | Codec adds latency | Native I2S | nRF52840 |
| Firmware ecosystem | STM32CubeIDE, large community | Zephyr RTOS, Nordic SDK | Tie |
Selected: STM32WL55 – The integrated LoRa radio eliminates the external SX1276 module, reducing board size by 30% and simplifying RF design (no impedance matching for SMA connector). The external I2S codec adds $2 per unit but provides clean audio for bee frequency analysis.
Fleet cost for 200 units: 200 x $10 SoC/codec + $3 PCB + $2 sensors + $1.50 battery + $1 enclosure = $3,500 total hardware. At 151 mAh over 2 years, batteries will actually last 45 years mathematically – in practice, battery self-discharge (1-2%/year) limits useful life to 8-10 years.
Key Insight: Both candidates use only 4-5% of battery capacity over 2 years because LoRaWAN transmission (not sensing or processing) dominates the power budget at 68% of total consumption. The FFT computation that originally seemed like the power challenge (audio processing on an MCU) actually takes only 50 ms and contributes less than 4% of energy use. When selecting SoCs for battery IoT, optimize for radio efficiency first, sleep current second, and processing power last.
33.12 Visual Reference Gallery
Understanding why dedicated hardware accelerators save 100× energy compared to software FFT implementations.
Software FFT (on MSP430 @ 1 MHz):
- 16-point complex FFT requires ~10,000 CPU cycles (multiply-accumulate operations)
- CPU active time: 10,000 cycles / 1 MHz = 10 ms
- CPU active current: 500 µA
- Energy per FFT: 500 µA × 10 ms = 5 µJ (microjoules)
Hardware FFT Accelerator:
- Dedicated butterfly units perform complex multiplications in parallel
- 16-point FFT completed in ~50 cycles
- Accelerator active time: 50 cycles / 1 MHz = 50 µs
- Accelerator current: 100 µA (specialized circuit, lower voltage rails)
- Energy per FFT: 100 µA × 50 µs = 0.005 µJ
Power Savings: 5 µJ / 0.005 µJ = 1000× less energy with hardware!
Why the Dramatic Difference:
- Parallelism: Hardware executes 8 butterfly operations simultaneously; software does them sequentially
- Specialized circuits: Fixed-point multipliers are 10× more power-efficient than general-purpose ALUs
- No instruction fetch overhead: Software FFT spends 40% of cycles fetching instructions from memory; hardware has zero fetch overhead
- Voltage scaling: Accelerators run at 0.6V vs 1.8V for CPU (quadratic power reduction: (0.6/1.8)² = 11% power)
Real-World Impact: A vibration sensor doing 100 FFTs/day uses 5 µJ × 100 = 500 µJ/day (software) vs 0.5 µJ/day (hardware). Over 10 years, that’s 1.8 J vs 1.8 mJ—the difference between a coin cell and a supercapacitor.
Objective: Choose the optimal SoC for a wearable fitness tracker.
Requirements:
- Sensors: 3-axis accelerometer (I2C), heart rate (ADC), GPS (UART)
- Processing: Step counting (local), heart rate analysis (FFT on 100 samples/min)
- Wireless: BLE 5.0 for smartphone sync every 5 minutes
- Battery: 200 mAh coin cell, target 7-day battery life
- Size: < 10mm × 10mm module
Candidate SoCs:
| Feature | nRF52832 | ESP32-C3 | STM32WB55 |
|---|---|---|---|
| CPU | Cortex-M4 64 MHz | RISC-V 160 MHz | Cortex-M4 64 MHz |
| RAM | 64 KB | 400 KB | 256 KB |
| BLE | 5.0 | 5.0 | 5.0 |
| Hardware FFT | No | No | No |
| Deep sleep | 0.4 µA | 5 µA | 0.6 µA |
| Active (BLE TX) | 5.3 mA | 12 mA | 4.2 mA |
| Size | 6mm × 6mm | 5mm × 5mm | 5mm × 6mm |
| Cost | $3.50 | $1.20 | $4.80 |
Your Task:
- Calculate power budget for each SoC (hint: device is active ~1% of time for BLE, asleep 99%)
- Determine which SoC meets 7-day battery life requirement
- Consider: Does the fitness tracker need hardware FFT, or is software sufficient at 100 samples/min?
- Make a selection with justification
What to Observe: The ESP32-C3 has 5 µA sleep (12.5× worse than nRF52832). Over 7 days at 99% sleep time, that’s 5 µA × 168 hours × 0.99 = 0.83 mAh vs 0.07 mAh—nearly 1 mAh difference from sleep alone! This demonstrates why sleep current dominates battery life.
Solution Hint: nRF52832 is optimal: 0.4 µA sleep + 5.3 mA BLE TX × 1% duty = ~0.06 mAh/day average → 3,333-day battery life (theoretical). Even with 50× safety margin for real-world usage, meets 7-day target easily.
Common Pitfalls
Assigning two functions to the same GPIO pin through hardware multiplexing without checking simultaneous use. An ESP32 cannot simultaneously use hardware SPI and a second UART on overlapping pins. Map all peripheral assignments before PCB layout.
Placing antenna traces near digital switching signals, ground plane gaps, or metal enclosure walls. RF layout violations reduce effective range by 50–90%. Follow manufacturer reference layouts precisely and validate with antenna efficiency measurements before production.
Using CPU-polled SPI to read a 100 ksps ADC, consuming 80% of CPU cycles on data transfer alone. DMA-driven SPI transfers complete in background, freeing the CPU for signal processing. Configure DMA for any peripheral exceeding 10 kbps data rate.
Deploying a chip revision with known silicon bugs (ADC nonlinearity, watchdog false triggers, clock glitches) discovered after tape-out. Always check manufacturer errata sheets and prefer revisions labeled “production” over “A0” or “engineering sample.”
33.13 Summary
This chapter covered IoT System-on-Chip architecture:
- SoC Integration: Modern IoT SoCs pack CPU, memory, radio, sensors, and power management on a single chip (4mm x 4mm for TI CC2650)
- Commercial vs Research: TI CC2650 draws ~1mW for general-purpose IoT; research SoCs achieve 6.45µW for battery-free sensors
- Hardware Accelerators: Dedicated DSP blocks (FFT, CORDIC, FIR, MAC) provide 20-100x power savings versus software implementations—critical for ultra-low-power sensing applications
- Asymmetric Radios: Research SoCs use simple UWB transmitters (100µW) with ultra-low-power wake-up receivers (1µW), offloading complex RF processing to wall-powered gateways
- Die Area Allocation: Radio (26%), memory (19%), power management (15%), DSP (15%), CPU (11%)—radio and memory dominate cost
- Memory Cost: 8KB SRAM occupies 19% of die area; memory architecture drives both chip cost and application capability
- Energy Harvesting: Integrated MPPT boost converters extract 75-150% more power from solar cells in suboptimal lighting conditions
33.14 Concept Relationships
| Concept | Relationship | Connected Concept |
|---|---|---|
| Hardware Accelerators | Enable | 20-100× power savings by replacing software loops with dedicated circuits (FFT, AES, CORDIC) |
| Die Area | Determines | Chip cost — radio (26%) and memory (19%) dominate, while CPU is only 11% |
| Asymmetric Radio | Optimizes for | IoT communication pattern (mostly transmit, rarely receive) with 100× simpler RX |
| MPPT Boost Converter | Increases | Energy harvesting efficiency 75-150% in suboptimal lighting vs fixed-impedance charging |
| On-chip SRAM | Costs | $0.10-0.50 per mm² — 8KB occupies 19% of die, driving up price from $0.50 to $5 |
| UWB Transmitter | Simplifies | Radio design by eliminating complex modulation (just pulse timing) |
| Power Gating | Reduces | Leakage current to <1 nA by completely disconnecting unused power domains |
33.15 See Also
SoC Fundamentals:
- MCU vs MPU Selection - Choosing between integrated SoCs and discrete processor+radio solutions
- Power Management and Interfaces - Sleep modes and power budgeting for SoC-based designs
- Enablers Fundamentals - Computing power and miniaturization trends enabling modern SoCs
Wireless Integration:
- Bluetooth & BLE - BLE radio integration in SoCs like nRF52 and TI CC2650
- LoRa & LoRaWAN - SoC-based LoRa transceivers and their power characteristics
System Design:
- Prototyping Hardware - ESP32, nRF52, and other SoC development kits
- Energy-Aware Considerations - Leveraging hardware accelerators for power optimization
Fundamentals:
- Enablers Fundamentals - Computing power and miniaturization enablers
- Communication and Protocol Bridging - Sensor communication protocols
Platforms:
- Prototyping Hardware - Arduino, ESP32, Raspberry Pi platforms
- Specialized Prototyping Kits - Platform selection guide
Power:
- Energy-Aware Considerations - Power budget calculations
- Enablers Production - Power management frameworks
Architecture:
- Edge-Fog Computing - MCU vs MPU in distributed architectures
- IoT Reference Models - Device layer specifications
Sensing:
- Sensor Fundamentals - ADC resolution requirements
- Sensor Interfacing - GPIO, I2C, SPI connections
Learning:
- Videos Hub - Hardware selection tutorials
33.16 What’s Next
| Direction | Chapter | Focus |
|---|---|---|
| Next | Communication and Protocol Bridging | Protocol translation, data aggregation, and gateway processing |
| Back | Power Management and Interfaces | Sleep modes, GPIO, PWM, and ADC for SoC-based designs |
| Related | Enablers Fundamentals | Computing power and miniaturization trends enabling modern SoCs |