USB Receiver/Transmitter for FPGA Implementation · 2017-12-28 · USB Receiver/Transmitter for...

www.semargroups.org,

www.ijsetr.com

ISSN 2319-8885

Vol.02,Issue.10,

September-2013,

Pages:1031-1036

Copyright @ 2013 SEMAR GROUPS TECHNICAL SOCIETY. All rights reserved.

USB Receiver/Transmitter for FPGA Implementation LEVAKU JYOTHI

1

M.Tech, ECE Dept, Srinivasa Institute of Technology and

Science, Kadapa, AP-INDIA.

E-mail: [email protected].

G.VENKATA SURESH BABU2

Assoc Prof, ECE Dept, Srinivasa Institute of Technology and

Science, Kadapa, AP-INDIA.

E-mail: [email protected]

Abstract: The paper is a study of USB standard based on

authors own concept of specialized digital architecture

providing USB communication. Presented module

connects peripheral device with a computer via USB

cable. In accordance with functionality, the design was

partitioned to three units. UTMI block deals with USB

cable, time frame synchronization and serial transmission.

PIE block, divided to two parts, is responsible for packet

construction/extraction and byte oriented communication

with the peripheral system. Each module is controlled by

the dedicated Finite State Machine. The architecture was

implemented in VHDL, verified and synthesized. Design

complexity arises questions about feasibility of USB

interface application in specialized devices and low

volume segments of electronic devices, especially when

compared to traditional RS232/UART interfaces.

Keywords: USB, UTMI block, VHDL, RS232/UART

interfaces.

I. INTRODUCTION

Universal Serial Bus (USB) interface since its

introduction has gained huge interest and scale of

application. In spite of this popularity, details and

capabilities of protocol remain unknown to some digital

circuit’s designers. One of the reasons is surprisingly high

level of functional and structural complexity of USB

interface [1]. Analysis of some details especially when

compared with the other serial data transmission systems,

supported by observation of the market trends may lead to

creative ideas opening the new paths in contemporary

digital communication. This paper presents the authors

own concept of USB receiver/transmitter architecture.

The concept was implemented in hardware description

language to provide model for simulations.

Simultaneously the code is synthesizable, and may be

physically implemented in programmable logic devices.

At this stage the full functionality is not ready; however

significant part is available for embedding in any digital

system that requires high speed communication with

computer.

II. USB PROTOCOL OVERVIEW

USB protocol provides communication between

computer and peripheral device. Its construction is based

on 3 layers:

Functional, which covers high-level relations

between a computer program and a peripheral

device,

Logic, responsible for the flow of data stream,

Physical, including wires, connections, analog

devices.

Physical connection consists of 4 wires – 2 for power

and 2 for bi-directional differential data transmission. The

same set of wires may be shared by up to 127 peripheral

devices (USB2.0). The master functionality of host

includes control of the time division multiple access to

communication channel. Depending on character (speed)

of the peripheral device this time division may be based

on frames or micro-frames. For a single frame 1 ms is

allotted whilst for micro-frame it is 125 μs. The begin of

each frame is determined by the specific Start of Frame

packet sent by host. The rest of frame space may be used

for transmission of other packets, which may contain

control, symbols or payload. Each peripheral device is

recognized by its unique endpoint number (ENDP) and

this number is used to allocate a frame in a time scale.

Time division multiple access enables concurrent

communication of host with several devices. Whilst the

frames organize the time space for transmission, the data

is transmitted in packets [1,2]. General structure of USB

packet is presented in Fig. 1. The start and end of packet

are determined by the 8-bit SYNC and EOP patterns

respectively. PID is the 8-bit packet identifier. Depending

on transmission type, the PAYLOAD field may contain

various kinds of data and some more specific fields (e.g.

mailto:[email protected]

LEVAKU JYOTHI, G.VENKATA SURESH BABU

International Journal of Scientific Engineering and Technology Research

Volume. 02,IssueNo.10, September-2013, Pages:1031-1036

address, frame number). For packets containing data the

length of PAYLOAD field may reach 8192 bits. For

control packets it is shorter, e.g. 8 bit. CRC is the result of

cyclic redundancy check calculated for the payload field

only.

In the typical communication scenario the host -

computer, starts transmission by sending some data to the

peripheral device. In the very begin the transmission

parameters (e.g. speed, kind of packets to be transmitted)

are clarified and then the transmission may start.

Figure1. USB packet construction

There are 4 main types of transmission:

Control transmission, used for setting up the devices.

Ischronous transmission used for real time

transmission of data (to/from e.g. camera,

microphone, and speaker).

Interrupt transmission, used for very fast transmission

of small data structures (e.g. from a mouse).

Bulk transmission, asynchronous, designed for huge

amount of data, optimized for speed and protection of

data integrity (e.g. flash memory, hard disk).

III. ARCHITETURE

USB interface in the peripheral device consists of two

main blocks - the USB Transceiver Macrocell Interface

(UTMI) and the Parallel Interface Engine (PIE). UTMI

interacts with the cable and PIE with the digital system

embedded in the peripheral device. Consequently the

UTMI block deals with SYNC and EOP patterns, whilst

PIE constructs packets and deals with the PID field.

Communication between the 2 modules is provided by 3

groups of signals. In the first group there are data in and

data out – separate signals for data transmission in both

directions. The second group – TX valid and TX ready

controls the transmission in the direction from peripheral

device to the computer, i.e. from PIE to UTMI. The third

group consists of 3 signals – RX active, RX valid and RX

error, which control the process of data transmission from

the computer to the peripheral device, i.e. from UTMI to

PIE.

A. UTMI block

General schematic of UTMI block is presented in Fig. 2.

According to the functionality it is divided to parts

responsible for transmitting and receiving the data.

Separate part provides two clocks - 60 and 480 MHz. On

the receiver side the incoming serial data (480 MHz) is

recovered from the nonreturn to zero inverted (NRZI)

shape and stored in the deserializer shift register. Then it

is sent to 8-bit data out bus. Finite State Machine controls

the process and drives all the RX signals communicating

with PIE block. The transmitter part collects the data

coming in parallel from PIE (8-bit data out bus, 60 MHz),

serializes the stream, codes it to NRZI shape and sends

serially to the cable, with the frequency of 480 MHz. This

Figure2. USB Transceiver Macrocell Interface (UTMI)

block.

functionality is controlled by another branch of the Finite

State Machine, dependent on the TX valid signal coming

from PIE. Simultaneously the FSM is responsible for

sending the TX ready signal to PIE. Additional function of

receiver and transmitter parts is recognition and

construction of the SYNC and EOP patterns respectively

[3,4]. Schematic of the UTMI FSM is presented in Fig. 3.

During typical receive operation the FSM transits from

SWAIT idle state to RSYNC when the SYNC pattern sent

by a computer is detected in a shift register. The next state

is RDATA_LOAD. In this state the stream of data is

continuously deserialized and sent to the 8-bit data in bus,

until the EOP signal is recognized. (The erroneous

detection of SYNC and EOP is avoided by bit

stuffing/unstuffing). After detection of EOP, the FSM

transits to REOP state where the receive operation is

finished. If there are no errors detected, the next state is

SWAIT. The other branch of FSM controls the transmit

process. PIE module may generate a request to transmit

data to a computer, by setting the TX valid signal to ‘1’. If

the UTMI is not busy e.g. receiving data from computer

or dealing with errors, i.e. the FSM is in the SWAIT state,

it may transit to the TSYNC_LOAD state. In this single

clock cycle state the SYNC pattern is loaded to the serial

output buffer. Then the FSM transits to the TSYNC state,

USB Receiver/Transmitter for FPGA Implementation



Where the SYNC pattern is transmitted serially to the

USB cable. In the next state - DATA_SENDING, the

regular transmission takes place. PIE block sends

consecutive bytes via the 8-bit data out bus with 60 MHz

frequency and UTMI serializes them for 480 MHz output.

When the PIE block decides to stop the transmission, it

switches the TX valid signal back to ‘0’. The FSM

transits to TEOP state where the EOP pattern is loaded to

the buffer and then shifted out. The next state is SWAIT

again. Switching the TX valid line to ‘0’ during the

transmission causes the FSM transit to the SERROR state.

Figure3. Finite State Machine controlling the USB

Transceiver Macro-cell Interface (UTMI) blocks.

B. PIE block

Parallel Interface Engine provides byte oriented

communication between UTMI and the peripheral device

functional blocks. On the receiver side it extracts and

deals with special parts of packet – Packet Identifier

(PID) and CRC coming from the cable, via UTMI. The

transmit functionality contains preparation of CRC-5 and

CRC-16 codes, General schematic of PIE block

interconnection is presented in Fig. 4. Its architecture was

divided to two parts – PACKET and TRANS, controlled

