Embedded USB 2.0 OTG Full-/Low-Speed Dual-Role Core FHG...

Embedded USB 2.0 OTG Full-/Low-Speed Dual-Role CoreFHG USB OTGDRDData Sheet

Version: 1.1

Date: April 27, 2004

Author(s): Andre SchlegelRalf OberlanderStefan Schulze

Document History

Version Date Responsible Description

v1.00 2003/02/01 St. Schulze First public version.v1.01 2003/03/25 St. Schulze OTG application notes added.v1.02 2003/03/29 A. Schlegel Reviewv1.03 2003/06/02 St. Schulze Top level symbol update.v1.1 2003/12/15 St. Schulze Top level symbol update according to the latest

release of UTMI+ Specification. Register Mapupdate concerning changed interface signals.

v1.11 2003/03/02 R. Oberlander Symbol update, DPRAM-Signals added

Disclaimer

This document is provided “as is” with no warranties whatsoever including any warranty of merchantability,fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification, or sample.

Contact

emsys Embedded Systems GmbHD-98693 IlmenauEhrenbergstrasse 11Phone: (+49)-3677-668250Fax : (+49)-3677-668259

Germany

Contents

List of Figures ii

List of Tables iv

1 Introduction 1-11.1 Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-11.2 Licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2

2 Interface 2-12.1 Parameter/Configuration Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22.2 USB Transceiver Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-42.3 Operational Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-62.4 Register Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7

2.4.1 Register Interface Write Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-82.4.2 Register Interface Read Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

2.5 Dual-Port RAM Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10

3 Architectural Overview 3-1

4 Register Map 4-14.1 Common Register Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

4.1.1 ID Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14.1.2 USB Control Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24.1.3 Frame Timer Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

4.2 Event Register Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-34.2.1 Main Event Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-34.2.2 Main Event Mask Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-44.2.3 Pipe Event Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-54.2.4 Pipe Event Mask Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5

4.3 Page Register Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-64.3.1 Pipe Select Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6

4.4 Port Register Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-64.4.1 Port Status Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-64.4.2 Port Control Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-84.4.3 Port Status Change Event Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-104.4.4 Port Status Change Event Mask Register. . . . . . . . . . . . . . . . . . . . . . . . .4-11

4.5 Pipe Register Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-124.5.1 Pipe Control Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-134.5.2 Pipe Configuration Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-134.5.3 Pipe Address Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-164.5.4 Pipe Status Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-164.5.5 Pipe Data Pointer Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-184.5.6 Pipe Total Bytes Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

c©emsys 2003

Contents

4.5.7 Pipe Alternative Data Pointer Register. . . . . . . . . . . . . . . . . . . . . . . . . . .4-194.5.8 Pipe Alternative Data Total Bytes Register. . . . . . . . . . . . . . . . . . . . . . . .4-20

4.6 Debug Register Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-214.6.1 Debug Control Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-214.6.2 Debug PID Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-224.6.3 Debug Status Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-234.6.4 Test Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23

4.7 Core Configurations Register Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-234.7.1 Main Configuration Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-244.7.2 Mode Configuration Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24

5 Software Application Notes 5-15.1 USB Transaction Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

5.1.1 Host Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25.1.2 Device Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8

5.2 Port Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-125.2.1 Port Test Capability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13

5.3 Buffer Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-145.4 Data Buffer Handling for Streaming Pipes. . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15

5.4.1 Data Streaming for Receive Pipes. . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-155.5 Pipe Register Permissions for Host Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-195.6 Peripheral Control Pipe Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-20

5.6.1 Software Dataflow for Setup Requests. . . . . . . . . . . . . . . . . . . . . . . . . . .5-235.7 Session Request Protocol Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-27

5.7.1 Host SRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-275.7.2 Peripheral SRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28

5.8 Host Negotiation Protocol Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-305.8.1 Host HNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-305.8.2 Peripheral HNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-31

6 Hardware Application Notes 6-16.1 Pipe Count Estimation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

6.1.1 Host Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16.1.2 Device Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3

6.2 USB Transceiver Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-36.3 Core Suspend. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-46.4 OTG Electrical Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5

6.4.1 Session Request Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-56.4.2 Implementation Example for SRP Support. . . . . . . . . . . . . . . . . . . . . . . . 6-6

6.5 System Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-86.5.1 Data Interface System Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86.5.2 Implementation Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9

A Symbol Index A-1

B Glossary B-1

c©emsys 2003 ii

List of Figures

2.1 USB Dual Role Controller Top Level Interface. . . . . . . . . . . . . . . . . . . . . . . . . . 2-22.2 Register Interface Write Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-92.3 Register Interface Read Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10

5.1 Pipe Page Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15.2 Transfer Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25.3 Host Isochronous OUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-45.4 Host Isochronous IN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-55.5 Host Bulk/Control/Interrupt IN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-65.6 Host Bulk/Control/Interrupt OUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-75.7 Host Control SETUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-85.8 Device Isochronous OUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-95.9 Device Isochronous IN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-105.10 Device Bulk/Control/Interrupt OUT/SETUP. . . . . . . . . . . . . . . . . . . . . . . . . . . .5-115.11 Device Bulk/Control/Interrupt IN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-125.12 Concatenating Data Buffers without Streaming. . . . . . . . . . . . . . . . . . . . . . . . . .5-165.13 Concatenating Data Buffers with Streaming. . . . . . . . . . . . . . . . . . . . . . . . . . . .5-185.14 Pipe States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-195.15 Setup Request with IN data stage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-225.16 Setup Request with OUT stage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-225.17 Setup Request without data stage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-235.18 Dataflow for Setup Request with IN data stage. . . . . . . . . . . . . . . . . . . . . . . . . . .5-245.19 Dataflow for Setup Request with OUT data stage. . . . . . . . . . . . . . . . . . . . . . . . .5-255.20 Dataflow for Setup Request without data stage. . . . . . . . . . . . . . . . . . . . . . . . . . .5-265.21 A-Device SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-285.22 B-Device SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-295.23 A-Device HNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-315.24 B-Device HNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-32

6.1 Typical USB Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-26.2 Connection to PDIUSBP11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-46.3 Connection to PDIUSBP11A using the single ended interface. . . . . . . . . . . . . . . . . . . 6-46.4 VBUS Pulsing Analog Part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-66.5 VBUS Threshold Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-76.6 Data-Line Pulsing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-86.7 Using theFHG USBOTGDRD core with Bi-directional Dual-Port RAM. . . . . . . . . . . . 6-9

c©emsys 2003

List of Tables

2.1 Parameter Interface Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-32.2 Configuration Interface Signals and Description. . . . . . . . . . . . . . . . . . . . . . . . . . 2-42.3 USB Transceiver Interface Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-52.4 Power Control Signal Interface Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-62.5 Operational Signal Interface Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-72.6 Register Interface Signals and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-82.7 Full-/Low-Speed Core Write Timing Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 2-92.8 Read Timing Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-102.9 Dual Port RAM Interface Signals and Description. . . . . . . . . . . . . . . . . . . . . . . . .2-10

4.1 ID Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14.2 USB Control Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24.3 Frame Timer Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-34.4 Main Event Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-34.5 Main Event Mask Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-44.6 Pipe Event Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-54.7 Pipe Event Mask Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-54.8 Pipe Select Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-64.9 Port Status Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-74.10 Port Control Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-84.11 Port Status Change Event Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-104.12 Port Status Change Event Mask Description. . . . . . . . . . . . . . . . . . . . . . . . . . . .4-124.13 Pipe Control Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-134.14 Pipe Configuration Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-144.15 Pipe Address Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-164.16 Pipe Status Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-164.17 Pipe Data Pointer Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-184.18 Pipe Total Bytes Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-194.19 Pipe Alternative Data Pointer Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-194.20 Pipe Alternative Data Total Bytes Description. . . . . . . . . . . . . . . . . . . . . . . . . . .4-204.21 Debug Control Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-214.22 Debug PID Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-224.23 Debug Status Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-234.24 Test Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-234.25 Main Configuration Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-244.26 Mode Configuration Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24

5.1 Pipe Register Access Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-205.2 Control Pipe Default Settings after USB Reset. . . . . . . . . . . . . . . . . . . . . . . . . . .5-21

6.1 Required Pipe Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-26.2 Comparison of Pipe Parametrization Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

c©emsys 2003

List of Tables

A.1 Label Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1A.2 Bit/Field Index 1 of 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-2A.3 Bit/Field Index 2 of 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-3A.4 Bit/Field Index 3 of 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-4A.5 Register Index 1 of 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-5A.6 Register Index 2 of 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-6A.7 Register Index 3 of 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-7A.8 Register Index 4 of 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-8

c©emsys 2003 v

Bibliography

[1] Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, Philips,Universal Serial Bus Specification, Revi-sion 2.0, Apr. 27 2000.

[2] Cypress, Hewlett-Packard, Intel, Microsoft, Motorola, NEC, Nokia, Philips, Texas Instruments, TransDi-mension,On-The-Go Supplement to the USB Specification, Revision 1.0, Dec. 18 2001.

[3] Compaq, Microsoft, National Semiconductor,Open Host Controller Interface Specification for USB, Release1.0a, Sept. 14 1999.

[4] Intel Corporation,Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1, Mar. 01 1996.

[5] USB IF,USB Mass Storage Class Specification Overview, Revision 1.1, June 28 2000.

[6] emsys Embedded Systems GmbH,Integrating the FHG Core as AHB Master, May 01 2003.

[7] Philips Semiconductors,PDIUSBP11A Universal Serial Bus Transceiver, Product Specification, June 1997.

[8] K. Koeman,Understanding USB On-The-Go. EDN Magazine, Nov. 22 2001.

c©emsys 2003

1 Introduction

1.1 Key Features

TheFHG USBOTGDRD is a scalable, high performance IP-Module for usage in ASIC- and FPGA-designs tointegrate full-/low-speed USB 2.0 device and host functionality in an embedded system. It provides an ease ofuse programming interface for the usage of almost every 16/32 bit microcontroller or DSP.

The key features of theFHG USBOTGDRD are:

• Fully compliant to USB Specification 2.0 [1] and the On-The-Go Supplement, Revision 1.0 [2]

• Full-/Low-Speed Device and Host capability (12Mbps/1.5Mbps)

• Supports Host Negotiation Protocol (HNP)

• Supports Session Request Protocol (SRP)

• Scalable number of pipes (max. 16)

• Supports all transfer types (Control, Interrupt, Bulk and Isochronous)

• Pipe direction, transfer type and fifo size can be configured during run-time

• Supports enhanced large buffer management

• Automatic retry for corrupted data packets

• Configurable for 16 or 32 bit data interface (64 bit in preparation)

• AMBA AHB ready

• PCI ready

• Dual-Port RAM interface available with scalable memory size

• Suspend/Resume/Remote Wakeup support

• Technology independent RTL implementation

• PCI evaluation module available

• Generic USB Host Software Stack with several class drivers available (for host/device and dual role)

• Optional OHCI [3] and UHCI [4] software emulation for host mode available

With the features described above, theFHG USBOTGDRD brings an USB interface to your system, which ishighly efficient from software’s point of view:

• All USB related timing critical features are realized in hardware. Therefore, for normal operation softwarehas only to manage the enumeration process

c©emsys 2003

1 Introduction

• Once a pipe or channel is established, the only task of the software is to provide data buffers (entire USBprotocol is managed by hardware, including data toggle, retry, polling of periodic pipes) This reduces thenumber and frequency of software interrupts to an minimum.

• The required interrupt latency time does not depend on the timing required by the USB packet level, buton the size of data buffers and pipe bandwidth

Typical USB devices working with the Embedded USB OTG Dual Role Controller are for example hard diskdevices, mobile phone devices, hand-held devices, high speed network or industrial applications.

1.2 Licenses

TheFHG USBOTGDRD core can be purchased using one of the following project based licenses:

• VHDL source code for ASIC designs

• Synopsys Design Ware Component for ASIC designs

• VHDL/Verilog Netlist for FPGA designs (Xilinx/Actel/Altera)

Other license models can be discussed upon request. The design kit contains the following parts:

• The IP component, depending on the selected license

• VHDL pre-compiled simulation models

• VHDL/Verilog USB 2.0 compliance test suite

• IP integration guideline

• Synthesis scripts

• Optional: PCI evaluation board

c©emsys 2003 1-2

2 Interface

This chapter describes the interface of theFHG USBOTGDRD. Refer to Section6.5.1for further details con-cerning the integration.

Figure2.1shows the top level of the USB Dual Role Controller with all its interfaces.

c©emsys 2003

2 Interface

Package List

ram_addr : OUT std_logic_vector (RAW-1 DOWNTO 0) ;

clk_rec : IN std_logic ;

clk_rec_out : OUT std_logic ;

clk_48 : IN std_logic ;

ram_en : OUT std_logic ; ram_dout : OUT std_logic_vector (DW-1 DOWNTO 0) ;

ram_din : IN std_logic_vector (DW-1 DOWNTO 0) ; over_current : IN std_logic ;

vb_on : OUT std_logic ;

reset_n : IN std_logic ;

uaddr : IN std_logic_vector (7 DOWNTO 0) ; ucs_n : IN std_logic ;

udata_in : IN std_logic_vector (DW-1 DOWNTO 0) ;

udata_out : OUT std_logic_vector (DW-1 DOWNTO 0) ; uint_n : OUT std_logic ;

urd_n : IN std_logic ;

uwr_n : IN std_logic ;

id_dig

id_dig : IN std_logic ;

rpu_ena : OUT std_logic ;

dlp_active : OUT std_logic ;

rpd_ena : OUT std_logic ;

alt_buffer_support : IN std_logic_vector (NOP-1 DOWNTO 0) ;

va_sess_vld : IN std_logic ;

vb_sess_end : IN std_logic ; vb_sess_vld : IN std_logic ;

vbus_vld : IN std_logic ;

dbg_support : IN std_logic ;

xtd_dbg_support : IN std_logic ;

ram_we : OUT std_logic ;

ucif_rdy : OUT std_logic ;

ser_rx_dm : IN std_logic ;

ser_rx_dp : IN std_logic ; ser_rx_rcv : IN std_logic ;

ser_tx_dm : OUT std_logic ;

ser_tx_dp : OUT std_logic ; ser_tx_se0 : OUT std_logic ;

ser_txen_n : OUT std_logic ;

xcvr_speed : OUT std_logic ;

id_pullup : OUT std_logic ;

core_suspend_n : OUT std_logic ;

ram_clk : OUT std_logic ;

chrg_vbus : OUT std_logic ;

dischrg_vbus : OUT std_logic ;

xcvr_suspend_n : OUT std_logic

Declarations Ports:

Generic Declarations

DW integer 32 RAW integer 10 NOP integer 8

over_current vb_on

rpu_ena

dlp_active

rpd_ena

va_sess_vld

vb_sess_end

vb_sess_vld

vbus_vld

ser_rx_dm

ser_rx_dp

ser_rx_rcv

ser_tx_dm

ser_tx_dp

ser_tx_se0

ser_txen_n

xcvr_speed

id_pullup

chrg_vbus

dischrg_vbus

xcvr_suspend_n

USB Transceiver Interface

Port/OTG Interface

Container

User:

ram_addr : (RAW-1:0)

clk_rec clk_rec_out

clk_48

ram_en

ram_dout : (DW-1:0) ram_din : (DW-1:0)

reset_n

uaddr : (7:0)

ucs_n

udata_in : (DW-1:0)

udata_out : (DW-1:0)

uint_n

urd_n

uwr_n

alt_buffer_support : (NOP-1:0)

dbg_support

xtd_dbg_support

ram_we

ucif_rdy

core_suspend_n

ram_clk

Register Interface

Dual Port RAM Interface

Configuration Interface

Operational Interface

Figure 2.1:USB Dual Role Controller Top Level Interface

2.1 Parameter/Configuration Interface

This section describes, how theFHG USBOTGDRD core can be customized to meet the requirements of a widerange of applications. Some (boolean) configuration values can be set by setting input signals to static “0” or“1”, whereas other configuration values can be set by generic parameters.

Table2.1shows the generic parameters used to configure the core for several requirements.

c©emsys 2003 2-2

2 Interface

Parameter Description

NOP Number of supported PipesThis parameter defines the number of pipes the core has to support. Depending on thisparameter, the hardware resources (pipe registers, pipe handling) will be generated.Must be within the range of 1..16.

DW Data WidthCan be set to 16 or 32 and defines the data width of the register interface and the wordsize for data pointer operations.

RAW RAM Address WidthSpecifies the dual port RAM address range. Upper limit is 17, when ifDW=16, and 34whenDW=32.

Table 2.1: Parameter Interface Description

c©emsys 2003 2-3

2 Interface

Table2.2shows the interface signals used to configure the core for several requirements.

Note: These signals must not change during normal operation.

Signal Width Scope Description

dbg support 1 IN Debug SupportSetting this signal to a one enables debug capabilitysupport as specified by theDebug Control Register.

xtd dbg support 1 IN Extended Debug SupportSetting this signal to a one enables extended de-bug capability support. Refer to theDebug RegisterGroupfor a detailed description.

alt buffer supportNOP IN Alternate Buffer Support

Setting one of these bits enables an alternative buffermanagement for this pipe. Enabling this featureis recommended for high-bandwidth, isochronouspipes. It requires additional hardware resources.This bit field is encoded as follows:

• alt buffer support[0] enable/disablefor pipe 0

• alt buffer support[1] enable/disablefor pipe 1

• : : :

• alt buffer support[NOP-1] en-able/disable for pipe NOP-1

Refer to thePipe Alternative Data Total Bytes Regis-ter andPipe Alternative Data Pointer Registerfor adetailed description. (Sections4.5.8, 4.5.7, 5.4)

Table 2.2:Configuration Interface Signals and Description

2.2 USB Transceiver Interface

Table2.3 shows all interface signals from/to the USB transceiver. Any USB transceiver with a serial interfacecan be used. Refer to Section6.2for a detailed description.


ser rx dm 1 IN Single Ended DMThis input must be connected to the single ended re-ceiver output of the D- data line.

ser rx dp 1 IN Single Ended DPThis input must be connected to the single ended re-ceiver output of the D+ data line.

ser rx rcv 1 IN Differential ReceiveThis input must be connected to the differential re-ceiver output.

USB Transceiver Interface Description (Continued on next page)

c©emsys 2003 2-4

2 Interface

Signal Width Scope Descriptionser tx dm 1 OUT DM Driver Output

This output must be connected to the DM line driver.ser tx dp 1 OUT DP Driver Output

This output must be connected to the DP line driver.ser tx se0 1 OUT Force SE0

This output is provided because some USB transceivershave an dedicated input for driving the SE0 line state.Will be asserted if an SE0 state must be driven.

ser txen n 1 OUT Output EnableLow active output enable for data line driver.

rpu ena 1 OUT Pullup Resistor EnableThis output will be set to one if the core works as aB-device mode, and the pull-up resistor must be con-nected to 3.3 V to indicate either a connect condition,or to request a session via data line pulsing.

rpd ena 1 OUT Pulldown Resistor EnableThis output will be set to one if the core works as an A-device, and the pull-down resistors must be connectedto ground.

id dig 1 IN USB Port ID PinThis input must be connected to theID pin (Identifi-cation) of the USB connector. Denotes the pin of theplugged Mini connectors that is used to differentiate aMini-A plug (ID pin resistance to ground< 10 Ohm)from a Mini-B plug (ID pin resistance to ground> 100KOhm)

id pullup 1 OUT USB Port ID Pull UpThis signal enables the sampling of the analog Id line.Only when this signal is high, theid dig input willbe sampled by the core.

xcvr speed 1 OUT Transceiver SpeedSlew rate control for transceiver.

• 0 = Low-Speed

• 1 = Full-Speed

xcvr suspend n 1 OUT Suspend ModePlaces the tranceiver in a mode that draws minimalpower from supplies.

• 0 = Tranceiver circuitry drawing suspend cur-rent

• 1 = Tranceiver circuitry drawing normal current

The signal will be set to zero if the appropriate bit oftheUSB Control Registeris set. The signal will asyn-chronously return to one after the USB linestate haschanged. (Refer also to Section6.3)

