sensor systems made easy - iot summit 2015 · (base spec) • 1.52 dmips/mhz ... • ahb, ahb-...

© Synopsys 2013 1

Smart Sensor Systems Made Easy SensorsCon 2013

Paul Garden, Jos Hegge March 6th, 2013

© Synopsys 2013 2

Smart Sensor Systems Made Easy

Sensor Systems

Building sensor systems with standard IP blocks

How to optimize further

Conclusion

© Synopsys 2013 3

Smart Sensor Systems Today

© Synopsys 2013 4

Sensor System Evolution

CPU based SoC

Analog in

Digital in

Sensor

Sensor

Discrete

Digital out Signal

Processing

Signal Processing

Mixer Peripheral

ADC

Peripheral

Signal Processing

DSP

MCU

Discrete Signal

Processing

Signal Processing

ADC

Peripheral

Mixer Peripheral Signal Processing

Sensor

Sensor

Analog in

Digital in

Digital out

Discrete Components Sensor Digital

Filter Peripheral Analog Signal

Processing Conversion ADC

Analog in Digital out

Com

plexity and Performance

© Synopsys 2013 5

Sensor Evolution

Sensor IC Scalable CPU

Analog in

Digital in

Sensor

Sensor

Digital out Signal Processing

Signal Processing

Mixer ADC

Peripheral

Signal Processing

Signal Processing ADC

Analog in Sensor

• Scalable Sensor CPU Solution • Signal Processing • Sensor Fusion Capability • Custom Instructions • Floating Point • DesignWare® IP Peripherals

© Synopsys 2013 6

Sensor Market Growth Example

© Synopsys 2013 7


Sensor systems



Conclusion

© Synopsys 2013 8

Digital IO

Sensor Hierarchy Multiple ways to get sensor data to the application processor

Application SoC

Storage CPU Audio subsystem

Video subsystem Connectivity

Graphics subsystem

Sensor Hub

Analog Sensor

Analog Sensor

Digital Sensor

Combo Sensor

Digital IO Analog IO

Analog Sensor

Digital Sensor

4

Analog input, requires ADC in SoC or on separate die

Sensor hub, real-time tasks for sensor

processing off-loaded to hub; can

support sensor fusion

Digital Sensor

1

3

2

Digital input, calibration,

linearization & filtering can take place in the sensor

Multiple sensors combined in one; could support sensor fusion

Presenter

Presentation Notes

1 Analog sensors essentially provide raw data, the receiver needs to calibrate, linearize and filter to be able to use it. 2 Digital sensors may already take care of a lot of this processing. This makes a digital sensor a lot more attractive for an application designer 3 Sensors may also be combined in one package. This could make it possible to use fusion algorithms to combine the data of the sensors in a meaningful way. In the case of motion sensors this goes already as far as combining the inputs of 10 different properties, hence also called 10-D (dimensional) sensors 4 Into the extreme all sensor processing may be off loaded to a dedicated slave system, often referred to as sensor-hub This overview depicts a kind of hierarchy since from a digital sensor onwards in all of these systems processors are used for the digital processing. ---------------- Since sensors are 3-D, and alignment is required between axis and sensors, sensors will be integrated together. In this way samples are aligned. Another reason maybe even more important would be reduction of BoM. Since sensor hub is already required, fusion on Combo sensor is dedicated (flexible unexpected to be validated !!!)

© Synopsys 2013 9

Sensor System

CPU based Sensor System

SoC

CO

MM

UN

ICATIO

NS

IF

NVM

Sensor IF

Actuator IF

AFE (AD

) AFE

Host Chip

CPU AHB

AHB

AHB

On chip bus (AH

B)

Sensor Chip

Actuator Chip

Application Processor

Presenter

Presentation Notes

This represents a digital sensor. A combo sensor is very similar, it just has multiple inputs Analog sensing element is probably on another die. A sensor may need outputs (actuator) to drive some kind of control signal. After Analog to digital conversion the data is transported across the internal bus to the processor. Sensor data is transmitted to the user via the communication interface.

© Synopsys 2013 10

UART

AMBA APB

GPIO

USB controller

Ethernet controller

SATA controller

PCIe controller

Synopsys DesignWare IP Portfolio

DDR PHY

DDR controller

USB PHY

PCIe PHY

SD/MMC controller

XAUI PHY

SATA PHY I2C

HDMI controller

HDMI PHY

Audio Codec

ARC Audio processor

