usb 2.0 device · 3、packet assembly this block assembles packets and places them in to the output...

USB 2.0 Device

User Guide

03/2014

Capital Microelectronics, Inc.

China

User Guide of USB2.0 Device IP

http://www.capital-micro.com 2

Contents

Contents ..................................................................................................................................................2

1 Introduction ......................................................................................................................................4

2 USB 2.0 Device IP Overview ...............................................................................................................5

2.1 USB 2.0 Device IP Block Diagram .......................................................................................................... 5

2.1.1 Overview ....................................................................................................................................... 5

2.1.2 Protocol Layer ............................................................................................................................... 5

2.1.3 Control Registers .......................................................................................................................... 6

2.1.4 FIFO Control with receive and transmit FIFO ............................................................................... 6

2.1.5 UTMI / ULPI Interface ................................................................................................................... 6

2.1.6 Wishbone Bus............................................................................................................................... 7

2.1.7 EMIF/AHB to wishbone transform ................................................................................................ 8

2.1.8 Local memory ............................................................................................................................... 8

2.2 Pin Description ..................................................................................................................................... 8

2.3 UTMI/ULPI interface Introduction ...................................................................................................... 11

2.3.1 UTMI ........................................................................................................................................... 11

2.3.2 ULPI............................................................................................................................................. 11

2.4 USB Core registers .............................................................................................................................. 12

2.4.1 Register Map .............................................................................................................................. 12

2.4.2 Register Description ................................................................................................................... 13

3 USB2.0 Device IP Usage .................................................................................................................... 21

3.1 USB data transfer overview ................................................................................................................ 21

3.2 USB control transfer ........................................................................................................................... 22

3.3 USB bulk transfer ................................................................................................................................ 23

3.4 USB isochronous transfer ................................................................................................................... 24

3.5 USB interrupt transfer ........................................................................................................................ 25

3.6 USB IP standard/vendor device request handler flow ....................................................................... 26

3.7 USB IP data transfer flow .................................................................................................................... 28

3.8 USB device enumerate flow ............................................................................................................... 30

3.9 USB IP Data Organization.................................................................................................................... 32

3.10 USB Core Process Flow ....................................................................................................................... 33

3.10.1 Special Token Processing ............................................................................................................ 33

3.10.2 IN Data Cycle .............................................................................................................................. 34

3.10.3 OUT Data Cycle ........................................................................................................................... 34

3.10.4 USB Device Control Processing ................................................................................................... 35

3.10.5 Interrupt ..................................................................................................................................... 37

3.11 EMIF/AHB to Wishbone ...................................................................................................................... 37

3.11.1 EMIF to Wishbone ...................................................................................................................... 37



3.11.2 AHB to Wishbone ....................................................................................................................... 38

3.12 Local memory interface and handshake interface ............................................................................. 39

3.12.1 Receive a packet ......................................................................................................................... 39

3.12.2 Send a Packet .............................................................................................................................. 39

3.13 Clocking and reset .............................................................................................................................. 40

3.14 External memory interface (EMIF) operation ..................................................................................... 41

3.14.1 EMIF Interface timing ................................................................................................................. 41

3.14.2 EMIF data bank operation .......................................................................................................... 41

3.15 AHB operation .................................................................................................................................... 43

3.15.1 AHB Interface timing .................................................................................................................. 43

3.15.2 AHB address mapping................................................................................................................. 43

3.16 Interrupt operation ............................................................................................................................ 44

3.16.1 8051 external interrupt sources ................................................................................................. 44

3.16.2 ARM external interrupt sources ................................................................................................. 44

3.17 Resource usage and performance analysis ........................................................................................ 45

4 Generate File Directory Structure ..................................................................................................... 46

4.1 File Directory Structure in M5 family device ...................................................................................... 46

4.2 File Directory Structure in M7 family device ...................................................................................... 47

5 Revision History............................................................................................................................... 50



1 Introduction

This document mainly describes the usage of the USB 2.0 Device IP core. This IP Core provides a function

(peripheral device) interface. It can be used to interface almost any peripheral to a computer via USB. This

core fully complies to the USB 2.0 specification and can operate at USB Full and High Speed rates. The USB IP

supports the following features:

USB device controller fully compliant with the USB 2.0 Specification;

Supports High Speed(480Mbps);

Support 8bit UTMI(Universal Transceiver Macrocell Interface) Interface, and 8bit ULPI(UTMI+ Low Pin

Interface) Interface;

Supports four endpoints, including

endpoint 0, control endpoint;

endpoint 1, IN endpoint, support bulk, interrupt and isochronous transfer;

endpoint 2, OUT endpoint, support bulk, interrupt and isochronous transfer;

endpoint 3, OUT endpoint, support bulk, interrupt and isochronous transfer;

the endpoints number is configurable:

a) All 4 endpoints, that is endpoint 0, 1, 2 & 3;

b) Only CTRL+IN endpoints, that is endpoints 0 & 1;

c) Only CTRL+OUT endpoints, that is endpoints 0, 2 & 3;

The four endpoints share 1 receive FIFO (128x32) and 2 transmit FIFO (128x64);

Packet-level transmission/reception (token, data, and handshake packets);

Error detection of CRC, invalid PID, and data payload errors;

With EMIF(External Memory Interface) and AHB interface to configure IP related registers;

With memory and handshake interface to access the 2KB(512x32) local memory. 1KB used as transmit

buffer and the other 1KB used as receive buffer. User can send data to host and get data from host

through this local memory;

With interrupt interface to help user handle the data reception from host;

Support Vendor Device Request of Control endpoint 0.

Device family support:

CME-M5, CME-M7



2 USB 2.0 Device IP Overview

2.1 USB 2.0 Device IP Block Diagram

2.1.1 Overview

USB2.0 PHY UTMI/ULPI

UTMI Interface

ControlRegisters

ProtocolLayer

FIFOControler

ReceiveFIFO

TransmitFIFO

Wishbone bus

Local Memory(TX and RX DPRAM)

Handshake LogicEMIF to

Wishbone Master

Wishbone Bus

Arbiter

8051Local Memory Access

InterfaceHandshake Interface

EMIF

Inte

rru

pt

AHB to Wishbone Master

ARM

AHB

ULPI Interface

MCU could be 8051 or ARM

Figure 2-1 USB2.0 Device IP block diagram

The figure 2-1 illustrates the overall architecture of the USB2.0 Device IP. The EMIF interface provides a bridge

between the 8051 and control registers. The local memory and handshake interface are used for user

memory access. The Protocol Layer block is designed to analyze the USB protocol. The Receive FIFO and

Transmit FIFO buffer the data. Each of the blocks is described in detail as below.

2.1.2 Protocol Layer

The protocol layer is responsible for all USB data IO and control communications.



Packet

Assembly

Protocol

Engine

Packte

Dis-assembly

DMA

& FIFO

Interface

Control

Register

Figure 2-2 Protocol layer diagram

1、DMA & FIFO Interface

This block interfaces to the data memory. It provides random memory access and also DMA block transfers.

2、Protocol Engine

This block handles all the standard USB protocol handshakes and control correspondence. Those are SOF

tokens, acknowledgment of data transfers (ACK,NACK, NYET), replying to PING tokens.

3、Packet Assembly

This block assembles packets and places them in to the output FIFO.

4、Packet Dis-assembly

This block decodes all incoming packets and forwards the decoded data to the appropriate

blocks.

2.1.3 Control Registers

This IP has a lot internal control registers, which can be set by user to implement the function according to

user requirements. This module implements all these registers control. Other modules can access these

registers through wishbone bus.

2.1.4 FIFO Control with receive and transmit FIFO

FIFO control module provides receive and transmit FIFO control signals, there are one receive FIFO and two

transmit FIFO, which are shared by 4 endpoints.

2.1.5 UTMI / ULPI Interface

This module provides the UTMI / ULPI interface to interconnect with external USB2.0 PHY(either UTMI or



ULPI PHY).

UTMI ULPI

Tx FIFOUTMI Tx Data

Interface

Interface State Engine

Speed Negotiation

Engine

Rx FIFOUTMI Rx Data

Interface

ULPITX

ULPIRX

UTMI System Interface

Figure 2-3 UTMI & ULPI Interface Block

1、Interface State Engine

This block handles the interface state. It controls suspend/resume modes and Full Speed/High Speed

switching.

2、Speed Negotiation Engine

This block negotiates the speed of the USB interface and handles suspend and reset detection.

