haftu_hailezgy

8/3/2019 Haftu_Hailezgy

1/109

Addis Ababa University

School of Graduate Studies

Faculty of Technology

Department of

Electrical and Computer Engineering

USB Interface protocol implementation on

Field programmable gate array (FPGA)

A thesis submitted to the Faculty of Technology, Department ofElectrical and Computer Engineering, in partial fulfillment for the

degree of Master of Science Computer Engineering.

By:

Haftu Hailezgy

Advisor: Prof. Dr. Gerald Higelin

February 2010

Addis Ababa, Ethiopia.


2/109

USB Interface protocol implementation on FPGA

MSC thesis by Haftu Hailezgy, Addis Ababa University, Department of Electrical and Computer Engineering, 2010 2

Acknowledgments

I was not alone in this thesis; other people have also contributed in different forms.

Primarily I want to thank my Advisor Professor Gerald Higelin for not only advisingand guiding me but also for providing me the title and supplying me his own FPGAs

for testing and implementation purposes.

My girl friend Yemisrach Tekle along with my friends Addisu Minalu and Tadele

Admasu, who have helped me with constant encouragement and materialcontribution, should be endowed with my gratitude. And finally I want to say thank

you for my family, my friends and my old colleagues at ETC who have been on my

side from the beginning of the journey.


3/109



Abstract

Now a days most of the old computer interfaces seems to converge in to the popular

and easy to use USB interface. Billions of electronics devices in the market connectthemselves to computers for different purposes using this interface. But USB

interface development is not easy as using it.

In this research, VHDL code for USB interface protocol was written, compiled,

synthesized, simulated and tried to implement in Xilinx Spartan 3 FPGA. The work

includes the development of the serial interface engine and the USB transceiver. It

has been developed by following the documents of USB2.0 specification, UTMI 2.0

specification and CDC-ACM 1.10 specification. Most of the requirements in these

documents are tried to be implemented.

The whole works is done on the FPGA side using the popular hardware description

language, VHDL. This means no special driver and application software was

developed in the computer side. Instead it uses the built in usbser.sys driver with

some modification to the .inf file to tell the vendor and product identification

numbers of the FPGA to the computer.

The USB program package was developed by dividing it in to different modules that

perform different activities simultaneously. The modules have their own finite

state machines and simulated independently then the entire components are

sintegrated and a 512byte RAM for storing USB descriptors information and forbuffering temporary receive and transmit data packets was also implemented.

Simple VHDL application is also developed for testing purpose which is intended to

receive data bytes from the windows built in hyper terminal emulation software,

stores in memory and sends back to the host when requested.

Only portable VHDL is used so that the hardware system can work on different

target FPGA computing boards. Finally the protocol was simulated on Xilinx ISE

simulator using test bench file by giving inputs what the host would give. The bit file

of the protocol also downloaded to the FPGA and programmed. The computer

identifies a USB device is attached but as malfunctioned one. To avoid the error, abig effort has been done manually because the absence of digital logic analyzer tools

and digital microscopes with a buffer that stores the data interactions that

happened in nanoseconds.


4/109



Contents

Acknowledgments 2

Abstract 3

Contents 4

List of figures 6

List of tables 8

Terms and abbreviations 9

1 Introduction 11

1.1 Overview USB interface 11

1.2 Overview of FPGA 12

1.3 Motivation 13

1.4 Objective 14

1.5 Approach 14

1.6 Scope 14

1.7 Thesis outline 15

2 Background 16

2.1 Specification documents 16

2.1.1 USB 17

2.1.2 UTMI 31

2.1.3 CDC and ACM 35

2.2 HDL Based FPGA design process 42

2.2.1 Hardware Description Languages 42

2.2.2 FPGA design flow 44


5/109



3 Design of the project 46

3.1 Overall design 46

3.2 Components and their design 47

3.2.1 Rcvr module 47

32.2 Trnsmtr module 52

3.2.3 Pkt module 55

3.2.4 Trnsct module 60

3.2.5 Cntrl module 65

3.2.6 Fpga_usb module 71

3.2.7 Application test module 76

4 Tests and Results 79

4.1 Devices and tools used 79

4.2 Simulation test cases and results 79

4.3 FPGA test procedures and results 101

5 Conclusion and Recommendation for future Works 103

5.1 Challenges 103

5.2 Summary and conclusion 104

5.3 Recommendation for Future Works 105

5.4 Research Application and contribution 105

6 Bibliography 106

7 Appendices 108

A. VHDL codes A1

B. Test bench codes A34


6/109



List of FiguresFigure2.1 Block diagram of USB controller [2] 16

Figure2.2 USB Protocol architecture[1]

17Figure2.3 Basic format of a USB transaction 21

Figure2.4 Sync sequence 21

Figure2.5 PID format 22

Figure2.6 EOP signaling 22

Figure2.7 Typical USB packet format 22

Figure2.8 Enumeration process 23

Figure2.9 Control transfers stages and phases 24

Figure2.10 Example of control transfers stages for get_dsc_rqst request 28

Figure2.11 Control transfer with no data stage 28

Figure2.12 control transfer when the host is requesting data 28

Figure2.13 control transfer when the host wants a write request 29

Figure2.14 OUT transaction 30

Figure2.15 IN transaction 30

Figure2.16 UTMI functional block diagram for full speed only 32

Figure2.17 Bit stuffing and NRZI encoding 33Figure2.18 Full speed device with pull up resistor connected to D+ 35

Figure2.19 HDL-based FPGA design flow 45

Figure3.1 Overall USB protocol design 46

Figure3.2 Entity of the rcvr module 47

Figure3.3 State machine diagram of rcvr module 48

Figure3.4 Sync byte detection state machine diagram 49

Figure3.5 Stuffed bit and bit stuff error detection state diagram 50

Figure3.6 EOP and EOP error detection state diagram 51

Figure3.7 Entity diagram of the trnsmtr component 52

Figure3.8 The state machine diagram of the trnsmtr component 53

Figure3.9 State machine diagram for detecting consecutive bits that needs bit

stuffing

54

Figure3.10 The entity of the pkt component 55


7/109



Figure3.11 State machine diagram of packet module 57

Figure3.12 Token packet 58

Figure3.13 Data packet format 59

Figure3.14 the Entity of the trnsct component 61Figure3.15 the state machine diagram of transct component 62

Figure3.16 Second byte of a token 63

Figure3.17 Third byte of a token 63

Figure3.18 The Entity diagram of cntrl module 66

Figure3.19 state machine diagram of cntrl module 68

Figure3.20 Entity diagram of the fpga_usb module 71

Figure3.21 State machine diagram of the fpga_usb component 72

Figure3.22 512 RAM memory for storing descriptors and data from host andto host

74

Figure3.23 State machine diagram of the test application 77

Figure4.1 Enumeration simulation steps 81

Figure4.2 Simulation snapshot when Setup token is input to test bench 82

Figure4.3 Simulation snapshot when receiving device descriptor request 83

Figure4.4 Simulation snapshot transmitting ACK packet 84

Figure4.5 Simulation snapshot when receiving IN token with default address

and control end point (both zero)

85

Figure4.6 Simulation snapshot when transmitting the eighteen byte device

descriptor.

86

Figure4.7 Simulation snapshot when receiving ACK packet 87

Figure4.8 Snapshot of out token with default address and endpoints 88

Figure4.9 Simulation snapshot when receiving set address request 83

Figure4.10 FPGA address changed from the default value (zero) to the

assigned value (two)

89

Figure4.11 Simulation snapshot when receiving setup token with address =2

and end_pt=0

90

Figure4.12 Simulation snapshot when receiving configuration descriptorrequest

91


8/109



Figure4.13 Simulation snapshot when transmitting configuration descriptor 92