Table 2.3:USB Transceiver Interface Description

c©emsys 2003 2-5

2 Interface


vbus vld 1 IN VBUS ValidThis input must be set ifVBUS > 4.4V . Indicates thatthe bus power is valid.

va sess vld 1 IN A-Device Session ValidThis input must be set if0.8V < VBUS < 2.0V . In-dicates an A-Device that a session is requested by theconnected device.

vb sess vld 1 IN B-Device Session ValidThis input must be set if0.8V < VBUS < 4.0V . Indi-cates an B-Device that a session is in progress.

vb sess end 1 IN B-Device Session EndThis input must be set if0.2V < VBUS < 0.8V . Indi-cates an B-Device that no session is in progress. (Re-quired condition to initiate SRP)

chrg vbus 1 OUT VBUS Session Request ControlThis output will be set to one if the core works as aB-device, and a session is requested viaVBUS pulsing.This output is controlled by theVBSON bit field of thePort Control Register. (refer to Section4.4.2)

vb on 1 OUT VBUS Power ControlThis output can be set if the core works as an A-device.Thevb on for the OTG port will be controlled by theVB ON bit field of thePort Control Register. (refer toSection4.4.2)

over current 1 IN Over Current ConditionIf the system supports power switches with over cur-rent detection, this input must be connected to the overcurrent output of the power switching circuitry. If nopower switches are used, the input will not be used andmust be tied to a logical zero.

dlp active 1 OUT Data Line Pulsing ActiveThis output will be set to one if the core works as B-device, and the pull-up resistor must be connected topower because of a session request (Data-line pulsing).Data-line pulsing must be done without a valid buspower. If the core normally sources the pull-up resistorvia the bus power, this signal can be used to switch thepull-up resistor to an internal power supply.

dischrg vbus 1 OUT Discharge Circuitry EnableThis output can be set to one if the core works as a B-device, and a session is requested by setting the appro-priate bit of thePort Control Register. Can be used toconnect a pull-down resistor to accelerate the dischargeprocess if software wants to initiate a session request.

Table 2.4:Power Control Signal Interface Description

2.3 Operational Interface

c©emsys 2003 2-6

2 Interface


clk 48 1 IN 48 MHz System ClockThe 48 MHz System clock. This clock is used for theinternal clock recovery.

clk rec 1 IN Recovered USB Clock inputThe recovered USB clock (clk rec out) must be appliedto this input.

clk rec out 1 OUT Recovered USB ClockThis signal contains the recovered USB clock. Dur-ing receive operations this clock is recovered fromthe incoming bit stream. During transmit opera-tions this clock is derived from the 48Mhz systemclock. This clock has a frequency of 12MHz whenthe FHGUSB OTGDRD core communicates to a fullspeed device. This clock is switched to 1.5MHz duringcommunication to low speed devices.

reset n 1 IN System ResetAsynchronous, low active system reset.

core suspend n 1 OUT Core SuspendThis low-active signal will be set to zero if the appro-priate bit of theUSB Control Registerwill be set. Itcan be used to control the clock managament unit forlow-power mode of the core.The signal will asynchronously return to one after theUSB linestate has changed. (Refer also to Section6.3)

Table 2.5:Operational Signal Interface Description

2.4 Register Interface

TheRegister Interfaceallows the access to the register map of the core. It can be easy adapted to a wide rangeof interfaces for popular bus systems like PCI or AMBA. (Refer to Section6.5.1)

Furthermore, this generic interface can be used to communicate with any kind of 16/32 bit microcontroller, CPUor DSP. This section describes the required timing behavior for the generic interface.

Table2.6describes allRegister Interfacesignals.


ucs n 1 IN Microcontroller Chip SelectLow active chip select forRegister Interface.

uint n 1 OUT Microcontroller InterruptLow active interrupt output.

Register Interface Signals and Description (Continued on next page)

c©emsys 2003 2-7

2 Interface

Signal Width Scope Descriptionucif rdy 1 OUT Microcontroller Interface Ready

This signal will be deasserted after theFHG USBOTGDRD has recognized valid syn-chronized control signals (ucs n/urd n/uwr n).It indicates that an read/write access is in process.Bounding hardware can only start a read/write-accessif the signal is set to one. The signal is synchronous tothe system clock of theFHG USBOTGDRD.

urd n 1 IN Microcontroller ReadLow active read strobe.

uwr n 1 IN Microcontroller WriteLow active write strobe.

uaddr 8 IN AddressAddress for register access.

udata in DW IN Data InData bus from microcontroller.

udata out DW OUT Data OutData bus to microcontroller.

Table 2.6:Register Interface Signals and Description

Note: Register read and write operations must always beData Wordaligned. For configuration withDW=32, aData Word is defined with a size of 4 bytes. ForDW=16 aData Word is defined with a size of 2 bytes. Thisimplies thatuaddr[1:0] must be zero for 32 bit data width configuration, anduaddr[0] must be zero for16 bit data width configuration.

2.4.1 Register Interface Write Timing

The write timing is determined by the system clockclk 48 (TCLK = 20,8 ns).

The chip select and write control signals are double-synchronized with the system clock. All other interfaceinput signals (uaddr andudata in ) are latched with the system clock after the synchronized control signalsare valid.

Because most of the core logic of the Full-/Low-Speed core works in the 12 MHz clock domain, a specialalgorithm is used to write the control and configuration registers located in the 12 MHz domain. After theincoming data is latched with the 48 MHz system clock, an internal write signal with a length of up to 100 nswill be generated to ensure the data will be latched with the 12 MHz clock into the registers.

The following write timing at theRegister Interfacemust be generated.

c©emsys 2003 2-8

2 Interface

uaddr

udata_in

ucs_n

uwr_n

T WRN

ucif_rdy synchronized control signals are valid

ready for new read/write access

T SYNC

T WRDY

Figure 2.2:Register Interface Write Timing

The following timing parameters are valid:

Identifier Value Description

TWRN ≥ 3 ∗ TCLK Width of low activeuwr n signal for Full-/Low-Speed coreregister access.

TSY NC 2..3 ∗ TCLK At this time, the double-synchronized control signals are validto theRegister Interface, and the data is latched to a temporaryregisters of theclk 48 clock domain.

TWRDY ≤ 6 ∗ TCLK Register Interfacewrite-recovery time. Will be asserted aftersynchronized control signals are invalid,and the contents ofthe temporary register was transferred to theclk 12 clockdomain. Indicates, that a new read/write access can be per-formed.

Table 2.7: Full-/Low-Speed Core Write Timing Parameters

2.4.2 Register Interface Read Timing

The length of a read access to the registers to get a stable output data is determined by the synchronizationregisters of the control signals, and the implemented registered output multiplexer.

c©emsys 2003 2-9

2 Interface

uaddr

udata_out

ucs_n

urd_n

T RDN

ucif_rdy synchronized control signals are valid and data is applied

T SYNC

ready for new read/write access

T SYNC

Figure 2.3:Register Interface Read Timing

The following timing parameters must are valid:

Identifier Value Description

TRDN ≥ 3 ∗ TCLK Width of low activeurd n signalTSY NC 2..3 ∗ TCLK At this time, the double-synchronized control signals are valid

to theRegister Interface.

Table 2.8: Read Timing Parameters

TCLK is the period of the used system clock as described in the previous section (2.4).

2.5 Dual-Port RAM Interface

The data which is transmitted/received by USB is transferred to/from the core using ansynchronousdual-portRAM module. TheFHG USBOTGDRD uses its system clock to read and write data from the RAM module.By this way, no synchronisation must be done. Table2.9shows all signals of the dual-port RAM interface. Alldata pointers the software writes to the FHGUSB OTGDRD core are related to the RAM address bus.


ram dout DW OUT RAM data output for receive dataram din DW IN RAM data input for transmit dataram addr RAW OUT RAM addressram en 1 OUT RAM enable(high active)ram we 1 OUT RAM write enable(high active)

Table 2.9:Dual Port RAM Interface Signals and Description

c©emsys 2003 2-10

3 Architectural Overview

Figure3 shows the block diagram of the Embedded USB Dual Role Device. It mainly consists of the followingcomponents:

Dual Role Serial Interface Engine - DRSIE Responsible for the low level part of any USB transaction.It generates every packet for transmission and decodes incoming traffic. This includes the coding anddecoding of the token, data, handshake PID, the generation and verification of the packet CRC. TheDRSIEcan switch from device to host functionality.

Data Controller - DCTR This module realizes the data storage management, which allows the core to transferthe data with the required bandwidth. TheDCTRis responsible for the complete buffer management, suchas data pointer management and buffer switching.

Transaction Management Unit - TM Only active during host mode: Realizes the transaction scheduler.This module scans all pipe register in a defined order and evaluates whether an transaction is executedand performs the status update after a transaction is finished. Several pipe related information must beupdated after every transaction. In Device mode: Waits for an USB token from the host and calculatesthe handshake operation. Several pipe related information must be updated after every transaction.

Frame Timer - FT Realizes the frame counter and splits the time into frame intervals. Frame events are usedas start event for the transaction scheduler and for device babble detection. The frame counter value itselfis used to determine, whether periodic transactions are candidates for execution.

Root Hub - RH Acts as a special USB hub. It propagates downstream data in a broadcast mode and bundlesupstream data. This module realizes all port related functionality, including USB reset/suspend/resumemanagement.

Port Power Controller - PPCTR Responsible for power control and SRP handling.

Microcontroller Register Interface - UCIF Responsible for exchanging control/status information with theµC or DSP. This module synchronizes all incoming data and provides all information which are stored inthe register map to theµC or DSP.

Register File - RF Realizes the memory map for control/status data exchange. The data is stored inside bitarrays, which are coupled with different types of access. This module is responsible for paging pipe andport registers. It also includes the hardware for masking and generating interrupts.

c©emsys 2003

3A

rchitecturalOverview

FHG_USB_OTGDRD

Dual Role SIE (DRSIE)

Microcontroller Interface (UCIF)

Register File (RF)

Frame Timer (FT)

Address

Data

Control

Data

Pipe Control

Transaction Item

USB

Data Controller (DCTR)

Transaction Manager

(TM) Transaction Status

Data

Read/Write Control

Port/Power Control

(PPCTR)

ID

Power Status

Power Control

Endpoint Control

Buffer Control

Frame Information- (to all modules)

Interrupt

Pipe Status

1-Port Root Hub

(RH)

Port Control

Transaction Status

Host/Device Select (to all modules)

USB_tx

USB_rx

USB_ctrl

Figure 1: Top Level Block Diagram

c©em

sys2003

3-2

4 Register Map

The following chapter contains a description of all implemented registers of theUSB 2.0 Full-/Low-Speed OTGDual Role Core.

All registers are 32 bit wide. Nevertheless, the genericDW(Data Width) parameter1 can be 16 or 32. In bothcases, there are only word/double word accesses allowed: ForDW=32 the address must be multiple of 0x4. ForDW=16 the address must be multiple of 0x2.

There exist different kinds of access types:

• rw : read/write: Bit(s) read and writeable.

• r : read-only: Bit(s) readable and not writeable.

• cow : clear-on-write: Bit(s) cleared after write ’1’.

Note: Some of the bit(s) are provided with ”labels” denoted within brackets. The core can be delivered with a C-Header file containing all of these labels as constant declarations, which can be helpful for software development.See also AppendixA for an overview about all labels.

4.1 Common Register Group

4.1.1 ID Register

Short Name ID

Address 0x00

ResetField Name Bit Value Access Description

- 31 : 13 - - Reserved.COREID 12 : 8 0x7 r Core-IDREV ID 7 : 0 0x00 r Revision ID

Table 4.1:ID Description

Core-ID This bitfield shows the unique ID of the core.

Revision ID These bits show the revision number of the core.

1see table2.1

c©emsys 2003

4 Register Map

4.1.2 USB Control Register

This register is only valid if the core works in host mode.

Short Name USB CTRL

Address 0x04


- 31 : 5 - - Reserved.PSE 4 0x0 rw Periodic Schedule EnableASE 3 0x0 rw Async Schedule EnableHRS 2 0x0 rw Host Run/StopXSUSP 1 0x0 rw XCVR SuspendCSUSP 0 0x0 rw Core Suspend

Table 4.2:USB Control Description

Periodic Schedule Enable When set to 1 and theHost Run/Stop Bitis set, the core schedules periodic trans-actions (interrupt and isochronous). If software sets this bit to zero, all pending periodic transactions ofthe current frame will be completed.

Async Schedule Enable When set to 1 and theHost Run/Stop Bitis set, the core schedules asynchronoustransactions (bulk and control). If software sets this bit to zero, all pending asynchronous transactions ofthe current frame will be completed.

Host Run/Stop When set to 1, the core starts framework and transaction scheduling. If software sets this bitto zero, all pending transactions of the current frame will be completed, and theHost Controller HaltedEvent Bitis set at the end of the frame, and no more SOFs will be sent.

The bit will be cleared by hardware if a serious error was detected

XCVR Suspend This bit controls thexcvr suspend n output signal. If this bit is set to 1, the low-activexcvr suspendm n output will be set to 0 to enable the low-power mode of the connected Tranceiver.Any change at theser rx dmor ser rx dp signal will force the deactivation of thexcvr suspend noutput signal. (Returns to 1)

Core Suspend This bit controls thecore suspend n output signal. If this bit is set to 1, the low-activecore suspend n output will be set to 0 to enable the low-power mode of this core. This signal shouldbe connected to an external clock controller. Any change at the signalsser rx dmor ser rx dp willforce the deactivation of thecore suspend n output signal. (Returns to 1)

4.1.3 Frame Timer Register

Short Name FRM TIMER

Address 0x08

c©emsys 2003 4-2

4 Register Map


- 31 : 13 - - Reserved.AGSOF 12 0x0 r Artificially Generated SOFFTLOCK 11 0x0 r Frame Timer LockedFRAME NR 10 : 0 0x000 rw Current Frame Number

Table 4.3:Frame Timer Description

Artificially Generated SOF This field is only valid, when the core works in peripheral mode.

This bit is set, if theFrame Event Bitof theMain Event Registerwas generated artificially in the case ofa lost SOF token.

Frame Timer Locked This field is only valid, when the core works in peripheral mode.

It indicates that the internal frame timer is locked. It will be set if more than two consecutive SOF tokensare received, and will be cleared if at least two consecutive SOF tokens are missed.

Current Frame Number This field shows the current frame number.

If the core works in host mode:

The frame timer is a free running counter that will be incremented every 1 ms. This register cannot bewritten unless the Host Controller is in the Halted state.

If the core works in pripheral mode:

The frame timer will synchronize to incoming SOF tokens. This field shows the frame number of thecurrent received SOF token.

4.2 Event Register Group

4.2.1 Main Event Register

Short Name MAIN EV

Address 0x0C


- 31 : 6 - - Reserved.BWERR EV 5 0x0 cow Bandwidth Error EventHCHA EV 4 0x0 cow Host Controller Halted EventGPIPEEV 3 0x0 r Global Pipe Transfer EventGPORTEV 2 0x0 r Global Port Status Change EventFRM32 EV 1 0x0 cow Frame 32 EventFRM EV 0 0x0 cow Frame Event

Table 4.4:Main Event Description

Bandwidth Error Event This field is only valid, when the core works in host mode.

c©emsys 2003 4-3

4 Register Map

This bit will be set by hardware if no sufficient bandwidth is available to complete all periodic transfers ina frame. It leads to an interrupt, if theBandwidth Error Event Mask Bitof theMain Event Mask Registeris set.

Host Controller Halted Event This field is only valid, when the core works in host mode.

The bit is set, if the host controller has stopped as a result of setting theHost Run/Stop Bitto the haltedstate and all pending transactions of a frame are completed. It leads to an interrupt, if the correspondingHC Halted Mask Bitof theMain Event Mask Registerwas set.

Global Pipe Transfer Event The bit is set if one of the bits of thePipe Event Registeris set. It leads to aninterrupt, if theGlobal Pipe Event Mask Bitof theMain Event Mask Registeris set.

Global Port Status Change Event The bit is set if one of the bits of thePort Status Change Event Registeris set. It leads to an interrupt, if theGlobal Port Status Change Event Mask Bitof theMain Event MaskRegisteris set.

Frame 32 Event The bit is set after every 32nd SOF token. It leads to an interrupt, if the correspondingFrame32 Event Mask Bitof theMain Event Mask Registerwas set. Can be used by software timers.

Frame Event The bit is set every 1 ms. It leads to an interrupt, if theFrame Event Mask Bitof theMain EventMask Registerwas set.

4.2.2 Main Event Mask Register

Short Name MAIN EM

Address 0x10


- 31 : 6 - - Reserved.BWERR EM 5 0x0 rw Bandwidth Error Event MaskHCHA EM 4 0x0 rw HC Halted MaskGPIPEEM 3 0x0 rw Global Pipe Event MaskGPORTEM 2 0x0 rw Global Port Status Change Event MaskFRM32 EM 1 0x0 rw Frame 32 Event MaskFRM EM 0 0x0 rw Frame Event Mask

Table 4.5:Main Event Mask Description

Bandwidth Error Event Mask Setting this bit will lead to an interrupt if theBandwidth Error Event Bitisactive.

HC Halted Mask Setting this bit will lead to an interrupt if theHost Controller Halted Event Bitis active.

Global Pipe Event Mask Setting this bit will lead to an interrupt if theGlobal Pipe Transfer Event Bitisactive.

Global Port Status Change Event Mask Setting this bit will lead to an interrupt if theGlobal Port StatusChange Event Bitis active.

Frame 32 Event Mask Setting this bit will lead to an interrupt if theFrame 32 Event Bitis active.

Frame Event Mask Setting this bit will lead to an interrupt if theFrame Event Bitis active.

c©emsys 2003 4-4

4 Register Map

4.2.3 Pipe Event Register

NOP = Number Of Pipes2

Short Name PIPEEV

Address 0x14


- 31 : NOP - - Reserved.PI EV NOP-1 : 0 0x0000 cow Pipe Event

Table 4.6:Pipe Event Description

Pipe Event There exist 1 bit in this bitfield for every pipe this core is configured for. The pipe number matchesthe bit index inside of this bitfield.


This event is triggered by the core if one of the following conditions apply: The pipe goes inactive andtheActive Status Bitof thePipe Status Registerwas cleared by hardware because of normal terminationor an error event. A data buffer was completed: theData Buffer Valid Bitor theAlternative Data BufferValid Bit was cleared by hardware.

If the core works in peripheral mode:

This event is triggered by the core if a data buffer was completed: theData Buffer Valid Bitor theAlter-native Data Buffer Valid Bitwas cleared by hardware.

4.2.4 Pipe Event Mask Register

Short Name PIPEEM

Address 0x18


- 31 : NOP - - Reserved.PI EM NOP-1 : 0 0x0000 rw Pipe Event Mask

Table 4.7:Pipe Event Mask Description

Pipe Event Mask Setting one of these bits enables the pipe event interrupt generation for the appropriatedpipe (refer section4.2.3).

2see table2.1

c©emsys 2003 4-5

4 Register Map

4.3 Page Register Group

4.3.1 Pipe Select Register

The physical register space for the pipe configuration and status registers is paged by thePipe Select Register.Therefore, all registers of thePipe Register Groupexist for every pipe.

Short Name PIPESEL

Address 0x24


- 31 : 5 - - Reserved.PI SEL 4 : 0 0x00 rw Pipe Select

Table 4.8:Pipe Select Description

Pipe Select Depending on the number of supported pipes (NOP) the core is configured for, one of the pipesmay be selected using this register for access of the appropriate status and configuration registers. (refersection4.5)

The width of this bitfield depends on the parameter NOP and is equal to log2(NOP).

This bitfield is coded as follows:

• b00000:Pipe 0

• ...:

• b01111:Pipe 15

4.4 Port Register Group