3、Rx & Tx FIFOs

The FIFOs hold the temporary received and transmitted data.

4、UTMI System, Tx & Rx Data Interface

These blocks ensure proper handshaking with the receive and transmit interfaces of the PHY.

5、ULPI Tx & Rx Interface

These blocks transfer the ULPI interface into UTMI interface.

2.1.6 Wishbone Bus

The Wishbone Bus and Arbiter arbitrates between the MCU(8051/ARM), USB IP and Local Bus.



Figure 2-4 Wishbone Bus

2.1.7 EMIF/AHB to wishbone transform

MCU(8051/ARM) can access USB2.0 device IP internal registers through EMIF/AHB interface. This module

transforms the EMIF/AHB operation to wishbone operation.

2.1.8 Local memory

The local memory includes a 2KB(512x32) buffers, first 1KB of the buffer used as transmit buffer and the

remaining 1KB used as receive buffer.

When host send data, the IP’s protocol layer will analyze the data and send it to the receive FIFO and start the

DMA to transform the data from FIFO to local memory, user can get the data from the local memory's receive

buffer.

When send data to host, user can directly put the data to the local memory's transmit buffer and start the

DMA, DMA will transform the data from local memory to transmit FIFO and send to host through protocol

layer and UTMI interface.

2.2 Pin Description

Table 2-1 USB2.0 Device IP Core Interface

Name Type Width Description

System interface

clk60 I 1 Clock for USB control logic, 60MHz

rst60n I 1 Asynchronous reset input for clk60 domain logic

usr_clk_i I 1 Clock for wishbone bus related logic, EMIF/AHB/Local memory

usr_rstn I 1 Asynchronous reset input for user clock domain logic

Local memory access interface(usr_clk_i clock domain)

ce_l I 1 Local memory chip enable

we_l I 1 Local memory write enable, high write, low read

Wishbone

to EMIF/AHB

Wishbone

Master Arbiter

Control

Registers

Local Logic

Wishbone Master

Interface

Wishbone Master

Interface

Wishbone Arbiter

Wishbone Slave

Interface

Wishbone Slave

Interface



addr_l I 9 Local memory address input

rdat_l O 32 Local memory read data output

wdat_l I 32 Local memory write data input

Handshake interface(usr_clk_i clock domain)

usb_txbuf_avail I 1 Local memory transmit buffer available, IP can start move/transmit

data out from the transmit buffer

usb_tx_done O 1 Local memory transmit done,

usb_rxbuf_avail I 1 Local memory receive buffer available, IP can start move/receive

data into the receive buffer

usb_rx_done O 1 Local memory receive done

EMIF Interface(usr_clk_i clock domain)

memack O 1 Memory acknowledge

memdatai I 8 8051 write data to USB IP

memdatao O 8 8051 read data from USB IP

memaddr I 23 Memory address

memwr I 1 Memory write enable

memrd I 1 Memory read enable

AHB Interface(usr_clk_i clock domain)

s_ahb_sel I 1 AHB slave select signal

s_ahb_addr I 32 AHB address

s_ahb_write I 1 AHB transfer direction, high means write, low means read

s_ahb_trans I 2 AHB transfer type of the current transfer

s_ahb_wdata I 32 AHB write data from master to slave

s_ahb_readyout O 1 AHB ready out, when high, indicates a transfer has finished

s_ahb_resp O 1 AHB transfer response, low means OKAY, high means ERROR

s_ahb_rdata O 32 AHB read data from slave to master

Interrupt interface(usr_clk_i clock domain)

usb_int O 1 Interrupt output to indicate that IP have received data from host, will

be automatically cleared when IP finishes related operation

PHY interface ULPI(ulpi_clk clock domain)

ulpi_clk I 1 ULPI clock input

ulpi_data I/O 8 ULPI bi-directional data bus

ulpi_dir I 1 ULPI direction, controls the direction of the data bus

ulpi_stp O 1 ULPI stop

ulpi_nxt I 1 ULPI next

PHY Interface UTMI(phy_clk_i clock domain)

phy_rstn I 1 UTMI Interface logic reset input, low active

phy_clk_i I 1 UTMI clock input

phy_rst_o O 1 UTMI Interface reset output to external PHY

phy_data_o O 8 Transmit data

phy_txvalid_o O 1 Transmit valid

phy_txready_i I 1 Transmit data ready

phy_datain_i I 8 Receive data



phy_rxvalid_i I 1 Receive data valid

phy_rxactive_i I 1 Receive active

phy_rxerror_i I 1 Receive error

phy_xcvselect_o O 1 Transceiver Select

phy_termsel_o O 1 Termination Select

phy_suspendm_o O 1 Suspend

phy_linestate_i I 2 Line State

phy_opmode_o O 2 Operation Mode

Note:

(1) Either one of "EMIF Interface" and "AHB Interface" can be selected, but not both.

(2) Either one of "PHY Interface ULPI" and "PHY Interface UTMI" can be selected, but not both, this is

determined by parameter "ULPI_EN".

Table 2-2 USB2.0 Device IP Core Parameters

Name Type Width Description

BASE_ADDR Int 23(emif)

32(ahb)

The base address of the USB2.0 Device IP on 8051 memory space,

width different between EMIF and AHB interface mode

ULPI_EN Int 1 Enabled, only "PHY Interface ULPI" will be used;

Disabled, only "PHY Interface UTMI" will be used

IN_ENDP_EN Int 1 Enabled, IN endpoint(Endpoint 1) will be used;

Disabled, IN endpoint will not be used

OUT_ENDP_EN Int 1 Enabled, OUT endpoint(Endpoint 2 and 3) will be used;

Disabled, OUT endpoint will not be used

EP1_TR_TYPE Int 2 Endpoint 1 transfer type:

Interrupt: 2'b00, Bulk: 2'b10, Isochronous: 2'b01

EP1_PKT_LEN Int 9 Endpoint 1 max packet length, can be:

Interrupt: 64/128/512, Bulk: 512, Isochronous: 64/128/512











2.3 UTMI/ULPI interface Introduction

2.3.1 UTMI

USB2.0 Device IP Core

USB2.0UTMI PHY

phy_clk_i

phy_rst_o

phy_data[7:0]

phy_xcvselect_o

phy_termsel_o

phy_opmode_o

phy_suspendm_o

phy_linestate_o[1:0]

phy_txvalid_o

phy_txready_i

phy_rxvalid_i

phy_rxactive_i

phy_rxerror_i

UTMI interface(8bit bi-directional data)

Figure 2-5 UTMI Interface

UTMI (USB2.0 Transceiver Macrocell Interface) defines an interface between two IP blocks: the USB

Transceiver Macrocell (IP) and the USB Link layer (SIE). The UTMI interface provides functionality for USB

peripherals only, not for USB hosts or On-The-Go. The signals for a UTMI interface with an 8-bit bi-directional

data bus are depicted in Figure 2-5. A minimum of 22 signals is required between the Link and PHY.

The following extra pins are found on atypical PHY IC package.

15-25 pins for power and ground.

2 pins for D+ and D- of the USB connector.

2 pins for crystal attachment.

1-2 pins for stable reference resistor/current source

Please refer to the UTMI specification for more information on UTMI.

2.3.2 ULPI

USB2.0 Device IP Core

USB2.0ULPI PHY

ULPI interface(8bit bi-directional data)

ulpi_clk

ulpi_data[7:0]

ulpi_dir

ulpi_nxt

ulpi_stp

Figure 2-6 UTMI Interface

ULPI defines a PHY to Link interface of 8 or 12 signals that allows a lower pin count option for connecting to

an external transceiver that may be based on the UTMI+ specification. The pin count reduction is achieved by

having relatively static UTMI+ signals be accessed through registers and by providing a bi-directional data bus

that carries USB data and provides a means of accessing register data on the ULPI transceiver.



2.4 USB Core registers

2.4.1 Register Map

The IP has an 4KByte space, first 2KByte is used for internal registers, and the last 2KByte is used as local

memory buffer. And Table-2-3 shows the space allocation, Table 2-4 shows all internal registers supported by

the IP.

Table 2-3 IP Device Space Allocation

Address Size

(Byte) Description Comment

12’h000 --- 12'h03f 64 Registers for the whole IP device

Function

Registers

12’h040 --- 12'h04f 16 Registers for endpoint 0

12'h050 --- 12'h05f 16 Reserved


12'h070 --- 12'h07f 16 Reserved


12'h090 --- 12'h09f 16

