CTO Hour - USB.org - Welcome · CTO Hour Rahman Ismail –Intel Corporation USB Developer Days 2017 ... •Remove requirement for 3.3v •Add options at 960Mbps, 1.44Gbps •Built

USB Developer Days – October 24 – 25, 2017 USB Implementers Forum © 2017

CTO HourRahman Ismail – Intel Corporation

USB Developer Days 2017

Taipei, Taiwan

October 24 – 25, 2017

1

Welcoming Slideshow 1.ppsx

Welcoming Slideshow 1.ppsx


Agenda

• USB Type-CTM Vision

• Next Gen USB Display

• Demo

• Auth 2.0 & Secure FW Update

• What about Embedded Usages?

2


USB Type-C Vision

• Scalable connector• Hosts [Phone, Tablet, Detachable,…]

• Peripherals [Displays, Docks, Storage …]

• Connector Uniformity• Equal Source and Sink capabilities

• Identical Alternate Mode support

• Security Infrastructure• Authentication to identify compliant

USB PD Chargers

• Safely upgrade peripheral firmware

• Consistent and Reliable Behavior• Compliance and Interoperability

3

USB Type-C : A World Class Connector!


How well do we back it up?Specifications [A+]

• USB Type-C

• USB Power Delivery

• USB 3.2

• USB Type-C Authentication

• Device Classes• Audio• Communication & CDC Control• HID• Still Imaging/MTP• Printer• Mass Storage• Hub• CDC-Data• Smart Card• Content Security• Video• Personal Healthcare• Billboard• USB Type-C Bridge

4

USB

Bluetooth

Wifi

4GKeyboards

Mice

Embedded Usages

Digital Still Cameras

Cellphones

Printers

Scanners

Power

StorageDocks

BiometricsSecure Input

Web Cams

Automotive

Health Monitors

Display

Speakers

Usages


But USB is used in embedded environments!• Xbox Kinect 1 Camera

• Arguably the most commonly used RGB-D camera in robotics

• FLIR Pan Tilt• Two interconnected servo motors

• Robotiq 2 Finger Gripper• Robotic gripper

• Robotiq FT 300• Force sensor mounted at the

wrist that allows the robot to “feel” the environment

• Realsense Camera• Small RGB-D camera mounted at

the wrist

5


Agenda



• Demo



6


What About Sound?

7

• All the phones above support USB Audio• Not all support USB Type-C Digital Audio (TCDA)

• All Audio adapters are NOT created equal• Some support TCDA while some are just Analog Audio Accessories• All Analog Audio Accessories are now required to support TCDA

Support TCDA!


Transport Agnostic Display (TAD) Protocol• A protocol to unify display across transports

• Enables display and non-display clients to share a common transport and a single connector• Build on the value of the USB Type-C connector

• A scalable display protocol that maximizes the capabilities of the available transport

• A protocol that will support a range of input display streams

8

USB Display Adapter Adaption of TAD on USB


USB Display Adapter (UDA) Overview• Features:

• Transports video data/metadata over USB

• Supports up to 7 displays

• Supports display of protected content

• Allows for scalable resolutions/frame rate

• Works on both USB 2.0 and USB 3.1

• Can be combined with other USB device classes for multi-function devices (e.g. audio, HID, etc.)

• Specifications:• Transport Agnostic Display (TAD) specification will define video data

packetization, display management, content protection, etc.

• UDA device class specification will define mapping of TAD to USB


Use Cases

• UDA Dongle

• Native USB Display

• USB Display Docking

• USB Device as Source

USB Display Adapter Dongle

Physical Display

USB Connection Display Data Connection

USB Host as Source

USB Connection

USB Host as SourceUSB Device as Sink

USB Display Adapter Function

USB Host as Source

USB Connection

Display Data Connection

USB Connection

Physical Display

USB Display

USB Host as Sink

USB Device as Source

USB Connection


UDA Stack• Streaming Layer

• Source generates display data• Sink consumes display data

• TAD Layer• Provides display configuration and

management functions• Provides transport agnostic

packetization/depacketization

• TSA Layer• Translates between transport

agnostic and transport specific constructs

• Transport Layer• Provides transport across USB

Streaming Layer

Stream Sink

Transport Layer

TSA Layer

TAD Layer

USB Device Controller

UDA (Sink TSA)

USB Host Controller

TAD TX

UDA Driver (Source TSA)

Stream Source

TxDM RxDMTAD RX

TAD Source TAD Sink

Source Management Entity

EP 0(Control)

EP 1(Int IN)

EP 2(Bulk Out)