ADCs DACs

Signal processing

VIP

Video Front End

ARC Video processor

Physical IP

MIPI DigRF, CSI, DSI

controller

MIPI D-PHY M-PHY

Digital IP

VIP VIP

Verification IP

Embedded Memories

Embedded Memories

(SRAM, ROM, NVM)

Datapath

Logic Libraries

VIP

ARC CPU

ARC RISC/ DSP

AMBA 3 AXI & AMBA 2.0 AHB

VIP

VIP

Presenter

Presentation Notes

Consumers are driving the need for full-featured products, SoCs are increasing in complexity/cost. IP is necessary to reduce cost, lower integration risk & improve time to market Good news is that the structure of these SoCs start to look very similar, Structure driven by, and enabled by STANDARDS on-chip interconnect and on-chip/off-chip interconnect Our job is to enable rapid assembly and implementation of these SoCs - IP is critical to enabling this Synopsys provides semiconductor suppliers the IP to lower their cost of development and to reduce their time-to-market. Highlight Subsystems

© Synopsys 2013 11

Synopsys ARC EM4 CPU Core

• ARCv2 16/32-Bit ISA • Less than 10K Gates (base spec) • 1.52 DMIPS/MHz • 3.6uW/MHz (28nm HPM) • 32-bit directly addressable memory • I & D CCM (single cycle up to 1MB) • Hardware Multiplier & Divider • Up to 190 custom instructions • Up to 240 configurable interrupts

with 16 priority levels • Low latency peripheral port • AHB, AHB-Lite, BVCI interfaces • JTAG Debug support • MetaWare Debugger & Compiler

Presenter

Presentation Notes

These are the details as needed. Key points are: The benefits of code density and performance described for ARCv2 in previous slides are leveraged in ARC EM family. The only difference between EM4 and EM6 is that EM6 has cache. EM4 can be built from an EM6 license.

© Synopsys 2013 12

ARC EM Processor Family

• EM delivers equal performance at 50% or less of the power and 50% of the area

• Configurable Core - Doesn’t waste gates

• Custom instruction support for code density and cycle count optimization

Performance and Area Efficiency Leadership

CONFIDENTIAL

© Synopsys 2013 13

Run Simulate

Optimize processor

features and capabilities

Model processor

performance

Write and debug

application code

Run application with out of box RTOS and OS

support

Development Tool Support

MetaWare GNU/GDB

FPGA

Develop Configure

xCAM, ISS, nSIM, xISS, nSIM, Virtual

Prototypes

ARChitect Simulators Development Tools

Operating Systems

MQX RTOS

Presenter

Presentation Notes

The ARC processor cores are supported with a complete suite of development tools. ARChitect is a configuration and delivery tool with a GUI interface that allows easy configuration of ARC processors including implementation of custom instructions. The tool can output either RTL or a Xilinx Bitstream File (.xbf). One seat of the ARChitect tool is provided with every ARC core license. The ARC processors are supported with a full range of simulation tools including xCAM which is 100% cycle accurate up to xISS and xISS Turbo that can run full simulations of the ARC processors at up to 200MHz on a standard PC. MetaWare is the premier ARC compiler, debugger, and linker. The full MetaWare toolkit also includes and Instruction Set Simulator (ISS). The MetaWare compiler is ~30% more efficient at compiling ARC code than the open source GNU for ARC. The ARC GNU and ARC Linux open source tools can be downloaded for free from SourceForge.com. The ARC processors are supported with a number of operating systems including the MQX RTOS that features a very small real-time kernel, and higher end OS Linux and Android. The ARC processors are supported on a number of FPGA development platforms that enable customers to build and debug their full SOC application.

© Synopsys 2013 14


Sensor systems



Conclusion

© Synopsys 2013 15

Sensor System Chip

CPU based Sensor System Chip

SoC

CO

MM

UN

ICATIO

NS

IF

NVM

Sensor IF

Actuator IF

AFE (AD

) AFE

Host Chip

CPU AHB

AHB

AHB

On chip bus (AH

B)

Sensor Die

Actuator Die


Presenter

Presentation Notes

This represents a digital sensor. A combo sensor is very similar, it just has multiple inputs Analog sensing element is probably on another die. A sensor may need outputs (actuator) to drive some kind of control signal. After Analog to digital conversion the data is transported across the internal bus to the processor. Sensor data is transmitted to the user via the communication interface.

© Synopsys 2013 16