12’h0a0 --- 12'h0af 16 Registers for endpoint 3

12'h0b0 --- 12'h13f 144 Reserved Reserved

12'h140 --- 12'h14f 16 Registers for endpoint 0 Wishbone

Registers 12'h150 --- 12'h15f 16 Reserved


12’h170 --- 12'h3ff 656 Reserved Reserved

12’h400 --- 12'h7ff 1024 RX buffer, for transaction of OUT endpoints Local memory

buffer 12'h800 --- 12'hbff 1024 TX buffer, for transaction of IN endpoints

12'hc00 --- 12'hc3f 64 RX & TX buffer, for transaction of CTRL endpoints Endpoint 0

buffer

12'hc40 --- 12'hfff 960 Reserved Reserved

Note:

(1) RX buffer(12'h400 --- 12'h7ff): this is buffer 0(OUT transfer buffer) of endpoint 2 & 3, which can also be

accessed by local memory interface;

(2) TX buffer(12'h800 --- 12'hbff): this is buffer 1(IN transfer buffer) of endpoint 1, which can also be accessed

by local memory interface;

(3) RX & TX buffer(12'hc00 --- 12'hc3f): this is buffer 0 & buffer 1 of endpoint 0;

(4) For local memory interface, the RX buffer(12'h400 --- 12'h7ff) is read-only with "addr_l" address space

9'h000~9'h0ff, the TX buffer(12'h800 --- 12'hbff) is write-only with "addr_l" address space 9'h100~9'h1ff,

signal "addr_l" definition can be seen at pin description table 2-1.

Table 2-4 All Internal Registers

Address Registers Description Access Type Reset Value

12’h000 Function command and status register RO 32'h0000_0019



12'h004 Function address register RW 32'h0000_0000

12'h008 Function interrupt mask register RW 32'h0000_0000

12'h00c Function interrupt source register ROC 32'h0000_0000

12'h010 Function frame number and time register RO 32'h0000_0000

12'h018 Function control register RW 32'h0000_0000

12'h01c Function attach power on time register RW 32'h0000_0064

12'h020 Function tx-data & rx-ack timeout register RW 32'h0064_00f0

12'h040 Endpoint 0 command and status register PRW, PRO 32'h0c00_0000

12'h044 Endpoint 0 interrupt mask register RW 32'h0000_0000

12'h048 Endpoint 0 interrupt source register ROC 32'h0000_0000

12'h04c Endpoint 0 buffer 0 register RW 32'h8000_0000

12'h060 Endpoint 1 command and status register PRW, PRO 32'h1840_0000



12'h080 Endpoint 2 command and status register PRW, PRO 32'h2880_0000



12'h08c Endpoint 2 buffer register RW 32'h8000_0000

12'h0a0 Endpoint 3 command and status register PRW, PRO 32'h28c0_0000

12'h0ac Endpoint 3 buffer register RW 32'h8200_0000

12'h140 Endpoint 0 buffer 1 register RW 32'h8000_0000

12'h144 Endpoint 0 buffer 1 status register RW 32'h0000_0000

12'h160 Endpoint 1 buffer 1 register RW 32'h0200_0800

12'h164 Endpoint 1 buffer 1 status register RW 32'h0000_0000

Note:

(1) RW: can both Read and Write access;

(2) RO: Read only;

(3) ROC: Read only, and Clear after read;

(4) PRW, PRO: part bits Read&Write, the other part bits ReadOnly.

2.4.2 Register Description

2.4.2.1 Function command and status register

This is the main configuration and status register of the USB core.

Bit Access Reset Description

31:5 RO 0 Reserved.

4:3 RO 2'h3 UTMI Line state. Real-time value of UTMI line state received.

2 RO 0 Interface Status. 1 means attached, 0 means de-attached.

1 RO 0 Interface Speed. 1 means High speed mode, 0 means Full speed mode.

0 RO 1 Suspend Mode. 0 means the function/device is under suspend mode, 1 means

normal mode.

2.4.2.2 Function address register



The function address should be set at enumeration period by standard request SET_ADDRESS, through

EMIF/AHB interface.


31:7 RO 0 Reserved.

6:0 RW 0 Function address.

2.4.2.3 Function interrupt mask register

A bit set to 1 enables the generation of the interrupt for that source, a bit set 0 disables the generation of an

interrupt.


31:9 RO 0 Reserved.

8 RW 0 USB reset. Receive a USB reset.

7 RW 0 UTMI Rx Error. Receive a UTMI Rx Error.

6 RW 0 Detached. The device is detached.

5 RW 0 Attached. The device is attached.

4 RW 0 Leave Suspend Mode. Resume.

3 RW 0 Enter Suspend Mode.

2 RW 0 No such endpoint. Endpoint does not exist.

1 RW 0 PID Error. PID check sum error.

0 RW 0 Bad Token. CRC5 error.

2.4.2.4 Function interrupt source register

The interrupt source register contains the function interrupt and the endpoints interrupt. Bit 16-24 will be

cleared immediately after read this register. Bit 0-2 can only be cleared when the corresponding endpoint's

interrupt source register is read.


31:25 RO 0 Reserved.

24 ROC 0 USB reset. Receive a USB reset.

23 ROC 0 UTMI Rx Error. Receive a UTMI Rx Error.

22 ROC 0 Detached. The device is detached.

21 ROC 0 Attached. The device is attached.

20 ROC 0 Leave Suspend Mode. Resume.

19 ROC 0 Enter Suspend Mode.

18 ROC 0 No such endpoint. Endpoint does not exist.

17 ROC 0 PID Error. PID check sum error.

16 ROC 0 Bad Token. CRC5 error.

15:3 RO 0 Reserved.

2 RO 0 Endpoint 2 interrupt. Interrupt occurs in endpoint 2.





2.4.2.5 Function frame number and time register

This register tracks the frame number as received from the SOF token, and the frame time.


31:28 RO 0 Same frame number. Number of frame with the same frame number.

27 RO 0 Reserved.

26:16 RO 0 Frame Number. 11-bit frame number received from SOF token.


11:0 RO 0 Time counter. Time count since last SOF, the unit is period of 'clk60'.

2.4.2.6 Function control register


31:3 RW 0 Reserved.

2 RW 0 Non drive. Enable power on reset.

1 RW 0 Enable suspend in linestate. When enabled, it can be suspend by host.

0 RW 0 Function USB Mode. Should be set to 1.

2.4.2.7 Function attach power on time register


31:7 RO 0 Reserved.

6:0 RW 7'h64 Power on time. Function attach power on time, the unit is ms(millisecond).

2.4.2.8 Function tx-data & rx-ack timeout register



24:16 RW 9'h64 Tx-data timeout. After sending a OUT token the host must send a data packet,

these bits indicate this time limitation. The unit is period of 'clk60'.

15:9 RO 0 Reserved.

8:0 RW 9'hf0

Rx-ack timeout. After send Data in response to an IN token from host, the host

must reply with an ack, these bits indicate this time limitation. The unit is period

of 'clk60'.

2.4.2.9 Endpoint 0 command and status register


31:30 RO 0 PID toggle track bits. Used by the USB core to keep track of the data PIDs for

high speed endpoints and for DATA0/DATA1 toggling.

29:28 RO 0 Endpoint Type. 2'h0: Control Endpoint, 2'h1: IN Endpoint, 2'h2: OUT Endpoint,

2'h3: Reserved.



27:26 RO 2'h3 Transfer Type. 2'h0: Interrupt, 2'h1: Isochronous, 2'h2: Bulk, 2'h3: Reserved.

25:22 RO 0 Endpoint Number.

21 RW 0 func_mk1_err.


11:5 RW 0 MAX_PL_SZ. The maximum payload size of a packet.

4:3 RW 0

EP_DIS. Temporarily Disable The Endpoint. 2'h0: Normal Operation, 2'h1: Force

the core to ignore all transfers to this endpoint, 2'h2: Force the endpoint in to

HALT state, 2'h3: Reserved.

2 RW 0 lrg_ok. 1 = Accept data packets of more than MAX_PL_SZ bytes, 0 = Ignore data

packet with more than MAXPL_SZ bytes.

1 RW 0 sml_ok. 1 = Accept data packets with less than MAX_PL_SZ bytes, 0 = Ignore

data packet with less than MAXPL_SZ bytes.

0 RW 0

ots_stop. When set, this bit enables the disabling of the endpoint when in DMA

mode, an OUT endpoint receives a packet smaller than MAX_PL_SZ. The