Figure4.14 out token with address=2 and end_pt=0 93

Figure4.15 Simulation snapshot when receiving OUT token with address=2

and end_pt=1

94

Figure4.16 Simulation snapshot when receiving user data input 95

Figure4.17 Simulation snapshot when receiving IN token with address=2 and

end_pt=1

96

Figure4.18 Simulation snapshot when transmitting from transmit buffer 97

Figure4.19 Setup token with mismatched CRC value 98

Figure4.20 A token packet with Unknown PID type 99

Figure4.21 Stall handshake packet is returned for unsupported requests 100

Figure4.22 wrong sync pattern 100

List of Tables

Table2.1 Request types and their descriptions 26

Table2.2 Descriptor Types and Values 29

Table2.3 USB classes and their class codes 36

Table2.4 Subclass codes of CDC class 38

Table2.5 Values and descriptions of the memory that hold device descriptor 39

Table2.6 Values and descriptions of the memory that holds configuration

descriptors

40

Table3.1 Data interface signals and their descriptions for rcvr module 48

Table3.2 Data interface signals and descriptions for trnsmtr component 53

Table3.3 Data interface signals for pkt component 56


9/109



Table3.4 Data interface signals of trnsct component 62

Table3.5 cntrl module signals and their description 68

Table3.6 Signal description of fpga_usb component 72

Table3.7 Data interface signals of application module 77

Terms and Abbreviations

Addr Address of FPGA assigned by a computer USB system.ACK Acknowledgement: packet that informs success of transfer.

ACM Abstract control model: subclass of communication device class.

CLB Control logic block

CDC Communication device class: one of the USB standard classes.

Cntrl Control: a module that implements the enumeration process.

CRC

Cyclic redundancy check: error checking mechanism of USB

protocol.

DCM Digital clock manager.

Dm

Data - : deferential signal that is transmitted using the white line

of the USB cable.Dp Data +: deferential signal that is transmitted using the green line

of the USB cable.

End_pt End point: data sources and sinks of USB protocol.

EnumEnumeration: the initial process where USB devices express theirattributes to the host computer.

EOP End of packet: signals that can inform the end of transaction.

FPGAFS

HS

Field programmable gate arrays.

Full speed: 12Mb/s.High speed: 480Mb/s.

FSM Finite state machine

Init Initialization process of the USB system.

ISE Integrated Software Environment.JTAG

LS

Joint Test Action Group.

Low speed: 1.5Mb/s.

LSB Least significant bit: the last bit of a byte.

MSB Most significant bit: the first bit of a byte.

NAK Negative acknowledgement.


10/109



NRZI Non return to zero inverses on 1: encoding method.

PACE Pin out and Area Constraints Editor.

PID Packet identification.

Pkt Packet: a module that performs CRC check.

PLL Phase Locked Loop. Circuit used for frequency generation.RAM Random access memory.

rcvr Receiver: a module that receives bits from host.

Reg Register: stores signals value in the FPGA.

RTL Register Transfer Level.

Rx Receive

SIE Serial Interface Engine: the main USB protocol.

SESig

Single Ended: a deferential signal where both Dm and Dp are low.

Signal: it is a variable for storing values.

Stl Stall: handshake mechanism replied for unsupported requests.

Sync Synchronization pattern: eight bits start of packet pattern in USB.Trnsct Transaction: a module that performs different transactions.

Trnsmtr Transmitter: a module that transmits bits to the host.

Tx Transmit

USB Universal serial bus.

USB IF Universal serial bus - Implementation forum.

UTMI USB transceiver macrocell interface.

var Variable: local variable in a process.

VHDL Very high speed integrated circuit Hardware Description Language.

XST Xilinxs synthesis tool.


11/109



CHAPTER ONE

INTRODUCTION

1.1 OVERVIEW OF USB INTERFACES[4]USB is a computer interface which has plenty features that pleases both the users

and developers in the following ways:

Benefits for Users

USB has become very popular by users that is why over 6 billion USB products are inthe market today. From the users perspective, the benefits of USB are

ease of useo One interface for many devices.o Automatic configurationo Easy to connecto Easy cableso Hot pluggableo No user settingso Frees hardware resources for other deviceso No power supply required (sometimes)

fast peedo super speed 5 Gigabits/sec (started at USB 3.0 )o high speed at 480 Megabits/sec (started at USB 2.0)o full speed at 12 Megabits/seco low speed at 1.5 Megabits/sec

data transfers port expansion reliable flexibility low cost Power conservation Wireless connectivity possible

Benefits for Developers

Many of the user advantages described above also make things easier for

developers.

Versatility Operating System Support

o Detect when devices are attached to and removed from the system.o Communicate with newly attached devices to find out how to

exchange data with them.


12/109



o Provide a mechanism that enables software drivers to communicatewith the computers USB hardware and the applications that want toaccess USB peripherals.

Peripheral SupportLimitation of USBAll of USBs advantages mean that its a good candidate for use on many peripherals.

But a single interface cant handle every task.

Interface Limits

Speed may not be enough for todays huge applications Distance is limited to maximum of 5 meters Peer-to-Peer Communications not possible Broadcasting Legacy hardware

Developer Challenges

Protocol complexity. Evolving support in the operating system. Fees for vendor ID.

In a USB system the three major actors are:

I. The Host (Computer) Detects devices Manages data flow Error checking Provides power Exchanges data with peripherals

II. The Device (Peripheral) Detects communications directed to the chip Responds to standard requests Error checking Manages power

III. Hub Provides additional attachment points to the USB Amplifies and repeats data signals Enables the distribution of power to downstream devices.

1.2 OVERVIEW OF FPGA

A field programmable gate array (FPGA) is a semiconductor device that can be

configured by the customer or designer after manufacturing. It is an integrated

circuit that contains many identical logic cells that can be viewed as standard


13/109



components. The individual cells are interconnected by a matrix of wires and

programmable switches. A user's design is implemented by specifying the simple

logic function for each cell and selectively closing the switches in the interconnect

matrix. The array of logic cells and interconnects form a fabric of basic building

blocks for logic circuits. Complex designs are created by combining these basicblocks to create the desired circuit.

To define the behavior of the FPGA, the user provides a hardware description

language (HDL) design. Todays FPGAs boast the following:

Low cost Low power Fast circuit speed Large on-chip memories Easy to use design software A large portfolio of customizable IP

Advantages include a shorter time to market, ability to re-program in the field to fix

bugs, and lower non-recurring engineering costs. Vendors can also take a middle road

by developing their hardware on ordinary FPGAs, but manufacture their final

version so it can no longer be modified after the design has been committed.

Applications of FPGAs include:

Digital signal processing Software defined radio Aerospace and defense systems ASIC prototyping Medical imaging Computer Interfacing Speech recognition Cryptography Bioinformatics Computer hardware emulation And a growing range of other areas

1.3MOTIVATION

Given the popularity USB interface is getting these days as millions of small and

mobile electronics are joining the market, to have the understanding of the design

of this protocol is very crucial for different uses and for integrating with many

electronics products as well as for further friendship with the digital electronics


14/109



world and this motivates for this application research to be developed using the

popular IEEE standard hardware description language, VHDL . Researches on digital

hardware designing and programming is very difficult in countries like Ethiopia

where there is no IC manufacturing companies hence FPGA seems the only choice to

at least test the prototype.

1.4OBJECTIVE

The general objective of this masters thesis project is to develop, simulate,

implement and test USB interface protocol on FPGA.

The specific objectives are to:

Develop USB interface protocol on the FPGA that enables to connect itto PC using USB interface with out writing a driver software andapplication software on the computer side.

Simulate the protocol on simulation tools. Test the protocol on hardware (FPGA).

1.5APPROACH

