This document discusses approaches to offloading processing tasks from a host or AP to improve power efficiency. It describes traditional offloading through embedding dedicated hardware as well as limitations. An approach called "refined offloading" is proposed to move tasks out of the main OS environment through embedding, virtualization, a hybrid approach, or an isolated execution environment. Key criteria for choosing the best approach include power budget, complexity, memory needs, event rate, platform support, cost, and functional scalability.

1. May 9, 2016
1
Scalable approach to offloading
in SoC platforms
Eddy Kvetny (Intel)
May 9, 2016

2. May 9, 2016
2
Personal intro – Eddy Kvetny
• System Engineering Group Leader in Wireless
Innovation Org in Intel’s Communication
Device Group (iCDG)
• 20+ year of experience in networking,
communication, SW architecture from Intel,
Marvell, ADC/Teledata, Telrad, IXI Mobile

3. May 9, 2016
3
Agenda
1. New usages and motivation for offloading
2. Traditional approach and its limitations
3. “Refined offloading“
4. Practical examples of implementation
5. Criteria for choosing the best solution

4. May 9, 2016
4
New usages and challenges
AON and background usages

5. May 9, 2016
5
Offloading – traditional approach
• Move from AP/host to dedicated HW (“Embedding”)
• Additional benefits:
– Avoidance of OS restrictions
– Better cross-platform support and TTM
– Better privacy and security (TEE-like)
• Adopted by industry, supported many players:
– HW/Silicon vendors
– OS vendors
– Standardization organizations

6. May 9, 2016
6
Limitations of offloading/embedding
• Weak embedded CPU capabilities
• Scarce memory resources
• Very basic Power management
• Cost/area impact
• Complex platform design
• Limited functional scalability

7. May 9, 2016
7
Refinement of “offloading”
Offloading from
host/AP to embedded
engine (“embedding”)
refine
Offloading from main
OS (HLOS)
environment
• Periodic processing in background usages:
• SW latency >> HW latency (secs vs. us/ms)
• High-level OS (HLOS) – not a good choice
(restrictions + wake overhead + “SW noise”)
• Proposal:
Example: wake in Linux/Android – up to 1-2 secs
Example: Google updated their
definition of Context Hub not ruling
out its instantiation in AP/host

8. May 9, 2016
8
“Refined” Offloading options
1. Embedding
2. Enhanced embedding
3. Virtualization
4. Hybrid
5. Isolated Execution Environment

9. May 9, 2016
9
1. Embedding
• Small MCU/DSP, embedded
memory, interfaces, timers etc.
• Footprint fits internal memory
• Best for handling high-
frequency events (> 1Hz)
• Event pre-processing to reduce
# of AP/host wakes  better
platform power
AP/host
MCU
SRAM UART I2C
CNV
sensors
Embedded Engine
SoC
ROM

10. May 9, 2016
10
2. Enhanced embedding
• Memory footprint doesn't fit
internal memory
• Access to external memory via
paging mechanism
• Possible enhancements – use of
“work-sets” and predictions
with pre-loading code to SRAM
• Better functional scalability
AP/host
MCU
SRAM UART I2C
CNV
sensors
Embedded Engine
SoC
ROM
DRAM
DMA

11. May 9, 2016
11
3. Virtualization
• Not for servers only, relevant to SoC
• HLOS VM: high overhead per wake
and “SW noise” (up to 2-3s)
• Lightweight OS VM (RTOS): low
overhead per wake (10-20ms)
• HLOS power cost per wake > RTOS VM
CPU 1
SoC
CPU 2 CPU 3 CPU 4
HLOS
VM
OS4
(RTOS)
VM
O3
VM
OS2
VM
OS1
VM
VMM – VM Manager
AP/Host
• Main idea: Offload from HLOS VM to RTOS VM
• Observed up to 20% power save for 0.2-0.1Hz wake
• Best fits periodic processing at < 1Hz event rates

12. May 9, 2016
12
4. Hybrid
• Combination of embedding and
virtualization
• “Best of both worlds”
• Partition of processing:
– “Fast” (>1Hz, embedded)
– “Slow” (<1Hz, VM in host/AP)
• Split can be transparent to HLOS
CPU 1
SoC
CPU 2 CPU 3 CPU 4
HLOS
VM
OS VM
VMM – VM Manager
Service
VM
AP/Host
Service
Embedded Engine

13. May 9, 2016
13
5. Isolated Execution Environment
• Special CPU operating mode (uCode, new ISA)
• Virtual execution environment supported by
HW-based access control (“HW virtualization”)
• For some platforms extending SoC capabilities
beyond security processing only
• Examples: ARM TrustZone, Intel/AMD System
Management Mode (SMM), Intel SW Guard
Extension (SGX)

14. May 9, 2016
14
Criteria for choice
• Power budget
• Computing complexity (MIPS/MCPS) and special
needs (FPU, extended ISA – e.g. SSE/AVX)
• Memory footprint
• Event rate
• Access to additional SoC platform components
• Competitive cost/area
• Functional scalability

15. May 9, 2016
15
Functional scalability
• Targeting “future-proof” architecture that:
– Fits existing and constantly evolving usages
– Ready to support future known usages
– Has room to support future unknown yet
usages
• Scalability across platforms and OS’s

16. May 9, 2016
16
Wrap-up
• Offloading is NOT Embedding only
• “Refined” Offloading  “moving out of main OS
environment” (either HW or still host/AP)
• Multiple implementations of “refined” offloading
• Functional scalability is one of most important
criteria for choosing implementation approach

17. May 9, 2016
17