disabling is achieved by setting EP_DIS to 2'h1.

2.4.2.10 Endpoint 0 interrupt mask/source register


31:8 RO 0 Reserved.

7 RW/ROC 0 Receive a setup token.

6 RW/ROC 0 In Buffer Empty.

5 RW/ROC 0 OUT Buffer Full.

4 RW/ROC 0 OUT packet smaller than MAX_PL_SZ.

3 RW/ROC 0 PID Sequencing Error. Data PID doesn't toggle as specification require.

2 RO 0 Reserved.

1 RW/ROC 0 Bad Packet. CRC16 error.

0 RW/ROC 0 Time Out. Rx-ack or Tx-data timeout interrupt.

2.4.2.11 Endpoint 0 buffer 0 register

The register is used for buffer 0(OUT transaction receive buffer) configuration for this endpoint.


31 RW 1

USED. This bit is set by the USB core after it has used this buffer. The function

controller must clear this bit again after it has emptied/refilled this buffer. This

bit must be initialized to 0.


22:16 RW 0 Buffer Size. Number of bytes in the buffer. Write this field will set packet size

from this buffer. Read this field will return the actual packet size.

15:0 RW 0 Buffer Pointer. Byte address of the buffer.







29:28 RO 1 Endpoint Type. 2'h0: Control Endpoint, 2'h1: IN Endpoint, 2'h2: OUT Endpoint,

2'h3: Reserved.



21:5 RO 0 Reserved.

4:3 RW 0








0 RW 0






31:7 RO 0 Reserved.

6 RW/ROC 0 In Buffer Empty.

5:3 RO 0 Reserved.

2 RW/ROC 0 Unsupported PID. Encounter this interrupt like sending OUT to an IN endpoint,

or sending IN to and OUT endpoint.

1 RO 0 Reserved.






29:28 RO 2'h2 Endpoint Type. 2'h0: Control Endpoint, 2'h1: IN Endpoint, 2'h2: OUT Endpoint,

2'h3: Reserved.




14:5 RW MAX_PL_SZ. The maximum payload size of a packet.

4:3 RW 0 EP_DIS. Temporarily Disable The Endpoint. 2'h0: Normal Operation, 2'h1: Force









0 RW 0






31:6 RO 0 Reserved.

5 RW/ROC 0 OUT Buffer Full.

4 RW/ROC 0 OUT packet smaller than MAX_PL_SZ.

3 RW/ROC 0 PID Sequencing Error. Data PID doesn't toggle as specification require.

2 RW/ROC 0 Unsupported PID. Encounter this interrupt like sending OUT to an IN endpoint,

or sending IN to and OUT endpoint.

1 RW/ROC 0 Bad Packet. CRC16 error.





31 RW 1





27:16 RW 0 Buffer Size. Number of bytes in the buffer. Write this field will set packet size

from this buffer. Read this field will return the actual packet size.






29:28 RO 2'h2 Endpoint Type. 2'h0: Control Endpoint, 2'h1: IN Endpoint, 2'h2: OUT Endpoint,

2'h3: Reserved.






14:5 RW MAX_PL_SZ. The maximum payload size of a packet.

4:3 RW 0








0 RW 0







31 RW 1





25:16 RW 10'h200 Buffer Size. Number of bytes in the buffer. Write/Read this field will set packet

size from this buffer.



This register is used for buffer 1(IN transaction transmit buffer) configuration of this endpoint.


31 RW 1





22:16 RW 0 Buffer Size. Number of bytes in the buffer. Write/Read this field will set packet



2.4.2.20 Endpoint 0 buffer 1 status register

This register is used for buffer 1(IN transaction transmit buffer) configuration of this endpoint. HS Control

endpoint max-payload size is 64Byte.


31:7 RO 0 Reserved.



6:0 RW 0 Max payload size. In byte.


This register is used for buffer 1(IN transaction transmit buffer) configuration of this endpoint.


31 RW 0





27:16 RW 12'h200 Buffer Size. Number of bytes in the buffer. Write/Read this field will set packet


15:0 RW 16'h800 Buffer Pointer. Byte address of the buffer.

2.4.2.22 Endpoint 1 buffer 1 status register

This register is used for buffer 1(IN transaction transmit buffer) configuration of this endpoint. HS Bulk

endpoint max-payload size is 512Byte.



9:0 RW 0 Max payload size. In byte.



3 USB2.0 Device IP Usage

3.1 USB data transfer overview

According to USB protocol, USB data transfer is shown as blow:

Transfer

Transaction Transaction Transaction

Each transfer consists of 1 or more transactions

Each transaction contains a token packet and may contain a data

and/or handshake packet

Token Packet Data PacketHandshake

Packet

PID Address Endpoint CRC PID Data CRC PID

Each packet contains a PID and may contain additional information and

CRC (Error-checking bits)

Figure 3-1 USB2.0 data transfer overview

Each transfer consists of one or more transactions, and each transaction in turn consists of two or three

packets. (Start-of-Frame markers transmit in single packets.) The USB 2.0 specification defines a transaction as

the delivery of service to an endpoint. Service in this case can mean either the host’s sending information to

the device or the host’s requesting and receiving information from the device. Setup transactions send

control-transfer requests to a device. OUT transactions send other data or status information to the device. IN

transactions send data or status information to the host.

Each USB 2.0 transaction includes identifying, error-checking, status, and control information as well as any

data to be exchanged. A transfer may take place over multiple frames or microframes, but each USB 2.0

transaction completes within a frame or microframe without interruption. No other packets on the bus can

break into the middle of a transaction. Devices must respond quickly with requested data or status

information. Device firmware typically arms (sets up, or configures) an endpoint’s response to a received

packet, and on receiving a packet, the hardware places the response on the bus.



There are four types of data transfer, as is shown below:

Figure 3-2 USB2.0 data transfer types

Each USB 2.0 transaction has two or three phases, A non-control transfer with a small amount of data may

complete in a single transaction. Other transfers use multiple transactions with each carrying a portion of the

data.

3.2 USB control transfer

Control transfers have two uses. For all devices, control transfers carry the standard requests that the host

uses to learn about and configure devices. Control transfers can also carry requests defined by a class or

vendor for any purpose.

Every control transfer must have a Setup stage and a Status stage. Not all transfers have Data stages, though

specific requests can require them. Because every control transfer requires transferring information in both

directions, the control transfer’s message pipe uses both the IN and OUT endpoint addresses

Figures below show the stages of control read and control write transfers at low and full speeds on a

low/full-speed bus.



Control write transfer

Setup Transaction

Token Packet

Host à Device

SETUP DATA ACK

Data Packet

Host à Device

Handshake Packet

Device à Host

The host sends a

setup packet

The host sends a

request in an 8-byte

data packet

The Device

Returns ACK

Zero or more data transactions

Token Packet

Host à Device

OUT DATA

Data Packet

Host à Device

Handshake Packet

Device à Host

ACK

NAK

STALL

The first data packet is data1.

Any data packets that follow

alternate data0/1

The host sends an

out packetThe host sends data The device

returns status

Status Transaction

Token Packet

Host à DeviceData Packet

Host à Device

Handshake Packet

Host à Device

IN DATA

NAK

STALL

ACK

The host sends an

in packetThe device

returns status

On receiving data

without error.

The host returns ACK

SETUP DATA ACK

Data Packet

Host à DeviceHandshake Packet

Device à Host

The host sends a

setup packet

The host sends a

request in an 8-byte

data packet

The Device

Returns ACK

One or more data transactions

Token Packet

Host à Device

Data Packet

Device à Host

Handshake Packet

Host à Device

The first data packet is

data1.

Any data packets that follow

alternate data0/1

Control read transfer

Setup Transaction

Token Packet

Host à Device

IN DATA ACK

NAK

STALL

The host sends an

In packetThe Device sends

data or status

On receiving data

without error.

The host returns ACK

Status Transaction

Token Packet

Host à Device

Token Packet

Host à DeviceHandshake Packet

Device à Host

OUT DATA ACK

NAK

STALL

The host sends an

out packet

The host sends

data packet

The device return

status

DATA1DATA1

Figure 3-3 USB control transfer

In a control write transfer, the data in the Data stage travels from the host to the device. Control transfers that

have no Data stage are also considered to be control write transfers. In a control read transfer, the data in the

Data stage travels from the device to the host.

3.3 USB bulk transfer

Bulk transfers are useful for transferring data when time isn’t critical. A bulk transfer can send large amounts