After thoroughly reading and understanding the specification documents needed to

develop the end to end USB protocol, VHDL programming language was studied andpracticed. Then the work was designed and divided in to components.

Each subcomponent was developed and simulated alone and modified continuously

until the expected correct results were found. Finally the components wereintegrated by a top module and simulated by writing appropriate test benches togive inputs to the stimuli and tested using Xilinx ISE simulator.

The final step was writing simple VHDL application that can receive and transmit

data from and to the host computer using the developed USB protocol. And theabove steps were followed by implementation, testing and troubleshooting theprotocol on a spartan3 Xilinx FPGA.

1.6SCOPE

The USB system is a dynamically developing area in which new features and classes

are being kept added. Given the time constraint, this work only includes USB 2.0 fullspeed only (maximum data transfer 12Mb/s) and it is back compatible with USB 1.1

host controllers but it does not support high speed data transfer.

It is designed to use one of the existing windows driver usbser.sys which is used for

communication device classes. However it implements only few of the requirements

by the CDC class.


15/109



1.7THESIS OUTLINE

This paper has five major chapters. The first chapter introduces what USB interface

is and its functions from the users and developers perspectives. The objective and

the scope of the research are also stated here in addition to an overview of FPGAs.Chapter two tells the background of the USB system by relating the different

necessary specification documents and what is implemented in this work. It also

gives introduction about VHDL language and FPGA design steps.

The third chapter is about the details of the overall design and the structure of

components. It briefs the input and output signals, the state machines and the

transitions of data as well as the control and status registers.

Chapter four shows how the design was tested and what results was found with

respective of simulation tools and FPGA implementations.

The conclusion, future work suggestion as well as the challenges faced and the

application areas of the research are stated in chapter five.

After a bibliography there are appendices containing the VHDL codes of the USB

interface protocol components, the specific application and the test bench.


16/109



CHAPTER TWO

BACKGROUND

2.1SPECIFICATION DOCUMENTS

USB system is a vast area such that to develop an end to end USB device, one has to

read in detail and understand at least the following documents.

1. Universal Serial Bus Specification. This specification puts details of the USBinterface protocol like packets, transfers, and transaction, flow and error

control mechanisms for both the device and host side.

2. USB Transceiver Macrocell Interface (UTMI) Specification: - is a standarddeveloped by Intel company and used to describe how to implement the lowlevel USB transceiver interfaces of the USB device.

3. Universal Serial Bus Class Definitions for Communication Devices. Thisone is specific for the class where the device is categorized. The FPGA is used

to be considered by the host as communication device.

USB is master/slave system in which the one which initiate the communication

(the master) is called the host and the slave is called the device. In this case thehost is the computer and the FPGA is the device.

Figure2.1. Block diagram of USB controller


17/109



Figure2.1 above shows the block diagram of USB controller, which exists in every

USB device. These are the three major functional blocks in USB 2.0 controllers: The

USB 2.0 Transceiver Macrocell Interface (UTMI), the Serial Interface Engine (SIE),

and the device specific logic.

2.1.1USBSPECIFICATION[1, 4,5]

USB protocol

The USB host handles most of the complexity of the USB protocol, which makes the

peripherals design relatively simple and low cost. Data flow can be from host to

device and/or from device to host.

Simple connection of a host to a USB device requires interaction between a number

of layers and entities as shown in the following figure.

Fig2.2 USB Protocol architecture [1]

USB Physical Device: A piece of hardware on the end of a USB cable that performs

some useful end user function. FPGA is the physical device for this work.

Client Software: Software that executes on the host, corresponding to a USB device.

This client software is typically supplied with the operating system or provided

along with the USB device. In this project windows hyper terminal software is to be

used as client software.


18/109



USB System Software: Software that supports the USB in a particular operating

system. It is typically supplied with the operating system, independently of

particular USB devices or client software.

USB Host Controller (Host Side Bus Interface): The hardware and software that

allows USB devices to be attached to a host.

The USB Bus Interface layer provides physical/signaling/packet connectivity

between the host and a device.

The USB Device layer is the view the USB System Software has for performing

generic USB operations with a device.

The Function layer provides additional capabilities to the host via an appropriate

matched client software layer. The USB Device and Function layers each have a view

of logical communication within their layer that actually uses the USB Bus Interface

layer to accomplish data transfer.The USB defines four data transfer types which are suited for different uses. These

transfers are:

1. Control transfer: It is a host software-initiated request responsecommunication, typically used for identification and configuration operations. It

is mandatory in every USB device. The configuration is done at the enumeration

process but can be done also at any state of the communication process. When a

device enters the system the host needs to learn about it and configure it at the

appropriate configuration, all this communication is done using the control

transfer. It is implemented and handled as the cntrl module in this design as will

be explained in chapter three.

2. Bulk transfer: Bulk transfer is used when a massive amount of data is to betransferred. It is used by devices that require it such as printers, scanners, mass

storages etc. The bandwidth allocated in each transaction of this transfer varies

according to the bus resources at the time. Bulk transfers are done reliably by

acknowledging each transaction.

Here in this work, it is implemented in the usb_fpga main module and its purpose is

to transfer the user data from the host computer to the FPGA device after

enumeration is done.

3. Isochronous transfer: Periodic, continuous communication between host anddevice, typically used for time-relevant information. It is used for multimedia

devices such as audio, video, etc. Important characteristic of the transfer is that

bandwidth is guaranteed i.e. the required bandwidth is reserved for the devices


19/109


20/109



Setup transaction: data travels from the host to the device, but it initiates acontrol transfer.

Every device should identify and respond to requests by setup transactions.

Any of the four transfer types may use IN or OUT transactions. Each transaction

contains a device address and an endpoint address. A device can have maximum of

16 end points.

In this thesis work, the mandatory bidirectional control end point has been

implemented in the cntrl module and one IN end point for IN transaction and one

OUT end point for OUT transaction for the bulk transfer are used and implemented

in usb_fpga module. Another IN end point for interrupt transfer is also implemented

though communications destined to the end point are to be stalled.

And the IN, OUT and Setup transactions are handled in the trnsct module.

USB Packets types

Every USB transfer consists of one or more transactions, and each transaction in

turn contains one, two, or three packets depending on the type. Packets are the

basic building blocks of USB transactions and there are different types of packet the

main types being:

Token Packet: -Each transaction begins with a token packet that definesthe destination device address, endpoint number, and the direction of the

data transfer.

Data Packet: -The data consists of a data packet that carries the payloadassociated with the transfer. A data packet can carry a maximum payloadof 1023 bytes of during a single transaction.

Handshake Packet: - all USB transfers (except isochronous) areimplemented to guarantee data delivery, and include a handshake packet

to verify a successful data transfer. If a packet error occurs, no handshake

packet is returned to the sender and an error is flagged. The host is

permitted to retry transactions that incur errors until the error count

reaches three.

Start-of-Frame Packets: The SOF token comprises the token-onlytransaction that distributes an SOF marker and accompanying framenumber at precisely timed intervals corresponding to the start of each

frame. All high-speed and full speed devices, including hubs, receive the

SOF packet.

The SOF, token and handshake packets do not cause any receiving function to

generate a return packet; therefore, SOF delivery to any given function cannot be

guaranteed whereas the delivery of data packets are acknowledged.


21/109



Figure2.3. Basic format of a USB transaction (typical transaction consists of three

packets)

The first three packets are handled in the pkt and trnsct modules where as SOF

packets are not handled here in this work as the FPGA device has no interest intracking the frame sequences sent by the host and recording it for checking against

duplicate packets.

Packet fields

I. SYNC ByteAll packets start with the synchronization sequence. It consists of eight bits startingwith seven consecutive logic 0s and ending with logic 1 (0000001B). When it is