Sensor System Chip

ARC EM Processor with AIE Extensions

SoC

NVM

Sensor Die

Actuator Die

A/D

D/A

Host Chip

User D

efined D

irect I/O

ARC EM4

Extension Registers

Link “I/O Functionality” to CPU by using

Custom Extensions


CO

MM

UN

ICATIO

NS

IF

Extension Instructions

Link “Data Functions” to CPU by using

Custom Instructions

Presenter

Presentation Notes

In the design of ‘small’ digital sensors criteria as lowest possible area and power are critical. The ARC processor is very configurable such that the processor itself can be optimized for its intended usage. Next to that the ARC EM processor provides a mechanism to support extreme levels of system optimization. The first one is the ability to create extensions to the core to support the required Input/Output functions. Both for interfacing to the sensors and for interfacing to the application processor. Having this functionality in the core avoids the inherent area, latency and processing overhead that comes with an on-chip bus. The second one is the ability to create custom instructions. Performance intensive functions may be implemented in HW. In the software these functions are then represented by dedicated instructions. The designer must make the trade-offs between the static & dynamic consequences.

© Synopsys 2013 17

• Part of ARC IP delivery • GUI to configure, extend,

make IP library selection • Easy to use • Point & click, drag & drop

environment • Pre-verified extensions • Provides:

– Verilog RTL Source – Simulation makefile – Synthesis scripts – Test vectors/Code – Documentation

Configuring the ARC EM Core Build your core to fit your Sensor Application using ARChitect

© Synopsys 2013 18

Easy to Implement Custom Hardware

• Used for user defined: – Instructions – Condition codes – Core registers – Auxiliary registers – Extension Flag – Allows complex interaction of any of

these types of extensions

• Generates: – Updates to tool chain – Verilog for RTL synthesis – Synthesis Scripts – Extension simulation models for the

Instruction Set Simulator (ISS) – Functional tests

with ARChitect Extension Automation Wizard

Extension Flag: for s/w optimization

Custom Extension Instruction: Process multiple data with complex operation in single instruction

Including condition code and/or set flag

Condition code: for s/w optimization

Extension Register: Core Register

Auxiliary Register

Presenter

Presentation Notes

Next to adding IO blocks and custom instructions to the core also other functions can be added, see the list here. The wizard helps the designer to make the necessary designs steps for these extensions and generates the related output files

© Synopsys 2013 19

Accelerator Benchmark Example Square root function

Confidential

‘Standard’ EM4 core

Performance Optimized ARC EM4

Area Optimized ARC EM4

Metrics @ 180nm (48-bit input & 24-bit output)

Code optimized for Cycle count

EIA custom Instruction

EIA custom Instruction

Footprint ROM Bytes (Instructions) 272 (136) 4 (1) 4 (1)

Cycles (Number) 353 1 24

Area (Gates) 600 3750b 1085

• EM4 with SQRT EIA versus ‘Standard’ EM4 only SQRT Code reduces from 136 to just 1 instruction! Code size footprint reduces by 98.5% Cycle count reduces by a factor of 353 or 14 depending on optimization – Area only increases by 485 gates (NAND2 equivalent)

Presenter

Presentation Notes

Here is an example of a square root. 4 implementations are compared with the resulting SW ROM footprint, the number of cycles for executing the code and the area (which a calculated sum of the area for the HW implementation and the area involved in the memory for storing the SW) NB we use the NAND compatible gate count @ 180nm process to translate the memory footprint to area The first case is a full software implementation for the square root where the software has been optimized for performance The second is partially implemented in HW, the software uses this HW via a custom instruction. The HW/SW combinations has been optimized for performance. The last column shows a similar HW/SW solution where it has been optimized for area. The column before is a special case where multiple square roots are calculated in a pipelined fashion. The table shows the consequences of the design choices made. This demonstrates the was a designer can make system level trade-offs and choose the optimal solution for his particular situation

© Synopsys 2013 21


• Configurable ARC EM4 Core suits sensor applications – Easy to extend the capability using custom extensions – Optimize for signal or algorithm processing, speed area or power

• Broad portfolio of Digital, Physical & Verification IP • Virtual & Physical Prototyping • Complete SW development environment • Training and Technical Support to match

With Synopsys and ARC it is Easy to build a best in class Sensor System Solution

sensor systems made easy - iot summit 2015 · (base spec) • 1.52 dmips/mhz ... • ahb, ahb-...

Documents