of data without clogging the bus because the transfers defer to the other transfer types, waiting until time is

available. Uses for bulk transfers include sending data to a printer, sending data from a scanner, and reading

and writing to a drive. On an otherwise idle bus, bulk transfers are the fastest transfer type.



Bulk transfers

In transaction

Token Packet

Host à Device

Data Packet

Device à Host

Handshake Packet

Host à Device

IN DATA ACK

NAK

STALL

The host sends an

in packet

The device responds

with data or status

The host returns

status

Out transaction

Token Packet

Host à Device

Data Packet

Host à Device

Handshake Packet

Device à Host

OUT DATA ACK

NAK

STALL

The host sends an

out packet

The host sends

an dataThe device

returns status

Figure 3-4 USB bulk transfer

A USB 2.0 bulk transfer consists of one or more IN or OUT transactions (Figure3-4). All data travels in one

direction. Transferring data in both directions requires a separate pipe and transfer for each direction.

In bulk transfer, A USB 2.0 device has these responsibilities for transfers on a bulk endpoint:

For OUT transfers, ACK data received in data packets.

For IN transfers, return data in data packets in response to IN token packets.

The allowed maximum data bytes in a bulk transaction’s data packet vary with the bus speed:

Table 3-1 Bulk transfer data packet size of different bus speed

Bus Speed Maximum data packet size (bytes)

Full 8, 16, 32 or 64

High 512

These bytes include only the information transferred in the data packet (USB 2.0) excluding PID and CRC bits.

3.4 USB isochronous transfer

Isochronous transfers are streaming, real-time transfers that are useful when data must arrive at a constant

rate or within a specific time limit and occasional errors are tolerable. At full speed and high speed,

isochronous transfers can transfer more data per frame or bus interval compared to interrupt transfers, but

the transfer type doesn’t support automatic resending of data received with errors.

Examples of uses for isochronous transfers include encoded voice and music to be played in real time. Data

that will eventually be consumed at a constant rate doesn’t always require an isochronous transfer. For

example, a host can use a bulk transfer to send a music file to a device. After receiving the file, the device can

stream the music on request.



Isochronous means that the data has a fixed transfer rate, with a defined number of bytes transferring in

every frame, microframe, or bus interval.

A USB 2.0 isochronous transfer consists of one or more IN transactions or one or more OUT transactions at

equal intervals. Transferring data in both directions requires a separate transfer and pipe for each direction.

High-speed isochronous transfers are more flexible. They can request as many as 3 transactions per

microframe (USB 2.0) or 48 transactions per bus interval (SuperSpeed) or as little as 1 transaction every

32,768 microframes/bus intervals.

Isochronous transfers

In transaction

Token Packet

Host à Device

Data Packet

Device à Host

IN DATA

The host sends an

in packetThe device responds

with data

Out transaction

Data0

Token Packet

Host à Device

Data Packet

Host à Device

OUT DATA

Data0The host sends an

out packetThe host sends data

Figure 3-5 USB isochronous transfer

Figure 3-5 shows the packets in full-speed isochronous IN and OUT transactions. An isochronous transfer is

one way. The transactions in a transfer must all be IN transactions or all OUT transactions. Transferring data

in both directions requires a separate pipe and transfer for each direction.

The allowed maximum data bytes in an isochronous transaction’s data packet varies with bus speed and the

number of packets per microframe.

Table 3-2 Isochronous transfer data packet size of different bus speed

Bus Speed Maximum Data packet size Maximum number of Packets/interval

Full 0-1023 1 / frame

High 0-1024 1 / microframe

513-1024 2 / microframe


These bytes include only the information transferred in the data packet (USB 2.0) or Data Packet Payload

(SuperSpeed), excluding PID and CRC bits.

3.5 USB interrupt transfer

Interrupt transfers are useful when data has to transfer without delay. Typical applications include keyboards,

pointing devices, game controllers, and hub status reports. Users don’t want a noticeable delay between

pressing a key or moving a mouse and seeing the result on screen. A hub needs to report the attachment or

removal of devices promptly. Low-speed devices, which support only control and interrupt transfers, are

likely to use interrupt transfers.



At low and full speeds, the bandwidth available for an interrupt endpoint is limited, but high speed has no

limits.

Interrupt transfers are interrupt-like because they guarantee fast response from the host. For both bulk and

interrupt endpoints, firmware typically uses interrupts to detect new received data. On a USB 2.0 bus, both

bulk and interrupt endpoints must wait for the host to request data before sending data.

A USB 2.0 interrupt transfer consists of one or more IN transactions or one or more OUT transactions.

Transferring data in both directions requires a separate transfer and pipe for each direction.

Interrupt transfers

In transaction

Token Packet

Host à Device

Data Packet

Device à Host

Handshake Packet

Host à Device

IN DATA ACK

NAK

STALL

The host sends an

in packet

The device responds

with data or status

The host returns

status

Out transaction

Token Packet

Host à Device

Data Packet

Host à Device

Handshake Packet

Device à Host

OUT DATA ACK

NAK

STALL

The host sends an

out packet

The host sends

an dataThe device

returns status

Figure 3-6 USB interrupt transfer

The allowed maximum data bytes in an interrupt transaction’s data packet varies with bus speed and the

number of packets per micro-frame.

Table 3-3 Interrupt transfer data packet size of different bus speed

Bus Speed Maximum Data packet size Maximum number of Packets/interval

Low 1-8 1 / 10 frames

Full 1-64 1 / frame

High 1-1024 1 / microframe



These bytes include only the information transferred in the data packet (USB 2.0) or Data Packet

Payload (SuperSpeed), excluding PID and CRC bits.

3.6 USB IP standard/vendor device request handler flow

This IP support the following standard device requests:



Figure 3-7 Standard USB device requests

And following 3 vendor device requests are also supported, provided in 8051/ARM firmware. User can add

their own special vendor request in firmware based on these provided vendor device request.

Table 3-4 Vendor device request provided in 8051/ARM firmware(in hexadecimal)

bmRequestType bRequest wValue wIndex wLength data

SET_no_data 40 a2 0000/0001 0000 0000 Non

SET_data 40 a0 0000 0000 00xx 0~64Byte

GET_data c0 a1 0000 0000 00xx 0~64Byte

To handle these standard/vendor device requests, need 8051/ARM firmware support. As is shown in the

diagram below, USB IP only responsible for getting request from the host and transform data to local memory,

and 8051/ARM firmware will responsible for different requests handling.



Host send out request

UTMI interface

Protocol layer

Control Register

Receive FIFO

Check interrupt source

Generate Interrupt

USB ResetEP0

InterruptOther

Check interrupt type

DATA Packet

IN type

SETUPPacket

OUT type

Device request handler

Get statusClear

feature

Set function address

Clear feature

GetConfiguration

GetDescriptor

GetInterface

Set Address

SetConfiguration

SetDescriptor

SetFeature

SetInterface

LocalMemory

USB IP Handle flow

8051 Firmware Handle flow

USB Request

Figure 3-8 Standard USB device requests handle flow

Using 8051/ARM firmware to implement the USB emulation is very helpful for user to customize their own

USB device. User can easily change USB device descriptor, configure the endpoint according to different

application requirements.

3.7 USB IP data transfer flow

For bulk, isochronous and interrupt data transfer, the USB IP handle flows, including: IN request and OUT

request handle flow are shown as below:



Initial IP configure

USB Device Enumerate

Get IN request from Host?

Write data to local memory

Set usb_txbuf_avail

usb_tx_done become active?

Bulk in transfer finish

Get interrupt

Check interrupt source and type

Endpoint bulk IN request?


Start DMA


Set endpoint descriptor, set as bulk in transferSet IP control registers, including:Endpoint buffer pointer, buffer sizeEndpoint direction(IN), type(Bulk)

Waiting

Y Y

N

Waiting N

Y

WaitingN

FPGA Logic Handle flow

8051 firmware Handle flow

Data Ready?

Y

NAK

N

Figure 3-9 Data In transfer handle flow

Initial IP configure

USB Device Enumerate

Get Out request from Host?

Read data from local memory

usb_rx_done become active?

Bulk out transfer finish

Get interrupt

Check interrupt source and type

Endpoint bulk OUT request?


Start DMA


Set endpoint descriptor, set as bulk out transferSet IP control registers, including:Endpoint buffer pointer, buffer sizeEndpoint direction(OUT), type(Bulk)

Waiting

Y Y

N

Waiting N

Y