encoded using NRZI, it becomes 01010100B. So it creates a transition during each

bit time, thus providing a clock that can be synchronized to. It informs the USB

receivers that a packet is being sent, which will immediately follow.

Figure2.4 Sync sequence

II. Packet ID (PID)The type of packet is defined by a bit pattern called a packet ID (PID). Packet

identifiers define the purpose and thus the format and content of a given packet. The

format and length of a packet depends on its type. Packet IDs consist of a 4 bit

identifier field followed by a 4 bit check field. The check field contains the inverted

value (1s complement) of the packet ID value, hence it is self error checking.


22/109



Figure2.5 PID format

III.Packet-Specific InformationEach packet contains information that is related to the task it performs. The

information may consist of a USB device address, a frame number, data to be

transferred to or from a USB device, etc. This information is crucial to the success of

a given transaction and is verified at the end of the packet with CRC bits.

IV.Cyclic Redundancy Checking (CRC)The USB agent that sends a given packet computes either a 5-bit CRC if it is token

packet or 16-bit CRC if it is data packet. The PID is not included in the CRC

calculation and checking since it has its own check bits.

V. End of Packet (EOP)The end of each packet is signaled by the sending agent by driving both differential

data lines low for two bit times followed by an idle for one bit time. The agent

receiving the packet recognizes the EOP when it detects the differential data lines

both low for greater than one bit time.

Figure2.6EOP signaling


23/109



Figure2.7 Typical USB packet format

Sync and EOP detection and generation are implemented in the trnsmtr and rcvr

module where as PID generation and removal is implemented in trnsct module and

CRC checks and calculations are handled in pkt module of this design.

USB communications

USB communication can be divided in to two major categories as communications

used in enumerating the device and communications used by the applications that

carry out the devices purpose.

A. Enumeration CommunicationEnumeration process is the major components that should be successfully

implemented in order for any USB device to work. It implements the details of the

control transfer protocol. Control transfer is one of the four USB transfer types and

it is the most complex one and also it should be available in every USB devices. Itenables information exchange between the host and the device. The information

may be standard, class specific or vendor specific information. Unlike the other

transfers, its functions are defined by the USB specification.

Figure2.8 Enumeration Process


24/109



Control transfer consists of three stages

1. Setup stage2. Data stage3. Status stage

Each stage contains one or more transaction that each contains three phases

A. Token phaseB. Data phaseC. Handshake phase

Each phase contains either token or data or handshake packets.

Figure2.9 Control transfers stages and phases

1.

Setup StageConsists setup transaction for the following purposes

To detect the transfer type as a control transfer To transmit requests and information the device need to complete the

enumeration steps.


25/109



Devices must accept and acknowledge every incoming setup transactions even in

the middle of other transactions.

And the setup transaction has three packet types that are transferred in its three

phases.

A. Token packet: - identifies to whom the packet is sent and it also identifies thetransaction as a setup transaction. It is sent by the host and it consists of the

Setup PID (00101101B), the device address (primarily 0000000B) and the

endpoint address (0000B).

B. Data packet: - used to transmit the request and related information. It is sent bythe host and it consists of data PID (11000011B) and eight bytes in five fields:

bmRequestType, bRequest, wValue, wIndex, and wLength.

I. BmRequestType: is a byte that specifies the direction of data flow, thetype of request, and the recipient.

II. BRequest: is a byte that specifies the request. There are differentstandard requests and non standard requests.

Hosts request devices for some information. Hence every device responds to

the following device requests even if the device is not yet configured or given

an address.

If an unsupported or invalid request is made to a USB device, the device

responds by returning stall in the data or status stage of the request. If the

device detects an error in the setup stage, it is preferred that the device

returns stall at the earlier of the data or status stage.

Request

name

Binary

value

Hex

value

Description

get_status_rqst 00000000 0 Returns status for the specified recipient

clr_ftr_rqst 00000001 1 used to clear or disable a specific feature

set_ftr_rqst 00000011 3 Used to set or enable a specific feature.

set_addr_rqst 00000101 5 Sets the device address for all future

device accesses.

get_dsc_rqst 00000110 6 Returns the specified descriptor if the

descriptor exists.

set_dsc_rqst 00000111 7 Optional and may be used to update

existing descriptors or new descriptors

may be added.

get_cnf_rqst 00001000 8 returns the current device configuration

value


26/109



set_cnf_rqst 00001001 9 Sets the device configuration.

get_intrfc_rqst 00001010 A Returns the selected alternate setting for

the specified interface.

set_intrfc_rqst 00001011 B Allows the host to select an alternate

setting for the specified interface.

Table2.1 Request types and their descriptions

In this research those requests listed on table2.1 are handed by the cntrl module as

will be explained in chapter three.

III. WValue: host uses this field to pass information to the device. It is twobytes long. Each request defines the meaning of these bytes in its own

way. For instances set_addr_rqst, contains the device address in its

wValue field.

IV. WIndex: it is two bytes long. Each request may define the meaning ofthese bytes in its own way though its main use is to pass an index or

offset such as an interface or endpoint number.

V. WLength: host uses this field to pass the number of data bytes it needs orit will transfer in data stage that follows. It is two bytes long. If the

direction of the data stage is IN, wLength is the exact number of bytes the

host wants to transfer otherwise wLength is a maximum value, and the

device may return this number of bytes or fewer. A zero value in this field

indicates there is no data stage.

C. Handshake Packet:-it transmits an acknowledgement from the device to thehost and it consists of ACK PID (11010010B). If error was detected in the setup

or data packet, the device needs not send acknowledgement.

2. Data StageThis stage is an optional stage; it is available according to the request type. For some

request, there will be no need of data stage so it will be bypassed and status stage

follows. But for some requests it is needed. For example if the request is

get_dsc_rqst, surely the host needs some description data from the device; hence

there will be data stage but if the request is set_addr_rqst, the host is giving addressto the device so it does not need the data stage. Any way the wLength field in the

data phase of the setup stage determines whether there is data stage or not. If

wLength is zero, data stage will be skipped.

Data stage consists of one or more IN or OUT transactions. When the host needs

data from the device like in the case of get_dsc_rqst, the data stage will be IN


27/109



transaction but if the host needs to send data to the device, the data stage will be

OUT transaction.

If there is data stage but no data transfer, the zero-length data (only data PID)

should be transferred in the data phase of the data stage.

And each transaction should contain the following packets

A. Token packet: - identifies to whom the packet is sent and it also identifies thetransaction as IN (if the request requires the device to send data to the host) or

OUT transaction (If the request requires the host to send data to the device). It is

sent by the host and it consists of the IN or OUT PID, the device address and the

endpoint address.

B. Data packet: transfers all or a portion of the data specified in the wLength fieldof the Setup transactions data packet. If the token packets PID is IN, the device

sends the data packet; if the token packets PID is OUT, the host sends the data

packet. The first packet is data PID (11000011B). Zero-length data packet may

also be sent.

C. Handshake packet: the receiver of the data stages data packet returns statusinformation. The FPGA device may return ACK PID (11010010B) if valid data

was received, NAK PID (01011010B) if the endpoint or the device is busy, or

STALL PID (00011110B) if the request is not supported. However if the receiver

detected an error in the token or data packet, the receiver returns no handshake

packet.

3. Status StageThe status stage is where the FPGA device reports the success or failure of the entire

transfer. The purpose of the status stage is similar to the purpose of a transactions

handshake packet, and in fact the status information sometimes travels in the

handshake packet of the Status stage. But the status stage reports the success or

failure of the entire transfer, rather than of a single transaction.

Like the others, the status stages transaction contains token, data and handshake

packets.

The following figures shows some cases of control transfer


28/109



Figure2.10 Example of control transfers stages for get_dsc_rqst request