4.4.1 Port Status Register

Short Name PORTSTAT

Address 0x2C

c©emsys 2003 4-6

4 Register Map


- 31 : 10 - - Reserved.LINESTATE 9 : 8 0x0 r USB Line StateOCURC 7 0x0 r Over Current ConditionDLS 6 0x0 r Device Low SpeedPCS 5 0x0 r Port Connect StatusCONN ID 4 0x0 r USB Connector ID ValueVB SESSEND 3 0x1 r VB Session EndVB SESSVLD 2 0x0 r VB Session ValidVA SESSVLD 1 0x0 r VA Session ValidVBUS VLD 0 0x0 r Vbus Valid

Table 4.9:Port Status Description

USB Line State This bit shows the current line state:

LINESTATE[1:0] = [ser rx dp ,ser rx dm]

Over Current Condition This bit will be set to one if the core has detected an overcurrent condition, other-wise it is zero. An overcurrent condition is defined asvb vld is deasserted butvb on is set.

Device Low Speed This field is only valid if the core works in host mode.

This bit indicates, if the connected device is a full or low speed device. The bit is only valid if thePortConnect Status Bitindicates a connected device.

• b0:Full speed device connected

• b1:Low speed device connected

Port Connect Status This field is only valid if the core works in host mode.

This bit indicates, if a device is connected.

• b0:No device attached[label = ”PCSDISCONN”]

• b1:Device attached to root port[label = ”PCSCONN”]

USB Connector ID Value This bit shows the ID value of the USB connector. If set to one, it indicates thatthe core works as B-Device, with initial peripheral mode. If set to zero, the core will work as A-Device,with initial host mode. The core can change the host/peripheral roles using the Host Negotiation Protocol(HNP). Therefore, the real mode of the core depends on this bit in conjuntion with the selected termination.(refer theTermination Select Bit). The core will update this bit, when a falling edge is detected at theID-Pullup Enable Bit!

• b0:A-Device (initial host)[label = ”CONN ID A”]

• b1:B-Device (initial peripheral)[label = ”CONN ID B”]

VB Session End Hardware will set this bit to one if thevb sess end input is set, indicating VBUS is aboveVB-SESS-END.

VB Session Valid Hardware will set this bit to one if thevb sess vld input is set, indicating VBUS is aboveVB-SESS-VLD.

VA Session Valid Hardware will set this bit to one if theva sess vld input is set, indicating VBUS is aboveVA-SESS-VLD.

Vbus Valid Hardware will set this bit to one if thevb vld input is set, indicating VBUS is above 4.4 V.

For OTG Devices this bit is set to one, when Vbus is above VA-VBUS-VLD. When Vbus goes below thisthreshold an overcurrent condition did occur.

c©emsys 2003 4-7

4 Register Map

4.4.2 Port Control Register

Short Name PORTCTRL

Address 0x30


- 31 : 24 - - Reserved.P LEN 23 : 16 0x00 rw Pulse Length

- 15 : 13 - - Reserved.ID PU 12 0x0 rw ID-Pullup Enable

- 11 - - Reserved.VBS ON 10 0x0 rw VBUS Session Request ControlDCHRG 9 0x0 rw Enable Discharge CircuitryTERM ENA 8 0x0 rw Termination EnableTERM SEL 7 0x0 rw Termination SelectVB ON 6 0x0 rw VBUS ControlPSUSP 5 0x0 rw Port SuspendPENA 4 0x0 rw Port EnableFPRESU 3 0x0 rw Force ResumeURESET 2 0x0 rw USB ResetPTESTC 1 : 0 0x0 rw Port Test Control

Table 4.10:Port Control Description

Pulse Length It defines the pulse length in milliseconds if the core wants to request a session using the dataline pulsing or VBUS pulsing method. Setting this bitfield to zero allows software controlled pulse length.If set to a non-zero value, this field will be updated every millisecond by hardware.

• 0x00: Software controlled pulse length. Software must reset theVBUS Session Request Control Bitor theTermination Enable Bitmanually.

• 0x01: 1 ms pulse length. Hardware will reset theVBUS Session Request Control Bitand theTermi-nation Enable Bitautomatically after 1 ms.

• ...

• 0xFF: 255 ms pulse length. Hardware will reset theVBUS Session Request Control Bitand theTermination Enable Bitautomatically after 255 ms.

If the this bitfield counts down from one to zero, thePulse End Event Bitof theMain Event Registerwillbe set.

ID-Pullup Enable Software can control the ID-pullup output signal (id pullup ) using this bit.

The core will update the status of theUSB Connector ID Value Bitonly if this bit becomes inactiv.

VBUS Session Request Control Software can control the power circuitry (chrg vbus ) using this bit.

If set to 1, thevbs on output will be set.

Enable Discharge Circuitry Software can control the discharge circuitry using this bit to accelerate the dis-charge of the host bus power capacitors.

Setting this bit to 1 will lead to setting thedischrg vbus output.

c©emsys 2003 4-8

4 Register Map

Termination Enable Software can enable the data line termination at the OTG port using this bit.

If set to 0, therpu ena andrpd ena outputs are tied to zero.

Software can set this bit after it has detected the following conditions after power on reset:

• The ID value indicates the core must work as B-Device and is initially in peripheral mode and validbus power was detected

• The ID value indicates the core must work as A-Device

Software can set this bit to switch the host/peripheral role following the Host Negotiation Protocol.

The pull-up resistor can also be switched on if software wants to request a session using data line pulsing(according to Session Request Protocol). This requires that theVBUS Control Bitand theVBUS SessionRequest Control Bitmust indicate the powered off state, and will also lead to setting thedlp activeoutput.

Termination Select Software can select the data line termination at the port using this bit:

• b0:Host termination. If theTermination Enable Bitis set, this will lead to settingrpd ena = 1 andrpu ena = 0. [label = ”TERM SEL HOST”]

• b1:Device termination. If theTermination Enable Bitis set, this will lead to settingrpu ena = 1andrpd ena = 0. [label = ”TERM SEL DEV”]

Software can set this bit after it has detected the following conditions after power on reset:

• The ID value indicates the core must work as B-Device and is initially in peripheral mode

• Valid bus power was detected

Software can set this bit to switch the host/peripheral role following the Host Negotiation Protocol.

VBUS Control Software can control the power circuitry (vb on output) using this bit.

If set to 1, thevb on output will be set.

Note: Softwaremust set this bit to be able to detect a connected device!

Port Suspend This field is only valid if the core works in host mode.

The bit can be set by software if the device driver wants to set the connected device into suspended state.Setting the bit will block data propagation on the root port. If the bit is set, the core is sensitive to resumedetection.

The bit must also be set to prepare the core for changing the host/peripheral role. (Host NegotiationProtocol)

Setting theForce Resume Bitwill automatically clear this bit.

Port Enable This field is only valid if the core works in host mode.

The bit will be set automatically by hardware after the software has finished the USB reset. The core willstart sending SOF tokens if the connected device is working at full speed, or low speed keepalive strobesif the connected device is working at low speed.

Force Resume If the core works in host mode:

The bit can be set by software if, the connected device has to finish its suspend mode. The bit will beset by hardware, if a Remote Wakeup condition was detected. (Resume Event Bitis set). In that case,software must finish the resume sequence by setting this bit to zero. The bit will remain set until theresume sequence was completed by hardware by a low speed EOP. (indicated byResume Complete EventBit)


The bit can be set by software if it wants to wake up the host/hub it is connected. (Remote Wakeup)Software is responsible for the timing of the remote wakeup resume, and must set the bit for at least 1 ms,but no more than 15 ms. (Refer the USB Specification, chapter 7.1.7.7 [1])

c©emsys 2003 4-9

4 Register Map

USB Reset This field is only valid if the core works in host mode.

When software writes a one to this bit, an USB reset sequence (SE0 state) will be started by the core.Writing a zero to this bit will terminate the reset sequence. There may be a delay before the bit statuschanges to zero, because hardware will clear the bit if it has completed the reset sequence.

Software must keep the bit at one long enough as defined in the USB Specification 2.0, chapter 7.3.2.(10..20 ms)

• b0:No USB reset driven.[label = ”URESETINACTIVE”]

• b1:Core drives USB reset.[label = ”URESETACTIVE”]

Port Test Control This bitfield allows to set the port into specific test modes. When the field is zero, the portis not operating in test mode. The encoding of test mode is:

• b00:Test mode disabled[label = ”PTESTCDIS”]

• b01:Test JState[label = ”PTESTCJST”]

• b10:Test KState[label = ”PTESTCKST”]

• b11:Test SE0[label = ”PTESTCSE0”]

4.4.3 Port Status Change Event Register

Short Name PSCEV

Address 0x34


- 31 : 9 - - Reserved.P END EV 8 0x0 cow Pulse End EventPWRSCEV 7 0x0 cow Power Status Change EventCDC EV 6 0x0 cow Connect/Disconnect EventURESEV 5 0x0 cow USB Reset EventSUSPEV 4 0x0 cow Suspend EventRSUCEV 3 0x0 cow Resume Complete EventRSU EV 2 0x0 cow Resume EventBERR EV 1 0x0 cow Babble Error EventOCU EV 0 0x0 cow Over Current Event

Table 4.11:Port Status Change Event Description

Pulse End Event This field is only valid, when the core works in peripheral mode.

The bit is set if thePulse Length Fieldchanges from one to zero.

Power Status Change Event The bit is set if one of the following bits has changed:

• Vbus Valid Bit

• VA Session Valid Bit

• VB Session Valid Bit

• VB Session End Bit

c©emsys 2003 4-10

4 Register Map

Connect/Disconnect Event This field is only valid if the core works in host mode.

If set to one, this bit indicates that thePort Connect Status Bitvalue has changed.

USB Reset Event If the core works in host mode:

After software has completed the USB reset by clearing theUSB Reset Bitbit, this event bit will be set afterthe reset was completed by hardware. (The core continues driving the reset after URESET is deasserteduntil the next Start Of Frame)

If the core works in peripheral mode.

This bit is set if an USB reset condition was detected. (data lines more than 2,5µs SE0).

Suspend Event This bit is only valid if the core works in peripheral mode.

This bit indicates a lack of bus activity for more than 3 ms. Software can use this event to activate a lowpower mode.

Note: If the low power mode causes that the clock of the USB Core is removed, the bounding hardware isresponsible to turn on the clock controller if a state other than IDLE state at the USB data lines is asserted.This requires some additional, asynchronous circuitry.

If HNP was not enabled previously, software shall set thePort Suspend Bitto be sensitive for resumesignaling, and enter the low power state. If HNP was enabled, software can now switch to host modeaccording to the HNP rules.

Resume Complete Event If the core works in host mode:

This bit will be set after the core has completed the resume sequence with a low speed EOP.


This bit is set if the resume sequence was completed by the host with a low speed EOP.

Resume Event If the core works in host mode:

This bit is set if the host driver has set the port in suspended state, and a resume condition driven by theconnected device was detected. (remote wakeup)


This bit is set if resume condition was detected (more than 2.5µs K-State).

Babble Error Event This field is only valid, when the core works in host mode.

this bit gets only to a one when the root port is disabled due to the appropriate conditions existing at theEOF2 point (/USB-Spec20/ chapter 11.2.5).

Over Current Event This bit will be set to one if the core has detected an overcurrent condition. (refer theOver Current Condition Bit)

4.4.4 Port Status Change Event Mask Register

Short Name PSCEM

Address 0x38

c©emsys 2003 4-11

4 Register Map


- 31 : 9 - - Reserved.P END EM 8 0x0 rw Pulse End Event MaskPWRSCEM 7 0x0 rw Power Status Change Event MaskCDC EM 6 0x0 rw Connect/Disconnect Event MaskURESEM 5 0x0 rw USB Reset Event MaskSUSPEM 4 0x0 rw Suspend Event MaskRSUCEM 3 0x0 rw Resume Complete Event MaskRSU EM 2 0x0 rw Resume Event MaskBERR EM 1 0x0 rw Babble Error Event MaskOCU EM 0 0x0 rw Over Current Event Mask

Table 4.12:Port Status Change Event Mask Description

Pulse End Event Mask Setting this bit will lead to an interrupt if thePulse End Event Bitis active.

Power Status Change Event Mask Setting this bit will lead to an interrupt if thePower Status ChangeEvent Bitis active.

Connect/Disconnect Event Mask Setting this bit will lead to an interrupt if theConnect/Disconnect EventBit is active.

USB Reset Event Mask Setting this bit will lead to an interrupt if theUSB Reset Event Bitis active.

Suspend Event Mask Setting this bit will lead to an interrupt if theSuspend Event Bitis active.

Resume Complete Event Mask Setting this bit will lead to an interrupt if theResume Complete Event Bitis active.

Resume Event Mask Setting this bit will lead to an interrupt if theResume Event Bitis active.

Babble Error Event Mask Setting this bit will lead to an interrupt if theBabble Error Event Bitis active.

Over Current Event Mask Setting this bit will lead to an interrupt if theOver Current Event Bitis active.

4.5 Pipe Register Group

This section defines the interface data structures, which will be used to communicate control/status informationand data between the software and the hardware.

See section5.5to get information about read/write constraints from the CPU side and how the hardware modifiesthe contents of the following registers.


Pipe[0] is reserved to handle control transfers. No other pipe can be used for control transfer. Because the controlpipe is defined as bidirectional pipe, the core is sensitive to tokens for both directions. A SETUP transaction willalways be accepted with an ACK handshake as required by the USB Specification. If no data buffer is available,the default response to OUT or IN tokens is NAK. Refer section5.6for a detailed description of the control pipehandling.

All pipe registers will be set to their reset values after the core has detected an USB reset. The pipe registers forpipe[0] have other reset values as described in section5.6

c©emsys 2003 4-12

4 Register Map

There exist some additional parameter TBW.

TBW (Total Bytes Width) is derived from AW and DW as: TBW = AW+1 when DW = 16 else AW+2 . Theupper limit is 31!

4.5.1 Pipe Control Register

Short Name PIPECTRL

Address 0x40


- 31 : 3 - - Reserved.ACT 2 0x0 rw Activate PipeTPID 1 : 0 0x0 rw Token PID/Direction

Table 4.13:Pipe Control Description

Activate Pipe If the core works in host mode:

Setting this bit will initiate one or more transactions with the given configuration for pipe. The bit willbe cleared automatically if the transfer is finished or an error condition has occured. Data transfer is onlyinitiated, if valid buffer space is provided by software.


Setting this bit will enable the response to an endpoint with the given pipe parameters. If no valid bufferspace is provided, the endpoint will respond with a NAK handshake. The bit will be set automatically forpipe[0] after an USB reset was detected. It will be automatically cleared by hardware for all other pipesafter the detection of an USB reset.

Token PID/Direction If the core works in host mode:

This field indicates the PID (and direction) used for the token to be sent.


This field indicates the direction of data flow for this endpoint. For receive direction, the bitfield mustbe set to TPIDIN. For transmit direction, the bitfield must be set to TPIDOUT. The bitfield will beautomatically set to TPIDSETUP for pipe[0] after a SETUP token was received.

• b00:OUT transfer[label = ”TPID OUT”]

• b01:IN transfer[label = ”TPID IN”]

• b10:SETUP transfer[label = ”TPID SETUP”]

• b11:Reserved.

4.5.2 Pipe Configuration Register

Access Rules:


The contents of this register must not be changed when theActivate Pipe Bitor theActive Status Bitis 1.


c©emsys 2003 4-13

4 Register Map

The contents of this register (except theStall Pipe Bit) must not be changed when theActivate Pipe Bitis 1.

Short Name PIPECFG

Address 0x44


- 31 - - Reserved.IOT 30 0x0 rw Interrupt on Transaction.HIDBE 29 0x0 rw Halt on ISO Data Buffer ErrorSKIPISO 28 0x0 rw Skip ISO TokenPI 27 : 24 0x0 rw Polling IntervallPOFF 23 : 16 0x00 rw Polling OffsetSTALL 15 0x0 rw Stall PipeACID 14 0x0 rw Accept corrupted ISO DataEPS 13 0x0 rw Endpoint SpeedSTRM 12 0x0 rw Streaming ModeET 11 : 10 0x0 rw Endpoint TypeMPS 9 : 0 0x000 rw Maximum Packet Size

Table 4.14:Pipe Configuration Description

Interrupt on Transaction. This field is only valid if the core works in host mode.

If this bit is set, the core will assert an interrupt after every performed transaction on this pipe, inde-pendently on the transaction status. That means, also for NAKed transactions or after an error condition(timeout, CRC-error) an interrupt will be generated. Setting this bit is only useful if the transactionscheduling must be performed by software.

Halt on ISO Data Buffer Error This field is only valid if the core works in host mode.

If the Skip ISO Token Bitis not set, and the core sends an IN token for isochronous IN pipes, and there isno buffer available, the core will halt this pipe, when the HIDBE bit is activated. If HIDBE is deactivated,the core will not change the pipe state.

Skip ISO Token This field is only valid if the core works in host mode.

When this bit is set, the HC will send no IN/OUT token for isochronous pipes, when no data buffer spaceis available. In the case, the IN token is send (theSkip ISO Token Bitis 0) and there is no bufferspace theHC will not write any data to the RAM. The received data is lost. For OUT pipes the HC will send anOUT-DATA0 sequence, when no buffer space is available.

Polling Intervall This field is only valid if the core works in host mode.

This value defines the polling interval for this pipe as2PI , if the endpoint is configured as an interrupt orisochronous endpoint. The polling intervals for full/low speed interrupt endpoints is enoded as follows:

• b0000:1 frame

• b0001:2 frames

• b0010:4 frames

• :::

• b1000:256 frames

c©emsys 2003 4-14

4 Register Map

PI must be less/equal 8. Setting PI to a value greater 8 will lead to undefined results.

Polling Offset This field is only valid if the core works in host mode and for interrupt endpoints.

Defines the polling interval frame offset the pipe is scheduled for. The pipe is polled if PIOFF[PI-1:0]matches the current frame number slice FRAMENR[PI-1:0]. (8≥ PI≥ 1)

Stall Pipe This bit is only valid if the core works in peripheral mode.

Setting this bit will lead to a STALL response to an endpoint with the given pipe parameters. The bit willbe automatically cleared for pipe[0] after an USB reset was detected or a SETUP token was received.

Accept corrupted ISO Data When this bit is set, the core accepts also corrupted data, transfered by isochronousreceive pipes. Packets with CRC error are accepted completely. Packets with bitstuff error are accepteduntil the bitstuff error occurs.

Endpoint Speed This field is only valid if the core works in host mode.

Indicates the speed of the function with this endpoint.

• b0:Full speed[label = ”EPSFULL”]

• b1:Low speed[label = ”EPSLOW”]

If the device connected to the root port is a full speed, and the bit is set to low speed, a PRE token will begenerated automatically.

Streaming Mode This bit is only valid for receive pipes/endpoints. It should be used for high bandwidthperiodic receive pipes/endpoints.

If this bit is activated, the streaming mode is used for this pipe:

• The data received by several bus transactions can be stored in one buffer.

• The inter buffer byte alignment is done, so that different buffers can be concatenated without shiftingthe entire data by 1 or more bytes.

If this bit is deactivated for this pipe:

• The data of one transaction for this pipe is stored in a separate buffer

• No inter buffer byte alignment is done.

See chapter5.4.1for more detailes.

Endpoint Type Indicates the transfer type for the transactions of this pipe/endpoint:

• b00:Control Transfer[label = ”ET CTRL”]

• b01:Isochronous Transfer[label = ”ET ISO”]

• b10:Bulk Transfer[label = ”ET BULK”]

• b11:Interrupt Transfer[label = ”ET INT”]

Maximum Packet Size This field defines the maximum number of bytes per data packet that can be sent to orreceived from the endpoint of this pipe.


If more bytes are received, and the core is configured for host mode, a babble error will be generated.