Other request handling

N

FPGA Logic Handle flow

8051 firmware Handle flow

Set usb_rxbuf_avail

Ready to receive?

NAK

N

Y

Y

Figure 3-10 Data Out transfer handle flow



There are two ways to use this IP to handle data transfer: using FPGA logic or using 8051 firmware to

implement. To implement data transfer, after power on reset, user should first initialize IP configure,

including:

Endpoint descriptor setting, set endpoint type(IN/OUT), endpoint attribute(Control, Isochronous, bulk,

interrupt), endpoint max packet size, transfer interval.

IP internal control register setting, endpoint buffer pointer, buffer size, endpoint type(IN/OUT), attribute

(Control, Isochronous, bulk, interrupt), interrupt mask.

If using FPGA logic, user can send and receive data from host through memory and handshake interface. User

can get the status of the IP controller from usb_rx_done and usb_tx_done. After write data to local memory,

user can tell the IP controller that the transmit buffer is available (usb_txbuf_avail), after read the data from

the local memory, user can tell the IP controller that the receive buffer is available (usb_rxbuf_avail).

If using 8051/ARM firmware, when IP controller gets the request from the host, interrupt will be generated.

User needs to check the interrupt source and type and implement the data write and data read operation.

Please NOTE: when using 8051/ARM firmware to implement data transfer, the handshake interface signal:

usb_rxbuf_avail and usb_txbuf_avail inputs should always keep high.

3.8 USB device enumerate flow

Before applications can communicate with a device, the host needs to learn about the device and assign a

driver. Enumeration is the exchange of information that accomplishes these tasks. The process includes

assigning an address to the device, reading descriptors from the device, assigning and loading a driver, and

selecting a configuration that specifies the device’s power requirements and interfaces. The device is then

ready to transfer data.

The USB device enumerate flow is shown as below:



USB Device Connect to Host

Get Device Descriptor

Set Device Address

Get Device Descriptor again

Get Configuration Descriptor

Get Device and Configuration Descriptor again

Set Configuration

Emulation Done

Figure 3-11 USB device emulation flow

1、 Get device descriptor

The host sends a Get Descriptor request to learn the maximum packet size of the default pipe. The host

sends the request to device address 00h, endpoint zero. Because the host enumerates only one device at

a time, only one device will respond to communications addressed to device address 00h even if several

devices attach at once.

The eighth byte of the device descriptor contains the maximum packet size supported by endpoint zero. A

Windows host requests 64 bytes but after receiving just one packet (whether or not it has 64 bytes), the

host begins the Status stage of the transfer. On completing the Status stage, Windows requests the hub

to reset the device as in step 5 above. The USB 2.0 specification doesn’t require a reset here. The reset is

a precaution that ensures that the device will be in a known state when the reset ends.

2、 Set device address

When the reset is complete, the host controller assigns a unique address to the device by sending a Set

Address request. The device completes the Status stage of the request using the default address and then

implements the new address. The device is now in the Address state. All communications from this point



on use the new address. The address is valid until the device is detached, a hub resets the port, or the

system reboots. On the next enumeration, the host may assign a different address to the device.

3、 Get device descriptor again

The host learns about the device’s abilities. The host sends a Get Descriptor request to the new address

to read the device descriptor. This time the host retrieves the entire descriptor. The descriptor contains

the maximum packet size for endpoint zero, the number of configurations the device supports, and other

basic information about the device.

4、 Get device configuration descriptor

The host continues to learn about the device by requesting the one or more configuration descriptors

specified in the device descriptor. A request for a configuration descriptor is actually a request for the

configuration descriptor followed by all of its subordinate descriptors up to the number of bytes

requested. A Windows host begins by requesting just the configuration descriptor’s nine bytes. Included

in these bytes is the total length of the configuration descriptor and its subordinate descriptors.

5、 Get device and configuration descriptor again

Host requests the configuration descriptor again, this time requesting the number of bytes in the

retrieved total length. The device responds by sending the configuration descriptor followed by all of the

configuration’s subordinate descriptors, including interface descriptor(s), with each interface descriptor

followed by any endpoint descriptors for the interface. Some configurations also have class- or

vendor-specific descriptors. This chapter has more on what the descriptors contain

6、 Set Configuration

The host assigns and loads a device driver (except for composite devices). After learning about a device

from its descriptors, the host looks for the best match in a driver to manage communications with the

device. Windows hosts use INF files to identify the best match. The INF file may be a system file for a USB

class or a vendor-provided file that contains the device’s Vendor ID and Product ID.

The host’s device driver selects a configuration. After learning about a device from the descriptors, the

device driver requests a configuration by sending a Set Configuration request with the desired

configuration number. Many devices support only one configuration. If a device supports multiple

configurations, the driver can decide which configuration to request based on information the driver has

about how the device will be used, or the driver can ask the user what to do or just select the first

configuration. (Many drivers only select the first configuration.) On receiving the request, the device

implements the requested configuration. The device is now in the Configured state and the device’s

interface(s) are enabled.

3.9 USB IP Data Organization

Since the buffer memory is 32 bits wide and USB defines all transactions on byte boundaries it is important to

understand the relationship of data in the buffer to actual USB byte sequence. This USB core supports Little

Endian byte ordering.

Byte1Byte2Byte3Byte40781516232431

Figure 3-12 Byte Ordering

The buffer pointer always points to byte 0. The USB core always fetches four bytes from the buffer memory.

The actual final byte that is transmitted in the Nth transaction depends on the Buffer Size. The MaxPacketSize

must always be a multiple of 4 bytes.



3.10 USB Core Process Flow

Below flowcharts outline the basic operation of the USB core.

PING/SOF

Token

Special

Token

Process

IDLE

Token

Interrupt?

Decode

Token

Report

Token

Error

Perform

Setup

Cycle

Perform

IN Data

Cycle

Perform

OUT Data

Cycle

Received

Token

Yes

No Unsupported

Or Invalid Token

Setup

Token

IN Token

Out Token

Figure 3-13 USB Core Main Flowchart

3.10.1 Special Token Processing

The USB Core currently supports only two special tokens in addition to SETUP, IN and OUT tokens. These

tokens are SOF and PING. When a SOF token is received, the FRM_NAT register is updated.

The PING token is a special query token for high speed OUT endpoints. It allows the host to query whether

there is space in the output buffer or not.



Decode

Token

Update

FRM_NAT

Register

HS

Mode?

HALT

Mode?

Buffer

Available?

Reply

Ack

Reply

Ack

Reply

Stall

SOF

PING

NO

NO NOYes

Yes Yes

Figure 3-14 Special Token Processing Flowchart

3.10.2 IN Data Cycle

This section illustrates the decision flow for an IN token.

HALT

Mode?

Buffer

Available?

Reply

Stall

Reply

Ack

Reply

Ack

Stand

Data

Packet

Wait

For

Ack

Toggle

PID bits

Advanced

Buffer Ptr

Yes Yes

No No

Got Ack

Time Out

Figure 3-15 IN Data cycle Flowchart

3.10.3 OUT Data Cycle

This section illustrates the decision flow for an OUT token.



HALT

Mode?

No

Reply

Stall

Wait For

Data

Packet

PIN in

Sequence?

Data

Accepted?

Reply

Ack

Advance

PID

Advance

Buffer

High Speed

Mode?

Next Buffer

Available?

Reply

Ack

Reply

NYET

Yes

Yes

No

No

Yes

Yes

No

Yes

NoGot Data

Packet

Timeout or

Crc16 error

Figure 3-16 OUT Data cycle Flowchart

3.10.4 USB Device Control Processing

The USB provides a special mechanism to control the attached devices beyond data exchange. Those special

controls are: Reset, Suspend/Resume and Speed Negotiation. Below flow chart illustrates the support

provided by this USB core.



IDLE asserted for

> 3.0mS & FS

mode

Power On/Function Reset

Switch to FS mode

Wait 100 mS

Set attached flag

Normal Operation

Switch to FS mode

Wait 100 uS

Suspend Reset

‘J’asserted

‘J’asserted

IDLE asserted for

> 3.0mS & HS mode

IDLE asserted for

> 2.5uS but 3.0ms

& FS modeSE0 asserted

IDLE: ‘J’for

FS；Full Speed

HS: High Speed Figure 3-17 USB Device Control Process

SUSPEND

-Set Suspend Mode

Reset

Clear Suspend Mode

- Clear Suspend Mode

- Wait up to 10mS