Figure2.11 control transfer with no data stage

Figure2.12 control transfer when the host is requesting data


29/109



Figure2.13 control transfer when the host wants a write request

Descriptors

Every USB devices report their attributes using descriptors. A descriptor is a data

structure that contains information about the device so that the host will know

about the device type, the driver to be used and the resources it needs. It is a

devices means of reporting its attributes.

Each descriptor begins with a byte-wide field that contains the total number of

bytes in the descriptor followed by a byte-wide field that identifies the descriptor

type. There are many types of descriptors as shown in the following table.

Descriptor Types Binary Value Hexadecimal

Value

Device 00000001 1

Configuration 00000010 2

String 00000011 3

Interface 00000100 4

Endpoint 00000101 5

Device qualifier 00000110 6

Other speed configuration 00000111 7

Interface power 00001000 8

Table2.2 Descriptor types and values

i. Device descriptorA device descriptor describes general information about a USB device. It includes

information that applies globally to the device and all of the devices configurations.

A USB device has only one device descriptor.


30/109



The Device descriptor used for the FPGA is given in the table2.5 of the CDC-ACM

section.

ii. Configuration descriptorIt describes information about a specific device configuration. When the host

requests the configuration descriptor, all related interface and endpoint descriptors

are returned. A USB device has one or more configuration descriptors. Each

configuration has one or more interfaces and each interface has zero or more

endpoints.

The configuration descriptors used for the FPGA are given in the table2.6 next

section.

B. Application CommunicationsAfter the host has exchanged enumeration information with the device and a device

driver has been assigned and loaded, the application communications can begin. Atthe host, applications can use standard Windows API functions or other software

components to read and write to the device. At the device, transferring data

typically requires either placing data to send in the USB controllers transmit buffer

or retrieving received data from the receive buffer. Each data transfer uses one of

the four transfer types: control, interrupt, bulk, or isochronous. Each has a format

and protocol to suit different needs.

Transaction direction can be either one of the followings:

OUT (to the device)

Figure2.14 OUT transaction

IN (to the host)

Figure2.15 IN transaction


31/109



An application program at the FPGA side is developed and it uses the host hyper

terminal software and it implements the bulk and interrupts transfers.

2.1.2UTMISPECIFICATION[2]

Intel has provided specification for developing low level USB transceiver calledTransceiver Macrocell Interface (UTMI) Specification in order that one vendor can

produce only the SIE part and buy the UTMI transceiver from another vendors and

vice versa.

This block handles the low level USB protocol and signaling. This includes features

such as; dataserialization and deserialization, bit stuffing and clock sampling and

synchronization. Some key features of the USB 2.0 transceiver are:

Eliminates high speed USB 2.0 logic design for peripheral developers.

Standard transceiver interface enables multiple IP sources for USB 2.0 SIE.

Supports 480 Mb/s (High Speed)/ 12 Mb/s (Full Speed), FS only and Lowspeed only 1.5 M b/s serial data transmission rates.

Utilizes 8-bit or 16-bit parallel interface to transmit and receive USB 2.0

cable data.

SYNC/EOP generating and checking.

Allows integration of high speed components in to a single functional block

as seen by the peripheral designer.

High speed and full speed operation to support the development of dual

mode devices.

Bit stuffing/unstuffing and bit stuff error detection.

Holding registers to stage transmit and receive data.

Logic to facilitate resume signaling.

Supports USB 2.0 test modes

Ability to switch between FS and HS terminations/signaling.

The UTMI is designed to support HS/FS, FS only and LS only UTM implementations.

The three optionsallow a single SIE implementation to be used with any speed USB

transceiver. Vendors can choose thetransceiver performance that best meets their

needs. [2] However it does not include the analog front end about cable, resistor and

voltage specifications.

In this project, the full speed only UTMI is implemented. Hence it does not require

the speed selection signals since there are noalternate speeds to switch to.


32/109



Figure2.16 UTMI functional block diagram for full speed only

The blocks of Figure 2.16 are described as follow

Clock Multiplier

This block generates the appropriate internal clocks for the UTMI and the clock

output signal. All data transfer signals are synchronized with the clock signal. TheUTM vendor determines the frequency of the external crystal. But in this case, the

clock is to be sourced from the FPGA 50 MHz oscillator. However; the clock

frequency needed by full speed only device is 48 MHz as this specification states

thus Xilinxs digital clock manager was applied to synthesizes this frequency from

the 50 MHz source.

Tx Shift/Hold Register

This block is responsible for reading parallel data from the SIE interface and

serializing for transmission over USB cable. This module consists of an 8-bit shift

and hold register for parallel to serial conversion and for buffering the next data toserialize.

NRZI Encoder

This is a standard USB 1.X compliant serial NRZI encoder module. Whenever a bit 0

is encountered in the data stream, it is negated. A bit 1 is transmitted as it is as

shown in figure 2.16. It is implemented in the trnsmtr component of this work.


33/109



Bit stuff Logic

In order to ensure adequate signal transitions, bit stuffing is employed when

sending data on USB bus. A 0 is inserted after every six consecutive 1s in the data

stream before the data is NRZI encoded, to enforce a transition in the NRZI data

stream. Bit stuffing is enabled beginning with the SYNC Pattern and through the

entire transmission. The data 1 that ends the SYNC Pattern is counted as the first

one in a sequence. The following figure shows bit stuffing and NRZI encoding.

Figure2.17 Bit stuffing and NRZI Encoding

This logic is implemented in the trnsmtr module of this design.

Rx Shift/Hold Registers

This block is responsible for converting serial data received from the host to parallel

data. It consists of an 8-bit Rx Shift and hold register for serial to parallel conversionand for buffering received data bytes and present them to the SIE.

NRZI Decoder

This is a standard USB 1.x compliant serial NRZI decoder module. The data received

on Dp and Dm lines is NRZI (1) decoded and it is sent to the bit unstuff module. And

this is handled in the rcvr component of this design.

Bit Unstuff Logic

The bit unstuff logic is a state machine, which strips away a stuffed 0 bit from the

data stream and detects bit stuff errors. It is implemented in rcvr module.

Data+ and Data-

Data+ and Data- are bidirectional deferential signals and they are used to connect

the USB device to the outer world. The data transmission and reception occur on

these two lines. If bit 1 is present on Dp line, bit 0 will present on Dm line in the

same clock duration. This is required because if bit 1 i.e., +5V is present on DP line,


34/109



a magnetic field will be created around the line. This magnetic field may affect the

near by lines. To compensate the affect of magnetic field, a bit 0 i.e., -5V is present

on Dm line. The net effect of the magnetic field will be zero. Thus the noise is

reduced.

In this design they are represented in the top module as Dp and Dm and transferred

to the rcvr module of rx_Dp and Rx_Dm when the USB is receiving data from the host

otherwise to the trnsmtr as tx_Dp and tx_Dm when transmitting data to the host.

Receive and transmit state machines.

These are finite state machines that tell the different states at different conditions

and what activities are performed and what signals are changed when transitions

occur. Chapter three of this paper explains each in detail.

Control logic

This block includes different control signals that sends and receives informationwith SIE about the detection of events like the arrival of data, the occurrence of bit

stuff errors and the completion of data transfer. Details of these are explained in the

next chapter.

Operational Modes

UTMI specifies three operational modes:

Normal Operation (0)

Non-Driving (1)

Disable Bit Stuffing and NRZI encoding (2)

Mode 0 allows the transceiver to operate with normal USB data decoding and

encoding.

Mode 1 allows the transceiver logic to support a soft disconnect feature which tri-

states both the HS and FS transmitters, and removes any termination from the USB

making it appear to an upstream port that the device has been disconnected from

the bus.