Monitor

Stream Tx

Main Stream Data

Control

Device Context

EP 0 EP 1 EP 2

Secondary Data

EP 3EP 3

(Bulk Out)


External UDA Architecture• Single device class function

• Can be combined with Audio, HID, any Interface level class

• Two bulk OUT endpoints per Stream Sink• 1 for video data

• 1 for metadata

• One interrupt IN endpoint• Used for UDA-to-Host notifications

• Shared across all internal entities

• Default Control endpoint• Used to service class specific requests

TAD Sink

Streaming LayerTAD LayerUDA Class Function (TSA Layer)

1

USB Device Control

Interrupt IN Endpoint

Default Control Endpont

USB Standard Command Processing

TAD Main Stream Data

UDA & TAD Notification Data

TAD Response, UDA Class Responses

USB, UDA, TAD Control

Required Optional

TAD Rx2

TAD Rx1

2

Bulk OUT Endpoints

TAD Rx7

4

14

TAD Commands, UDA Class Requests

Display Data Connection

Stream TX1

Stream Sink 1

Stream Sink2

Stream TX2

Stream TX7

Stream SinkN

3TAD Secondary Data

5

15

12


Internal UDA Architecture• UDA Function

• 1 per USB device• Receives and routes data and

metadata• Provides correlation between USB

time and presentation time

• TAD Rx • 1 per Stream Sink• Provides de-packetization and stream

control functions• TAD Handles provide Stream Sink

addressing

• RxDM • 1 per UDA Function• Handles device-level management

and configuration

TAD Sink

Streaming LayerUDA Function (TSA Layer)

Std. USB Device Control

UDA & TAD Notification Data

Defined in this specification Implementation specific

Bulk OUT

IN

TAD Main Stream Data

USB, UDA & TAC Command & Control

I/O

TAD Layer

RxDM

Command/Response Data

Notifications

Video Pipeline1

Stream Tx1

Video Post-Process

& Render

Video Decrypt

Video Decode

Bulk OUTTAD Secondary

DataSecondary Data Packets

Main Stream Data Packets video pixel data

metadata

Notifications

Control Requests/Responses

TAD Rx

Stream Control

De-Packetizer

Time Sync


Encapsulation Overview

TAD Data

TAD Control

USB Bulk OUT

v Uni-directional: TAD Source to TAD Sink

TAD Tx TAD Rx

v Maps TAD Data onto USB Transfers

v Unique Bulk OUT EP per TAD Rx Instance

UDA Class Notification

v Uni-directional : TAD Sink to TAD Source

TAD Rx TAD Tx

RxDM TxDM

v Single shared Interrupt IN EP per UDA

TAD Control Messages

UDA Class-Specific Control Transfers

v USB Message Pipe

TAD TxDM RxDM

TAD Tx TAD Rx

v Carries TAD Control Messages to TAD

Sink and Message responses to TAD

Source

v Uses USB Default Control EP

TAD Main Stream Data and TAD Secondary Data

v One or more streams per UDA (depending on

UDA structure)

14


Agenda



• Demo



15


USB Type-C Docking• Dock

• Two USB-A 2.0 ports

• Ethernet port

• HDMI output

• A USB Type-C charging port

• Enable desktop PC experience• Connect a Display, Mouse and Keyboard

• Simultaneously charge your docked cell phone

16


Agenda



• Demo



17


USB Type-C Authentication 2.0• A USB device cannot Authenticate a USB Host

• The specification does allow a USB PD Source to authenticate a USB PD Sink• Need to provide a means for a USB Device to Authenticate a USB Host

• Allows only for one way Authentication• Need to support mutual Authentication• Need to support link encryption

• Define a means to protect against illegal firmware updates• Provide a simple standardized hardened FW update process

18


USB Device FW Security Goals

•USB Device FW contains known good image

•USB Devices support Secure FW Update

• Security Options:• No FW update allowed• New standard commands: Get_FW_Status,

Set_FW_Status• Support full FW enforcement by the device

• Expensive to implement

• Device needs to support on-device image signature verification

19


USB Device Architecture • ROM equivalent implementation

of new commands: Get_FW_Status, Set_FW_Status

• The FW hash + Valid State• Cached locally to reduce

performance Penalty

• ROM equivalent implementation of FW Update command to support secure recovery

• No FW in updateable FW be able to Compromise the above

20

USB Device non-updateable FW

Supports Get_FW_Status, Set_FW_Status,

FWUpdate command

USB Device Updateable FW

FW hash + Valid State


HW Block Diagram of the device

21