The bitfield will be ignored if the received transaction was a SETUP transaction. (SETUP transactionsmust always be accepted)

c©emsys 2003 4-15

4 Register Map

4.5.3 Pipe Address Register

Access Rules: identical to thePipe Configuration Register.

Short Name PIPEADDR

Address 0x48


- 31 : 11 - - Reserved.EPADDR 10 : 4 0x00 rw Endpoint AddressEPNR 3 : 0 0x0 rw Endpoint Number

Table 4.15:Pipe Address Description

Endpoint Address This field defines the USB device address of this pipe.

It must be set for both host and peripheral mode. If working in peripheral mode, this field defines the deviceaddress. Software must set this field only for pipe[0] after the successful completion of a SetAddress-request. The value of this field of pipe[0] is used for all other pipes. It will be automatically reset to 0x00if an USB reset was detected.

Endpoint Number It specifies the endpoint number of this pipe/endpoint.

This field must be set for both host and peripheral mode.


The bitfield will be automatically set to 0x0 for pipe[0].

4.5.4 Pipe Status Register

This register contains the complete status information of the selected pipe and can be changed by hardware.

Access Rules: identical to thePipe Configuration Register.

Short Name PIPESTAT

Address 0x4C


- 31 : 10 - - Reserved.CERR 9 : 8 0x3 r Error CounterDBERR 7 0x0 r Data Buffer ErrorACTS 6 0x0 r Active StatusHALT 5 0x0 r Pipe HaltedBBL 4 0x0 r Babble detectedDBSEL 3 0x0 rw Selected Data BufferDT 2 0x0 rw Data ToggleDBOFF 1 : 0 0x0 rw Data Byte Offset

Table 4.16:Pipe Status Description

c©emsys 2003 4-16

4 Register Map

Error Counter This field is only valid if the core works in host mode.

Shows the status of a 2-bit down counter that, keeps track of the number of consecutive errors detected.The core decrements the counter if the transaction fails. If the counter counts from one to zero, the pipewill be halted and sets thePipe Halted Bit. When theActivate Pipe Bitof thePipe Control Registergoesfrom 0x0 to 0x1, the core resets this bitfield.

Data Buffer Error This field is only valid if the core works in host mode.

Set to a 1 during the status update to indicate that the core is unable to keep up with the reception ofincoming data (overrun).

This bit is only valid for isochronous IN pipes. For all other kinds of transfers the core ensures, that thereis enough buffer space for at least 1 packet with maximum payload size. When theActivate Pipe BitofthePipe Control Registergoes from 0x0 to 0x1, the core resets this bit.

Active Status This field is only valid if the core works in host mode.

This bit shows the current status of the pipe. It will be set, after theActivate Pipe Bitwas set to 1. It willbe cleared, after theActivate Pipe Bitwas set to 0, or the pipe was halted due to several transfer events(pipe halted, babble, short packet for control/bulk pipes etc.).

Pipe Halted This field is only valid if the core works in host mode.

Set to a 1 by the core during status update if the core works in host mode to indicate that a serious errorhas occurred at the device/endpoint.This can be caused by babble errors, the error counter counting downto zero, or reception of the STALL handshake from the device. Any time that a transaction results in thethis bit being set to a one, theActivate Pipe Bitis also set to 0.

When theActivate Pipe Bitof thePipe Control Registergoes from 0x0 to 0x1, the core resets this bit.

Babble detected This field is only valid if the core works in host mode.

Set to a 1 by the Host Controller during status update when a babble is detected during the transaction. Inaddition to setting this bit, the hardware also sets thePipe Halted Bitto a 1 (only for IN endpoints). WhentheActivate Pipe Bitof thePipe Control Registergoes from 0x0 to 0x1, the core resets this bit.

Selected Data Buffer This bit is only valid if the pipe is configured to have an alternative data buffer. Other-wise the bit will stuck at zero.

The bit indicates, which buffer is currently processed by hardware:

• b0:(Normal) Data Buffer processed.[label = ”DBSEL NORMAL”]

• b1:Alternative Data Buffer processed.[label = ”DBSEL ALTERNATE”]

The bit will be updated by hardware if the data controller switches between the data buffers. The bit canalso be changed by software.

Data Toggle This bit shows the current data toggle. It is valid for all bulk, control and interrupt transfers. Thisbit will be changed by hardware according to the current data toggle state. The bit can also be changed bysoftware.

• b0:DATA0 data toggle value[label = ”DT DATA0”]

• b1:DATA1 data toggle value[label = ”DT DATA1”]


When SETUP token was received, the bit will be automatically set to DTDATA1 for pipe[0].

Data Byte Offset For transmit transfers, this field indicates the current byte of data to be sent within a dataword. For receive transfers, this field points to the first byte within the data word where the first receivedbyte must be stored.

If the core parameter DW (Data Width) is set to 16, only the lowest bit of this bitfield is valid.

The bitfield can be changed by software.

c©emsys 2003 4-17

4 Register Map

• For transmit pipes: this bitfield traces the current byte offset for this pipe, it is set by hardware to 0after an buffer becomes invalid.

• For streaming receive pipes: this bitfield traces the current byte offset for this pipe. If the pipeworks in streaming mode (referStreaming Mode Bit), this byte offset is also used, to eliminate byteshifting operations by software (see section5.4.1). Software has only to initialize the byte offset atthe beginning of the transfer.

• For non-streaming receive pipes: this bitfield traces the current byte offset for this pipe, it is set byhardware to 0 after an buffer becomes invalid.


The bitfield will be automatically set to 0x0 for pipe[0] if a SETUP transaction is received.

4.5.5 Pipe Data Pointer Register

The contents of this register can be changed by hardware.

Access Rules: the contents of this register must not be changed when the access to thePipe ConfigurationRegisteris granted and theData Buffer Valid Bitis active.

Short Name PIPEDATA PTR

Address 0x50


- 31 : RAW - - Reserved.DPTR RAW-1 : 0 0x00 rw Data Pointer

Table 4.17:Pipe Data Pointer Description

Data Pointer For transmit transfers, this field points to the first byte of data to be sent. For receive transfers, thisfield points to the address where the first received byte must be stored. The width of this field depends onthe address width of the used RAM. It is important to note, that this bitfield represents a realDATAWORD

POINTER. That means the complete address is calculated by appending the valid DBOFF bits4.5.4to thisbitfield.


The bitfield will be automatically set to 0x0000 for pipe[0] if a SETUP transaction is received.

4.5.6 Pipe Total Bytes Register


Access Rules: the contents of this register must not be changed when the access to thePipe ConfigurationRegisteris granted and theData Buffer Valid Bitis active.

Short Name PIPEDATA TBYTES

Address 0x54

c©emsys 2003 4-18

4 Register Map


DBV 31 0x0 rw Data Buffer Valid- 30 : TBW - - Reserved.

TBYTES TBW-1 : 0 0x00 rw Total Bytes To Transfer

Table 4.18:Pipe Total Bytes Description

Data Buffer Valid Software must set this bit to indicate that the data described by thePipe Data PointerRegisterandPipe Total Bytes Registeris valid, respectively the buffer is valid for incoming data. The bitwill be cleared by hardware after the buffer was finished (e.g. all data was transmitted or received).

Total Bytes To Transfer This bitfield contains the total number of bytes to be transmitted or received.

This field will be decremented according to the number of bytes received/transmitted with every transac-tion.

Software must ensure that the field is only written if the data buffer is not valid. Writing to this register ifthe data is validated will lead to undefined results

For receive pipes, software must set this field always to a multiple ofMaximum Packet Size Field. Trans-fers will only be initiated if TBYTES is greater/equal MPS


The bitfield will be ignored by hardware if the received transaction was a SETUP transaction. (SETUPtransactions must always be accepted)

4.5.7 Pipe Alternative Data Pointer Register


This register does only exist, if alternate buffer support3 is enabled for this pipe. Otherwise this bitfield will stuckat zero.

Access Rules: the contents of this register must not be changed when the access to thePipe ConfigurationRegisteris granted and theAlternative Data Buffer Valid Bitis active.

Short Name PIPEADATA PTR

Address 0x58


- 31 : RAW - - Reserved.ADPTR RAW-1 : 0 0x00 rw Alternative Data Pointer

Table 4.19:Pipe Alternative Data Pointer Description

Alternative Data Pointer This register does only exist, if alternate buffer support4 is enabled for this pipe.Otherwise this bitfield will stuck at zero.

3see table2.24see table2.2

c©emsys 2003 4-19

4 Register Map

For transmit transfers, this field points to the first byte of the alternative data buffer to be sent. For receivetransfers, this field points to the address where the first received byte must be stored. The width of thisfield depends on the address width of the used RAM.

4.5.8 Pipe Alternative Data Total Bytes Register


This register does only exist, if alternate buffer support5 is enabled for this pipe. Otherwise this bitfield will stuckat zero.

Access Rules: the contents of this register must not be changed when the access to thePipe ConfigurationRegisteris granted and theAlternative Data Buffer Valid Bitis active.

Short Name PIPEADATA TBYTES

Address 0x5C


ADBV 31 0x0 rw Alternative Data Buffer Valid- 30 : TBW - - Reserved.

ATBYTES TBW-1 : 0 0x00 rw Alternative Total Bytes To Transfer

Table 4.20:Pipe Alternative Data Total Bytes Description

Alternative Data Buffer Valid This bit is only valid if the pipe is configured to have an alternative databuffer6. Otherwise the bit will stuck at zero.

Software must set this bit to indicate that the data described by thePipe Alternative Data Pointer RegisterandPipe Alternative Data Total Bytes Registeris valid, respectively the buffer is valid for incoming data.The bit will be cleared by hardware:

• After an receive buffer was finished, this condition is checked during the status update. The Bufferwill be finished when theTotal Bytes To Transfer Fieldis lessMaximum Packet Size FieldandSelected Data Buffer Bitis 1.

• After an transmit buffer was finished, this condition is checked during the status update. The Bufferwill be finished when theTotal Bytes To Transfer Fieldis 0x0 andSelected Data Buffer Bitis 1.

• The pipe state (Active Status Bit) has changed from active to inactive and the core works in hostmode.

Alternative Total Bytes To Transfer It contains the total number of bytes of the alternative data buffer to betransmitted or received.

This field will be decremented according to the number of bytes received/transmitted with every transac-tion.

Software must ensure that the field is only written if the alternative data buffer is not valid. Writing to thisregister if the data is validated will lead to undefined results!

5see table2.26see table2.2

c©emsys 2003 4-20

4 Register Map

4.6 Debug Register Group

These registers provide various debug capabilities. They will not be used for normal operation. Debug mode isenabled if one of theDebug Control Registerbits are set to one.

Debug mode is only valid for pipe 0. The basic configuration of this pipe will be used for a transaction andchanges according to the debug configuration.

The core can be configured to support debug or extended debug capability7. Therefore, some registers or bits canbe not valid (stuck at zero).

4.6.1 Debug Control Register

Debug mode is enabled if one of the control bits is set to one.

Short Name DEBUG CTRL

Address 0x60


- 31 : 10 - - Reserved.UDTPID 9 0x0 rw Use Debug Token PIDUDHSPID 8 0x0 rw Use Debug Handshake PIDUDDPID 7 0x0 rw Use Debug Data PIDFRXCRC16G 6 0x0 rw Force Receive Good CRC16FRXCRC5G 5 0x0 rw Force Receive Good CRC5FRXCRCE 4 0x0 rw Force Receive CRC ErrorFTXCRC16E 3 0x0 rw Force Transmit CRC16 ErrorFTXCRC5E 2 0x0 rw Force Transmit CRC5 ErrorDBSTX 1 0x0 rw Disable Bitstuffing TransmitDBSERRDET 0 0x0 rw Disable Bitstuff Error Detection

Table 4.21:Debug Control Description

Use Debug Token PID If the bit is set, the host controller will use theDebug Token PID Fieldfor the nexttransaction.

The bit will only exist, if extended debug capability support was implemented. Otherwise the bit willstuck at zero.

Use Debug Handshake PID If the bit is set, the host controller will use theDebug Handshake PID Fieldforthe next transaction.


Use Debug Data PID If the bit is set, the host controller will use theDebug Data PID Fieldfor the nexttransaction.


7see table2.2

c©emsys 2003 4-21

4 Register Map

Force Receive Good CRC16 If this bit is set, the core will treat every received data CRC16 as a good CRC.

The bit will only exist, if debug capability support was implemented. Otherwise the bit will stuck at zero.

Force Receive Good CRC5 If this bit is set, the core will treat every received CRC5 of an incoming tokenor SOF as a good CRC.


Force Receive CRC Error If this bit is set, the core will treat every received CRC as a wrong CRC.


Force Transmit CRC16 Error If this bit is set, the core will generate a wrong data CRC16 (Ones comple-ment).


Force Transmit CRC5 Error If this bit is set, the core will generate a wrong CRC5 for every token/SOF(Ones complement).


Disable Bitstuffing Transmit If this bit is set, the core will not perform bitstuffing at the output stream.


Disable Bitstuff Error Detection If this bit is set, the core will not report bitstuff errors. Because everybitstuff error will lead to a CRC error, the completion code will show only CRC errors instead of bitstufferrors.


4.6.2 Debug PID Register

This register will only exist, if extended debug capability support was implemented. Otherwise the bit will stuckat zero.

Short Name DEBUG PID

Address 0x64


- 31 : 24 - - Reserved.DHSPID 23 : 16 0x00 rw Debug Handshake PIDDTPID 15 : 8 0x00 rw Debug Token PIDDDPID 7 : 0 0x00 rw Debug Data PID

Table 4.22:Debug PID Description

Debug Handshake PID This bitfield will be sent as handshake PID if the device has returned data.

Debug Token PID This bitfield will be sent as token PID if debug mode is enabled instead of an IN/OUT/SETUPtoken PID.

Debug Data PID This bitfield will be sent as data PID if debug mode is enabled instead of an DATA0, DATA1,DATA2 or MDATA PID.

c©emsys 2003 4-22

4 Register Map

4.6.3 Debug Status Register

This register will only exist, if extended debug capability support was implemented. Otherwise the bit will stuckat zero.

Short Name DEBUG STAT

Address 0x68


- 31 : 8 - - Reserved.DRXPID 7 : 0 0x00 r Debug Receive PID

Table 4.23:Debug Status Description

Debug Receive PID This bitfield contains the received PID of the last transaction, independently of the trans-action status.

4.6.4 Test Register

This register exists for system integration tests only.

Short Name TEST

Address 0x6C


RW32 31 : 0 0x5AF8CAFE rw Read Write 32

Table 4.24:Test Description

Read Write 32 This test field can be read and written in any order and with any contents. Every write accessstores the 1’s complement of the written value.

4.7 Core Configurations Register Group

The following registers show the parameters the core is configured with. Refer the2.1chapter for more informa-tions about the core configuration parameters and signals. All bitfields mirror the core’s configuration, it is notpossible to change the configuration by writing these registers!

c©emsys 2003 4-23

4 Register Map

4.7.1 Main Configuration Register

Short Name MAIN CFG

Address 0x80


- 31 : 30 - - Reserved.RAW CFG 29 : 24 RAW r RAM Address Width Configuration

- 23 : 12 - - Reserved.DW CFG 11 : 6 DW r Data Width ConfigurationNOP CFG 5 : 0 NOP r Number of Pipes Configuration

Table 4.25:Main Configuration Description

RAM Address Width Configuration This field shows the address width of the Dual Port RAM the core isconfigured for.

Data Width Configuration This bitfield shows the data width (DW) of the core.

Number of Pipes Configuration This field shows the number of pipes (NOP) the core is configured with.

4.7.2 Mode Configuration Register

Short Name MODE CFG

Address 0x84


- 31 : 18 - - Reserved.XDBG CFG 17 0x0 r Extended Debug ConfigurationDBG CFG 16 0x0 r Debug Configuration

- 15 : NOP - - Reserved.ABUFF CFG NOP-1 : 0 0x00 r Alternative Buffer Configuration

Table 4.26:Mode Configuration Description

Extended Debug Configuration This bit shows whether this core is configured for extended debug support.

Debug Configuration This bit shows whether this core is configured for debug support.

Alternative Buffer Configuration This bitfield shows which pipe is configured for alternative Buffer usage.

c©emsys 2003 4-24

5 Software Application Notes

This chapter describes a choice of some software implementation details. Because of the complexity of thesoftware requirements, dedicated OTG Dual-role device drivers are offered by various companies. It isrecommended to use theemsys USB Firmware Library. Fore more informations about pricing and availabilityplease contact emsys Embedded Systems GmbH [email protected]

5.1 USB Transaction Management

This chapter describes the USB transaction management of theFHG USBOTGDRD core. It is generally han-dled by the Transaction Manager Module. (TM)

The FHG USBOTGDRD can be configured to support up to 16 endpoints/pipes. The register-file moduleprovides a seperate set of registers for each endpoint as shown in Figure5.1. The structure of thePipe RegisterGroup is described in Section4.5. The access to these register resources is ”paged”. That means, that softwareselects the appropriate pipe register page by writing to thePipe Select Field. Each pipe page contains a completeset of bits/fields with all required control and status informations (including data buffer pointers and length) tohandle USB transactions.

PIPE 0

PIPE NOP-1

PIPE0 Data

Buffer

PIPE NOP-1 Data

Buffer

PIPE 1

PIPE1 Data

Buffer

Figure 5.1:Pipe Page Structure

All scheduling operation is done in hardware. After the software has configured the appropriate pipe registers,theFHG USBOTGDRD core schedules the USB transactions, evaluates the device responses and performes thestatus update. Software hast to manage the dataflow and to respond on serious error conditions.

c©emsys 2003

mailto:[email protected]


5.1.1 Host Mode

If the core is working in host mode, the Transaction Manager (TM) controls the generation of SOF tokens orLow Speed Keep Alives, and the scheduling of the different transfer types. TheTM will check the availablebandwidth of a frame. Transactions are only initiated if enough bandwidth is available. Periodic transfers arescheduled whenPeriodic Schedule Bitis active. Asynchronous transfers are scheduled only whenAsynchronousSchedule Bitis active.

TheTM will initiate different transfer types in an order as shown in Figure5.2. TheTM scans allPipe RegistersPages(refer to Section4.5) starting at index 0 for isochronous transfers. When it reaches pipe index (NOP-1), itswitches to the interrupt transfer type and scans again. At last, bulk and control endpoints are processed.

SOF Periodical Transfers Non periodical Transfers

ISO Interrupt Control Bulk

1 ms

time

Figure 5.2:Transfer Scheduling

Periodical transfers (interrupt and isochronous) are handled automatically. Isochronous and control transfersare initiated once per frame and pipe. Interrupt transfers are scheduled according the given polling interval andschedule index.

All remaining bandwidth is used for bulk transactions. Bulk pipes can be scheduled more than one time perframe.

The TM starts USB transactions and performs a pipe status update according the rules defined Figures5.3 to5.7.

A transaction will be executed if thePreConditionis true.

Transaction Flow Diagram Denotation The following denotation is used for the following transactionflow diagrams:

Register All fields of core registers are denoted upper-case, e.g. FRAMENR. Field names of thePipe RegisterGroupare prefaced with PIPE.*, e.g. PIPE.ACT means the ACT-bit of thePipe Control Registerthat ispart of thePipe Register Group.

Diagram Internal Variables All internal variables used in a diagram are denoted mixed-case in Italic-font,e.g.PreCondition

Actions Actions, which are used more than one time in a diagram are denoted as function call, mixed-case inItalic-font. The following action types are used:

deactivatePipe() ThePipe Active Bitis cleared by hardware.

haltPipe() The Pipe Active Bitis cleared and thePipe Halted Bit is set by hardware to inform thesoftware about a serious error.

c©emsys 2003 5-2


nextBuffer() The current data buffer cannot accept more data. ThePipe (Alternative) Data Buffer ValidBit is cleared by hardware. ThePipe Data Buffer Select Bittoggles if alternative buffer support isenabled for this pipe.