Mode 2 disables Bit Stuff and NRZI encoding logic so 1's loaded from SIE becomes

1's on the Dp line and 0s on Dm line and the reverse is true for loaded 0s.

Only mode 0 and mode 1 are implemented in this research work as mode 2 are

mainly used for high speed bus testing.

Analog Front End

On full speed devices, a differential 1 is transmitted by pulling D+ over 2.8V with a

15K ohm resistor pulled to ground and D- under 0.3V with a 1.5K ohm resistor


35/109



pulled to 3.6V. A differential 0 on the other hand is a D- greater than 2.8V and a D+

less than 0.3V with the same appropriate pull down/up resistors. The receiver

defines a differential 1 as D+ 200mV greater than D- and a differential 0 as D+

200mV less than D-.

USB transceivers will have both differential and single ended outputs. Certain bus

states are indicated by single ended signals on D+, D- or both. For example a single

ended zero or SE0 can be used to signify a device reset if held for more than 10ms. A

SE0 is generated by holding both D- and D+ low (< 0.3V). The low speed/full speed

bus has a characteristic impedance of 90 ohms.

A USB device must indicate its speed by pulling either the D+ or D- line high to 3.3

volts. A full speed device, as shown below uses a pull up resistor attached to D+ to

specify itself as a full speed device. These pull up resistors at the device end will also

be used by the host or hub to detect the presence of a device connected to its port.

Figure2.18 Full speed device with pull up resistor connected to D+2.1.3CDC-ACMSPECIFICATION [3, 34]

Device classes are intended to permit a device driver design that can manipulate a

set of devices that have similar attributes and services. A given class definition can

further describe the individual characteristics of particular device types within the

class, thereby providing the USB device driver with the information it needs to

manipulate the device as required.


36/109



All devices must support the standard requests and descriptor definitions described

in so far. Most devices provide additional requests and, possibly, descriptors for

device-specific extensions. In addition, devices may provide extended services that

are common to a group of devices.

Device class definition relates to a functional interface used to access and control a

particular class of device.

Device Class Code field from each functional interface descriptor. Sub Class Code field the definition of this field is device class specific. Protocol field this optional field may be defined for a given device class

and subclass to define some element of the programming interface

supported by the device.

All USB class specifications are based on the common class specification, how to

organize a specification document. A class specification defines the number and typeof required and optional endpoints in a class may have. A specification may also

define or name formats for data to be transferred, including both application data

and status and control information relating to the device and its operation. [4]

The following table shows some of the classes that have their own specification with

their class code.

USB class Class code

Audio device 01h

Communications Device 02h

Content Security 0Dh

Human Interface Device Class (HID) 03h

Image Device 06h

IrDA FEh

Mass Storage Device 08h

Monitor

Physical Interface Device Class (PID)

Power Device Class

Printer Device 07h

Table2.3 USB classes and their class codes

If a device can be classified with one of the above list, the developer should not need

to develop host side driver because he can use the already installed and supported

drivers for the above classes.

Hence in this project, the whole work was to be done on the FPGA and no driver or

application software was not to be written in the host side, it was classified as a


37/109



communication device. Therefore the communication device class specification

plays main role in this work.

Communication device classes

Several types of communication devices can benefit from the USB. This specification

provides models for telecommunication devices, such as telephones, analog

modems, ISDN devices and networking devices like routers and switches. It

describes:

Specifications for the following three classes:1. Communication Device Class2. Communication Interface Class3. Data Interface Class

Framework for building a communication device: Assembling the relevant USB logical structures into

configurations.

Communication Class interface and its usage. Data Class interface and its usage. Usage of additional class types or vendor specific interfaces.

Implementation examples of communication devices, such as a basictelephone, and an analog modem.

The Communications Device Class is a device-level definition and is used by the host

to properly identify a communications device that may present several differenttypes of interfaces.

The Communications Interface Class defines a general-purpose mechanism that can

be used to enable all types of communications services on the Universal Serial Bus

(USB).

The Data Interface Class defines a general-purpose mechanism to enable bulk or

isochronous transfer on the USB when the data does not meet the requirements for

any other class. The specification currently outlines the common elements needed

to support the following types of devices:

Telecommunications devices: Analog modems, ISDN terminal adapters, digitaltelephones, and analog telephones

Networking devices: ADSL modems, cable modems, 10BASE-T Ethernet

adapters/hubs, and Ethernet cross-over cables.

Other devices: that can not be categorized in the other well known classes like the

FPGA in this thesis.


38/109



The Communications Class defines mechanisms for a device and host to identify

which existing protocols to use. Where possible, existing data formats are used and

the transport of these formats is merely enabled by the USB through the definition

of the appropriate descriptors, interfaces, and requests.

The communication class is a very large class that contains many subclasses inside itas shown in the following table each containing its own specifications.

Code Subclass

00h RESERVED

01h Direct Line Control Model

02h Abstract Control Model

03h Telephone Control Model

04h Multi-Channel Control Model

05h CAPI Control Model

06h Ethernet Networking Control Model

07h ATM Networking Control Model

08h Wireless Handset Control Model

09h Device Management

0Ah Mobile Direct Line Model

0Bh OBEX

0Ch Ethernet Emulation Model

0Dh-7Fh RESERVED (future use)

80-FEh RESERVED (vendor specific)

Table2.4 Subclass codes of CDC class

Abstract control model is selected as subclass for the FPGA in this thesis as it is

possible to use the existing Microsofts hyper terminal software as a host side

application.

Hence considering the specification for this class and the parameters that could

match the FPGA, the device and configuration descriptors are prepared as shown in

the following tables. And the FPGA should respond to the host on requests.


39/109



Table2.5 Values and descriptions of the memory that hold device descriptor

Memory

address

( Decimal) Name

Value

(Hexadecimal) Description of the Values

0 bLength 12

It describes that the length of this data

is 18 bytes.

1 bDescriptorType 01

This describes that this is device

description.

2 bcdUSB (lsb) 00 USB Specification Release Number in

Binary-Coded Decimal=USB2.03 bcdUSB (msb) 02

4 bDeviceClass 02

This is Communication Device Class

code.

5 bDeviceSubClass 00This is given in configurationdescription table.

6 bDeviceProtocol 00

the device does not use class specific

protocol

7 bMaxPacketSize0 40

Maximum packet size for endpoint

zero=64byte.

8 idVendor(lsb) FD It is the vendor ID of the device

assigned by USB-IF and for this purpose

that of Xilinx's was used.9 idVendor(msb) 03

10 idProduct(lsb) 08 this is the serial number given to the

device by the manufacturer and some

value was given for this purpose.11 idProduct(msb) 00

12 bcdDevice(lsb) 00 It is device release number in binary-

coded decimal and for test purpose so it

was given to be version 1.0.13 bcdDevice(msb) 01

14 iManufacturer 00

No index of string descriptor describing

manufacturer.

15 iProduct 00


product.

16 iSerialNumber 00


device serial number.

17 bNumConfigurations 01

Number of possible configurations is

one.

18-63 padding 0's 00

This portion of the memory is unused

so it is filled with useless zeros Until

the configuration description starts.


40/109



Memory

address(Decimal) Name

Value(Hexadeci

mal) Description of the Values

9 bytes for configuration descriptor header

64 bLength 09 9 bytes long65 bDescriptorType 02 Configuration descriptor.

66 wTotalLength(LSB) 3e 62 byte long configuration

descriptor available.67 wTotalLength(MSB) 00

68 bNumInterfaces

02 Two interface configuration, one

for data & the other for control.

69 bConfigurationValue

01 Identifier for set_cnfg_rqst and

get__cnfg_rqst requests.

70 iConfiguration

00 No Index of string descriptor for

the configuration.

71 bmAttributes 80 80=Self powered, C0=bus powered