by two separate Finite State Machines. The key

functionality of PACKET module is extraction, analysis

and construction of packets, in particular PID and CRC

fields. Schematic of the appropriate FSM is presented in

Fig. 5. Receive and transmit functions are realized in two

different branches accessible from the common NONE

state. The receive sequence starts from the detection of

SYNC pattern in the UTMI, signaled by the high state of

RX active and RX valid lines. In the next state – RPID,

the packet identifier (PID) is recognized. PID determines

the content of the packet and consequently further

sequence of states. For packets containing data the next

state would be RPID_DATA, whilst for special packets

like token or “start of frame”, the next states are

RPID_TOKEN and RPID_SOF respectively. Regardless

of the branch taken, the low state of RX active line from

UTMI signals end of transmission. In the next state –

RCHECK, the CRC code which has been calculated on-

line is compared with the incoming one attached to the

end of packet. Depending on CRC result the next state is

either RFIN where the transmission is closed or the

SERROR where the alerts about invalid data are

generated.

The other branch of FSM controls data transmission

functionality, with alternative sequences depending on the

kind of packet to be sent (data or various kinds of control

again). Behavior of the TRANS Module strongly depends

on control packets received by UTMI block and

recognized by PACKET module. TRANS module

performs dialog with the computer, but on the higher level

of abstraction, consequently variety of its reactions is

more complicated. Depending on the requested action –

receive or transmit, the Finite State Machine, presented in

Fig. 6, transits form the IDLE state to SOUT or SIN states

respectively. SOUT starts the receive operation. The basic

sequence of states WAIT_4_PID_DATA, RPID_DATA,

RDATA, and RECEIVING_DATA leads to collection of

bulky data. Final stage of receive operation requires

handshake response sent to the computer in the form of

acknowledgment or not acknowledgement packets. This

action is performed in the two alternative branches with

WAIT2_ACK/TACK and WAIT2_TNAK/TNAK

sequences respectively. After sending the handshake the

Finite State Machine goes back to the IDLE state.

Alternative branch of the FSM controlling TRANS

module starts from the SIN state.

The next state is WAIT2T_PID_DATA, where the

TRANS module sets the TX valid signal to ‘1’ requesting

UTMI block to send the SYNC pattern to the USB cable.

If the UTMI is able to do it, it responds with a TX ready

signal (via the PACKET block) and the next state is

TPID_DATA. In this state the TRANS block sends the

packet identifier to 8-bit data out bus. Simultaneously it

sets the TX valid signal to inform the prospective

peripheral system that the transmission may start. In the

next TPID_DATA state the main transmission takes place

until the peripheral system resets the Ready line to ‘0’

(typically after sending all the data) and then the

PACKET module sets the TX fin signal to ‘1’ (after

transporting the last byte of packet to UTMI). The next

state is WAIT_4_ACK. All the blocks wait for

appropriate handshake packet, which must be sent by the

computer. If the appropriate PID is recognized the next




state is IDLE. If any other PID is received the next state is

SERROR. This state may be reached from most of the

states when further step of transmission is impossible, e.g.

because some device is busy. Depending on the reason,

the appropriate alerts may be sent to the peripheral or to

PACKET and UTMI blocks.

IV. IMPLEMENTATION

Presented architecture, was implemented in VHDL [5].

The code was partitioned to 3 main entities, containing

the 3 Finite State Machines as described in the previous

section. All the logic signals and operations refer to the

std_logic_1164 package from the IEEE library [6]. The

design is full synchronous with 2 clock domains.

Verification plan covered individual tests of all the blocks

and a few scenarios of data exchange engaging the whole

design. Eventually the code was successfully synthesized

using Xilinx ISE tools [7,8].

Figure4. Parallel Interface Engine (PIE) block structure and

connection Schematic.

Figure 5. Finite State Machine controlling PACKET module of Parallel Interface Engine block.

USB Receiver/Transmitter for FPGA Implementation



Figure6. Finite State Machine controlling TRANS module of Parallel Interface Engine block.

V. CONCLUSIONS

Selected details of construction and functionality of

USB protocol were presented. Introduction was followed

by author’s proposal of dedicated hardware containing the

most of data transmission mechanisms. The design was

partitioned to three modules forming a system of bi-

directional, sequential data flow. Each module,

responsible for specific stage of data processing is

controlled by its own Finite State Machine. The other

imaginable solutions are splitting the architecture in