discardData() All data received with the last USB transfer is completely ignored and the appropriatebuffer pointer and length counter are reverted.

revertData() The data transmission for the last USB transfer was not successfull. Therefore, the appro-priate buffer pointer and length counter must be reverted.

Transaction Status Attributes Attributes of the transactions status are denoted as Rx.<attribute> or Tx.<attribute>,e.g. Rx.Len means the transaction length of a receive transaction.

c©emsys 2003 5-3


Host Token

Host Data

OUT Token

ISO OUT

Next Pipe

PIPE.(A)DBV

Transmit Data Tx.PID=DATA0

Tx.Len= ...

valid

Tx.Len= Min (PIPE.MPS,PIPE.(A)TBYTES)

Status Update

PreCondition = (PIPE.ACT && (PIPE.(A)DBV ||!PIPE.SKIPISO) && PollingCondition ==true

Check PreCondition Next Pipe false

invalid

Transmit Tx.PID=DATA0

Tx.Len=0

true

Polling Condition:

if (PIPE. POFF [PIPE.PI-1:0]==FRAME_NR[PIPE.PI-1:0]) PollingCondition =true else PollingCondition =false

Figure 5.3:Host Isochronous OUT

c©emsys 2003 5-4


Rec

eive

Dat

a R

x.P

ID =

= D

ATA

0 R

x.Le

n>P

IPE

.MP

S

Bab

ble

Err

or

Tim

eout

if ((

Rx.

CR

CE

rror

|| R

x.B

itstu

ffErr

or) a

nd !P

IPE

.AC

ID){

dis

card

Dat

a()

} els

e {

if

(PIP

E.(A

)TB

YTE

S<P

IPE

.MP

S o

r PIP

S.S

TRM

==0)

next

Buf

fer (

) }

disc

ardD

ata(

)

IN

Toke

n

haltP

ipe(

) di

scar

dDat

a()

PIP

E.B

BL=

1

Hos

t Tok

en

Hos

t Sta

tus

Upd

ate

Func

tion

Res

pons

e

ISO

IN

Nex

t P

ipe

Pre

Con

ditio

n =

PIP

E.A

CT

&&

(P

IPE

.(A)D

BV

|| n

ot P

IPE

.SK

IPIS

O) &

&

Pol

lingC

ondi

tion =

=tru

e

Che

ck

Pre

Con

ditio

n N

extP

ipe

fals

e

Bad

PID

Rec

eive

Dat

a R

x.P

ID==

DA

TA0

Rx.

Len<

=PIP

E.M

PS

al

so C

RC

/Bits

tuff-

Err

or!

Dat

a su

cces

sful

ly

save

d?

if (P

IPE

.HID

BE

){

d

eact

ivat

e Pip

e()

P

IPE

.DB

ER

R=1

}

no

yes

Pol

ling

Con

ditio

n:

if (P

IPE

. PO

FF [P

IPE

.PI-1

:0]=

=FR

AM

E_N

R[P

IPE

.PI-1

:0])

Pol

lingC

ondi

tion

=tru

e el

se

P

ollin

gCon

ditio

n =f

alse

fals

e

true

Figure 5.4:Host Isochronous IN

c©emsys 2003 5-5


AC

K

PIP

E.D

T=!P

IPE

.DT

PIP

E.C

ER

R=3

if

(PIP

E.(A

)TB

YTE

S <

PIP

E.M

PS

||

P

IPE

.STR

M==

0) {

n

extB

uffe

r()

} if (R

x.Le

n<P

IPE

.MP

S) {

dea

ctiv

ateP

ipe(

) }

fals

e

NA

K

Bad

Xfe

r B

adP

ID

if P

IPE

.CE

RR

==1

{

hal

tPip

e()

} PIP

E.C

ER

R=P

IPE

.CE

RR

-1

disc

ardD

ata(

)

send

no

Han

dsha

ke

Hos

t Tok

en

Hos

t Res

pons

e

Sta

tus

Upd

ate

Func

tion

Dat

a/

Res

pons

e

Nex

t Pip

e

Bul

k/

Con

trol/

Inte

rrup

t IN

Rec

eive

Dat

a R

x.D

T!=P

IPE

.DT

Rx.

Len<

=PIP

E.M

PS

AC

K

PIP

E.C

ER

R=3

di

scar

dDat

a()

haltP

ipe(

) di

scar

dDat

a()

PIP

E.B

BL=

1

Bab

ble

Err

or:

-> s

end

no H

ands

hake

Nex

t P

ipe

Rec

eive

Dat

a R

x.P

ID==

DA

TA0/

1 R

x.Le

n>P

IPE

.MP

S

Rec

eive

Dat

a R

x.D

T==P

IPE

.DT

Rx.

Len<

=PIP

E.M

PS

IN

Toke

n

Inte

rrup

t Tra

nsfe

r on

ly

Che

ck

Pre

Con

ditio

n

haltP

ipe(

)

Pre

Con

ditio

n =

PIP

E.A

CT

&&

PIP

E.(A

)DB

V

&&

Pol

lingC

ondi

tion=

true

PIP

E.C

ER

R=3

Bul

k/C

ontr

ol T

rans

fer

only

Pol

ling

Con

ditio

n:

if (P

IPE

. PO

FF [P

IPE

.PI-1

:0]=

=FR

AM

E_N

R[P

IPE

.PI-1

:0])

Pol

lingC

ondi

tion

=tru

e el

se

P

ollin

gCon

ditio

n =f

alse

STA

LL

true

Figure 5.5:Host Bulk/Control/Interrupt IN

c©emsys 2003 5-6


ACK

PIPE.DT=!PIPE.DT PIPE.CERR=3 if (Tx.Len<PIPE.MPS) deactivatePipe()

NAK

PIPE.CERR=3 revertData()

STALL

haltPipe() revertData()

BadXfer BadPID

if PIPE.CERR==1 haltPipe() revertData() PIPE.CERR=PIPE.CERR-1

Host Token

Function Response

Next Pipe

OUT Token

Bulk/ Control/ Interrupt

OUT

false

Next Pipe

Status Update

Interrupt Transfer only Bulk/Control Transfer only

Check PreCondition

Transmit Data Tx.DT=PIPE.DT

Tx.Len= ...


Host Data

PreCondition = PIPE.ACT && PIPE.(A)DBV

&& PollingCondition==true

true

Polling Condition:

if (PIPE. POFF [PIPE.PI-1:0]==FRAME_NR[PIPE.PI-1:0]) PollingCondition =true else PollingCondition =false

Figure 5.6:Host Bulk/Control/Interrupt OUT

c©emsys 2003 5-7


ACK

PIPE.DT=!PIPE.DT PIPE.CERR=3 deactivatePipe()

BadXfer BadPID

revertData() if PIPE.CERR==1 haltPipe() PIPE.CERR=PIPE.CERR-1

Host Token

Function Response

Next Pipe

SETUP Token

Control SETUP

false

Next Pipe

Status Update

else

Check PreCondition


Tx.Len=PIPE.MPS Host Data

PreCondition = PIPE.ACT && PIPE.(A)DBV

true

Figure 5.7:Host Control SETUP

5.1.2 Device Mode

If the core is working in device mode, theFHG USBOTGDRD checks the transaction status after a completedtransaction. The status update according the rules defined in Figures5.8to 5.11will be performed when an USBtransfer is finished.

TheFHG USBOTGDRD uses the address field of the USB token packet1 to decide whether the following datapacket is forthis device. If this condition matches, the endpoint and PID field of the USB token packet is usedby the hardware to select the appropriate pipe page. Therefore, the information from the selected pipe page isused for the following USB transfer.

1see USB Specification[1] chapter 8.4.1 for the detailed description of the USB token packet format

c©emsys 2003 5-8


false

discardData()

BadXfer

Idle

Idle

Token.ADDR == PIPE.EPADDR and PIPE.ACT==1

and PIPE.(A)DBV==1 idle

OUT Token

true

PIPE.ACD=1

if (PIPE.(A)TBYTES < PIPE.MPS or PIPE.STRM==0) { nextBuffer() }

true

false

Receive Data Rx.PID==DATA0

select Pipe with: PIPE[i].EPNR=Token.ENDP

Host Data

Status Update

Host -Token

Figure 5.8:Device Isochronous OUT

c©emsys 2003 5-9


false

Idle

Idle

idle

true

IN Token



Host Token

Function Data valid

Status Update

PIPE.(A)DBV invalid

Transmit Tx.PID=DATA0

Tx.Len=0


Transmit Data Tx.PID=DATA0

Tx.Len= ...

Figure 5.9:Device Isochronous IN

c©emsys 2003 5-10


false

BadXfer TimeOut

discardData() PIPE.DT=!PIPE.DT if (PH.TPID==TPID_SETUP) (PIPE.(A)TBYTES < PIPE.MPS or PIPE.STRM==0) or (PIPE.ET!=ET_INT and Rx.Len<PIPE.MPS){ nextBuffer() }

Idle

Idle

Token.ADDR == PIPE.EPADDR and PIPE.ACT==1 idle

OUT/ SETUP Token

true

ACK NAK


Receive Data Rx.PID==PIPE.DT

Receive Data Rx.PID== !PIPE.DT

false

Host Data

Status Update

Host -Token

Function Response

send no handshake

PIPE.STALL == 1

STALL

true

invalid

valid PIPE.(A)DBV

ACK

Figure 5.10:Device Bulk/Control/Interrupt OUT/SETUP

c©emsys 2003 5-11


false

revertData() PIPE.DT=!PIPE.DT f (PIPE.ET!=ET_INT and Tx.Len<PIPE.MPS){ nextBuffer() }

Idle

Idle

idle

true

IN Token

ACK Timeout BadXfer


Tx.Len= ... STALL NAK



PIPE.(A)DBV


PIPE.STALL == 1

false

invalid

valid

true

Host Token

Function Response

Host Handshake

Status Update

Figure 5.11:Device Bulk/Control/Interrupt IN

5.2 Port Handling

All port control and status information is stored inside thePort Register Group. (Refer to Section4.4)

c©emsys 2003 5-12


Software is informed via thePort Status Change Event Registerif changes of the port state have been occured.(Refer to Section4.4.3)

The port supports the following functionality:

• Babble detection

• Connect/disconnect detection

• Over-current detection

• Device speed detection

• Port reset generation

• Set port into suspended state

• Port resume detection/generation

• Switch port into several test modes

5.2.1 Port Test Capability

The USB Specification defines some test modes for high-speed capable host controllers/hubs and functions. (SeeUSB Specification, chapter 7.1.20. [1])

TheFHG USBOTGDRD supports the following test modes. These test modes are derived from the high-speedtests and trimmed to work with the full-/low-speed core:

Test SE0 NAK In host mode, the port’s transceiver drives an SE0. In device mode, theFHG USBOTGDRDresponds to any IN token packet with NAK handshake within the normal response time.

Test J The port’s transceiver enters the J state.

Test K The port’s transceiver enters the K state.

Test Force Enable Not applicable for full-/low-speed devices. Not supported by theFHG USBOTGDRD.

Test Packet The port will repetitively transmit a test packet. The test packet is defined by the USB Speci-fication. It is required, that software must provide the appropriate pipe data and pipe configuration asdescribed below.

Entering the test mode will be done by setting thePTESTCbit field of thePort Control Registerto the appropriatevalue. (Refer to Section4.4.2)

c©emsys 2003 5-13


Software Requirements for Test Packet Generation

To send a test packet, software must initialize theMaximum Packet Sizeto 0x35 (53 bytes). The test packet datathat must be applied is:

0x000000000x000000000xAAAAAA000xAAAAAAAA0xEEEEEEAA0xEEEEEEEE0xFFFFFEEE0xFFFFFFFF0xFFFFFFFF0xDFBF7FFF0xFDFBF7EF0xDFBF7EFC0xFDFBF7EF0x7E

TheEndpoint Typecan be set to any value, but the scheduling of the test packet will be done in respect to thisvalue. All other pipe-specific settings do not influence the test packet generation. The core will start sendingtest packets after thePTESTCfield of thePort Control Registeris set toPTESTCPKT. Differering to the USBSpecification, the inter-packet gap can be more than 125µs. The test packet will be prefaced with a normalfull-/low-speed SYNC pattern, and completed with a normal full-/low-speed EOP according to the speed of theconnected device.

5.3 Buffer Management

The dataflow from/to theFHG USBOTGDRD core is done by using data buffers not simply fifo’s.The mainadvantage of the buffer management is, that each buffer can have more payload data than 1 single USBdata packet. It is the task of the FHG USB OTGDRD core to divide the large buffer into separate USBpackets! For receive operations the FHGUSB OTGDRD core stores the data of several USB packets into1 buffer!

Each data buffer is characterized by its start address and its size. The length is defined by theTotal Bytes FieldorAlternative Total Bytes Field. The start address is defined by theData Pointer Fieldor Alternative Data PointerField.

When the software provides a buffer to the hardware, it sets theData Buffer Valid Bitor theAlternate Data BufferValid Bit. The hardware will clear the valid bit after a data buffer is completed, and a pipe will be generated. The“alternative” versions of these bits will only exist if the hardware is configured for alternative buffer usage, asdescribed in Table2.2.

The software can operate with one single buffer. This can be sufficient for asynchronous pipes. For periodic,high-bandwidth endpoints it is necessary that theFHG USBOTGDRD core can generate a continuous datastream. Using single buffer management can cause problems, because the hardware cannot perform USB trafficfor this endpoint when the data buffer expires and the software must provide the new buffer within a very shorttime.

c©emsys 2003 5-14


To avoid this problem, theFHG USBOTGDRD can be configured to support “alternative buffers” (Refer Table2.2. This enables the hardware to process the 1st data buffer during software fills the 2nd buffer and vice versa.After pipe initialization, hardware always starts at the non-alternative data buffer. TheData Buffer Select Bitisused to store the information which data buffer is in progress. This bit is toggled by hardware after a data bufferexpires and alternative buffering is enabled for this pipe .

The following notes must be considered for writing efficient software drivers:

• Bulk/Control/Interrupt/Isochronous transmit pipes:

– When the buffer size is any multiple ofMaximum Packet Size, the hardware generates USB packetswith length of MPS.

– When the buffer size is not any multiple ofMaximum Packet Size, the hardware generates the 1stUSB packets with length of MPS and the last USB packet as short packet. (which has a specialmeaning in the context of USB for control and bulk endpoints)

– When the buffer size is 0, the hardware generates a Zero-Data packet.

• Bulk/Control receive pipes:

– The streaming mode should be activated to catch many USB packets in one buffer.

– The buffer size must be a multiple ofMaximum Packet Size.

– A short packet condition is characterized by a total bytes value that is greater 0, and is not a multipleof theMaximum Packet Sizeafter the buffer has expired.

• Interrupt/Isochronous receive pipes:

– The streaming mode should be activated for high bandwidth pipes.

– The buffer size must be a multiple of the doubledMaximum Packet Size

5.4 Data Buffer Handling for Streaming Pipes

TheFHG USBOTGDRD supports the automatic handling of large data buffers. All USB data is transferred viadata channels called pipes in the USB Specification.

For high bandwidth pipes, it is recommended to configure the core to have alternative buffers (ReferInterfaceSection, 2.1). This feature can be activated for every pipe. It allows to completely decouple the interrupt latencyof theµC or DSP from any USB timing requirement.

All data that is stored into a buffer or that has to be fetched from a buffer will be handled with Little Endian byteorder.

Normally, a data buffer that must be transmitted or received is a multiple of the allowed maximum packet size(seeMaximum Packet Size, section4.5.2). TheFHG USBOTGDRD allows software to provide large buffers(seeTotal Bytes, Section4.5.6) with more than Maximum Packet Size. Transmit buffers will be automaticallysplit into pieces of Maximum Packet Size, and receive buffers will be automatically concatenated.

5.4.1 Data Streaming for Receive Pipes

Received data can be concatenated and byte-aligned automatically using theStreaming Modefeature.

There are some software issues concerning the streaming data buffer handling that must be taken into account:

c©emsys 2003 5-15


• For all streaming receive pipes:bufferSize ≥ 2×MaxPacketSize

• For high bandwidth receive pipes with ISO/Bulk transfer mode streaming mode recommended

Problem Description The following situation occurs, if streaming mode is deactivated for receive pipes,and the core receives packets with a data payload which does not fit in multiple of data words (data words containeither 2 bytes, when data width=16; or 4 bytes, when data width=32).

Because the USB’s dataflow model is byte oriented, it can happen that the core did receive much data and storedin several buffers. Especially for isochronous transfer type, which allows different packet sizes for a transfer, theprobability of empty byte fields is very high as shown in Figure5.12. Normally, filling the buffer starts at byteaddress 0. This shown example uses only 25 or 27 bytes per buffer.

simple copy

copy and shift right by 2 bytes



Dat

awor

ds

Bytes Byte 3 Byte 2 Byte 1 Byte 0

� ��

Buffer #3 25 Bytes received

� ��


� ��


� ��


1 Dataword = 32 Bit = 4 Bytes �Data to be copied

0

4

3

2

1

5

6

Dat

awor

ds

0

4

3

2

1

5

6

Dat

awor

ds

0

4

3

2

1

5

6

Dat

awor

ds

0

4

3

2

1

5

6

from Buffer #3

from Buffer #2

from Buffer #1

from Buffer #0

Dat

awor

ds

4

3

2

1

5

6

7

11

10

9

8

12

13

14

18

17

16

15

19

20

21

25

24

23

22

0

Figure 5.12:Concatenating Data Buffers without Streaming

The software is now responsible to concatenate these buffers, because they can belong to the same image, videoor something else. Because at the end of these buffers data words with empty byte fields can exist and a byte

c©emsys 2003 5-16


shifting must be done. This must be performed by software using a special byte shifting routine (which can bevery time consuming), or using an DMA channel with byte shifting capability.

As shown in Figure5.12, the transfer is finished after buffer #3 was written to memory. Now software mustconcatenate all buffers. This is done by:

• Copy buffer #0, data words 0-6

• Copy buffer #1, data words 0-6, shifting all data words by 1 byte



It is important to note, that 3 of 4 copy operations must be donewith byte shifting.

The Solution The problem above occurs because the byte alignment must be doneafter several buffers arefilled with data. Some simple additional logic to the core solves this problem. The byte alignment is donewhilethe buffers are filled with data, as shown in Figure5.13if the Streaming Modeis activated.

c©emsys 2003 5-17


Bytes Byte 3 Byte 2 Byte 1 Byte 0

Buffer #1

from Buffer #3

from Buffer #2

from Buffer #1

simple copy

from Buffer #0


Buffer #0

1 Dataword = 32 Bit = 4 Bytes

�Data to be copied

� ��


� ��


� ��


� ��


�

Dat

awor

ds

4

3

2

1

5

6

7

11

10

9

8

12

13

14

18

17

16

15

19

20

21

25

24

23

22

Dat

awor

ds

0

4

3

2

1

5

6

Dat

awor

ds

0

4

3

2

1

5

6

Dat

awor

ds

0

4

3

2

1

5

6

Dat

awor

ds

0

4

3

2

1

5

6

�

�

simple copy

simple copy

simple copy 7

�Data from the previous buffer

0

Figure 5.13:Concatenating Data Buffers with Streaming

After Buffer #0 was received and all data was written to memory, the core stores the current byte offset value(DBOFF=1) internally. If the first packet of buffer #1 is written to memory, the core knows the last byte offset ofthe previous buffer and writes byte #0 of data word #6 of buffer #0 again to memory, to the beginning of buffer#1.

After Buffer #1 was received and all data was written to memory, the core stores the current byte offset value(DBOFF=2) internally. If the first packet of buffer #2 is written to memory, the core knows the last byte offsetof the previous buffer and writes bytes #0/#1 of data word #6 of buffer #1 again to memory, to the beginning ofbuffer #2.

After Buffer #2 was received and all data was written to memory, the core stores the current byte offset value(DBOFF=1) internally, and writes byte #0 of data word #6 of buffer #2 again to memory if the first packet ofbuffer #2 is received.

After Buffer #3 was written to memory, the entire transfer is finished. Now software must copy all buffer. Thisis done by:

c©emsys 2003 5-18






All copy operations can be performedwithout byte shifting.

5.5 Pipe Register Permissions for Host Mode

This Chapter describes, how the software has to access to thePipe Register Page. Because there exist registerswhich must be modified by hardware, it is necessary to define some access rules to avoid conflicts betweensoftware and hardware register modifications.

The software can access pipe registers if it selects a specific page by setting thePipe Select Field. Eachpipe register page has assigned a state, which is defined by the contents of thePIPE CTRL.ACT Bitand thePIPE STAT.ACTS Bit(subsequently named asACT andACTS) as shown in Figure5.14:

Software

sets

ACT

Hardware clears

ACTS

Hardware sets

ACTS

Pre Active

Idle

Pre Idle

Active

Softwar

e clea

rs

PIPE.A

CT

Hardware clears ACT and ACTS

ACT : 0 ACTS : 1

ACT : 1 ACTS : 0

ACT : 1 ACTS : 1

ACT : 0 ACTS : 0

Figure 5.14:Pipe States

Idle This is the initial state. It is identified byACT=0 andACTS=0. The hardware ignores this pipe completely.Software can modify all registers belonging to this register page while theACTbit remains 0. The softwarecan configure the pipe for the required transfer. When the pipe configuration is done, theACT bit can beset to initiate USB traffic for this pipe.

PreActive This state becomes active when the software sets theACT bit. The state is identified byACT=1 andACTS=0. The hardware will set theACTSbit to 1 the next time it processes this register page.

Active This state becomes active after the hardware has set theACTSbit. USB traffic is generated for this pipe.The hardware can modify dedicated bits. Software has only to access the data buffer registers. When thehardware changes the state toIdle, it clears theACT andACTSbits and generates an pipe event, whichcan lead to an interrupt.

c©emsys 2003 5-19


PreIdle This state becomes active when the software clears theACT bit. USB traffic can still be executed forthis pipe and hardware can change dedicated bits. The hardware will clear theACTSbit the next timeit processes this pipe and will enter theIdle state. A pipe event will be generated, which can lead to aninterrupt.

Table5.1shows how the software and the hardware can change dedicated pipe register resourccs:

State Idle PreActive Active PreIdleSW HW SW HW SW HW SW HW

PIPE ADDR A F F F F F F FPIPE CFG A F F F F F F FPIPE CTRL A F F F A∗ F F FPIPE STAT A F F A F A F APIPE DPTR A F D D D D D DPIPE TBYTES A F D D D D D DPIPE ADPTR A F D D D D D DPIPE ATBYTES A F D D D D D D

Table 5.1: Pipe Register Access Rules

Symbol definition:

A Write access allowed (A∗ software is allowd to reset theACT bit only)

F Write access forbidden.

D Software can modify when (Alternative) Data Buffer Validis not set. Hardware can modify when (Alternative)Data Buffer Validis set.

5.6 Peripheral Control Pipe Handling

This section describes, how the software has to use the pipe registers for the control pipe when acting as USBdevice.

The USB protocol defines a default control pipe for device configuration and control. This pipe has some fixedattributes:

• Transfer type is Control Transfer.

• MaxPacketSize is less or equal than 64 bytes.

• Data phase following a SETUP token isalways8 bytes and definesalwaysan USB Request.

• Pipe must be active immediately after an USB reset was received. It is required according to the USBSpecification that a SETUP stagemust be completed with an ACK handshake.

• Endpoint number is 0.

• Pipe is bi-directional.

These specifics require a special handling of the control pipe if the core works in peripheral mode. The FHGUSB OTGDRDuses the pipe control and status registers for both host and peripheral mode. If the core works in peripheral mode,it must be sensitive for USB tokens of both directions for the control pipe. (SETUP, OUT and IN tokens).

c©emsys 2003 5-20


Control Pipe Default Settings After an USB reset was received, pipe[0] is reserved as control pipe.Table5.2shows the default settings for this pipe.

Register Bit/Field Value Description

PIPE CTRL ACT 1 Pipe is enabled. Core will respond to tokens atcontrol pipe.

STALL 0 Pipe is not stalled.TPID TPID SETUP At first, a SETUP token is expected.

PIPE CFG STRM - This bit is not affected by USB reset.EPS - This bit is not affected by USB reset.ET ET CTRL Pipe is control pipe.MPS - This bit field is not affected by USB reset. Nev-

ertheless, SETUP tokens will always be ac-cepted with ACK handshake.

PIPE ADDR EPADDR 0x00 Device address reset value.EPNR 0x0 Control endpoint is always EP0.

PIPE STAT all read-only - Same reset values as after power-on reset.DBOFF 0 Pipe data buffer offset is zero.DBSEL 0 First buffer selected.DT 0 At first, a SETUP token with DATA0 data PID

is expected.PIPE DATA TBYTES TBYTES 0 No data to transfer. SETUP tokens will be ac-

cepted with ACK handshake anyway.PIPE DATA PTR DPTR 0 This value is reserved as default pointer for

IN/OUT transactions of the control pipe. It isnot valid for SETUP transactions. USB Re-quests following a SETUP token will be writtento address 0x0000.

DBV 0 No valid data buffer. This will lead to a NAKresponse to IN and OUT tokens. Nevertheless,SETUP tokens will be accepted with ACK.

Table 5.2: Control Pipe Default Settings after USB Reset

Control Pipe Data Sequencing The direction sequencing of the data flow of the control pipe followsthe rules defined in the USB Specification, Chapter 8.5.3 [1]. The following cases exist:

• Setup stage with IN-data stage (host receives data), and status stage.

• Setup stage with OUT-data stage (host sends data), and status stage.

• Setup stage without data stage. The request is only completed with the status stage.

Figures5.15to 5.17illustrate these cases.

Furthermore it must be taken into consideration that an IN-data stage can be finished without the transmission ofall data. The host is allowed to cancel the data stage by sending the OUT zero data packet before all data wasreceived.

c©emsys 2003 5-21


SETUP DATA0 ACK Setup Stage

IN DATA1 ACK

IN DATA0 ACK

IN DATA1/0 ACK

OUT DATA1 ACK

8 Bytes

MPS Bytes

Request

Data

Token Data PID Data Handshake

MPS Bytes Data

less or equal MPS Bytes Data

0 Byte

Data Stage

Status Stage

Figure 5.15:Setup Request with IN data stage


OUT DATA1 ACK

OUT DATA0 ACK

OUT DATA1/0 ACK

IN DATA1 ACK

8 Bytes

MPS Bytes

Request

Data


MPS Bytes Data

less or equal MPS Bytes Data

0 Byte

Data Stage

Status Stage

Figure 5.16:Setup Request with OUT stage

c©emsys 2003 5-22



OUT DATA1 ACK

8 Bytes Request


0 Byte Status Stage

Figure 5.17:Setup Request without data stage

The following sections give an overview how to handle the control pipe for the different cases.

5.6.1 Software Dataflow for Setup Requests

Figures5.18to 5.20show the dataflow and the required software actions for all SETUP request types.

c©emsys 2003 5-23


PIPE_CFG.MPS:=MaxPacketSize; PIPE_DATA_TBYTES:=TotalBytes; PIPE_DATA_PTR:=DataPointer; PIPE_CTRL.DBV := 1; PIPE_CTRL.TPID := TPID_IN;

Action

Condition

USB Reset received PIPE_CTRL.ACT:=1; (set by Hardware)

Software reads request from RAM at address DMA_SADDR

PIPE_EV[0] == 1 && PIPE_CTRL.TPID ==TPID_IN

PIPE_CTRL.STALL := 1;

More Data to send?

WR_DATA Write data to RAM

IN_DATA_STAGE Request requires IN data stage

EVAL_REQ Evaluate request

REQ_RCVD Valid request received

IDLE Control pipe enabled

VALIDATE_BUFFER Validate written data

REQ_NOT_SUPP Request not supported

Request requires OUT data stage or no data stage

PIPE_EV[0] == 1 && PIPE_CTRL.DBV ==0 && PIPE_STAT.DT ==1 && PIPE_CTRL.TPID ==TPID_SETUP

Yes

PIPE_EV[0] == 1 && PIPE_CTRL.TPID ==TPID_SETUP

STATUS_STAGE_RCVD Status stage received

TX_BUFFER_EMPTY IN data transmitted

PIPE_EV[0] == 1 && PIPE_CTRL.TPID ==TPID_OUT

No

Figure 5.18:Dataflow for Setup Request with IN data stage

c©emsys 2003 5-24


PIPE_CFG.MPS:=MaxPacketSize; PIPE_DATA_TBYTES:=TotalBytes; PIPE_DATA_PTR:=DataPointer; PIPE_CTRL.DBV := 1; PIPE_CTRL.TPID := TPID_OUT;

Action

Condition

USB Reset received PIPE_CTRL.ACT:=1; (set by hardware)

Software reads request from RAM at address DMA_SADDR

PIPE_EV[0] == 1 && PIPE_CTRL.TPID ==TPID_OUT


OUT_DATA_STAGE Request requires OUT data

stage


REQ_RCVD Valid setup request received


VALIDATE_BUFFER Make data buffer valid


Request requires IN data stage or no data stage

PIPE_EV[0] == 1 && PIPE_CTRL.DBV ==0 && PIPE_STAT.DT ==1 && PIPE_CTRL.TPID ==TPID_SETUP


STATUS_STAGE_SENT Core sent zero data packet

RX_BUFFER_FULL Buffer filled with incoming data


Figure 5.19:Dataflow for Setup Request with OUT data stage

c©emsys 2003 5-25


PIPE_CFG.MPS:=MaxPacketSize; PIPE_DATA_TBYTES:=0; PIPE_CTRL.DBV := 1; PIPE_CTRL.TPID := TPID_IN;

Action

Condition

USB Reset received PIPE_CTRL.ACT:=1; (set by hardware)

Software reads request from RAM at address 0x0000


NO_DATA_STAGE Request requires no data stage


REQ_RCVD Valid request received


VALIDATE_BUFFER Make data buffer valid


Request requires IN data stage or OUT data stage

PIPE_EV[0] == 1 && PIPE_CTRL.DBV ==0 && PIPE_CTRL.DT ==1 && PIPE_CTRL.TPID ==TPID_SETUP


STATUS_STAGE_SENT Core sent zero-data packet


Figure 5.20:Dataflow for Setup Request without data stage

Dataflow State Description

IDLE This state is entered after a valid USB reset was received. The control endpoint pipe is automaticallyenabled by hardware and the core is sensitive to incoming tokens.

REQ RCVD Every USB request starts with a SETUP token followed by 8 bytes with the encoded request. Anincoming request is indicated by the occurrence of a pipe event for pipe[0], and theTPID field of the PipeControl Register indicating a SETUP token was received. Hardware will automatically set the data toggleto DATA1 and invalidate the data buffer. Incoming IN and OUT tokens are NAK’d until software validatesthe data buffer.

EVAL REQ Software must evaluate the request and determine if the request requires an IN, OUT or no datastage.

c©emsys 2003 5-26


IN DATA STAGE Software has detected that request requires an IN data stage.

OUT DATA STAGE Software has detected that request requires an OUT data stage.

NO DATA STAGE Software has detected that request requires no data stage.

WR DATA Fill a buffer area of the RAM with the data to be sent.

REQ NOT SUPP If software has detected an unsupported request, it must set theSTALLbit of the Pipe ControlRegister. This will lead to a STALL handshake response to the next token (IN or OUT).

VALIDATE BUFFER Software must set all buffer specific values, such as maximum packet size for the pipe,the total amount of data to be transferred and the data pointer to the buffer. Validating the buffer iscompleted by setting theDBV bit andTPID bit field of the Pipe Control Register.

TX BUFFER EMPTY Hardware will send the data buffer in pieces of max. packet size as response to INtokens. After all data is sent, the pipe event will occur, and theTPID field of the Pipe Control Registerwill show the last received token as IN token. If the amount of data specified byTBYTESis a multiple ofMPS, the core will automatically send a zero data packet as last packet.

RX BUFFER FULL Hardware will fill the data buffer with the received data. If no more buffer space is avail-able, the pipe event will occur, and theTPID field of the Pipe Control Register will show the last receivedtoken as OUT token.

STATUS STAGE RCVD Software can detect the completion of the SETUP transfer by checking theTPIDfield of the Pipe Control Register that must indicate an OUT PID.

STATUS STAGE SENT If the TPID field of the Pipe Control Register is set to OUT PID, and the data bufferis valid, the core will send a Zero Data Packet as response to an IN token as status stage.

5.7 Session Request Protocol Handling

The OTG Supplement [2] allows an A-Device to turn offVBUS when the bus is not in use. The A-Device is bydefinition the device that providesVBUS . TheSession Request Protocol(SRP) allows the connected B-device torequest a session ifVBUS is not available. Refer [2] for details of SRP handling.

There are two methods defined by the OTG Supplement that can be used by the B-device to request a session:

Data Line Pulsing The B-device turns on it’s pull-up resistor for a period of 5 ms to 10 ms.

Bus Power Pulsing The B-device drivesVBUS above a specified level.

An SRP-capable host or dual-role device can get the information about the SRP-capability of an connected deviceby requesting and parsing its OTG descriptor.

The following two sections describe the SRP handling using the FHGUSB OTGDRD core from the view of theA-device and the B-device.

5.7.1 Host SRP

If the core is working as A-device and an SRP-capable B-device is connected, it must monitorVBUS also if ithas turned off the bus power. If it detectsVBUS > 0.8V , it has to recognize that as a session request and mustrespond within 5 seconds by turning onVBUS .

Figure5.21shows the flow diagram for the core working as an A-device (host mode) that turns offVBUS .

c©emsys 2003 5-27


A-Device active

Turn on VBUS within 5 seconds

Connected B-device is SRP capable: OTG_Descriptor.wValue.bmAttributes(0) == 1

Turn off V BUS PORT_CTRL.VB_ON := 0

Action

Condition

//VBUS pulsing (PSC_EV.PWRSC_EV and PORT_STAT.VA_SESS_VLD == 1) or // data line pulsing (PSC_EV.CDC and PORT_STAT.PCS == PCS_CONN)

PORT_CTRL.VB_ON = 1

Figure 5.21:A-Device SRP

Note that the A-Device can not distinguish between connect line states and data line pulsing. Therefore, data linepulsing results in an connect event.

5.7.2 Peripheral SRP

A core working as B-device that supports the SRP, is required to be capable of handling both methods. (Data linepulsingand VBUS pulsing)

If a B-device wants to request a session, it has to verify that the following initial conditions are met:

• VBUS has dropped below session valid threshold: Wait untilPORTSTAT.VBSESSEND = 1

• D+ and D- data lines have been low for at least 2 ms: Wait untilPSCEV.SUSPEV = 1 (will be set after3 ms inactivity, which implicates the required 2 ms)

Figure5.22shows the flow diagram for the B-device working in peripheral mode that detects a turned offVBUS ,and will initiate SRP using data line andVBUS pulsing. If the Session Request fails, the B-device may repeat thesession request.

c©emsys 2003 5-28


Data Line Pulsing

B-Device active

HW controlled timing

V BUS turned off B-Device enters Sleep Mode

Action

Condition

Connected B-device is SRP capable: OTG_Descriptor.wValue.bmAttributes(0) == 1; PSC_EV.PWRSC_EV && PORT_STAT.VB_SESS_VLD = 0

PORT_CTRL.TERM_SEL := TERM_SEL_DEV PORT_CTRL.TERM_ENA := 1

Software requests Session; check initial conditions: PORT_STAT.VB_SESS_END == 1 and PSC_EV.SUSP_EV == 1

PORT_CTRL.P_LEN = T B_DATA_PLS

SW controlled timing

PORT_CTRL.P_LEN := 0x00; Pulse_Length_Timer := T B_DATA_PLS

PSC_EV.P_END_EV && PORT_CTRL.TERM_ENA == 0

Wait for Response

Pulse_Length_Timer elapsed

PORT_CTRL.TERM_ENA := 0;

V BUS Pulsing HW controlled timing SW controlled timing

Response_Timer := T A_SRP_RSPNS_MAX

Response_Timer == 0x00 && PORT_STAT.VB_SESS_VLD == 0 PORT_CTRL.P_LEN := 0x00;

Pulse_Length_Timer := T B_VBUS_PLS

PORT_CTRL.P_LEN := T B_VBUS_PLS

Response_Timer := T A_SRP_RSPNS_MAX

Session Request completed successfully

PSC_EV.P_END_EV && PORT_CTRL.VBS_ON == 0 Pulse_Length_Timer elapsed

PORT_CTRL.VBS_ON := 0

Wait for Response

Session Request failed

PORT_CTRL.TERM_ENA := 0

Response_Timer == 0x00 && PORT_STAT.VB_SESS_VLD == 0

PORT_CTRL.VBS_ON = 1

PORT_STAT.VB_SESS_VLD == 1

PORT_STAT.VB_SESS_VLD == 1 PORT_CTRL.TERM_ENA = 1

Response_Timer == 0x00 && PORT_STAT.VB_SESS_VLD == 1

PORT_CTRL.TERM_ENA := 1

Figure 5.22:B-Device SRP

The timing for data line andVBUS pulsing can be done using either the internal pulse length timer (controlled bythePort Control Register), or a software timer. The diagram5.22uses two timer variables:

Pulse Length Timer Software variable for pulse length timer. Loaded with required pulse length and decre-

c©emsys 2003 5-29


mented during stateSW Controlled Timing.

Response Timer Software variable to determine the session request response timeout. Loaded with max.session request response time.

The timer preset values are defined as:

TB DATA PLS Data-Line pulse time. Must be between 5 and 10 ms.

TB V BUS PLS VBUS pulse time. Depends on drawn current.

TS SRP RSPNS MAX SRP response time. Must be less 5 seconds.

Whereas the timing values forTB DATA PLS andTS SRP RSPNS MAX are defined in the On-The-Go Supple-ment [2], the VBUS pulse time depends on the current drawn duringVBUS pulsing. It must be chosen to meetthe following requirements:

• Charge a capacitance onVBUS that is smaller than 13µF to at least 2.1 V

• Charge a capacitance onVBUS that is more than 97µF not above 2.0 V

Therefore, the OTG Supplement [2] defines the range of an electric charge. The needed charge time must bederived using these given parameters.

5.8 Host Negotiation Protocol Handling

A Dual-role device’s initial role is defined by which end of the cable the user inserts into the mini-AB receptacle.The Dual-role device with the mini-A plug is the initial OTG Host (core is working in host mode), also known asA-Device. The Dual-role device with the mini-B plug is the initial OTG peripheral (core is working in peripheralmode), also known as B-Device. The On-The-Go supplement defines the Host Negotiation Protocol (HNP) thatallows a B-Device to become an host. This eliminates the need for an end-user to swap the Mini-AB cable aroundwhen the roles of the attached Dual Role Devices need to change. The following sections describe the softwarerequirements to support this protocol. Refer [2] for details of HNP handling.

5.8.1 Host HNP

Figure5.23shows the state diagram for the DRD working as an OTG Host that becomes the role of an OTGPeripheral.

c©emsys 2003 5-30


Host-Mode active

Set port into suspended state Wait for disconnect

PORT_CTRL.PSUSP := 1;

PORT_CTRL.VB_ON := 1; PORT_CTRL.TERM_SEL := TERM_SEL_HOST; PORT_CTRL.TERM_ENA := 1; PORT_CTRL.PENA := 1;

Enable HNP Feature at B-Device

Send Request: SET_FEATURE(a_hnp_support) Send Request: SET_FEATURE(b_hnp_enable)

Connect Pullup and wait for USB Reset

PSC_EV.CDC_EV and PORT_STAT.PCS == PCS_DISCONN

Peripheral-Mode active

PORT_CTRL.TERM_SEL := TERM_SEL_DEV;

B-Suspend Disconnect Pullup

Connect Detected Perform USB Reset

PORT_CTRL.URESET := URESET_ACTIVE; wait for T DRST ; PORT_CTRL.URESET := URESET_INACTIVE;

PSC_EV.URES_EV == 1

PSC_EV.SUSP_EV == 1

PORT_CTRL.TERM_SEL = TERM_SEL_HOST;

Session End Wait for SRQ

alternatively turn off Vbus: PORT_CTRL.VB_ON := 0;

Session Request detected

Session Request Handler

PSC_EV.CDC_EV and PORT_STAT.PCS == PCS_CONN

Host Mode

Device Mode

Action

Condition

Request successfully completed

RESET and PORT_STAT.CONN_ID == CONN_ID_A;

PORT_CTRL.PSUSP := 0;

Figure 5.23:A-Device HNP

5.8.2 Peripheral HNP

If a DRD is working initially as OTG Peripheral, it can inform the host about it’s capability to work also as OTGHost using a special descriptor.

Figure5.24shows the state diagram for the DRD working in peripheral mode that becomes the role of an OTGHost.

c©emsys 2003 5-31


Peripheral-Mode active

PSC_EV.SUSP_EV == 1

HNP Feature enabled Wait for suspend

received Request: SET_FEATURE(a_hnp_support) received Request: SET_FEATURE(b_hnp_enable)

Remove Pullup Wait for connect

Connect detected Perform USB Reset

Finish Bus activity

Connect Pullup and wait for USB Reset

received USB reset; receiving USB traffic

PSC_EV.CDC_EV and PORT_STAT.PCS == PCS_CONN

PORT_CTRL.PSUSP := 1

PSC_EV.CDC_EV == 1 PORT_STAT.PCS == PCS_DISCONN

PORT_CTRL.TERM_SEL := TERM_SEL_DEV;

PSC_EV.URES_EV == 1

Host Mode

Device Mode

Action

Condition

PORT_CTRL.TERM_SEL := TERM_SEL_HOST;

Host-Mode active

PORT_CTRL.URESET := URESET_ACTIVE; wait for T DRST ; PORT_CTRL.URESET := URESET_INACTIVE;

Session end

alternatively Vbus can be turned off: PSC_EV.PWRSC_EV and PORT_STAT.VBUS_VLD == 0

Session Request Handler

PORT_STAT.CONN_ID == CONN_ID_B && PORT_STAT.VBUS_VLD == 1;

PORT_CTRL.VB_ON := 1 PORT_CTRL.TERM_SEL := TERM_SEL_DEV PORT_CTRL.TERM_ENA := 1

PORT_CTRL.PSUSP := 0 PORT_CTRL.PSUSP := 0

Figure 5.24:B-Device HNP

c©emsys 2003 5-32

6 Hardware Application Notes

The following sections give an overview on how to configure the core to get the best performance at optimal cost.

6.1 Pipe Count Estimation

TheFHG USBOTGDRD is targeted for the usage in high-performance, low-cost embedded systems to enableUSB functionality with a minimum of software overhead. This is achieved by the implementation of a scalablenumber of hardware resources for USB pipes.

Nevertheless, the effective number of usable pipes is not limited by the hardware resources but requires moresoftware overhead for sharing the pipes. Sharing pipes will also decrease the performance (bandwidth).

The parameterization of the core depends on the dedicated application. The following examples show typicalimplementations and how theNOPparameter can be estimated.

6.1.1 Host Mode

Single Device Examples

Mass Storage Device Support One major field of application is the usage of theFHG USBOTGDRDfor the connection of external mass storage devices to an embedded system. There exist 2 versions of USB massstorage devices:[5]

• Control and Bulk-only implementation

• Control/Bulk/Interrupt (CBI) implementation

Both versions use control transfer for the control data, and bulk transfer for the payload data. These kinds oftransfer are not timing critical, and mostly they will not be active at the same time. It is reasonable to share onehardware pipe for these transfers.

If the connected device supports also interrupt transfer (typically used to inform software about status changes atthe device), it is recommended implement one additional pipe for this periodic transfer.

Human Interface Device Support Typical implementations also require the connection of interfacedevices like keyboard, mouse, joystick or gamepad. Most of these devices require control transfer for the config-uration of the device, and one or more interrupt pipes for the transport of the payload data. Because of the smallamount of payload data, it is reasonable to share one hardware pipe for all tasks.

c©emsys 2003


Complex Device Example

Figure6.1shows an example for a typical, more complex USB tree that is also possible for an embedded system.

External Storage Device USB Keyboard

USB Mouse

USB

USB capable Embedded System

USB Hub

Figure 6.1:Typical USB Topology

Table6.1shows the maximum pipe count required for each connected device. There exist more than one solution,each one having its advantages and disadvantages as summarized in Table6.2.

USB Device Control TransferPipes

Interrupt TransferPipes

Bulk TransferPipes

USB Hub 1 1 -USB Keyboard 1 1 -USB Mouse 1 1 -USB Mass Storage Device 1 1 1

ALL 4 4 1

Table 6.1: Required Pipe Summary

c©emsys 2003 6-2


NOP Description Advantages Disadvantages

9 All pipe resourcesare available in hard-ware.

Easy to handle for software part.Highest Performance.

Highest gate count. Cost of areaon silicon.

6 All control pipes areshared.

Less gate count. Well balancedsoftware/hardware partitioning.

Sharing algorithm for controlpipes must be implemented insoftware

3 All control pipes areshared and all inter-rupt pipes are shared

Small gate count. Sharing algorithm for controland interrupt pipes required insoftware.

1 All pipes are shared Smallest gate count. Very complex pipe sharing algo-rithm must be implemented insoftware. Possibility of loss ofperformance. (insufficient band-width usage)

Table 6.2: Comparison of Pipe Parametrization Cases

6.1.2 Device Mode

The estimation of the pipe count simply depends on the kind of application the core is used for, and the requireddata channels.

Every USB Device must support the bi-directional Control Endpoint 0. TheFHG USBOTGDRD uses pipe 0for this endpoint.

It must be taken into account, that a device can have more than one Interfaces (Composite Device), and each In-terface itself consists of a collection of endpoints. Foreveryendpoint that belongs to a Configuration Descriptorof a device, one pipe resource must be supplied for the core.

For an example application with 2 interfaces, the required NOP value could be

NOP = NOP INTERFACE 1 + NOP INTERFACE 2 + CTRL EP0 = 2 + 1 + 1 = 4

with

NOP INTERFACE 1 = 2 Interface 1 described by Interface Descriptor 1 contains 2 Endpoints

NOP INTERFACE 2 = 1 Interface 2 described by Interface Descriptor 2 contains 2 Endpoints

CTRL EP0 = 1 The device that consists of 2 interfaces will be configured via 1 bi-directional control endpoint.

6.2 USB Transceiver Connection

Figure6.2 shows an example how the transceiver interface can be connected to the Philips USB TransceiverPDIUSBP11/PDIUSBP11A.[7]

In this example, the single ended output pinsser tx dmandser tx dp are used. If the PDIUSBP11A is used, theMODE input may be left unconnected, and the transceiver is backward compatible to PDIUSBP11.

c©emsys 2003 6-3


The Philips transceiver PDIUSBP11A supports a single-ended data interface in conjunction with a special FSE0-Input. An example using this version is shown in Figure6.3.

PDIUSBP11/ PDIUSBP11A

VMO/FSE0

VPO

OE#

VM

VP

RCV

ser_tx_dm

ser_tx_dp

ser_rx_dm

ser_rx_dm

ser_txen_n

ser_tx_se0

ser_rx_rcv

SPEED xcvr_speed

D+

D-

FHG_Core

Figure 6.2:Connection to PDIUSBP11

PDIUSBP11A

VMO/FSE0

VPO

OE#

VM

VP

RCV

ser_tx_dm

ser_tx_dp

ser_rx_dm

ser_rx_dm

ser_txen_n

ser_tx_se0

ser_rx_rcv

SPEED xcvr_speed

D+

D-

FHG_Core

MODE

Figure 6.3:Connection to PDIUSBP11A using the single ended interface

To meet all electrical requirements for OTG, this circuit must be extended by some additional analog hardware,described in Section6.4.

6.3 Core Suspend

It is possible to set theFHG USBOTGDRD and/or the connected USB transceiver into low-power mode usingthe dedicated bits of theUSB Control Register.

c©emsys 2003 6-4


Setting these bits forces the signalscore suspend n/xcvr suspend n going low. These signals can beused to set the connected transceiver and the core to low power mode. If these signals are active, it is assumedthat the core will have no clock, and the input signals indicating the USB line state are combinationally applied tothe core. The core stores the last line state into registers, and uses the contents of these registers together with theapplied line state to derive combinatinally a wake-up state. If the applied line state changes, both output signalscore suspend n/xcvr suspend n will return to one. This must trigger the connected clock managementunit to supply the clock to the core immediately.

6.4 OTG Electrical Issues

A part of the OTG Supplement [2] to the USB 2.0 Specification [1] is the definition of theSession RequestProtocol(SRP), whose implementation requires some additional analog circuitry. This section shows an exampleimplementation to support the SRP.

It is assumed that the reader is familiar with basic USB electrical requirements. A good introduction to the OTGSupplement is the article “Understanding USB On-The-Go” [8].

6.4.1 Session Request Protocol

According the OTG Supplement, any USB device or USB host can support the SRP. Dual-role devices arerequired to respond and to initiate SRP.

The electrical requirements for B-Devices to support SRP are:

• Detect, wheatherVBUS > 0.8V (session valid)

– B-Devices have to detect, whetherVBUS falls belowVB SESS V LD. According to the OTG Sup-plement,VB SESS V LD threshold has a range from0.8V to 4.0V .

– B-Devices have to detect, whetherVBUS falls belowVB SESS END. According to the OTG Sup-plement,VB SESS END has a threshold range of0.2V to 0.8V .

• Timed data-line pulsing. This requires the ability to switch on/off the pull-up resistor.

• Timed charge ofVBUS

• Optional, ability to dischargeVBUS

• Supply power forRPU also whenVBUS is not provided by the A-Device (for data-line pulsing)

Electrical requirements for A-Devices to support SRP:

• Detect, wheatherVBUS > 0.8V is true.

– Required to detectVBUS-pulsing.

– Because an A-Device can support either data-line orVBUS-pulsing, this feature is optional.

• Over-current detection and protection.

– An unconfigured B-Device must not consume more than 8 mA.

– The A-Device must detect such an failure condition. This can be done by current measurement, orindirectly by checking thatVBUS falls belowVBUS V ALID = 4.4V

• SwitchVBUS on/off

c©emsys 2003 6-5


6.4.2 Implementation Example for SRP Support

The examples described below show how to realize the analog parts for SRP support in principle.

All digital logic to control the OTG features is already included in theFHG USBOTGDRDand can be controlledby dedicated registers. In the same way, software can get information about bus-power status changes. (refer thePort Status RegisterandPort Control Register).

The threshold events can be processed by the hardware. The core defines output signals and hardware timer forcontrolling theVBUS and data-line pulsing. The core also allows to select and switch all pull up/down resistors.

The required analog circuit to support SRPVBUS-pulsing can be implemented in principle as shown in Figure6.4.

+ - >3.0V

Timer

V bus

discharge controlled by signal < discharge_ena >

signal < vbs_on >

>281Ohm

>656 Ohm

Hardware-Timer controlled by PORT_CTRL.P_LEN

Figure 6.4:VBUS Pulsing Analog Part

The analog circuit to detectVBUS V ALID, VB SESS V LD, VA SESS V LD andVB SESS END conditions:

c©emsys 2003 6-6


+ -

0.8..4.0 V

V BUS +

-

+

-

+ -

4.4..4.75 V

input signal < vbus_vld >

input signal < vb_sess_vld >

+ - 0.8..2.0 V

+

- input signal <v a_sess_vld >

+ -

0.8..0.2 V

+

- input signal <vb _sess_end >

Figure 6.5:VBUS Threshold Detection

c©emsys 2003 6-7


Controlled by output signal < rpd_ena >

D+

D-

USB Transceiver

signal < rpu_ena >

V DEVICE 3.0-3.6V Voltage Regulator

3.0-3.6V 4.4-5.25V V BUS

Controlled by output signal < dlp_active >

1.5kOhm +-5%

15kOhm +-5%

15kOhm +-5%

Timer

Hardware-Timer controlled by PORT_CTRL.P_LEN

Figure 6.6:Data-Line Pulsing

The Figure above shows also the pull-up/down resistors, as required by the USB Specification for host or functiondevices.

6.5 System Integration

6.5.1 Data Interface System Integration

This Chapter describes how theFHG USBOTGDRD core can be adapted to a wide range of system concepts.The physical data interface of theFHG USBOTGDRD core can be connected to a backbone bus, like PCI orAMBA AHB .

Any transfer either to the Dual Port RAM or to theRegister Interfaceis initiated by software. This requires, thatthe data to be sent through USB must be copied to the RAM module before the transaction can start. On theother side, the received data has to be read from the software after the USB transaction is completed. Figure6.7shows the architecture for this implementation.

c©emsys 2003 6-8


Reg

iste

r In

terf

ace

US

B Transceiver Interface

USB udata_in

uint_n

ucif_rdy

ucs_n

urd_n

uwr_n

uaddr

udata_out

Dual Port RAM P

ort A

Por

t B

cs

we

di

do

addr

cs

we

di

do

addr

clk clk

RA

M S

lave Interface

Bac

kbon

e S

lave

Inte

rfac

e P

CI o

r A

HB

Register S

lave Interface

DMA Slave Interface Adapter (PCI/AHB)

udata_out

uint_n

ucif_rdy

ucs_n

urd_n

uwr_n

uaddr

udata_in

slave PCI slave AHB D

ual P

ort R

AM

In

terf

ace ram_din

ram_clk

ram_we

ram_en

ram_addr

ram_dout

FHG_Core

Figure 6.7:Using theFHG USBOTGDRD core with Bi-directional Dual-Port RAM

6.5.2 Implementation Example

The previous Section has shown how the core can be implemented concerning the data interface.

This section shows how the signals/parameters defined in the Parameter/Configuration Section (refer to Section2.1) must be set for a given example configuration.

The following requirements are assumed for this example:

The core will be controlled by an 32 bit ARM CPU running at 100 MHz via an 32 bit AHB Slave interface. Thedual port RAM size is limited to 2kByte.

If working in device mode, the target USB application will be a Mass Storage Device, which has one ControlEndpoint, one data endpoint for each direction, and one interrupt endpoint for signaling status changes. The dataendpoints should support alternative buffers. The pipe - endpoint mapping is as follows:

• Pipe 0: Control Endpoint EP0, no alternative data buffer

• Pipe 1: IN EP1, transmit data pipe with alternative data buffer

• Pipe 2: OUT EP1, receive data pipe with alternative data buffer

• Pipe 3: IN EP2, interrupt pipe, no alternative data buffer

If working in host mode, the target application should be able to connect to a Digital Camera, that works as aMass Storage Device, and to download images at the flash to the Mass Storage Device. For that case, the samepipe - endpoint mapping can be used as in device mode to communicate with the connected camera.

None of the debug capability specified by the Debug Registers is required. (Refer to theDebug Register Group)

With this configuration, the core should be instantiated as follows:

u_fhg_usb_otgdrd : fhg_usb_otgdrdGENERIC MAP (

-- EP0 + EP1 (Data IN) + EP1 (Data OUT) + EP2 (Interrupt)NOP => 4,

c©emsys 2003 6-9


-- 32 bit ARMDW => 32,-- Core can access a 4kByteRAW => 11

)PORT MAP (

---- Configuration Interfacedbg_support => ’0’, -- not requiredxtd_dbg_support => ’0’, -- not requiredalt_buff_support => "0110",-- only data pipes--...

)

c©emsys 2003 6-10

A Symbol Index

Label Name Coding

CONN ID A b0CONN ID B b1DBSEL ALTERNATE b1DBSEL NORMAL b0DT DATA0 b0DT DATA1 b1EPSFULL b0EPSLOW b1ET BULK b10ET CTRL b00ET INT b11ET ISO b01PCSCONN b1PCSDISCONN b0PTESTCDIS b00PTESTCJST b01PTESTCKST b10PTESTCSE0 b11TERM SEL DEV b1TERM SEL HOST b0TPID IN b01TPID OUT b00TPID SETUP b10URESETACTIVE b1URESETINACTIVE b0

Table A.1: Label Index

c©emsys 2003

ASym

bolIndex

Table A.2: Bit/Field Index 1 of 3 (Sorted by Name)Reset

Field Name Path Width AccessValue

Description

ABUFF CFG CONFIG/ MODE CFG NOP r 0x00 Alternative Buffer ConfigurationACID PIPE/ PIPECFG 1 rw 0x0 Accept corrupted ISO DataACT PIPE/ PIPECTRL 1 rw 0x0 Activate PipeACTS PIPE/ PIPESTAT 1 r 0x0 Active StatusADBV PIPE/ PIPEADATA TBYTES 1 rw 0x0 Alternative Data Buffer ValidADPTR PIPE/ PIPEADATA PTR RAW rw 0x00 Alternative Data PointerAGSOF COMMON / FRM TIMER 1 r 0x0 Artificially Generated SOFASE COMMON / USB CTRL 1 rw 0x0 Async Schedule EnableATBYTES PIPE/ PIPEADATA TBYTES TBW rw 0x00 Alternative Total Bytes To TransferBBL PIPE/ PIPESTAT 1 r 0x0 Babble detectedBERR EM PORT/ PSCEM 1 rw 0x0 Babble Error Event MaskBERR EV PORT/ PSCEV 1 cow 0x0 Babble Error EventBWERR EM EVENT / MAIN EM 1 rw 0x0 Bandwidth Error Event MaskBWERR EV EVENT / MAIN EV 1 cow 0x0 Bandwidth Error EventCDC EM PORT/ PSCEM 1 rw 0x0 Connect/Disconnect Event MaskCDC EV PORT/ PSCEV 1 cow 0x0 Connect/Disconnect EventCERR PIPE/ PIPESTAT 2 r 0x3 Error CounterCONN ID PORT/ PORTSTAT 1 r 0x0 USB Connector ID ValueCOREID COMMON / ID 5 r 0x7 Core-IDCSUSP COMMON / USB CTRL 1 rw 0x0 Core SuspendDBERR PIPE/ PIPESTAT 1 r 0x0 Data Buffer ErrorDBG CFG CONFIG/ MODE CFG 1 r 0x0 Debug ConfigurationDBOFF PIPE/ PIPESTAT 2 rw 0x0 Data Byte OffsetDBSEL PIPE/ PIPESTAT 1 rw 0x0 Selected Data BufferDBSERRDET DEBUG/ DEBUG CTRL 1 rw 0x0 Disable Bitstuff Error DetectionDBSTX DEBUG/ DEBUG CTRL 1 rw 0x0 Disable Bitstuffing TransmitDBV PIPE/ PIPEDATA TBYTES 1 rw 0x0 Data Buffer ValidDCHRG PORT/ PORTCTRL 1 rw 0x0 Enable Discharge CircuitryDDPID DEBUG/ DEBUG PID 8 rw 0x00 Debug Data PIDDHSPID DEBUG/ DEBUG PID 8 rw 0x00 Debug Handshake PIDDLS PORT/ PORTSTAT 1 r 0x0 Device Low SpeedDPTR PIPE/ PIPEDATA PTR RAW rw 0x00 Data PointerDRXPID DEBUG/ DEBUG STAT 8 r 0x00 Debug Receive PIDDT PIPE/ PIPESTAT 1 rw 0x0 Data ToggleDTPID DEBUG/ DEBUG PID 8 rw 0x00 Debug Token PIDDW CFG CONFIG/ MAIN CFG 6 r DW Data Width ConfigurationEPADDR PIPE/ PIPEADDR 7 rw 0x00 Endpoint AddressEPNR PIPE/ PIPEADDR 4 rw 0x0 Endpoint NumberEPS PIPE/ PIPECFG 1 rw 0x0 Endpoint SpeedET PIPE/ PIPECFG 2 rw 0x0 Endpoint Type

c©em

sys2003

A-2

ASym

bolIndex



Description

FPRESU PORT/ PORTCTRL 1 rw 0x0 Force ResumeFRAME NR COMMON / FRM TIMER 11 rw 0x000 Current Frame NumberFRM32 EM EVENT / MAIN EM 1 rw 0x0 Frame 32 Event MaskFRM32 EV EVENT / MAIN EV 1 cow 0x0 Frame 32 EventFRM EM EVENT / MAIN EM 1 rw 0x0 Frame Event MaskFRM EV EVENT / MAIN EV 1 cow 0x0 Frame EventFRXCRC16G DEBUG/ DEBUG CTRL 1 rw 0x0 Force Receive Good CRC16FRXCRC5G DEBUG/ DEBUG CTRL 1 rw 0x0 Force Receive Good CRC5FRXCRCE DEBUG/ DEBUG CTRL 1 rw 0x0 Force Receive CRC ErrorFTLOCK COMMON / FRM TIMER 1 r 0x0 Frame Timer LockedFTXCRC16E DEBUG/ DEBUG CTRL 1 rw 0x0 Force Transmit CRC16 ErrorFTXCRC5E DEBUG/ DEBUG CTRL 1 rw 0x0 Force Transmit CRC5 ErrorGPIPEEM EVENT / MAIN EM 1 rw 0x0 Global Pipe Event MaskGPIPEEV EVENT / MAIN EV 1 r 0x0 Global Pipe Transfer EventGPORTEM EVENT / MAIN EM 1 rw 0x0 Global Port Status Change Event MaskGPORTEV EVENT / MAIN EV 1 r 0x0 Global Port Status Change EventHALT PIPE/ PIPESTAT 1 r 0x0 Pipe HaltedHCHA EM EVENT / MAIN EM 1 rw 0x0 HC Halted MaskHCHA EV EVENT / MAIN EV 1 cow 0x0 Host Controller Halted EventHIDBE PIPE/ PIPECFG 1 rw 0x0 Halt on ISO Data Buffer ErrorHRS COMMON / USB CTRL 1 rw 0x0 Host Run/StopID PU PORT/ PORTCTRL 1 rw 0x0 ID-Pullup EnableIOT PIPE/ PIPECFG 1 rw 0x0 Interrupt on Transaction.LINESTATE PORT/ PORTSTAT 2 r 0x0 USB Line StateMPS PIPE/ PIPECFG 10 rw 0x000 Maximum Packet SizeNOP CFG CONFIG/ MAIN CFG 6 r NOP Number of Pipes ConfigurationOCU EM PORT/ PSCEM 1 rw 0x0 Over Current Event MaskOCU EV PORT/ PSCEV 1 cow 0x0 Over Current EventOCURC PORT/ PORTSTAT 1 r 0x0 Over Current ConditionP END EM PORT/ PSCEM 1 rw 0x0 Pulse End Event MaskP END EV PORT/ PSCEV 1 cow 0x0 Pulse End EventP LEN PORT/ PORTCTRL 8 rw 0x00 Pulse LengthPCS PORT/ PORTSTAT 1 r 0x0 Port Connect StatusPENA PORT/ PORTCTRL 1 rw 0x0 Port EnablePI PIPE/ PIPECFG 4 rw 0x0 Polling IntervallPI EM EVENT / PIPEEM NOP rw 0x0000 Pipe Event MaskPI EV EVENT / PIPEEV NOP cow 0x0000 Pipe EventPI SEL PAGE/ PIPESEL 5 rw 0x00 Pipe SelectPOFF PIPE/ PIPECFG 8 rw 0x00 Polling OffsetPSE COMMON / USB CTRL 1 rw 0x0 Periodic Schedule Enable

c©em

sys2003

A-3

ASym

bolIndex



Description

PSUSP PORT/ PORTCTRL 1 rw 0x0 Port SuspendPTESTC PORT/ PORTCTRL 2 rw 0x0 Port Test ControlPWRSCEM PORT/ PSCEM 1 rw 0x0 Power Status Change Event MaskPWRSCEV PORT/ PSCEV 1 cow 0x0 Power Status Change EventRAW CFG CONFIG/ MAIN CFG 6 r RAW RAM Address Width ConfigurationREV ID COMMON / ID 8 r 0x00 Revision IDRSU EM PORT/ PSCEM 1 rw 0x0 Resume Event MaskRSU EV PORT/ PSCEV 1 cow 0x0 Resume EventRSUCEM PORT/ PSCEM 1 rw 0x0 Resume Complete Event MaskRSUCEV PORT/ PSCEV 1 cow 0x0 Resume Complete EventRW32 DEBUG/ TEST 32 rw

0x5AF8CAFERead Write 32

SKIPISO PIPE/ PIPECFG 1 rw 0x0 Skip ISO TokenSTALL PIPE/ PIPECFG 1 rw 0x0 Stall PipeSTRM PIPE/ PIPECFG 1 rw 0x0 Streaming ModeSUSPEM PORT/ PSCEM 1 rw 0x0 Suspend Event MaskSUSPEV PORT/ PSCEV 1 cow 0x0 Suspend EventTBYTES PIPE/ PIPEDATA TBYTES TBW rw 0x00 Total Bytes To TransferTERM ENA PORT/ PORTCTRL 1 rw 0x0 Termination EnableTERM SEL PORT/ PORTCTRL 1 rw 0x0 Termination SelectTPID PIPE/ PIPECTRL 2 rw 0x0 Token PID/DirectionUDDPID DEBUG/ DEBUG CTRL 1 rw 0x0 Use Debug Data PIDUDHSPID DEBUG/ DEBUG CTRL 1 rw 0x0 Use Debug Handshake PIDUDTPID DEBUG/ DEBUG CTRL 1 rw 0x0 Use Debug Token PIDURESEM PORT/ PSCEM 1 rw 0x0 USB Reset Event MaskURESEV PORT/ PSCEV 1 cow 0x0 USB Reset EventURESET PORT/ PORTCTRL 1 rw 0x0 USB ResetVA SESSVLD PORT/ PORTSTAT 1 r 0x0 VA Session ValidVB ON PORT/ PORTCTRL 1 rw 0x0 VBUS ControlVB SESSEND PORT/ PORTSTAT 1 r 0x1 VB Session EndVB SESSVLD PORT/ PORTSTAT 1 r 0x0 VB Session ValidVBS ON PORT/ PORTCTRL 1 rw 0x0 VBUS Session Request ControlVBUS VLD PORT/ PORTSTAT 1 r 0x0 Vbus ValidXDBG CFG CONFIG/ MODE CFG 1 r 0x0 Extended Debug ConfigurationXSUSP COMMON / USB CTRL 1 rw 0x0 XCVR Suspend

c©em

sys2003

A-4

ASym

bolIndex

Table A.5: Register Index 1 of 4 (Sorted by Register Address)Register Bitfield

Name Address Description Name Bit Description

ID 0x00 ID COREID 12 : 8 Core-IDREV ID 7 : 0 Revision ID

USB CTRL 0x04 USB Control PSE 4 Periodic Schedule EnableASE 3 Async Schedule EnableHRS 2 Host Run/StopXSUSP 1 XCVR SuspendCSUSP 0 Core Suspend

FRM TIMER 0x08 Frame Timer AGSOF 12 Artificially Generated SOFFTLOCK 11 Frame Timer LockedFRAME NR 10 : 0 Current Frame Number

MAIN EV 0x0C Main Event BWERR EV 5 Bandwidth Error EventHCHA EV 4 Host Controller Halted EventGPIPEEV 3 Global Pipe Transfer EventGPORTEV 2 Global Port Status Change EventFRM32 EV 1 Frame 32 EventFRM EV 0 Frame Event

MAIN EM 0x10 Main Event Mask BWERR EM 5 Bandwidth Error Event MaskHCHA EM 4 HC Halted MaskGPIPEEM 3 Global Pipe Event MaskGPORTEM 2 Global Port Status Change Event MaskFRM32 EM 1 Frame 32 Event MaskFRM EM 0 Frame Event Mask

PIPEEV 0x14 Pipe Event PI EV NOP-1: 0 Pipe EventPIPEEM 0x18 Pipe Event Mask PI EM NOP-1: 0 Pipe Event MaskPIPESEL 0x24 Pipe Select PI SEL 4 : 0 Pipe SelectPORTSTAT 0x2C Port Status LINESTATE 9 : 8 USB Line State

OCURC 7 Over Current ConditionDLS 6 Device Low SpeedPCS 5 Port Connect StatusCONN ID 4 USB Connector ID ValueVB SESSEND 3 VB Session EndVB SESSVLD 2 VB Session ValidVA SESSVLD 1 VA Session ValidVBUS VLD 0 Vbus Valid

c©em

sys2003

A-5

ASym

bolIndexTable A.6: Register Index 2 of 4 (Sorted by Register Address)Register Bitfield


PORTCTRL 0x30 Port Control P LEN 23 : 16 Pulse LengthID PU 12 ID-Pullup EnableVBS ON 10 VBUS Session Request ControlDCHRG 9 Enable Discharge CircuitryTERM ENA 8 Termination EnableTERM SEL 7 Termination SelectVB ON 6 VBUS ControlPSUSP 5 Port SuspendPENA 4 Port EnableFPRESU 3 Force ResumeURESET 2 USB ResetPTESTC 1 : 0 Port Test Control

PSCEV 0x34 Port Status Change Event P END EV 8 Pulse End EventPWRSCEV 7 Power Status Change EventCDC EV 6 Connect/Disconnect EventURESEV 5 USB Reset EventSUSPEV 4 Suspend EventRSUCEV 3 Resume Complete EventRSU EV 2 Resume EventBERR EV 1 Babble Error EventOCU EV 0 Over Current Event

PSCEM 0x38 Port Status Change Event Mask P END EM 8 Pulse End Event MaskPWRSCEM 7 Power Status Change Event MaskCDC EM 6 Connect/Disconnect Event MaskURESEM 5 USB Reset Event MaskSUSPEM 4 Suspend Event MaskRSUCEM 3 Resume Complete Event MaskRSU EM 2 Resume Event MaskBERR EM 1 Babble Error Event MaskOCU EM 0 Over Current Event Mask

PIPECTRL 0x40 Pipe Control ACT 2 Activate PipeTPID 1 : 0 Token PID/Direction

c©em

sys2003

A-6

ASym

bolIndex



PIPECFG 0x44 Pipe Configuration IOT 30 Interrupt on Transaction.HIDBE 29 Halt on ISO Data Buffer ErrorSKIPISO 28 Skip ISO TokenPI 27 : 24 Polling IntervallPOFF 23 : 16 Polling OffsetSTALL 15 Stall PipeACID 14 Accept corrupted ISO DataEPS 13 Endpoint SpeedSTRM 12 Streaming ModeET 11 : 10 Endpoint TypeMPS 9 : 0 Maximum Packet Size

PIPEADDR 0x48 Pipe Address EPADDR 10 : 4 Endpoint AddressEPNR 3 : 0 Endpoint Number

PIPESTAT 0x4C Pipe Status CERR 9 : 8 Error CounterDBERR 7 Data Buffer ErrorACTS 6 Active StatusHALT 5 Pipe HaltedBBL 4 Babble detectedDBSEL 3 Selected Data BufferDT 2 Data ToggleDBOFF 1 : 0 Data Byte Offset

PIPEDATA PTR 0x50 Pipe Data Pointer DPTR RAW-1: 0 Data PointerPIPEDATA TBYTES 0x54 Pipe Total Bytes DBV 31 Data Buffer Valid

TBYTES TBW-1: 0 Total Bytes To TransferPIPEADATA PTR 0x58 Pipe Alternative Data Pointer ADPTR RAW-1: 0 Alternative Data PointerPIPEADATA TBYTES 0x5C Pipe Alternative Data Total Bytes ADBV 31 Alternative Data Buffer Valid

ATBYTES TBW-1: 0 Alternative Total Bytes To TransferDEBUG CTRL 0x60 Debug Control UDTPID 9 Use Debug Token PID

UDHSPID 8 Use Debug Handshake PIDUDDPID 7 Use Debug Data PIDFRXCRC16G 6 Force Receive Good CRC16FRXCRC5G 5 Force Receive Good CRC5FRXCRCE 4 Force Receive CRC ErrorFTXCRC16E 3 Force Transmit CRC16 ErrorFTXCRC5E 2 Force Transmit CRC5 ErrorDBSTX 1 Disable Bitstuffing TransmitDBSERRDET 0 Disable Bitstuff Error Detection

DEBUG PID 0x64 Debug PID DHSPID 23 : 16 Debug Handshake PIDDTPID 15 : 8 Debug Token PIDDDPID 7 : 0 Debug Data PID

DEBUG STAT 0x68 Debug Status DRXPID 7 : 0 Debug Receive PID

c©em

sys2003

A-7

ASym

bolIndex



TEST 0x6C Test RW32 31 : 0 Read Write 32MAIN CFG 0x80 Main Configuration RAW CFG 29 : 24 RAM Address Width Configuration

DW CFG 11 : 6 Data Width ConfigurationNOP CFG 5 : 0 Number of Pipes Configuration

MODE CFG 0x84 Mode Configuration XDBG CFG 17 Extended Debug ConfigurationDBG CFG 16 Debug ConfigurationABUFF CFG NOP-1: 0 Alternative Buffer Configuration

c©em

sys2003

A-8

B Glossary

ACK Handshake packet indicating a positive acknowledgement.

Babble Unexpected bus activity that persists beyond a specified point in a (micro)frame.

Bit Stuffing Insertion of a ’0’ bit into a data stream to cause an electrical transition on the data wires, allowinga PLL to remain locked.

Bulk Transfer One of the four transfer types. Bulk transfers are non-periodic, large bursty communicationtypically used for a transfer that can use any available bandwidth and can also be delayed until bandwidthis available. See also Transfer Type.

Control Endpoint A pair of device endpoints with the same endpoint number that are used by a control pipe.Control endpoints transfer data in both directions and, therefore, use both endpoint directions of a deviceaddress and endpoint number combination. Thus, each control endpoint consumes two endpoint addresses.

Control Transfer One of the four USB transfer types. Control transfers support configuration/command/statustype communications between client and function. See also Transfer Type.

CRC Cyclic Redundancy Check: A check performed on data to see if an error has occurred in transmitting,reading, or writing the data. The result of a CRC is typically stored or transmitted with the checked data.The stored or transmitted result is compared to a CRC calculated for the data to determine if an error hasoccurred.

Device A logical or physical entity that performs a function. The actual entity described depends on the contextof the reference. At the lowest level, device may refer to a single hardware component, as in a memorydevice. At a higher level, it may refer to a collection of hardware components that perform a particularfunction, such as a USB interface device. At an even higher level, device may refer to the functionperformed by an entity attached to the USB; for example, a data/FAX modem device. Devices may bephysical, electrical, addressable, and logical. When used as a non-specific reference, a USB device iseither a hub or a function.

Device Address A seven-bit value representing the address of a device on the USB. The device address is thedefault address (0x00) when the USB device is first powered or the device is reset. Devices are assigneda unique device address by the USB System Software.

Downstream The direction of data flow from the host or away from the host. A downstream port is the port ona hub electrically farthest from the host that generates downstream data traffic from the hub. Downstreamports receive upstream data traffic.

Endpoint A uniquely addressable portion of a USB device that is the source or sink of information in a com-munication flow between the host and device.

Endpoint Address The combination of an endpoint number and an endpoint direction on a USB device. Eachendpoint address supports data transfer in one direction.

Endpoint Number A four-bit value between 0x0 and 0xF, inclusive, associated with an endpoint on a USBdevice.

Enumeration Detecting, identifying and configuring USB devices.

c©emsys 2003

B Glossary

EOF End-of-(micro)Frame

EOP End-of-Packet

Frame A 1 millisecond time base established on full-/low-speed buses.

Full Speed USB operation at 12 Mb/s. See also low-speed and high-speed.

Function A USB device that provides a capability to the host, such as an ISDN connection, a digital micro-phone, or speakers.

High Bandwidth Endpoint A high-speed device endpoint that transfers more than 1024 bytes and less than3073 bytes per microframe.

High Speed USB operation at 480 Mb/s. See also low-speed and full-speed.

Host The host computer system where the USB Host Controller is installed. This includes the host hardwareplatform (CPU, bus, etc.) and the operating system in use.

Hub A USB device that provides additional connections to the USB.

Interrupt Transfer One of the four USB transfer types. Interrupt transfer characteristics are small data, non-periodic, low frequency, and bounded-latency. Interrupt transfers are typically used to handle serviceneeds. See also Transfer Type.

Isochronous Transfer One of the four USB transfer types. Isochronous transfers are used when workingwith isochronous data. Isochronous transfers provide periodic, continuous communication between hostand device. See also transfer type.

Little Endian Method of storing data that places the least significant byte of multiple byte values at lowerstorage addresses.

Low Speed USB operation at 1.5 Mb/s. See also high-speed and full-speed.

NAK Handshake packet indicating a negative acknowledgment. (Device is busy)

NYET Handshake packet indicating that the endpoint accepted the data but does not have room for another.

Non Return to Zero Invert (NRZI) A method of encoding serial data in which ones and zeroes are repre-sented by opposite and alternating high and low voltages where there is no return to zero (reference)voltage between encoded bits. Eliminates the need for clock pulses.

PID Packet ID. A field in a USB packet that indicates the type of packet, and by inference, the format of thepacket and the type of error detection applied to the packet.

Pipe A logical abstraction representing the association between an endpoint on al device and software on thehost.

Polling Asking multiple devices, one at a time, if they have any data to transmit.

Request A request made to a USB device contained within the data portion of a SETUP packet.

Resume Resume signaling is used by the host or a device to bring a suspended bus segment back to the activecondition.

Root Hub A USB hub directly attached to the Host Controller. This hub (tier 1) is attached to the host.

Single Ended Zero (SE0) This state exists on the bus, if both data lines D+ and D- are driven with a zero.

SOF Start-of-Frame: The first transaction in each (micro)frame. An SOF allows endpoints to identify the startof the (micro)frame and synchronize internal endpoint clocks to the host.

Split Transaction A transaction type supported by host controllers and hubs. This transaction type allowsfull- and low-speed devices to be attached to hubs operating at high-speed.

c©emsys 2003 B-2

B Glossary

Stage One part of the sequence composing a control transfer; stages include the Setup stage, the Data stage,and the Status stage.

STALL Handshake packet indicates that the function is unable to transmit or receive data, or that a control piperequest is not supported.

Suspend Describes a low power device state.

Termination Passive components attached at the end of cables to prevent signals from being reflected orechoed.

Timeout The detection of a lack of bus activity for some predetermined interval.

Token Packet A type of packet that identivies what transaction is to be performed on the bus.

Transfer Type Determines the characteristics of the data flow between a software client and its function. Fourtransfer types are defined: control, interrupt, bulk and isochronous.

Upstream The direction of data flow towards the host. An upstream port is the port on a device electricallyclosest to the host that generates upstream data traffic from the hub. Upstream ports receive downstreamdata traffic.

USB Reset A device seeing an SE0 on its upstream port for more than 2.5µs may treat that signal as an USBReset.

c©emsys 2003 2-3

Embedded USB 2.0 OTG Full-/Low-Speed Dual-Role Core FHG...

Documents

Transcript of Embedded USB 2.0 OTG Full-/Low-Speed Dual-Role Core FHG...