72 bMaxPower

fa 250mA is half of the maximum

power needed by this device.

9 bytes for communication control class interface descriptor

73 bLength 09 9 bytes long.

74 bDescriptorType 04 Interface descriptor.

75 bInterfaceNumber 00 Zero interfaces.

76 bAlternateSetting 00 No alternate setting.

77 bNumEndpoints 01 One end point.

78 bInterfaceClass

02 Communication Device Class

Interface.

79 bFunctionSubClass

02 Abstract Control Model Subclass

code.

80 bFunctionProtocol 01 Protocol code for AT commands.

81 iFunction

00 No Index of string descriptor for

the function.

5 bytes for functional descriptor header

82 bFunctionLength 05 5 bytes long.

83 bDescriptorType 24 Functional descriptor.84 bDescriptorSubtype 00 Header of functional descriptor.

85 bcdCDC(lsb) 10 Communication device class

specification is 1.10h.86 bcdCDC(msb) 01

4 bytes for abstract control model functional descriptor



41/109



88 bDescriptorType 24 Functional descriptor.

89 bDescriptorSubtype

02 Abstract Control Management

functional.

90 bmCapabilities

00 Commands for ACM are not

supported.5 bytes for Union functional descriptor


92 bDescriptorType 24 functional descriptor

93 bDescriptorSubtype

06 Union Descriptor Functional

Descriptor

94 bMasterInterface

00 Interface number of the control

(Communication Class)

95 bSlaveInterface0

01 Interface number of the slave (Data

Class)7 bytes for notify IN endpoint descriptor (interrupt transfer)

96 bLength 07 7 bytes long

97 bDescriptorType 05 endpoint descriptor

98 bEndpointAddress 82 IN_2

99 bmAttributes 03 interrupt transfer

100 wMaxPacketSize(lsb) 08 Maximum packet size supported.

Bits 10 through 0 are the maximum

packet size, from 0 to 1023101 wMaxPacketSize(msb)

00

102 bInterval

ff Maximum latency/polling

interval/NAK rate

9 bytes for data class interface descriptor


104 bDescriptorType 04 interface descriptor

105 bInterfaceNumber 01 one interface

106 bAlternateSetting 00 no alternating

107 bNumEndpoints

02 2 end points one Out and the other

In.

108 bInterfaceClass 0a Data Interface

109 bInterfaceSubClass 00 none

110 bInterafceProtocol 00 none

111 iInterface 00 none

7 bytes for data IN endpoint descriptor (bulk transfer)




42/109



114 bEndpointAddress 81 IN_1

115 bmAttributes 02 bulk data transfer

116 wMaxPacketSize(lsb) 40

64 bytes117 wMaxPacketSize(msb) 00

118 bInterval 00 zero interval7 bytes for data OUT endpoint descriptor (bulk transfer)



121 bEndpointAddress 01 OUT_1

122 bmAttributes 02 bulk data transfer

123 wMaxPacketSize(lsb) 40

64 bytes124 wMaxPacketSize(msb) 00

125 bInterval 00 zero interval

126-255 padding 0's 00

This portion of the memory filledwith Padded 0s since the

configuration description is only 62

byte long.

Table2.6 Values and descriptions of the memory that holds configuration

descriptors

2.2HDLBASED FPGADESIGN PROCESS

2.2.1HARDWARE DESCRIPTION LANGUAGESHDLs provide formats for representing various design stages. They are used to

describe hardware for the purpose of simulation, modeling, testing, design, and

documentation. These languages provide a convenient and compact format for the

hierarchical representation of functional and wiring details of digital systems. There

are several levels of abstraction of digital systems using hardware description

languages [33]. The two main IEEE standard HDLs are VHDL and Verilog.

VHDL is intensively used in this thesis work. VHDL is an acronym standing for

VHSIC Hardware Description Language. VHSIC is also an acronym for Very High-

Speed Integrated Circuits. Hence VHDL is a hard ware programming language usedto design, test, and implement digital circuits.

VHDL descriptions of circuits are based upon the black box approach. The two main

parts of any hierarchical design are the black box and the stuff that goes in the black

box. In VHDL, the black box is referred to as the entity and the stuff that goes inside

is referred to as the architecture. For this reason, the VHDL entity and architecture

are closely related.


43/109



The VHDL entity declaration describes the interface or the external representation

of the circuit.

The architecture part describes what the circuit actually does. In other words, it

describes the internal implementation of the associated entity.

The VHDL entity construct provides a method to abstract the functionality of a

circuit description to a higher level. It describes how the black box interfaces with

the outside world. Since VHDL is describing a digital circuit, the entity simply lists

the various input and outputs to the underlying circuitry.

The architecture is comprised of two parts: the declaration section followed by a

collection of concurrent statements. There are different types of concurrent

statements like: concurrent signal assignment, conditional signal assignment,

process statement and selected signal assignment. The process statement is a

concurrent statement which is comprised of exclusively sequential statements. The

main types of sequential statements are the signal assignment statement, the ifstatement, and the case statement.

There are three different approaches to writing VHDL architectures. These

approaches are known as dataflow style, structural style, and behavioral style

architectures. [13]

A Behavioral description is the most abstract. It describes the function of the

design in a software-like procedural form and provides no detail as to how the

design is to be implemented. Behavioral descriptions are necessary in the early

design stage so that simulations can ensure that the chip is functionally correct. The

advantage of this approach is that one can make this assessment independent of the

many possible physical implementations.

A dataflow description is a concurrent representation of the flow of control and

movement of data. It gives more detail of hardware implementation and shows how

data moves between registers.

A structural description is the lowest and most detailed level of description

considered and is the simplest to synthesize into hardware.

Here in these work, a mixed description approach was used that combines all of the

three.

Complex circuits are described using finite state machines. Finite state machines

(FSM) constitute a special modeling technique for sequential logic circuits. Such a

model can be very helpful in the design of certain types of systems, particularly

those whose tasks form a well-defined sequence. In this work, finite state machines


44/109



for each component was designed and checked each rising edge of the clock for

change of some control signals and occurrences of events.

Available software for VHDL includes simulators and hardware synthesis programs.

A simulation program can be used for design verification, while a synthesizer is used

for automatic hardware generation. Moreover, synthesizers can be divided into two

parts, high level synthesizer and low level synthesizer. The high level synthesizer

can transform behavioral description HDL into structural description HDL, which

includes some primitive components, generally gates, flip-flops and latches. The low

level synthesizer depends on the target hardware and its main tasks are place &

route and optimization. In some papers and books, this process is called hardware

implementation since the output of the low level synthesizer directly maps to the

primitives that are used in the target chip. [33]

2.2.2FPGADESIGN FLOWThe WebPack ISE design software offers a complete design suite based on the Xilinx

foundation ISE series software. This package was used from the design step to the

final implantations during this work.

Typically, the HDL-based FPGA design flow has four main steps:

1. Use VHDL to describe the whole systems;2. Use Simulation tool to simulate and verify the design.3. Use RTL synthesis tool to obtain structure level design.4. Use FPGA Implementation tools to obtain physical FPGA bit stream file.

The implementation process undertakes four key steps.

i. Translate Interprets the design and runs a design rule check.ii. Map Calculates and allocates resources in the targeted device.

iii. Place and Route Places the CLBs in a logical position and utilizes therouting resources.

iv. Configure Creates a programming bit stream file.


45/109



Figure2.19 HDL-based FPGA design flow

Xilinx ISE simulator, XST, PACE, and Impact are among the ISE WebPack tools which

were used for simulation, synthesis and implementation. The final bit-stream file is

downloaded from a computer to the FPGA computing board through JTAG download

cable.And the FPGA is also connected with USB cable to the computer.


46/109