uC

Write Protected Flash Address Space(Secure code)

USB Interface

Unprotected Flash Address space

(Unsecure code)

Parses all USB commands Executes ROM equivalent Commands and Completes Response on the interface for all commands

InterfaceHW

RST

Fixed NMI/RST Entry Point(s) to secure code

Executes non Secure Commands and providesresponse to Secure code

Temp Writable Hash, Valid State Storage,

Write Protected (when code exits)

NMI


SW Flow Diagram

22

Disallow FW Update

Update FWIs FW HashCorrect?

Secure Device

N

Y

DeviceSupports

FW_Status?

Y

Legacy Device

N


Agenda



• Demo



23


Why USB?• What’s good with USB: Plug and play – Just works!

• Unified SW stack, saving development cost

• Comprehensive compliance program, assured interop

• Ubiquitous implementation

• What’s not so good with USB: it’s a universal serial bus• Lack of optimization for application specific connectivity

• A “walk up” port needs to be general

• Inbox USB was not a focus in the past Not a fundamental barrier

• Industry Perception is that USB is Complex, Expensive and Inefficient• Much of the problem is generality We will cut away what isn’t needed

• Existing IP reduces development costs Need to match recurring costs


Areas of Exploration• Multi-drop

• Asymmetry - for devices that have predominantly simplex traffic

• Simplify Enumeration/addressing of devices

• Host system complexity• Need to be able to scale both HW and SW complexity• enable simple hosts (in addition to simple devices)

• Security• Link encryption

• Energy Efficiency• Perception/Real Issue?

• Reduce Wire count

• More BW options

25


USB for embedded applications: IO portfolio• Expand on existing USB 3.2

• Add asymmetrical lane configuration (x1/x3, x3/x1)

• Add more data rate options (2.5Gbps, 7.5Gbps, …)

• Fix USB 2.0 legacy issues• Remove requirement for 3.3v

• Add options at 960Mbps, 1.44Gbps

• Built on eUSB2.0

• Introduce asymmetrical IOs for application specific interfaces• Dual-simplex LFPS/SS with optional LFPS on VBus

• Half-duplex LS,FS/HS

• Simplified link/protocol layers to adapt application specific usages

26

Customized PHY for power, cost and device

complexity


LFPS LFPS

SSTX SSRX

Port A Port B

LFPS on VBus for cabled based applications

Dual simplex link for embedded application

Example LFPS/SS Asymmetrical Link Topologies5V

capacitive coupling

LFPS LFPS

VBUSSource

VBUSSink

SSRX SSTX

Port A Port B

Full-duplex link with single pair of wires

LFPS LFPS

SSTX SSRX

Port A Port B


Embedded USB2 – built on eUSB2• eUSB2 is low-voltage USB2

• 3.3v removed

• LS/FS single-ended

• Still DC coupled

• eUSB2 extension• Introduce asymmetry

• Maintain the same PHY architecture but go far (30”)

• Introduce HS+/HS- gears for rate match• 240xN Mbps (N=1~6)

• Introduce bridging hub

28

HS_Data_Driver_Input_P

HS receiver

eD+

eD-

Single-ended Receivers

Single-ended Transmitters

SE_Receiver_Output_P

SE_Driver_Input_P

HS transmitter

HS_Differential Receiver_Enable

Low-speed/Full-speed

Rpd Rpd

RSRC_HS

Squelch

Squelch detector

SE_Receiver_Enable_P

SE_Driver_Enable_P

High-speed

Differential receiver

termination(Repeater Mode)

HS_Data_Driver_Input_N

HS_Driver_Enable

HS_Differential_Receiver_Output

SE_Receiver_Output_N

SE_Driver_Input_N

RSRC_HS

RSRC_LSFS

RSRC_LSFS

SE_Receiver_Enable_N

SE_Driver_Enable_N


Guiding Philosophy• Software:

Use what we have but “compile out” what isn’t needed

• Host Si:

Simplified HC pre-configured for intended use

• Bus:

Asymmetric Link with optimized speeds

• Device:

Already good, we’ll make it better

29

Enhancing USB for In-Box Applications for Best TTM


Call to Action• Talk to us about your embedded needs

• Support Authentication

• Join the USB Display WG

• Use Industry standard specifications (www.usb.org)

• Get certified!

USB : It Just Works!

http://www.usb.org/


Certification & Brown M&Ms

31

• Test: Non-removable bit in Hubs

• If you fail these kind of tests then to paraphrase David Lee Roth:• Guaranteed you’re going

to have a technical error• You didn’t read the