- Drive ‘K’ for 1-15mS

Switch to HS mode

Normal Operation

SE0 asserted for

> 2.5 uS

Funct,Resume

Request &

Suspend > 5mS‘K’ asserted

SE0 asserted &

HS Mode

SE0 asserted &

HS Mode

SE0 asserted &

FS ModeSE0 asserted &

FS Mode

Figure 3-18 Suspend Control processing



Reset

Send Chirp ‘K’ for 1mS

Wait for Chirp ‘K’ for

1mS

Wait for Chirp ‘J’ for 1mS

Swtich to ‘HS’ mode Normal Operation

Chirp Count = 6

Chirp Count = 6

Got SE0

Got SE0

Got SE0

Got Chirp ‘J’ Got Chirp ‘K’

Figure 3-19 Reset Control processing

3.10.5 Interrupt

The USB core provides two interrupt outputs. Outputs are fully programmable. The programming for both

outputs is identical to provide full flexibility to software. The intention is to have one high priority interrupt

and one low priority interrupt. The actual usage of the interrupts is up to the system into which the USB core

is incorporated. The interrupt mechanism in the USB core consists of a two level hierarchy:

The main interrupt source register (INT_SRC) indicates interrupts that are endpoint independent. These

interrupts indicate overall events that have either global meaning for all endpoints or can not be

associated with an endpoint because of an error condition.

The endpoint interrupt source registers indicate events that are specific to an endpoint.

3.11 EMIF/AHB to Wishbone

3.11.1 EMIF to Wishbone

The EMIF address width is 8 bits and the data width is 8 bits. The wishbone address width is 16 bits.

The 8051 access the USB IP register through the EMIF, and the emif2wishbone module change the EMIF to

the wishbone.

3.11.1.1 Registers

Table 3-5 EMIF to Wishbone Registers



Address Registers Comment Width Description Access

Type

Reset

Value

BASE Address +

0 cmd

command

register 8 bit

Bit 7: Wishbone write

Bit 6: Wishbone read

Bit 5-4:Reserved

Bit 3:0: Wishbone sel

R/W 0

BASE Address +

1 A0

Wishbone

address 8 bit

Wishbone address

7:0 bit R/W 0

BASE Address +

2 A1

Wishbone

Address 8 bit

Wishbone address

15:8 bit R/W 0

BASE Address +

3 D0

Wishbone

Data 8 bit

Wishbone data

7:0 R/W 0

BASE Address +

4 D1

Wishbone

Data 8 bit

Wishbone data

15:8 R/W 0

BASE Address +

5 D2

Wishbone

Data 8 bit

Wishbone data

23:16 R/W 0

BASE Address +

6 D3

Wishbone

Data 8 bit

Wishbone data

31:24 R/W 0

3.11.1.2 Operation

When reading a data from wishbone bus, should follow the steps:

1. Set the wishbone address through the registers A1,A0;

2. Set the wishbone data through the registers D3,D2,D1,D0;

3. Set the byte available through the registers cmd 3:0 bit;

4. Set the cmd 7th bit to start the write operation.

When reading a data from the wishbone bus, should follow the steps:

1. Set the wishbone address through the registers A1,A0;

2. Set the byte available through the registers cmd 3:0 bit;

3. Set the cmd 7th bit to start the write operation.

4. Read the D3,D2,D1,D0 to get the read data.

3.11.2 AHB to Wishbone

The AHB address width is 32 bits and the data width is 32 bits. The wishbone address width is 16 bits.

The ARM access the USB IP register through the AHB, and the ahb2wishbone module change the AHB to the

wishbone.

3.11.2.1 Operation

When reading/writing a data from/to wishbone bus, the AHB should just put its low 16bits address be

wishbone address + BASE_ADDRESS(base address of the IP device as a slave).



3.12 Local memory interface and handshake interface

The interface between the local logic and the USB IP is the memory interface and the handshake interface.

3.12.1 Receive a packet

As shown in figure 3-20, When receive a packet, the local logic should set the rxbuf_avail available to indicate

the local logic ready to receive the packet from the USB host through the USB IP. Without the available of

rxbuf_avail, when receive the OUT data packet, the USB IP will send the NAK to the USB host to indicate the

device has not prepare to receive data packet.

Figure 3-20 Receive the packet

After receive the packet, the usb_rx_done is available which indicates the receive data has already write to

the receive buffer. the local logic first set the rxbuf_avail unavailable, then the local logic read the data from

the receive buffer through the memory interface, after getting all the received data, local logic set rxbuf_avail

available to receive the next out data packet.

3.12.2 Send a Packet

As shown in the figure 3-21, the local logic should set the txbuf_avail available to indicate there is a packet

ready to send. Without the available of txbuf_avail, When receive the IN packet, the USB IP will send the NAK

to the USB host to indicate the device has no data to send.

Before sending the packet, the txbuf_avail is available which indicates the the data is waiting for sending.



When the USB IP receive the IN packet, USB IP send ACK to indicate data is ready, then read the data from the

local buffer. After send data to host, the USB IP set usb_tx_done available and the local logic set the

txbuf_avail unavailable. If the local logic want to send next packet , it will write the data to the txbuf and set

the txbuf_avail available.

Figure 3-21 Send the packet

3.13 Clocking and reset

To use this IP, three clock inputs and related reset inputs are needed: clk60, usr_clk_i, phy_clk_i/ulpi_clk

(rst60n, usr_rstn, phy_rstn).

clk60 is the clock for USB core control logic, must be 60MHz.

usr_clk_i is the clock for wishbone interface logic, EMIF logic and local memory interface logic. User can set

this clock frequency according to system application requirements, it is suggested that it keeps the same with

clk60 to be 60MHz.

phy_clk_i/ulpi_clk is the 60MHz clock from external USB2.0 UTMI/ULPI PHY.

Following figure shows the clock connection, the GBUF module can drive phy_clk_i/ulpi_clk to the global

clock tree of CME FPGA, which can cost low timing deskew. Suggest user using clock pad to connect PHY clock

to avoid big latency of the clock input.

USB 2.0 UTMI/ULPI

PHY

phy_clk_o

PLL

clk60

usr_clk_i

phy_clk_i

USB2.0 Device

IP

phy_rst_o

rst60n

usr_rstn

phy_rstn

pad

clk pad

GBUF

local clock source

Figure 3-22 Example of clock&reset connection



3.14 External memory interface (EMIF) operation

3.14.1 EMIF Interface timing

EMIF is used to extend the MSS (MCU sub-system) memory, address 20000~7FFFFF, can be implemented with

Fabric.

The CME-M5 family provides synchronous and asynchronous EMIF for Fabric extended memory which has the

same data/address and control ports but have different timing waveforms. The synchronous or asynchronous

EMIF mode is selected by the parameter sync_mode_en.

Figure 3-23 EMIF read waveform

When reading, Fabric places the read data to memdatai bus and not outputs a valid “memack” after one or

several cycles until the fabric data is ready after the memrd is asserted.

Figure 3-24 EMIF write waveform

In write cycle, Fabric writes the memdatao to extended memory when the memwr is asserted and send a

valid “memack” to MSS on the next cycle

3.14.2 EMIF data bank operation



Figure 3-25 CME 8051 memory map

Figure 3-26 CME 8051 bank arrangement

As is shown in figure up, the common area starts at 0x0000H address and ends at 0x7FFFH. Bank 0 is not

available, it is physically the same memory spaces at the common area. While code/xdata memory banking

feature is enabled, the code/xdata memory address is composed of two parts:

15 bit address

8bits from a bank switching register SW_REGISTER:

PAGESEL for code memory

D_PAGESEL for xdata memory



Figure 3-27 code/xdata memory address with banking

For more information of EMIF interface, please refer to:

http://www.agatelogic.com.cn/PDF/CME-M5_Family_FPGA_Simplified_Data_Sheet_EN.pdf

3.15 AHB operation

3.15.1 AHB Interface timing

Following is the AHB interface timing of write and read operation. This AHB interface only support single burst

transfer, and 32bit data transfer size.

Figure 3-28 AHB write and read waveform

3.15.2 AHB address mapping

FP0

bfff_ffff

a000_0000

FP1

dfff_ffff

c000_0000

Figure 3-29 CME M7 ARM AHB Address mapping

The ARM Core provides two groups of AHB Bus signals, AHB0 and AHB1, so there are two memory space for

user logic which are called as FP0 and FP1.It means that if you instantiate an ARM Core and choose the AHB0 ,