accordance with direction of data transmission, to the two

parts – receive and transmit, controlled by e.g. two Finite

State Machines or implementation of all the functionality

in a single automaton. Selected approach brings some risk

of deadlock caused by cross-dependencies of the three

automata. Its key advantage however is preservation of

natural concurrency of operation of the three modules.

Functionality of USB interface quite often requires

simultaneous processing of various parts of transmitted

data. USB is nowadays probably the most commonly used

interface between computer and peripherals. There is

constantly growing number of low-cost devices, whose

great advantage shall be ease of use. Detailed analysis of

protocol mechanisms, accompanying presented project

led to the surprising conclusion that these mechanisms are

very complicated. Variety of sequential actions and

reactions that must be performed to provide the plug and

play operation of the target device requires substantial

effort devoted to both design and verification of the

prospective module. This level of complication is hard to

justify. And it forces digital design teams to buy and reuse

the appropriate Intellectual Property modules rather than

develop their own versions and integrate them with the

application specific architectures, e.g. on the Hardware

Description Language code level. This practice remains in

total opposition to the old RS232 serial interface, where

the design of UART modules used to be a popular task for

students and young engineers starting their careers in

digital electronic design. Another functional difference

between USB and RS232 is the need for software drivers

providing the computer operating system’s supervision

and communication with the USB equipped device.

Problems with drivers compatibility and installation are




well known for all users of niche products and made them

skeptical about the plug and play myth. These problems

are rarely observed for massive products where the

vendors are able to (technically speaking) buy the

compatibility with e.g. Microsoft Windows systems. The

third issue and limitation for individual constructions of

USB interfaces and their embedding in the designs

implemented in low-cost programmable logic devices is

relatively high clock frequency of the serial transmission.

480 MHz remains quite high and difficult to reach in the

low cost programmable circuits available nowadays (A.D.

2011/2012). Continuous development and growing speed

of FPGA circuits will eventually enable implementation

of architectures working with this speed. Before that time

however, the faster version of USB may become the new

standard. These three issues rise serious questions about

the sense of continuous growth of variety and volume of

USB based devices on the market. Seems like the reliable

(unlikely to crash), designer friendly and user friendly

RS232-UART solution was replaced by much faster USB

for the price of more frequent crashing, problems with

drivers, and loosing open character of design. This

replacement is extensively supported by personal

computer vendors, removing RS232 from main boards as

obsolete. The little and desperate exception from this

trend is “RS232 over USB” concept based on popular off-

the-shelf FT232 circuit which enables connection of

classic UART interface with RS232 dedicated computer

software via the USB socket. This approach is extensively

used by developers of specialized devices and in some

low-cost products. For the higher speeds however, at this

stage, there is no escape from purchasing USB cores

developed by small group of the design houses and then

either fabricated as separate chips or embedded in the

higher quality programmable logic devices.

VI. REFERENCES

[1] Universal Serial Bus Specification, rev. 2.0,

(www.usb.org), 2000.

[2] J. Axelson, USB Complete. Everything You Need to

Develop Custom USB Peripherals, Third Edition,

Lakeview Research LLC, 2005.

[3] USB 2.0 Transceiver Macrocell Interface (UTMI)

Specification, Version1.05, Intel Corporation, 2001.

[4] Jang Jin Nam, USB 2.0 PHY Design Compatible to

UTMI Specification, 2003.

[5] IEEE Standard, VHDL Language Reference Manual,

(IEEE Std 1076), 2000 Edition.

[6] IEEE Standard nr 1076, VHDL Language Reference

Manual.

[7] Xilinx ISE Web Pack, ver 12.3, www.xilinx.com,

2011.

[8] Xilinx Spartan-3 Family Complete Data Sheet,

(www.xilinx.com),

Xilinx Inc. 2007,

Authors Profile:

Levaku Jyothi ,M.Tech

Research Scholar, Srinivasa

Institute of Technology and

Science, Kadapa, AP-INDIA,

E-mail: [email protected]

G.VENKATA SURESH BABU,

M.Tech, Assoc Prof, Srinivasa

Institute of Technology and

Science, Kadapa, AP-INDIA,

Experience: 9Years

E-mail: [email protected].



USB Receiver/Transmitter for FPGA Implementation · 2017-12-28 · USB Receiver/Transmitter for...

Documents

Transcript of USB Receiver/Transmitter for FPGA Implementation · 2017-12-28 · USB Receiver/Transmitter for...