specification… Sometimes it would threaten to just destroy the whole show.


Finally, to reiterate… • Only design to official released versions of USB specifications

• Developer presentations are intended to help familiarize you with the general characteristics of these specifications and provide design guidance

• These presentations are not technically complete and should not be used as the sole basis for product designs

• USB technology has evolved into highly complex and challenging designs• Always make use of certified product suppliers – silicon, connectors, etc.

• Proper materials and manufacturing processes are increasingly more critical to making successful products

• Submit your products for USB certification

32


Q&A

33


Dual-Simplex LFPS/SS Asymmetrical PHY Options

Same PHY, different combo simply simplified

34

PISOTxD SSTx

SIPORxD

SSRx

PLL

Rosc

CR

D

RefCLK

LFPS Tx

LFPS Rx

LTSSM

LFPS/LBPMencode

LFPS/LBPMdecodeCDR

Tx BufferTxD

SIPORxD

SSRx

PLL

Rosc

CR

D

RefCLK

LFPS Tx

LFPS Rx

LTSSM

LFPS/LBPMencode

LFPS/LBPMdecodeCDR

PISOTxD SSTx

Rx BufferRxD

PLL

Rosc

RefCLK

LFPS Tx

LFPS Rx

LTSSM

LFPS/LBPMencode

LFPS/LBPMdecode

Power Source

VBusSource

Tx BufferTxD

SIPORxD

SSRx

PLL

Rosc

CR

D

RefCLK

LFPS Tx

LFPS Rx

LTSSM

LFPS/LBPMencode

LFPS/LBPMdecodeCDR

PISOTxD SSTx

Rx BufferRxD

PLL

Rosc

RefCLK

LFPS Tx

LFPS Rx

LTSSM

LFPS/LBPMencode

LFPS/LBPMdecode

Power Sink

VBusSink

Dual-simplex symmetrical

Dual-simplex asymmetrical

LFPS on VBus


Full-Simplex LFPS/SS Asymmetrical PHY

LFPS/SS separation in the frequency domain made it possible for a full-duplex link

35

PISOTxD SSTx

SIPORxD

SSRx

PLL

Rosc

CR

D

RefCLK

LFPS Tx

LFPS Rx

LTSSM

LFPS/LBPMencode

LFPS/LBPMdecodeCDR

Dual-simplex symmetrical Full-duplex asymmetrical

dB

ffLFPS

~ 10~50MHz

f2 f1 fSS

~2.5GHz

LPF HPF

Device

+-

+-

Txp

Txn

Rxp

Rxn

AC Capacitor

Device systemCable Assembly

Host

+-

+-

Txp

Txn

Rxp

Rxn

AC Capacitor

Host system

PISOTxD SSTx

Rx BufferRxD

PLL

Rosc

RefCLK

LFPS Tx

LFPS Rx

LTSSM

LFPS/LBPMencode

LFPS/LBPMdecode

Tx BufferTxD

SIPORxD

SSRx

PLL

CR

D

RefCLK

LFPS Rx

LTSSM

LFPS/LBPMdecodeCDR

Rosc

LFPS/LBPMencode

LFPS Tx

HFP


HS receiver

eD+

eD-




SE_Driver_Input_P

HS_Differential Receiver_Enable

Low-Speed

Rpd Rpd

Squelch

Squelch detector


SE_Driver_Enable_P

High-speed

HS_Differential_Receiver_Output


SE_Driver_Input_N

RSRC_LSFS

RSRC_LSFS


SE_Driver_Enable_N

eD+

eD-




SE_Driver_Input_P

HS transmitter

Low-Speed

Rpd Rpd

RSRC_HS


SE_Driver_Enable_P

High-speed

HS_Driver_Enable


SE_Driver_Input_N

RSRC_HS

RSRC_LSFS

RSRC_LSFS


SE_Driver_Enable_N

HS_Data_Driver_Input_P

HS_Data_Driver_Input_N

eUSB2 asymmetrical link – touch, low res camera

• Customized for asymmetrical data traffic

• Same USB 2.0 protocol but simplified

• LS half-duplex (single-ended forwarded clocking) for control and initialization

• HS simplex for bulk data (isoch’) transfer• Add 6 HS+/- gears for rate match (240, 480, 720, 960, 1200, 1440-Mbps)

36

Host DFP Device UFP

Documents

CTO Hour - USB.org - Welcome · CTO Hour Rahman Ismail –Intel Corporation USB Developer Days 2017 ... •Remove requirement for 3.3v •Add options at 960Mbps, 1.44Gbps •Built