you must access your slaves on the address from a000_0000 to bfff_ffff, but if you connect the AHB interface

to AHB1, the slaves can be accessed on the address from c000_0000 to dfff_ffff.

http://www.agatelogic.com.cn/PDF/CME-M5_Family_FPGA_Simplified_Data_Sheet_EN.pdf



3.16 Interrupt operation

For this USB IP, after each transmission and reception complete, interrupt request (usb_int) is generated. User

can connect this interrupt request to any 8051/ARM’s external interrupt input. And 8051/ARM will follow the

normal interrupt handle procedure to handle USB’s interrupt request.

Following are external interrupt sources of both 8051 and ARM.

3.16.1 8051 external interrupt sources

Table 3-6 8051 external interrupt sources

Vector

Number

Type Polarity Alternate Port Description

0 I Low/Fall Port3i[2] External interrupt 0

2 I Low/Fall Port3i[3] External interrupt 1

9 I Fall/Rise Port1i[4] External interrupt 2

10 I Fall/Rise Port1i[0] External interrupt 3

11 I Rise Port1i[1] External interrupt 4




3.16.2 ARM external interrupt sources

Table 3-7 ARM external interrupt sources

Interrupt Serve Function Type Alternate Port Description

Void FP0_IRQHandler(void) I fp_interrupt[0] External interrupt 0


















3.17 Resource usage and performance analysis

Resource usage and performance of the USB IP on Primace.

Table 3-8 USB IP resource usage and performance

Resource

Chip Interface Endpoints LUT4s REGs EMB5K Performance(fMAX, up to)

M5

UTMI

0, 1, 2, 3 3103 1977 16 120MHz

0, 1 2715 1799 14 100MHz

0, 2, 3 2914 1874 14 110MHz

ULPI

0, 1, 2, 3 3196 2033 16 80MHz

0, 1 2819 1855 14 70MHz

0, 2, 3 2955 1930 14 90MHz

M7

UTMI

0, 1, 2, 3 2988 1976 16 90MHz

0, 1 2637 1798 14 100MHz

0, 2, 3 2760 1873 14 110MHz

ULPI

0, 1, 2, 3 3072 2032 16 65MHz

0, 1 2641 1854 14 80MHz

0, 2, 3 2801 1929 14 80MHz

Note: The performance is fetched from Primace, based on the Typical timing condition.



4 Generate File Directory Structure

The USB IP wizard generated file includes: source files (src), simulation files(sim) and example design files.

And different device family has a little difference in design files, the detailed design directory structure for M5

and M7 is as below.

4.1 File Directory Structure in M5 family device

Following is the detailed directory structure with figure and table description for M5 family device.

Project

src outputs ip_core

ip_top.v(define by user)

emif_usb_ip_top.v

emif_usb_top.v

emif_sfr2wb_wrapper.v

simsrc doc example

testb_usb.v

usb_host_model.v

mcu_behave.v

CME_USB20_user_guide_EN02.pdf

prj


= directory

= source RTL code

= simulation related files

= documentation

usb20_device_v2

src_vp

*.vp(Protected RTL)

file_list.f

usb_sim.do

firmware

m5_usb.c

m5_usb.h

m5_usb_hw.c

m5_usb_hw.h

app

m5_device_related_module.v

CME3_sim.v

tb_m5

Figure 4-1 USB IP wizard generated file directory structure of M5

Table 4-1 Generated File Directory structure of M5

Directory Description

src\ Directory for project source code, including IP wizard

generate code, for example: ip_top.v, which instantiate the

USB2.0 Device IP and define related parameters

ip_core\ The directory specially for all IPs



\usb20_device_v2 Directory for USB2.0 Device IP

\doc\CME_USB20_user_guide

_EN02.doc

User guide version 2 for USB2.0 Device IP

\src IP Design RTL

emif_usb_ip_top.v USB2.0 Device IP top module (Encrypted)

emif_usb_top.v USB2.0 core control module (Encrypted)

emif_sfr2wb_wrapper.v EMIF to wishbone transform wrapper logic (Encrypted)

m5_device_related_module.v Specific hard-IP(like EMB) of M5 device used in design

\sim Design functional verification

\tb_m5\testb_usb.v Test bench top module

\tb_m5\usb_host_model.v The behavior module of USB host

\tb_m5\phy_clk_output.v The module used to generate PHY clock

\tb_m5\mcu_behave.v MCU behavior model for EMIF interface

\tb_m5\host_utmi2ulpi.v UTMI to ULPI behavior module

\tb_m5\usb_demo.v,

local_user.v

USB IP demo RTL, and local memory access RTL

\tb_m5\gbuf_v1.v, MyMcu.v,

MyPll60.v

Gbuf, MCU, PLL module instantiate from Wizard

\tb_m5\CME3_sim.v M5 simulation library file

\tb_m5\file_list.f File list of simulation related file

\src_vp\*.vp Protected USB2.0 Device IP design RTL for Modelsim

simulaiton

usb_sim.do For Modelsim simulation

\example

prj example design FPGA project

app The driver application

CME_USB20_example_user_

guide_EN02. pdf

User guide of example design

\firmware

m5_usb.c Define the USB device request response function

m5_usb.h The header file for m5_usb.c

m5_usb_hw.c High level USB device usage function

m5_usb_hw.h The header file for m5_usb_hw.c

4.2 File Directory Structure in M7 family device

Following is the detailed directory structure with figure and table description for M5 family device.



Project

src outputs ip_core

ip_top.v(define by user)

ahb_usb_ip_top.v

ahb_usb_top.v

ahb_sfr2wb_wrapper.v

simsrc doc example

testb_usb.v

usb_host_model.v

mcu_behave.v


prj


= directory

= source RTL code

= simulation related files

= documentation

usb20_device_v2

src_vp

*.vp(Protected RTL)

file_list.f

usb_sim.do

firmware

m7_usb.c

m7_usb.h

m7_usb_hw.c

m7_usb_hw.h

app

m7_device_related_module.v

m7_sim.v

tb_m7

Figure 4-2 USB IP wizard generated file directory structure of M7

Table 4-2 Generated File Directory structure of M7

Directory Description

src\ Directory for project source code, including IP wizard

generate code, for example: ip_top.v, which instantiate the

USB2.0 Device IP and define related parameters

ip_core\ The directory specially for all IPs

\usb20_device_v2 Directory for USB2.0 Device IP

\doc\CME_USB20_user_guide

_EN02.doc

User guide version 2 for USB2.0 Device IP

\src IP Design RTL

ahb_usb_ip_top.v USB2.0 Device IP top module (Encrypted)

ahb _usb_top.v USB2.0 core control module (Encrypted)

ahb _ahb2wb_wrapper.v AHB to wishbone transform wrapper logic (Encrypted)

m7_device_related_module.v Specific hard-IP(like EMB) of M7 device used in design

\sim Design functional verification

\tb_m7\testb_usb.v Test bench top module



\tb_m7\usb_host_model.v The behavior module of USB host

\tb_m7\phy_clk_output.v The module used to generate PHY clock

\tb_m7\mcu_behave.v MCU behavior model for EMIF interface

\tb_m7\host_utmi2ulpi.v UTMI to ULPI behavior module

\tb_m7\usb_demo.v,

local_user.v

USB IP demo RTL, and local memory access RTL

\tb_m7\gbuf_v1.v, MyPll60.v,

armcm3_v10.v

Gbuf, MCU, PLL module instantiate from Wizard

\tb_m7\m7_sim.v M7 simulation library file

\tb_m7\file_list.f File list of simulation related file

\src_vp\*.vp Protected USB2.0 Device IP design RTL for Modelsim

simulaiton

usb_sim.do For Modelsim simulation

\example

prj example design FPGA project

app The driver application

CME_USB20_example_user_

guide_EN02. pdf

User guide of example design

\firmware

m7_usb.c Define the USB device request response function

m7_usb.h The header file for m7_usb.c

m7_usb_hw.c High level USB device usage function

m7_usb_hw.h The header file for m7_usb_hw.c



5 Revision History

Revision Date Comments

1.0 2013-07-28 Initial release

2.0 2014-03-05 Add support of ULPI interface, vendor device

request and configurable endpoints number.

2.1 2014-7-18 Change the shared buffer & bus among IN,

OUT and CTRL, into three buffers for the three

kind of Endpoints(IN, OUT and CTRL)

respectively.

usb 2.0 device · 3、packet assembly this block assembles packets and places them in to the output...

Documents