CHAPTER THREE

DESIGN OF THE PROJECT

3.1OVERALL DESIGN

The whole work of developing the USB protocol is divided into different

components which will perform different activities at different stage of the data

transfer.

After the USB received the binary bits from the host, it performs various processing

and checking according to the USB and its related specification documents. Hence

Figure3.1 shows what different modules are needed. And what each module does

and how it does is explained in this chapter.

Figure3.1 Overall USB protocol design

In the above figure, the two boxes which are closer to the host (rcvr and trnsmtr)

modules are parts of the UTMI specification that implements the transceiver and

directly communicates with the host.

Where as the other three boxes (pkt, trnsct, and cntrl modules) are parts of the USB

2.0 specification that implements the USB protocol and the top-level module which

is the biggest box that contains the other components and integrates the service of


47/109



the modules by feeding clk and rst signals. And it is also directly connected to the

FPGA application.

Details of the designs and purposes of all modules are expressed in the following

subsections.

3.2COMPONENTS AND THEIR DESIGN

3.2.1RCVR MODULE

This module is a unidirectional component which continuously receives binary bits

from the host computer and makes some processing and detection such as

Detection of sync sequence Detection of End of packet (EOP) signals NRZI decoding of the received bits Detection and removing of stuffed bits Detection of EOP and bit stuff errors Deserializes the received valid data bits in to bytes Transmits the data byte by byte to upper module Synchronizes clock with host clock Informs the pkt module the occurrence of error, the availability of valid byte,

the start and end of receiving.

Figure3.2 Entity of the rcvr module


48/109



Name Direction Number of bits

Description

clk in 1 48 MHz clock

rst in 1 If asserted , every signals will be reseted

and be at their initial valuesrx_Dp in 1 Received bit from D+ cable

rx_Dm in 1 Received bit from D- cable

rx_vld out 1 Is asserted for one clock time whenever

valid byte is received

rx_actv out 1 Asserted when sync pattern is detectedand deasserted either when EOP is

detected or bit stuff error is detected

rx_err out 1 Asserted for one clock time when ever bit

stuff error is detected

data_out out 8 Data byte received from host and will besent to upstream module

Table3.1 Data interface signals and their descriptions for rcvr module


49/109



Figure3.3 State machine diagram of rcvr module

The ports listed in table3.1 and the state machine diagram shown in figure3.3 are

explained as follow:

Initially state machine is at idle_state and all signals are initiated to zero. When rst is

deasserted, it will transit to rx_wait_state.

At rx_wait_state, the module will stay here till it receives the sync pattern which is

the beginning of receiving. The sync is an eight bit patterns which is the continuous

transition of K and J signals as follow KJKJKJKK in each clock cycle. J and K are a

special state of USB deferential signals where J signal is high when D+ is high and D-

is low but the reverse is true for K signal. Hence to implement this detection,

another state machine is needed and is done as in the following diagram inside this

rx_wait_state.

Figure3.4 Sync byte detection state machine diagram

In figure3.4 as well as in other state machine diagrams, the ellipse shapes shows the

states of FSM.

When the sync pattern is detected because of the successful execution of the above

state machine, the main state machine will enter strip_sync_state.

In the strip_sync_state, rx_actv will be asserted so that upper module will prepare

for arrival of data. The state machine transition will happen when the first valid data

byte is received and it will enter rx_data_state.


50/109



At rx_data_state, rx_vld will be asserted and the content of the rx_hld_shft register

(the received and paralleled byte) will be outputted as data_out to pkt module if no

error or EOP signal is detected and the state machine transits to rx_data_wait_state.

Otherwise if either error or EOP is detected, it will enter err_state or strip_eop_state

accordingly.In rx_data_wait_state, rx_vld will be deasserted; bits will be received and decoded.

The decoding is done using the NRZI algorithm by simply XNORing the current bit

with the previous bit that means if both the consecutively received bits are identical

the decoded bit is one otherwise it is zero.

The decoded bits will be fed to another state machine that serves for detecting a

stuffed bit as the host sends the data by stuffing a zero bit after consecutive six bits

so this module should detect and remove the stuffed bits as shown in the following

diagram.

Figure3.5 Stuffed bit and bit stuff error detection state machine diagram.

If six successive decoded bits are received, the seventh bit should be zero and this

zero is a stuffed bit and should be removed from the data that means it will not be

held in the rx_hld_shft_rgstr. However if the seventh bit is found to be one, some

error should have occurred in the middle of the receiving because according to the

UTMI specification of normal transfer, seven 1s can not be transmitted without zero

in a middle, hence the state machine will go to the err_state.

After the stuffed bits are removed, the state machine will go back to rx_data_state if

eight new data bits are stored in the rx_hld_shft_reg. Each incoming decoded non-


51/109



stuffed bit will be stored as the least significant bit of the eight bit wide register so

the previous bits will be shifted to left by one bit and the most significant bit of the

register will be striped off as it is a pervious data.

If the unstuffed bit counter becomes seven which means so far eight bits were

stuffed to the data, rx_vld will not be asserted for one byte clock cycle tosynchronize the delay due to the stuffing and unstuffing overheard.

There is another state machine which continuously checks for end of packet

detection. If it detects the appropriate signals for the EOP it forces the rcvr modules

state machine to go to the strip_eop_state. This state machine works as follow

Serial ended zero (SE0) is a deferential signal state which will be high when both D+

and D- bits are low. Therefore occurrence of two successive SE0 followed by J

confirms that the host has completed a packet transfer. It is implemented as the

following FSM diagram.

Figure3.6 EOP and EOP error detection state diagram

When in strip_eop_state, rx_actv (which was high starting from sync was detected)

will be deasserted so that pkt module will be aware of the end of the receiving. The

state machine will go to the rx_wait_state.

At err_state, rx_err will be asserted so that upstream pkt module will be informed so

the previously received bytes will be invalidated. The state machine will go to theabort state. Alignment error in which case EOP is not detected on a byte boundary is

also one source of error in rcvr module.

At abort_state, the rx_err, rx_vld and rx_actv signals will be deasserted and it goes to

the rx_wait_state for the next sync packet detection.


52/109



3.2.2TRNSMTR MODULE

This module is a unidirectional component which transmits binary bits to the host

computer. It performs the following major activities.

Receives parallel data from pkt module

Serializes the received bytes Generates and transmits Sync packet Checks the need for bit stuffing and adds bit stuff whenever necessary Encodes the serialized bits using NRZI Transmits the encoded bits to the host (D+ and D-) Generates and transmits end of packet signals when transfer is completed.

Name Direction Number

of bits

Description

clk in 1 48 MHz clock

rst in 1 If asserted , every signals of thiscomponents will be reseted and be at

their initial values

tx_Dp out 1 encoded Data bit to the D+ cabletx_Dm out 1 encoded Data bit to the D- cable

tx_vld in 1 when asserted, this module starts to send

sync pattern to the host and transmissionwill continue until it is deasserted

data_in in 8 received data byte from pkt component

and is to be processed and transmitted to


53/109



Figure3.7 Entity diagram of the trnsmtr component

Table3.2 data interface signals and descriptions for trnsmtr component

Figure3.8 The state machine diagram of the trnsmtr component

The following paragraphs describe how the state machine diagram of the

transmitter component shown in figure3.8 works along with data interface signals

of table3.2.

the host bit by bit

tx_rdy out 1 it is asserted when the component isready to receive the next byte to be

transmitted from the pkt module

Op_mode in 2 When 00 Normal transmission modewhen01 it will be non-driving mode

(SE0 deferential signals will betransmitted)and this input comes from

usb_fpga


54/109


MSC thesis by Haftu Hailezgy, Addis Ababa University, Department of Electrical and Com

haftu_hailezgy

Documents