Haftu Hailezgy

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 of Electrical 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.
USB Interface protocol implementation on FPGA
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 advising and 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 material contribution, 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.
MSC thesis by Haftu Hailezgy, Addis Ababa University, Department of Electrical and Computer Engineering, 2010 2
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 connect themselves 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 for buffering 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, a big 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.
Contents
Acknowledgments Abstract Contents List of figures List of tables Terms and abbreviations 1 Introduction 1.1 Overview USB interface 1.2 Overview of FPGA 1.3 Motivation 1.4 Objective 1.5 Approach 1.6 Scope 1.7 Thesis outline 2 Background 2.1 Specification documents 2.1.1 USB 2.1.2 UTMI 2.1.3 CDC and ACM 2.2 HDL Based FPGA design process 2.2.1 Hardware Description Languages 2.2.2 FPGA design flow 2 3 4 6 8 9 11 11 12 13 14 14 14 15 16 16 17 31 35 42 42 44
3 Design of the project 3.1 Overall design 3.2 Components and their design 3.2.1 Rcvr module 32.2 Trnsmtr module 3.2.3 Pkt module 3.2.4 Trnsct module 3.2.5 Cntrl module 3.2.6 Fpga_usb module 3.2.7 Application test module 4 Tests and Results 4.1 Devices and tools used 4.2 Simulation test cases and results 4.3 FPGA test procedures and results 5 Conclusion and Recommendation for future Works 5.1 Challenges 5.2 Summary and conclusion 5.3 Recommendation for Future Works 5.4 Research Application and contribution 6 Bibliography 7 Appendices A. VHDL codes B. Test bench codes
46 46 47 47 52 55 60 65 71 76 79 79 79 101 103 103 104 105 105 106 108 A1

A34
List of Figures
Figure2.1 Block diagram of USB controller [2] Figure2.2 USB Protocol architecture [1] Figure2.3 Basic format of a USB transaction Figure2.4 Sync sequence Figure2.5 PID format Figure2.6 EOP signaling Figure2.7 Typical USB packet format Figure2.8 Enumeration process Figure2.9 Control transfers stages and phases 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 Figure2.13 control transfer when the host wants a write request Figure2.14 OUT transaction Figure2.15 IN transaction Figure2.16 UTMI functional block diagram for full speed only Figure2.17 Bit stuffing and NRZI encoding Figure2.18 Full speed device with pull up resistor connected to D+ Figure2.19 HDL-based FPGA design flow Figure3.1 Overall USB protocol design Figure3.2 Entity of the rcvr module Figure3.3 State machine diagram of rcvr module Figure3.4 Sync byte detection state machine diagram Figure3.5 Stuffed bit and bit stuff error detection state diagram Figure3.6 EOP and EOP error detection state diagram Figure3.7 Entity diagram of the trnsmtr component Figure3.8 The state machine diagram of the trnsmtr component Figure3.9 State machine diagram for detecting consecutive bits that needs bit stuffing Figure3.10 The entity of the pkt component 16 17 21 21 22 22 22 23 24 28 28 28 29 30 30 32 33 35 45 46 47 48 49 50 51 52 53 54 55
Figure3.11 State machine diagram of packet module Figure3.12 Token packet Figure3.13 Data packet format Figure3.14 the Entity of the trnsct component Figure3.15 the state machine diagram of transct component Figure3.16 Second byte of a token Figure3.17 Third byte of a token Figure3.18 The Entity diagram of cntrl module Figure3.19 state machine diagram of cntrl module Figure3.20 Entity diagram of the fpga_usb module Figure3.21 State machine diagram of the fpga_usb component Figure3.22 512 RAM memory for storing descriptors and data from host and to host Figure3.23 State machine diagram of the test application Figure4.1 Enumeration simulation steps Figure4.2 Simulation snapshot when Setup token is input to test bench Figure4.3 Simulation snapshot when receiving device descriptor request Figure4.4 Simulation snapshot transmitting ACK packet
57 58 59 61 62 63 63 66 68 71 72 74 77 81 82 83 84
Figure4.5 Simulation snapshot when receiving IN token with default address 85 and control end point (both zero) Figure4.6 Simulation snapshot when transmitting the eighteen byte device 86 descriptor. Figure4.7 Simulation snapshot when receiving ACK packet Figure4.8 Snapshot of out token with default address and endpoints Figure4.9 Simulation snapshot when receiving set address request 87 88 83
Figure4.10 FPGA address changed from the default value (zero) to the 89 assigned value (two) Figure4.11 Simulation snapshot when receiving setup token with address =2 90 and end_pt=0 Figure4.12 Simulation snapshot when receiving configuration descriptor request 91
Figure4.13 Simulation snapshot when transmitting configuration descriptor Figure4.14 out token with address=2 and end_pt=0
92 93
Figure4.15 Simulation snapshot when receiving OUT token with address=2 94 and end_pt=1 Figure4.16 Simulation snapshot when receiving user data input 95
Figure4.17 Simulation snapshot when receiving IN token with address=2 and 96 end_pt=1 Figure4.18 Simulation snapshot when transmitting from transmit buffer Figure4.19 Setup token with mismatched CRC value Figure4.20 A token packet with Unknown PID type Figure4.21 Stall handshake packet is returned for unsupported requests Figure4.22 wrong sync pattern 97 98 99 100 100
List of Tables
Table2.1 Request types and their descriptions Table2.2 Descriptor Types and Values Table2.3 USB classes and their class codes Table2.4 Subclass codes of CDC class Table2.5 Values and descriptions of the memory that hold device descriptor Table2.6 Values and descriptions of the memory that holds configuration descriptors Table3.1 Data interface signals and their descriptions for rcvr module Table3.2 Data interface signals and descriptions for trnsmtr component Table3.3 Data interface signals for pkt component 26 29 36 38 39 40
48 53 56
Table3.4 Data interface signals of trnsct component Table3.5 cntrl module signals and their description Table3.6 Signal description of fpga_usb component Table3.7 Data interface signals of application module
62 68 72 77
Terms and Abbreviations

Addr ACK ACM CLB CDC Cntrl CRC DCM Dm Dp End_pt Enum EOP FPGA FS HS FSM Init ISE JTAG LS LSB MSB NAK Address of FPGA assigned by a computer USB system. Acknowledgement: packet that informs success of transfer. Abstract control model: subclass of communication device class. Control logic block Communication device class: one of the USB standard classes. Control: a module that implements the enumeration process. Cyclic redundancy check: error checking mechanism of USB protocol. Digital clock manager. Data - : deferential signal that is transmitted using the white line of the USB cable. Data +: deferential signal that is transmitted using the green line of the USB cable. End point: data sources and sinks of USB protocol. Enumeration: the initial process where USB devices express their attributes to the host computer. End of packet: signals that can inform the end of transaction. Field programmable gate arrays. Full speed: 12Mb/s. High speed: 480Mb/s. Finite state machine Initialization process of the USB system. Integrated Software Environment. Joint Test Action Group. Low speed: 1.5Mb/s. Least significant bit: the last bit of a byte. Most significant bit: the first bit of a byte. Negative acknowledgement.
NRZI PACE PID Pkt PLL RAM rcvr Reg RTL Rx SIE SE Sig Stl Sync Trnsct Trnsmtr Tx USB USB IF UTMI var VHDL XST
Non return to zero inverses on 1: encoding method. Pin out and Area Constraints Editor. Packet identification. Packet: a module that performs CRC check. Phase Locked Loop. Circuit used for frequency generation. Random access memory. Receiver: a module that receives bits from host. Register: stores signals value in the FPGA. Register Transfer Level. Receive Serial Interface Engine: the main USB protocol. Single Ended: a deferential signal where both Dm and Dp are low. Signal: it is a variable for storing values. Stall: handshake mechanism replied for unsupported requests. Synchronization pattern: eight bits start of packet pattern in USB. Transaction: a module that performs different transactions. Transmitter: a module that transmits bits to the host. Transmit Universal serial bus. Universal serial bus - Implementation forum. USB transceiver macrocell interface. Variable: local variable in a process. Very high speed integrated circuit Hardware Description Language. Xilinxs synthesis tool.
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 in the market today. From the users perspective, the benefits of USB are ease of use o One interface for many devices. o Automatic configuration o Easy to connect o Easy cables o Hot pluggable o No user settings o Frees hardware resources for other devices o No power supply required (sometimes) fast peed o 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/sec o 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.
o Provide a mechanism that enables software drivers to communicate with the computers USB hardware and the applications that want to access USB peripherals. Peripheral Support
Limitation of USB All 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
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 basic blocks 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.3 MOTIVATION
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
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.4 OBJECTIVE
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 it to PC using USB interface with out writing a driver software and application software on the computer side. Simulate the protocol on simulation tools. Test the protocol on hardware (FPGA).
1.5 APPROACH
After thoroughly reading and understanding the specification documents needed to develop the end to end USB protocol, VHDL programming language was studied and practiced. 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 were integrated by a top module and simulated by writing appropriate test benches to give 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 the above steps were followed by implementation, testing and troubleshooting the protocol on a spartan3 Xilinx FPGA.
1.6 SCOPE
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 full speed 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.
1.7 THESIS 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.
CHAPTER TWO BACKGROUND

2.1 SPECIFICATION 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 USB interface 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 standard developed by Intel company and used to describe how to implement the low level USB transceiver interfaces of the USB device. 3. Universal Serial Bus Class Definitions for Communication Devices. This one 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 the host is the computer and the FPGA is the device.
Figure2.1. Block diagram of USB controller
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.1 USB SPECIFICATION [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.
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 response communication, 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 be transferred. 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 and device, 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
that use this transfer type. In isochronous transfer, there is less attention to the success of the transfer (whether or not the whole data arrived on time) since the traffic included in this transfer type has a high tolerance for errors. This transfer is not needed for this project so not handled in this research work. 4. Interrupt transfer: Interrupt transfer is a limited-latency transfer and used for devices such as mouse, joystick that needs to report short event notification, characters or coordinates. A USB device that works in an interrupt transfer mode defines, as part of its configuration, the time interval it wants to send or receive information. The host is responsible to turn to device at that specific rate, and then the device is allowed to send or receive the necessary data. In this work, although it is implemented in usb_fpga main module because the communication device class requires it for the exchange of commands, it is not fully functional. If data arrives using this transfer, the FPGA replies with stall handshake to mean unsupported. Device Endpoints Endpoints are the sources and/or sinks of data. It is a buffer (a block of data memory or a register) that stores multiple bytes. The data stored at an endpoint may be received data or data waiting to be transmitted. According to USB specification, a device endpoint is defined as A uniquely addressable portion of a USB device that is the source or sink of information in a communication flow between the host and device. An endpoint carries data in one direction only. However, a control endpoint (Endpoint 0) is a special case that is bidirectional and every device must be configured to have it for control transfer. An endpoints address consists of an endpoint number and direction. The number is a value from 0 to 15. The direction is expressed in references of the hosts: 1. IN endpoint: provides data to transmit from the device to the host 2. OUT endpoint: stores data received from the host Every transaction on the bus begins with a packet that contains an endpoint number and a code that indicates the direction of data flow and whether or not the transaction is initiating a control transfer. There are three main transaction types. IN transaction: when the data travels from the device to the host. OUT transaction: when the data travels from the host to the device.
Setup transaction: data travels from the host to the device, but it initiates a control 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 defines the destination device address, endpoint number, and the direction of the data transfer. Data Packet: - The data consists of a data packet that carries the payload associated with the transfer. A data packet can carry a maximum payload of 1023 bytes of during a single transaction. Handshake Packet: - all USB transfers (except isochronous) are implemented 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-only transaction that distributes an SOF marker and accompanying frame number 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.
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 in tracking the frame sequences sent by the host and recording it for checking against duplicate packets. Packet fields I. SYNC Byte All packets start with the synchronization sequence. It consists of eight bits starting with 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.
Figure2.5 PID format III. Packet-Specific Information Each 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.6 EOP signaling
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 Communication Enumeration 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. It enables 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
Control transfer consists of three stages 1. Setup stage 2. Data stage 3. Status stage Each stage contains one or more transaction that each contains three phases A. B. C. Token phase Data phase Handshake phase
Each phase contains either token or data or handshake packets.
Figure2.9 Control transfers stages and phases 1. Setup Stage Consists 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.
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 the transaction 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 by the host and it consists of data PID (11000011B) and eight bytes in five fields: bmRequestType, bRequest, wValue, wIndex, and wLength. I. II. BmRequestType: is a byte that specifies the direction of data flow, the type of request, and the recipient. BRequest: is a byte that specifies the request. There are different standard 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 get_status_rqst clr_ftr_rqst set_ftr_rqst set_addr_rqst get_dsc_rqst set_dsc_rqst Binary value 00000000 00000001 00000011 00000101 00000110 00000111 Hex value 0 1 3 5 6 7 Description Returns status for the specified recipient used to clear or disable a specific feature Used to set or enable a specific feature. Sets the device address for all future device accesses. Returns the specified descriptor if the descriptor exists. Optional and may be used to update existing descriptors or new descriptors may be added. returns the current device configuration value
get_cnf_rqst
00001000
set_cnf_rqst get_intrfc_rqst set_intrfc_rqst
00001001 00001010 00001011
9 A B
Sets the device configuration. Returns the selected alternate setting for the specified interface. 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 two bytes 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. WIndex: it is two bytes long. Each request may define the meaning of these bytes in its own way though its main use is to pass an index or offset such as an interface or endpoint number. WLength: host uses this field to pass the number of data bytes it needs or it 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.
IV.
V.
C. Handshake Packet:-it transmits an acknowledgement from the device to the host 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 Stage This 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 address to 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
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 the transaction 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 field of 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 status information. 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 Stage The 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
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
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 1 2 3 4 5 6 7 8
Device Configuration String Interface Endpoint Device qualifier Other speed configuration Interface power
00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000
Table2.2 Descriptor types and values i. Device descriptor
A 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.
The Device descriptor used for the FPGA is given in the table2.5 of the CDC-ACM section. ii. Configuration descriptor
It 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 Communications After the host has exchanged enumeration information with the device and a device driver has been assigned and loaded, the application communications can begin. At the 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
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.2 UTMI SPECIFICATION [2]

Intel has provided specification for developing low level USB transceiver called Transceiver 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; data serialization 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 Low speed 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 options allow a single SIE implementation to be used with any speed USB transceiver. Vendors can choose the transceiver 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 no alternate speeds to switch to.
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. The UTM 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 to serialize. 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.
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 conversion and 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 DataData+ 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,
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 information with 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 tristates 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
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.3 CDC-ACM SPECIFICATION
[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.
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 type of 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 Audio device Communications Device Content Security Human Interface Device Class (HID) Image Device IrDA Mass Storage Device Monitor Physical Interface Device Class (PID) Power Device Class Printer Device Class code 01h 02h 0Dh 03h 06h FEh 08h
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
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 Class 2. Communication Interface Class 3. Data Interface Class Framework for building a communication device: Assembling the configurations. relevant USB logical structures into
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 basic
telephone, 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 different types 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, digital telephones, 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.
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 it as 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.
Memory address ( Decimal)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Value Name
bLength bDescriptorType bcdUSB (lsb) bcdUSB (msb) bDeviceClass bDeviceSubClass bDeviceProtocol bMaxPacketSize0 idVendor(lsb) idVendor(msb) idProduct(lsb) idProduct(msb) bcdDevice(lsb) bcdDevice(msb) iManufacturer iProduct iSerialNumber
( Hexadecimal)
Description of the Values

It describes that the length of this data is 18 bytes. This describes that this is device description. USB Specification Release Number in Binary-Coded Decimal=USB2.0 This is Communication Device Class code. This is given in configuration description table. the device does not use class specific protocol Maximum packet size for endpoint zero=64byte. It is the vendor ID of the device assigned by USB-IF and for this purpose that of Xilinx's was used. this is the serial number given to the device by the manufacturer and some value was given for this purpose. It is device release number in binarycoded decimal and for test purpose so it was given to be version 1.0. No index of string descriptor describing manufacturer. No index of string descriptor describing product. No index of string descriptor describing device serial number. Number of possible configurations is one. This portion of the memory is unused so it is filled with useless zeros Until the configuration description starts.
12 01 00 02 02 00 00 40 FD 03 08 00 00 01 00 00 00
bNumConfigurations 01
18-63
padding 0's
00
Table2.5 Values and descriptions of the memory that hold device descriptor
Memory address
(Decimal)
Value Description of the Values 9 bytes for configuration descriptor header bLength 09 9 bytes long bDescriptorType 02 Configuration descriptor. wTotalLength(LSB) 3e 62 byte long configuration wTotalLength(MSB) 00 descriptor available. 02 Two interface configuration, one bNumInterfaces for data & the other for control. 01 Identifier for set_cnfg_rqst and bConfigurationValue get__cnfg_rqst requests. 00 No Index of string descriptor for iConfiguration the configuration. bmAttributes 80 80=Self powered, C0=bus powered fa 250mA is half of the maximum bMaxPower power needed by this device. 9 bytes for communication control class interface descriptor bLength 09 9 bytes long. bDescriptorType 04 Interface descriptor. bInterfaceNumber 00 Zero interfaces. bAlternateSetting 00 No alternate setting. bNumEndpoints 01 One end point. 02 Communication Device Class bInterfaceClass Interface. 02 Abstract Control Model Subclass bFunctionSubClass code. bFunctionProtocol 01 Protocol code for AT commands. 00 No Index of string descriptor for iFunction the function. 5 bytes for functional descriptor header bFunctionLength 05 5 bytes long. bDescriptorType 24 Functional descriptor. bDescriptorSubtype 00 Header of functional descriptor. bcdCDC(lsb) 10 Communication device class bcdCDC(msb) 01 specification is 1.10h. 4 bytes for abstract control model functional descriptor bFunctionLength 04 4 bytes long. Name
(Hexadeci mal)
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87
88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113
bDescriptorType
Functional descriptor. Abstract Control Management bDescriptorSubtype functional. 00 Commands for ACM are not bmCapabilities supported. 5 bytes for Union functional descriptor bFunctionLength 05 5 bytes long. bDescriptorType 24 functional descriptor 06 Union Descriptor Functional bDescriptorSubtype Descriptor 00 Interface number of the control bMasterInterface (Communication Class) 01 Interface number of the slave (Data bSlaveInterface0 Class) 7 bytes for notify IN endpoint descriptor (interrupt transfer) bLength 07 7 bytes long bDescriptorType 05 endpoint descriptor bEndpointAddress 82 IN_2 bmAttributes 03 interrupt transfer wMaxPacketSize(lsb) 08 Maximum packet size supported. Bits 10 through 0 are the maximum 00 wMaxPacketSize(msb) packet size, from 0 to 1023 ff Maximum latency/polling bInterval interval/NAK rate 9 bytes for data class interface descriptor bLength 09 9 bytes long bDescriptorType 04 interface descriptor bInterfaceNumber 01 one interface bAlternateSetting 00 no alternating 02 2 end points one Out and the other bNumEndpoints In. bInterfaceClass 0a Data Interface bInterfaceSubClass 00 none bInterafceProtocol 00 none iInterface 00 none 7 bytes for data IN endpoint descriptor (bulk transfer) bLength 07 7 bytes long bDescriptorType 05 endpoint descriptor
24 02
114 115 116 117 118
bEndpointAddress 81 IN_1 bmAttributes 02 bulk data transfer wMaxPacketSize(lsb) 40 wMaxPacketSize(msb) 00 64 bytes bInterval 00 zero interval 7 bytes for data OUT endpoint descriptor (bulk transfer) 119 bLength 07 7 bytes long 120 bDescriptorType 05 endpoint descriptor 121 bEndpointAddress 01 OUT_1 122 bmAttributes 02 bulk data transfer 123 wMaxPacketSize(lsb) 40 124 wMaxPacketSize(msb) 00 64 bytes 125 bInterval 00 zero interval This portion of the memory filled with Padded 0s since the configuration description is only 62 byte long. 126-255 padding 0's 00 Table2.6 Values and descriptions of the memory that holds configuration descriptors
2.2 HDL BASED FPGA DESIGN PROCESS

2.2.1 HARDWARE DESCRIPTION LANGUAGES
HDLs 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 HighSpeed Integrated Circuits. Hence VHDL is a hard ware programming language used to 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.
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 if statement, 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
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.2 FPGA DESIGN FLOW

The 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. ii. iii. iv. Translate Interprets the design and runs a design rule check. Map Calculates and allocates resources in the targeted device. Place and Route Places the CLBs in a logical position and utilizes the routing resources. Configure Creates a programming bit stream file.
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.
CHAPTER THREE DESIGN OF THE PROJECT

3.1 OVERALL 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
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.2 COMPONENTS AND THEIR DESIGN

3.2.1 RCVR 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
Name clk rst rx_Dp rx_Dm rx_vld rx_actv
Direction in in in in out out
Numbe Description r of bits 1 48 MHz clock 1 1 1 1 1 If asserted , every signals will be reseted and be at their initial values Received bit from D+ cable Received bit from D- cable Is asserted for one clock time whenever valid byte is received Asserted when sync pattern is detected and deasserted either when EOP is detected or bit stuff error is detected Asserted for one clock time when ever bit stuff error is detected Data byte received from host and will be sent to upstream module
rx_err data_out
out out
1 8
Table3.1 Data interface signals and their descriptions for rcvr module
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 Dis 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.
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-
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 to synchronize 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 the abort 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.
3.2.2 TRNSMTR 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 clk rst
tx_Dp tx_Dm tx_vld
data_in
Direction Number Description of bits in 1 48 MHz clock in 1 If asserted , every signals of this components will be reseted and be at their initial values out 1 encoded Data bit to the D+ cable out 1 encoded Data bit to the D- cable in 1 when asserted, this module starts to send sync pattern to the host and transmission will continue until it is deasserted in 8 received data byte from pkt component and is to be processed and transmitted to
the host bit by bit it is asserted when the component is ready to receive the next byte to be transmitted from the pkt module Op_mode in 2 When 00 Normal transmission mode when01 it will be non-driving mode (SE0 deferential signals will be transmitted)and this input comes from usb_fpga Figure3.7 Entity diagram of the trnsmtr component tx_rdy Table3.2 data interface signals and descriptions for trnsmtr component out 1
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 state machine is initially in the idle state and will negate tx_rdy and transit to tx_wait_state when rst signal is active low. At tx_wait_state, the module waits for the assertion of tx_vld by the upper stream pkt module so it will enter the snd_sync_state. When at snd_sync_state, the encoded sync pattern of KJKJKJKK will be transmitted to the host and the state machine enters tx_data_load_state. When tx_data_load_state, it will load the data_in with a byte from the pkt module by asserting tx_rdy signal and goes to tx_data_wait_ state to process and transmit the received byte. When tx_data_wait_state, it will deassert the tx_rdy and it will put the content of data_in into tx_hld_reg. At rising edge of each clock, the most significant bit of the tx_hld_reg will be shifted so that the byte will be serialized bits. In this state there is another state machine which checks for the need of the bit stuffing. It is fed with the serial bits as shown in the following diagram.
Figure3.9 State machine diagram for detecting consecutive bits that needs bit stuffing If six successive serial bits are detected, bit_stf_en will become high so that a zero will be added to the serial bits. The serial bits will be encoded using the non return on zero inverse mechanism. The encoded bits will be transmitted as Dp and Dm to the host.
If the tx_hld_reg is emptied, the state machine goes back to the rx_load_data_ state to get new byte but if tx_vld is negated by upper module, the state machine enters snd_eop_state. At snd_eop_state, two SE0 signals followed by J signal will be sent so that the host will understand about the end of the transfer. Then state machine goes back to the tx_wait_state.
3.2.3 PKT MODULE

This module is designed to perform two basic functions 1. Receive data bytes from the rcvr module ,then identify the packet type, check against PID and CRC errors and transmit the bytes upstream to trnsct module. 2. Receive data bytes from tnsct module that are to be transmited to the host, identify packet type, calculate and attach the corresponding crc field then finally transmit the data downstream to trnsmtr module. Hence it interacts with three other modules as shown in the following entity interface.
Figure3.10 The entity diagram of the pkt component Name clk rst Direction Number Description of bits in 1 48 MHz clock in 1 If asserted, every signals of this components will be resetted and be at their initial values out 8 data bytes to be sent to trnsmtr module out 1 will be asserted when data is being received from upstream trnsct module and transmitted to the trnsmtr module if asserted, data_out will be loaded with new byte contains data byte received from the rcvr module if asserted , new byte has arrived from rcvr byte when asserted, the module is receiving bytes from rcvr module when asserted, receiving will be stopped and inform upstream module asserted to inform trnsct module data is being received from host asserted when new byte is available in data_in asserted when receiving is ended (rx_actv is low) received byte to be sent to trnsct module asserted when new byte is needed form trnsct module when asserted, the module is transmitting bytes to trnsmtr module Holds data bytes that are received from trnsct module and will be sent to trnsmtr by attaching CRC fields
data_out tx_vld
tx_rdy data_in rx_vld rx_actv rx_err pkt_rx_actv pkt_rx_rdy
in in in in in out out
1 8 1 1 1 1 1 1 8 1 1 8
pkt_rx_cmpl out pkt_rx_data pkt_tx_rdy pkt_tx_actv pkt_tx_data out out in in
Table3.3 data interface signals for pkt component The detail analysis can be seen by dividing the module as two parts with respect of the host. 1) When the FPGA is receiving data from the host. 2) When the FPGA transmitting data to the host.
And these details tell how the pkt module works along with figure3.10 or table 3.3 and figure3.11.
Figure3.11 State machine diagram of packet module 1) When the FPGA is receiving data from the host When data is being received from the host, it is the rcvr module which is the source of the bytes to this pkt module. The rcvr module also update the control status signals rx_vld, rx_actv and rx_err. rx_actv is the signal which will be asserted through out the receiving duration but rx_vld is asserted only for single clock duration when a valid eight bit data is ready by the rcvr module. And rx_err is only asserted if error is detected while receiving by the rcvr module.
Initially the state machine is in the idle state and waits till either rx_actv is asserted by the rcvr module or pkt_tx_actv is asserted by the trnsct module. If rx_actv is asserted it start to prepare for receiving. While rx_err is 0 and rx_vld is asserted, data_in will be loaded with an 8 bit data from the rcvr module. The first byte is the Packet Identifier (PID); so the lowest four bits should be the negation of the highest four bits. If it fails to do so, this means the PID is corrupted so the state machine will enter to wait_state till rx_actv is deasserted and then it will go to the idle sate for waiting another transfer. However if the PID has no error, the module identify the type of the packet using the last two bits of the PID as follow. 01=token packet, 11=data packet, 10=handshake packet, and 00=unsupported packet types. If it is token packet, the state machine will enter rx_token_state, if it is data packet, the state machine will enter rx_data_state, or if it is a handshake packet, it will enter rx_handshake_state, other wise it will go to wait_state. It also enters to this state if rx_err is asserted while being in any state. If it is in rx_hndshk_state, it expects rx_actv to be low as handshake packets are only one byte long which is the PID. So if rx_actv is low, the module enters to rx_fin_state but if rx_vld is high after receiving the handshake packet, this means some error has occurred so it will go to the wait_state. If the state machine is in rx_token_state while rx_actv is high, bytes will be received in to data_in whenever rx_vld is asserted. These bytes will be put to pkt_rx_data so that it will be outputted to trnsct component and at the same time the bytes will be sent to the CRC5 checker so that each token bit (total length of 2 byte with out the PID) will be calculated and buffered till rx_actv is deasserted and the remainder will be compared with the CRC5 residual which is 01100B. If the remainder and the residual matches, the token has no error so it goes to rx_fin_state. But if the match failed, the state machine goes back to the idle_state.
Figure3.12 Token packet If the state machine is in rx_data_state while rx_actv is high, bytes will be received in to data_in whenever rx_vld is asserted. The bytes will be put to pkt_rx_data so that it will be outputted to trnsct component and at the same time the bytes will be sent to
the CRC16 checker function so that each data bit (total length is variable) will be calculated and buffered till rx_actv is deasserted and the remainder will be compared with the crc16 residual which is 1000000000001101. If the remainder and the residual matches, the data packet has no error so it goes to rx_fin_state (the last two bytes of the data are the attached CRC values that are calculated by the host). But if the match failed, the state machine goes back to the idle_state.
Figure3.13 Data packet format The pkt module needs not to inform the upper modules about the occurrence of an error instead it deasserts pkt_rx_actv with out asserting pkt_rx_cmpl signal. The host will retransmit the data if it does not get an acknowledgment with in some time interval. When the state machine is in the rx_fin_state, pkt_rx_cmpl will be asserted for one clock cycle thus it informs the trnsct module about the successful completion of the transfer. When both rx_actv and rx_vld are high, pkt_rx_rdy will be asserted to tell trnsct module valid data byte is available and the data_in will be transferred to pkt_rx_data so that it will be processed by the upstream module. Pkt_rx_actv is high when the pkt module is in one of these states: rx_token, rx_data, rx_hndshk or rx_fin. When the FPGA is transmitting data to the host When data is to be transferred from the FPGA to the host, the data may be handshake packet or control information like descriptors and statuses or application data. The trnsct module transfers the bytes to the pkt module and after processing, the pkt modules in turn transfers the data to the trnsmtr module which is its downstream. The state machine, initially at idle_state, checks at every rising edge of the clock for the assertion of pkt_tx_actv by the trnsct component, so that it will go to the tx_strt_state. At the tx_strt_state, it asserts tx_vld so that the trnsmtr begins to send sync byte and it receives the first byte which is the PID from the pkt_tx_data and checks for its type and transferred to the data_out . If the last two bits are 00, it is data packet so state machine goes to tx_data_state but if the bits are 10, it is handshake packet so state
machine goes to wait_state. However if the bits are other than the mentioned ones, still it will go to the wait_state and waits until pkt_tx_actv signal is deasserted because token packets can not be sourced from the FPGA(USB devices). When at tx_data_state , as far as pkt_tx_actv remains high it receives bytes from pkt_tx_data then updates CRC16 buffer signlal values and transmits it to data_out every time tx_rdy is asserted by the trnsmtr component. While doing tx_vld is kept asserted. However; if pkt_tx_actv is deasserted, the state machine goes to tx_crc1_state. At tx_crc1_state ,this component sends the the first byte of CRC16 field (the higher eight bits of the 16 bit crc buffer signal value) to data_out when tx_rdy is high and goes to the tx_crc2_state. At tx_crc2_state, this component sends the the second byte of CRC16 field (the lower eight bits of the 16 bit CRC buffer signal value )to data_out when tx_rdy is high and goes to the wait_state by deasserting tx_vld. In the wait_state, if neither of pkt_tx_actv nor rx_actv are high , it will go to the idle_state because there is no transmision or receiving. Acording to the USB specification token packets are not sent from device to the host, they are only generated by the host and sent to the device. Hence this module only implements data CRC calculator while transmiting although it checks for both data and token CRCs when receiving.
3.2.4 TRNSCT MODULE

This module handles diferent transactions of the bulk and the control transfers. Its major purpose is to perform the following activities . A. Receives data from the pkt component and deals with token, data and handshake packets by identifying the transaction type as IN, OUT and Setup. And strips off the PIDs. B. Identifies the destination end points and transfer the data either as control transfer or bulk transfer. C. Receives data from main or cntrl component, prepare PID and transfer it to the pkt compnent. D. Generates handshake packets and sends when needed.
This module interconnects with other three componets in the following ways.
Figure3.14 the Entity of the trnsct component Name clk rst pkt_rx_actv pkt_rx_rdy pkt_rx_cmpl pkt_rx_data pkt_tx_actv pkt_tx_rdy pkt_tx_data in_trnsct out_trnsct setup_trnsct fin addr end_pt Directi on In In In In In In Out In Out Out Out Out Out In Out Number of bits 1 1 1 1 1 8 1 1 8 1 1 1 1 7 4 Description 48 MHz clock If asserted, every signals of this components will be resetted and be at their initial values If asserted, data will be being received from downstream module (pkt) If asserted, received byte will be fetched If asserted, the module finishes the current transaction. Data from downstream module Asserted when the module got data to transmit to the host If asserted, pkt_tx_data will be loaded Data to downstream module High when current transaction is IN High when current transaction is OUT High when current transaction is Setup Asserted when transmission ended Address of the FPGA, initially 0. The end point number for current
nak stl snd rx_rdy rx_data tx_rdy tx_data
In In In out Out Out In
1 1 1 1 8 1 8
transaction If high, Initiates NAK handshake to be sent If high, Initiates stall handshake to be sent If high, upstream modules are transmitting Asserted, if ready to receive data from upstream modules Received data to cntrl or fpga_usb module Asserted, if it is ready to the next byte from the upper modules Data from upper modules, to be transmitted to the host
Table3.4 data interface signals of trnsct component And it has the following finite state machine diagram
Figure3.18 the state machine diagram of transct component We can see how and what the different activities are done by classifying them to two with respect to the direction of the data flow using the signals of table3.4 and figure3.18.
1) When the FPGA is receiving data from the host Initially it waits at the idle_state till when the signals pkt_rx_actv is high and pkt_rx_rdy is asserted to show the pkt module has got valid byte and so pkt_rx_data (the PID) will be checked for its lower four bits to identify the transaction type. As the first packet is a token and it should be one of the followings out_pid = "0001", in_pid = "1001", setup_pid = "1101" then it will enter to the frst_tkn_state. Otherwise it goes to skip_state. At the frst_tkn_state, when pkt_rx_rdy is asserted, pkt_rx_data will receive its second byte and extract the lowest seven bits and compare it with the stored address of the FPGA in the addr signal inputted from cntrl component. If it matches, the data is destined to this device so it goes to scnd_tkn_state after putting the eighth bit of the received byte in the lowest significant bit of the end_pt signal. If it does not match, it goes to skip_state and ignores the rest of the incoming packets.
Figure3.16 Second byte of a token At the scnd_tkn_state, when pkt_rx_rdy is asserted, pkt_rx_data will receive its third byte and extract the highest three bits and concatenate them in to the end_pt signal with the previous bit so that the destination end point address will be identified. And state machine will go to the third_tkn_state. The CRC bits are ignored.
Figure3.17 Third byte of a token At thrd_tkn_state, it waits for confirmation of the end of the token packet. If pkt_rx_cmpl is asserted by the pkt component, it means the full valid token is received without CRC error so it will go to tkn_rcvd_state. And it sets time counter to either 10 clock cycles if the transaction type is IN (because the next packet will be sourced from the FPGA) or 500 clock cycles if the transaction type is Setup or OUT because the next packet is expected from the host and there are in the middle a lot of non application data packets like sync, EOP, CRC, PID as well as some buffering
and processing times, a longer time out counter is needed before it expires. If the timer expires it will go to the idle_state. At tkn_rcvd_state, here already the valid token is received so either of the in_trnsct or out_trnsct or setup_trnsct will be asserted till the end of the whole transfer. if pkt_rx_actv is high it checks at every clock cycle for the value of pkt_rx_rdy, if it is one and the transaction is not IN, it will receive the first data byte and it checks if the PID type is data_pid (lower three bits 011) then it will go to rx_data_state and if it is not data PID, it will go to the skip_state. But if Pkt_rx_rdy is zero, the counter decreases by one every clock cycle. If counter is zero and in_trnsct is high, it will go to snd_data_state unless one of the stl or nak signals are asserted in which case it will enter snd_hndshk_state to send the appropriate handshake packet towards the host. However if the counter is zero while the asserted transaction type is either out_trnsct or setup_trnsct, the expected data from the host has not arrived with in the expected time so it will go to the idle_state. In rx_data_state, trnsct module receives data bytes in pkt_rx_data and transfers it to rx_data output port either to the cntrl module if the end_pt is zero or to the fpga_usb module if the end_pt is one or two until the completion of the incoming data (when pkt_rx_cmpl is asserted, the state machine will be transited to data_rcvd_state). Every time data comes (pkt_rx_rdy is asserted), it will assert rx_rdy output signal. In data_rcvd_state, the whole data is received so it waits for the inter packet counter timer to become zero (ten clock cycle) and goes to snd_hndshk_state. In the skip_state, it waits till pkt_rx_actv is deasserted and by then it goes to idle_state. 2) When the FPGA is transmitting data to the host This module sends handshake packets when it wants to inform the host whether data is successfully received (ACK) or the received data is unsupported type (stall) or the FPGA application is busy or has no memory space to accept and process the data(NAK). It also transmits data from upstream modules (control and fpga_usb) to the host. At snd_hndshk_state, this module sends a one byte PID (handshake packet) to the packet module. The hand shake packet is either stall (00011110) if the stl signal is asserted or NAK (01011010) if the nak signal is asserted or ACK (11010010) if the data is successfully received and the above two input signals are low. After this it will go to the fin_state.
In snd_data_state, data PID is sent and the next byte will be prepared. When pkt_tx_rdy is asserted, the state machine goes to sndg_state. At sndg_state, every time pkt_tx_rdy is asserted, data bytes from upper module (tx_data) will be transferred to lower module (pkt_tx_data) as far as the snd input control signal is kept high. Each time the next tx_data is needed by the pkt module, tx_rdy will be asserted. When snd is low (transmission is complete), it goes to wait_ack_state. Pkt_tx_actv will be high when the state machine is in one of the states: snd_data_state, sndg_state and snd_hndshk_state. In wait_ack_state, the module waits for acknowledgment packet from the host by decreasing the time out counter every clock cycle until it becomes zero where it will go to idle_state. If before the timeout expires, pkt_rx_actv is asserted and the pkt_rx_data is a handshake byte (ACK PID), state machine goes to rx_ack_state otherwise if another PID comes it goes to frst_tkn_state. In the rx_ack_state, if pkt_rx_cmpl is asserted, the state machine goes to the fin_state however if pkt_rx_actv is deasserted, it goes to the idle_state. In the fin_state, the fin signal will be asserted for one clock cycle and the state will be changed to the idle_state. But if pkt_rx_actv is deasserted without pkt_rx_cmpl is asserted, this means error occurs in downstream modules so it goes to the idle_state.
3.2.5 CNTRL MODULE

This module is very essential component which is used to complete the mandatory enumeration process. It accepts different requests and information from the host and acts up on the requests accordingly.
Figure3.18 The entity diagram of cntrl module
Name clk rst
Directi on In In
Number of bits 1 1
Description 48 MHz clock If asserted, every signals of this component will be resetted and be at their initial values. Address of the FPGA, set by this module when the host assigns, otherwise it is zero. Asserted, to synchronize IN endpoints. Asserted, to synchronize OUT endpoints. High when this component needs to read data from memory of the fpga_usb module and put it into tx_data. High, when the memory should reset its read address to the first byte of the device descriptor to start reading. High, when the memory should reset its read address to the first byte of the configuration descriptor to start reading. High, when the memory should read one byte, puts its value on tx_data, and increment the read address. If asserted, it informs that IN transaction has begun for control end_pt. If asserted, it informs that OUT transaction has begun for control end_pt. If asserted, it informs that Setup transaction has begun for control end_pt. If asserted, it informs that trnsct module has completed receiving from downstream modules. High, when it can not accept data. High, when unsupported request type arrived. High, when this module is sending data bytes. If asserted, data bytes will be received on rx_data from trnsct module. Byte received from trnsct module. If asserted, data will be put on tx_data. Data byte to be transmitted down stream.
addr clr_sync_in clr_sync_out rd_dsc_mem
Out Out Out Out
7 2 2 1
rd_dvc_dsc
Out
rd_cfg_dsc
Out
rd_nxt_dsc
Out
in_trnsct out_trnsct setup_trnsct fin
In In In in
1 1 1 1
nak stl snd rx_rdy rx_data tx_rdy tx_data
Out Out Out In In In Out
1 1 1 1 8 1 8
Table3.5 cntrl module signals and their description
Figure3.19 state machine diagram of cntrl module. How Control Module Works. How it works is described below using the help of figure3.19 and table3.5 above. This module is connected with the trnsct module if the end_pt signal is zero (control endpoint). At first the addr signal is initialized to the value of zero (0000000B) till it is changed by the set_addr_rqst. And this module interacts with the memory of the fpga_usb module using the signals: rd_dsc_mem, rd_dvc_dsc, rd_cfg_dsc and rd_nxt_dsc. When reset the state machine of the module will be at idle_state and waits till setup_trnsct is asserted by the trnsct module so that it will go to the setup_state.
At the setup_state, each time rx_rdy is asserted it receives request bytes from the host that means it is in the data phase of the setup stage so that eight bytes of request data will be received and processed in the following way. First byte (bmRequestType): bit 5 and bit 6 should be zero (standard request); otherwise it goes to non-standard state. Second byte (bRequest): higher four bits should be always zero and the lower four bits will be stored in cntrl_rqst signal (it is the request type) other wise, it goes to err_state. Third byte (wValue lsb): this byte should be stored in cntrl_prmtr_sig. Depending on the cntrl_rqst value it can have different meanings. Fourth byte (wValue msb): if cntrl_rqst is get_dsc_rqst, this byte should be 00000001B for device description or 00000010B for configuration description and should be stored in the cntrl_prmtr signal. Otherwise it goes to err_state. Fifth byte (wIndex lsb): if cntrl_rqst is clr_ftr_rqst, it clears the endpoint halt feature and store this byte in cntrl_prmtr. Sixth byte (wIndex msb): do nothing it does not care whatever values it has in this work. Seventh byte (wLength lsb): the last six bits specifies how much bytes the host needs in the response. So it stores this in the answr_lngth signal. Eighth byte (wLength msb): it must be zero. After the above eight bytes are received, the state machine will transit to setup_end_state. However if in the middle of this transfer, fin signal is asserted it will go to stl_state and if setup_trnsct is deasserted it will go to idle_state. These signals are input from trnsct module. At setup_err_state, it waits till fin is asserted and then goes to stl_state but if setup_trnsct is deasserted before fin assertion, it will go to idle_state. At non_stndrd_state, it will wait until setup_trnsct is deasserted so that it will go to the idle_state. In the setup_end_state, it will wait till fin is asserted by the transct component after that it will parse cntrl_rqst and then act accordingly. If cntrl_rqst is get_status_rqst, it goes to waiting_state. If cntrl_rqst is clr_ftr_rqst, it will go to idle_state by asserting either clr_sync_in or clr_sync_out depending on the 7th bit of cntrl_prmtr. If cntrl_rqst is set_addr_rqst, it goes to waiting_state. If cntrl_rqst is get_dsc_rqst, it goes to waiting_state. If cntrl_rqst is get_cnf_rqst, it goes to waiting_state. If cntrl_rqst is set_cnf_rqst, it will go to idle state by setting the confgd to the last bit of the cntrl_prmtr if the other bits are 0, otherwise it will go to stl_state.
If cntrl_rqst is get_intrfc_rqst, it goes to waiting_state. However if cntrl_rqst is other than the above (unsupported requests) then it goes to stl_state but if setup_trnsct is 0, it will go to idle state. In stl_state, the stl signal will be asserted so that the trnsct module will send the stall handshake packet and the state machine goes to setup_state when setup_trnsct becomes high. At waiting_state, if in_trnsct is asserted, this module responds depending on the content of the pervious cntrl_rqst as follow: If cntrl_rqst is get_status_rqst, the state machine will go to snd_zero_state. If cntrl_rqst is set_addr_rqst, addr signal will be set with the content of the cntrl_prmtr and it goes to idle_state. If cntrl_rqst is get_dsc_rqst, it is going to respond with the descriptor data so it will check whether the request is device descriptor (when cntrl_prmtr = 00000001B) or the request is configuration descriptor (when cntrl_prmtr = 00000010B) so that it will set the answr_lngth with the needed number of bytes. And finally it will go to strt_dsc_state. If cntrl_rqst is get_cnf_rqst, it goes to snd_cfg_state to respond with configuration byte. If cntrl_rqst is get_intrfc_rqst, it goes to snd_zero_state to respond with zero byte. At this state rd_dsc_mem will be set with the value of in_trnsct and rd_dvc_dsc will be asserted if cntrl_prmtr = 00000001B but if cntrl_prmtr = 00000010B, rd_cfg_dsc will be asserted. If state machine is at snd_cfg_state, it should send the configuration byte (set tx_data with 0000000&confg) and if tx_rdy is asserted it goes to snd_cmpl_state otherwise if in_trnsct is deasserted it will go to wait_state. When at strt_dsc_state, it prepares to send descriptor data by asserting rd_dsc_mem and rd_nxt_dsc signals and it also asserts snd signal so that trnsct component will prepare to send. Then it goes to snd_dsc_state after one clock cycle. At snd_dsc_state, data bytes will be fetched from the fpga_usb components memory and put in to tx_data each time tx_rdy is asserted by the trnsct component by asserting rd_nxt_dsc signal until answr_lngth is zero (it will be reduced by one each time data is sent) at which point the state machine transit to snd_cmpl_state and rd_dsc_mem and snd signals will be kept high. If in the middle of transfer, in_trnsct goes to low (becomes zero), the transmission will be aborted and it will enter to waiting_state incase the host retries the transaction.
When at snd_zero_state, the module responds to IN transaction with zero byte or bytes each time tx_rdy is asserted till answr_lngth is zero and it keeps snd signal high and then it goes to snd_cmpl_state. At snd_cmpl_state, if fin is asserted which means successful completion of transaction, it will go to idle_state but if in_trnsct is deasserted before fin is asserted, the state machine goes to waiting_state incase the host retries the transaction.
3.2.6 FPGA_USB MODULE

This module integrates all the above subcomponents and also it performs three major activities: 1. Memory interaction 2. Bulk and interrupt transferring 3. Initialization and resetting
Figure3.20 Entity diagram of the fpga_usb module.
Name clk dvc_rst
Number Direction Description of bits 1 1 in In 48Mhz clock When high, the application is resetting, so every components should be reset. Asserted, if a valid byte is available to be sent to the application. Data byte received from host. If asserted, the next byte will be sent to the application. When high, data is being from the FPGA application. Data byte received from the FPGA application. Asserted so the application will send the next byte. A bidirectional signal for receiving and sending bits from and to the host A bidirectional signal for receiving and sending bits from and to the host
hst_rx_vld data_rx_frm_hst fpga_rx_rdy fpga_tx_vld data_tx_frm_fpga hst_rdy_to_nxt_byt Dp
1 8 1 1 8 1 1
Out Out in in in Out inout
Dm
inout
Table3.6 Signal description of fpga_usb component
Figure3.21 State machine diagram of the fpga_usb component 1. Memory interaction This module implement a 512 byte memory, 256 byte as a ROM for storing the device and configuration descriptors, 128 byte as transmit buffer so that data coming from the FPGA application can be stored until they are transferred to the host and the remaining 128 byte is for storing data that comes from the host before they are picked by the application. For the descriptors, the first 18 bytes are for the device descriptor and the other configuration descriptors which include the interface, endpoint and functional descriptors occupy 62 bytes addressed from 64 to 126 and the rest of the descriptor memory space is padded with zero bytes. The memory is written and read from two directions: from the host and from the application. From the host side: When the trnsct_out signal is activated and the trnsct_end_pt is set to data endpoint, write mode is enabled and the memory pointer signal will be taken to the head of the receiving memory and bytes (trnsct_rx_data values) will be written and the memory pointer is increased each time trnsct_rx_rdy is asserted. If the activated signal is trnsct_in (read mode), the pointer goes to the tail of the transmitting buffer and data will be read by adjusting the appropriate memory pointer and sent to the trnsct module (trnsct_rx_data) whenever trnsct_tx_rdy signal is active. But if the active end point address is set to zero which is the control endpoint, whenever the cntrl_rd_dvc_mem signal is high, the pointer will be taken to start of the device descriptor memory and begin to read the bytes of device descriptor and transmit when ever cntrl_tx_rdy is asserted but if the active signal is
cntrl_rd_cfg_mem, the pointer will be taken to the start of the configuration descriptor and bytes will be read and transmitted. From the application side: If fpga_rx_rdy is asserted which implies the FPGA application is ready for the next byte, data from receiving buffer will be fetched and put in to the output signal data_rx_frm_hst. If the application has valid data to send to the PC, it asserts fpga_tx_vld so that the data from data_tx_frm_fpga will be received and stored in the transmitting buffer till the host requests it. And if this data is transmitted to the host, hst_rdy_to_nxt_byt will be active so that the application will send the next data.
Figure3.22 512 RAM memory for storing descriptors and data from host and to host 2. Bulk and interrupt transfers
With the help of figure 3.21 and table 3.6, the main function of this module is explained as follow. According to the specification of the CDC class, two end points are implemented. One end point for data transport between the host and the FPGA in both direction and it uses bulk transfer and its end point address is 0001B. The other endpoint is for class specific management and notification and it uses interrupt transfer. But in this work, it is given an endpoint address of 0010B though data destined to this endpoint are NAKed because implementing the complex class specific management of the FPGA as communication device is beyond the scope of this work. When the module is reset, the buffers are empty and the head and tail pointer signals of both the rx and tx buffers are zero. And it is in idle_state. When at Idle_state, it waits till trnsct_end_pt is set to data end point (0001B) and either of trnsct_in or trnsct_out signal to be asserted. If trnsct_in is asserted, transmitted buffer will be checked for the presence of data and if no data, state machine will go to nak_state otherwise to in_strt_1_state. However If the trnsct_end_pt address is 0010B which is the end_pt_notify, although trnsct_in might be asserted state machine goes to nak_state. If trnasct_out signal is asserted while the end_pt address is the data end point, it will check if the available receive memory can handle the maximum packet size which is 64 byte. If enough buffer is available, state machine transits to out_strt_state otherwise to out_nak_state. In nak_state, the trnsct_nak signal will be asserted so that the trnsct module will send NAK handshake packet to inform the host to stop sending data. And the state machine will transit back to idle_state as soon as both trnsct_in and trnsct_out signals are asserted. At in_strt_1_state, it prepares the memory to send data by taking the memory pointer to the tail of the transmit buffer. If there is no data in the buffer, it will go to in_cmpltd_state otherwise it will go to the in_strt_2_state. At in_strt_2_state, it will assert the block RAM signal rd_nxt_mry so that it can read the first byte and send to the trnsct component and transit to in_snd_state. At in_snd_state, it will read from the transmit buffer and send the data to trnsct_tx_data (towards the host) each time trnsct_tx_rdy is asserted and as far as the buffer is not empty (otherwise it will go to in_cmpltd_state) and the trnsct_in signal is high (otherwise it will go to idle_state). It will also keep the trnsct_snd signal high. At in_cmpltd_state, if trnsct_fin is high it will set the transmitting buffer tail to the current pointer and goes back to the idle_state but if trnsct_in becomes low it means that no valid acknowledgement came from the host so the memory pointer will not be changed in case the host retransmits the IN token and goes to the idle_state.
When in out_strt_state, it prepares to receive data by taking the pointer signal to the head of the receiving buffer and then it transits to the out_rcv_state. At out_rcv_state, each time trnsct_rx_rdy is asserted (new data byte is arrived from the host); it will put to the receiving buffer so that the application will take the data and the memory pointer will be incremented. When trnsct_out is deasserted, receiving is finished so the state machine will go back to the idle_state as the acknowledgement is sent by the trnsct module. In the out_nak_state, it will receive non duplicate packets but they will be discarded as there is no room in the receiving buffer and the state machine goes to the nak_state otherwise it will wait till the trnsct_out is deasserted and then goes back to idle_state. 3. Initialization and resetting This module also handles the initializing (power on) process and different resting activities of the whole system. As soon as the FPGA device is plugged to the USB port, there is a countdown counter which counts 17.5ms until the device is ready to receive and transmit. There is also a two bit signal called line_state which monitors the current states of Dp and Dm. At normal data transfer, line_state values should toggle between J and K and it will be SE0 for two bit times when sending or receiving EOP signals. Otherwise If line_state is found to be SE0 (both Dp and Dm are low) for at least 2.5s or 132 clock cycle, it detects a reset signal sent from the host so it will assert the local signal bus_rst_sig and starts to count down for the expiry of the power on timer where it will deassert it. The module also can be reset from the FPGA application as will be explained in the next subsection. In this case dvc_rst will be asserted. The assertion of either of the previous two signals will cause the assertion of usb_rst which results in resetting of this component and this is also the input to the rst signal of the other components. When the usb_rst is high the op_mode will be in non-driving mode which means both the Dp and Dm will be low and nothing will be transmitted in this mode.
3.2.7 FPGA APPLICATION MODULE

This module is intended as test application for the USB protocol. It is a top level module whose subcomponent is the fpga_usb module. It has two modes: computer control mode and FPGA control mode Initially it is in computer control mode, the FPGA reads input bytes from the host. When it receives the enter character, the FPGA responds by sending the received bytes in reverse order to the host. The FPGA then goes back to reading data from the host. This is done by implementing 1024 byte RAM ,hence only the first 1Kbytes will be returned if the host sends more than that before pressing the enter key.
If the FPGA receives a 0x01 byte, it switches to FPGA control mode. 0x02 byte, it will reset itself and reconnect to the USB bus. In the FPGA control mode, the FPGA can use the FPGA buttons and switches to perform some simple activities. It can also switches to computer control mode and starts to read incoming bytes if the FPGA receives a 0x3 byte from the computer while it is in FPGA control mode.
Name Direction Number Description of bits clk Dp Dm btn swt led an In inout inout in in out out 1 1 1 4 7 7 4 For monitoring the control signals For receiving/transmitting D+ differential signals from/to the host For receiving/transmitting D+ differential signals from/to the host Input from FPGAs push buttons Input from FPGAs switches Output to FPGALEDS Output to FPGAs seven segment decoders
Table3.7 data interface signals of application module
Figure3.23 State machine diagram of the test application The main purpose of this module is to receive data bytes from the fpga_usb components receive buffer and use it. And it also supplies the transmit buffer with data if the host requests. Table 3.7 shows the signal interfaces of the module. It works as follow, initially it is in the Init_state and waits till the ASCII code of the enter key is arrived, and then by initializing the memory pointers to the starting of the RAM, it will go to the read_from_pc_state. At read_from_pc_state, it receives bytes from the user and save it to 1024 byte RAM until some switching mode bytes are detected. If hst_rx_vld control register from the fpga_usb component is asserted and the received byte (data_rx_frm_hst) is the ASCII code of the enter key (00001101B) it will go to the wrt_to_pc_state whereas if data_rx_frm_hst is equal to 00000001B, the state machine will switch to fpga_cntrl_state but if data_rx_frm_hst is equal to 00000010B, it will go to bus_rst_state. At this state fpga_rx_rdy is kept high so that the host can send the bytes continuously. In the bus_rst_state, the FPGA disconnects it self from the host and starts reconnecting. That means, every signals and control registers will be reset and the
enumeration process of the USB will be done and finally the state machine will start in the init_state. At wrt_to_pc_state, the application reads bytes from the RAM from up to bottom direction and feeds data_tx_frm_fpga so that it will be written to the transmit buffer of the USB protocol and sent to the host. This means, what is received from the host will be sent back to the host in reverse order till the RAM is empty where it will goes back to the read_from_pc_state. If the host sent more bytes than the 1024 RAM capacity, only the first 1024 bytes will be sent. The fpga_tx_vld signal will be kept high through out the transmission period. When in fpga_cntrl_state, it will keep listening to the inputs from the host and only the byte data_rx_frm_hst=00000011B will change this state back to the read_from_pc_state. Parallely the FPGA can be driven from inputs of its own switches and buttons. For example in this application, the eight LEDs of the FPGA can be derived by changing the inputs from the switches by keeping switch 7 high. And a simple 0 to 9 counter will count and display in the four seven segment decoders. And these decoders can also be driven by the four push buttons. Similarly pressing push button 3 of the FPGA will take back the state machine to read_from_pc_state. Since it waits the switching byte from the host, fpga_rx_rdy is kept asserted.
CHAPTER FOUR TESTS AND RESULTS

4.1 DEVICES AND TOOLS USED
The following devices and tools were used in part or the whole development of this thesis research 1. Xilinx ISE 8.2i WebPack for developing and compiling the VHDL codes, as well as to implement and configure the FPGA. 2. XST synthesis tool was used for gate level synthesizing 3. Xilinx ISE simulator was used for simulating the codes 4. USBlyzer and USBtrace soft wares for capturing USB traffic from the host 5. Windows hyper terminal serial emulator for accessing the FPGA 6. Windows built in usbser.sys driver for the CDC_ACM class 7. Modified .inf file to register vendor and product ID of the FPGA. 8. FPGAs: Xilinx spartan3 FPGA family, device types XC3S200 and XC3S1000 with FT256 package and -4 speeds. 9. Computers with Microsoft window XP operating system.
4.2 SIMULATION TEST CASES AND RESULTS

The work was developed module by module and then integrated. When a module is completed, a VHDL test bench was developed per each module and simulated using Xilinx ISE simulator by giving appropriate inputs and looking for the outputs, then troubleshooting the problems and unexpected outputs by making the appropriate modification to the VHDL module. An isolated CRC5 and CRC16 checker and calculator was written using VHDL for checking purposes. The simulation results and the test bench codes for each subcomponent are not included in this paper. How ever after the end to end development is done, another test bench file giving the inputs was written and simulated as the following continuous procedures. The procedures followed to simulate are the same as what the host is expected to do except the resetting requests are not included here. For every token, handshake and data packets: sync, EOP and the corresponding CRC values are added and the whole data is NRZI encrypted before given as a test bench input.
And followings are different simulation scenarios which can be seen by dividing in to phases as below. Phase 1: enumeration steps (as shown in figure kk) case1: device descriptor i. ii. iii. setup stage data stage status stage
case2: device address i. ii. setup stage status stage
case3: configuration descriptor i. ii. iii. setup stage data stage status stage
Phase 2: application communication case1: data transfer from the host to device case2: data from transfer device to host Phase3: some abnormal conditions case1: token received with CRC error case2: unknown or erroneous PID received case3: stall packet for unsupported request replied case4: Wrong sync pattern received
Figure4.1 Enumeration simulation steps Phase 1: enumeration steps case1: device descriptor Setup stage Step 1: Setup token with addr=0 and end_pt=0 was given as input
Figure4.2 Simulation snapshot when Setup token is input to test bench. As can be shown in figure4.2 and the rest of the other simulation figures, each rising cycle of the clock (line3), Dp and Dm toggles between NRZI decoded 0 and 1 bit except in the case of a reset signal and EOP signal where both can be SE0s. The time from t0 to t1 shows the receiving of Sync pattern (which is 01010100) and the state of the FSM of the rcvr module will be changed from rx_wait_state to strip_sync_state( line 17) and receives the first byte by asserting the rx_activ signals( line4 and line7). After the first byte is received (mostly the PID), rx_vld (line8) will be asserted and the rcvr module go to rx_data_state (line 17) for one clock cycle. At t2, the first setup token PID which is 45(00101101B), so pkt module goes to rx_token_state and waits the next two bytes 0(00000000B) and 16(00010000B) with fields address, endpoint and CRC5. According to the CRC algorithm, each time non PID bytes are received, the token_crc_bfr_sig (line12) will be updated and the final result must be 12(01100B) to be error free. Hence this update of CRC buffers occurs at t3 and t4.
Immediately after t4, both Dp and Dm are low (SE0) followed by J (Dp=1 and Dm=0) hence this indicates EOP detection, so at t5 receiving of setup token came to an end. The trnsct module (line 19) identifies the token as setup token hence it will assert setup_trnsct signal (line 11) starting at t5 and compare the existing address (00000000B line14) with the address in the token field (00000000B at line10 & t3 ). Lines 17 to 20 shows the states of the FSM of the different modules explained in chapter three. Step 2: An eight byte request for device descriptor is given as input
Figure4.3 Simulation snapshot when receiving device descriptor request The simulation snapshot shown in figure 4.3 indicates a data packet from the host to the device for requesting device descriptor. Up to the time t1, Sync pattern is detected (line4, 5, 18) and in the interval t1 to t2thefirst byte which is the data PID received (195=11000011B). Starting from t2, the eight bytes(128,6(descriptor request),0,1(device descriptor), 0,0,18(length),0) of the requests received each time rx_vld(line7) is asserted followed by two byte of data CRC16( 224 and 244 at t5 and t6 in line9). Rx_actv (line3) is high starting from the sync detection until pkt_rx_cmpl (line 8) is asserted.
As shown in line13, data_crc_bfr_sig is updated each time the request bytes are received and the final value must be 32781(1000000000001101B) to be error free. if there was CRC error pkt_rx_cmpl would not be asserted. Line 17-22 shows the change of the states of the modules (detailed in chapter three) Step 3: The FPGA returns an acknowledgement PID with sync and EOP
Figure4.4 Simulation snapshot transmitting ACK packet The setup stage will be completed by the device sending a handshake packet to the host for acknowledging the receive of the request as shown in figure4.4. As soon as the setup request is received successfully, the trnsct modules FSM will go to snd_hndshke_state (line18) and send ACK PID (lin13 and 14) which is 210 (11010010B) by asserting tx_actv as a result tx_vld (line4). The trnsmtr FSM (line15) will enter snd_sync_state and transmit the sync pattern (line 6 and 7) and then assert tx_rdy (line5) for getting a byte to transmit which by then enters tx_data_state and transmits the ACK PID (210) starting at t2. In this figure and others the encoding, decoding, bit stuffing and other internal activities done by the modules are not shown to simplify the clarity of the figures.
Transmitting signal (line3) will be kept asserted through the whole sending phase. Data stage Step 1: IN token with address zero and endpoint zero was given as input
Figure4.5 Simulation snapshot when receiving IN token with default address and control end point (both zero) So far the host has sent the request and the device received and knows what the host needs and acknowledged the receiving of the request, the device will send the device descriptor as soon as it received IN token as shown in figure4.5 The figure is similar to setup token in figure4.2 except the token PID type here is 105 in stead of 45 (line 10) at t2. So the explanation at figure4.2 applies here. Step2: The FPGA sent back the 18 byte of the device descriptor from the memory by prefixing sync and data PID byte and suffixing crc16 and EOP.
Figure4.6 Simulation snapshot when transmitting the eighteen byte device descriptor. Figure4.6 shows when descriptor data is being transmitted to the host. Dp and Dm (line 6, 7) begins by sending sync patterns until t1. As shown in line 14 and 15, then data PID which is 75(01001011B)is transmitted at t1 followed by the 18 device descriptor bytes (18,1,0,2,2,0,0,64,253,3,8,0,16,0,0,0,0,10) followed by two bytes of CRC16(161,107). When transferring each non PID bytes, data_crc_bfr_sig (line 10) calculates and updates the CRC values of the data so far transmitted and the remaining value will be then sent as two bytes. Each time the trnsmtr module transmits a byte; it asserts tx_rdy (line5) and loads data_in (line14) then process and transmits serially (line6 and 7). What state each modules will be is shown in line 14 to line 20. Step 3: Then Acknowledgement packet was given to the device so that the transaction will be completed.
Figure4.7 Simulation snapshot when receiving ACK packet The host is supposed to send an acknowledgment for receiving the device descriptors as in figure 4.7 It is a sync byte followed by ACK PID and EOP as can be seen in the lines 4, 5, 9 from the time interval of t0 to t3. The CRC buffers do not change as hand shake packets are only PID which are self checking (line 11 and 12). And FSM states are shown in line 15 to 20. Status stage Step 1 out token (address and end point are default) followed data PID was given as stimuli as the token and data packet of the states stage
Figure4.8 snapshot of out token with default address and endpoints Figure4.8 shows at t0 sync is detected, at t1 OUT PID which is 225(11100001B) (line 7) is received followed by the two bytes (at t2 and t3) that specify default device address and endpoints with 5bits of which is CRC and after that sync followed by zero length data byte (data PID as shown from t5 t0 t8) is received. The other lines and timing events are similar to the previously explained figures. Step2 acknowledgment for the whole transfer of device descriptor is sent to the host (similar to figure4.4) This completes the status stage of the control transfer for device descriptor request. Case2: device address Setup stage Step 1: Setup token with addr=0 and end_pt=0 was given as input (similar to figure4.2)
Step 2: The eight byte request for setting addresses was inputted with the necessary USB headers and trailers (Sync, data PID, and CRC16 and EOP signals).
Figure4.9 Simulation snapshot when receiving set address request This is same with that of figure4.3 for device descriptor except the bytes of the request here are (0, 5, 2, 0, 0, 0, 0, 0) which also results in CRC bytes of 213 and 22. Hence the explanation for figure4.3 can be referred here. Step3: The trnsct module returns an acknowledgement PID with sync and EOP for receiving the above set address request (similar to figure figure4.4) Status stage Step1: IN token with addressed zero and endpoint zero was given as input (similar to figure4.5) Step2: Acknowledge is followed to the above IN token (similar to figure4.7) so that it will completes the status stage for the transfer
Step3: The cntrl module changes the address of the device from the default zero to two which was sent as the lsb Wvalue in the set address request of figure4.9 as follow.
Figure4.10 FPGA address changed from the default value (zero) to the assigned value (two) Case3: Configuration Descriptor Setup stage Step 1: With the newly assigned device address and control endpoint, setup token was given.
Figure4.11 Simulation snapshot when receiving setup token with address =2 and end_pt=0 Like figure4.2, the above figure shown the receiving of the setup token but the difference is, this token uses the newly assigned address (in this case, two) in the address field of the token hence 45, 2,168 are the three bytes of the new setup
token, 45 being the PID and 2 and 168 (00000010B and 10101000B) are the address field (0000010B), the endpoint field (0000B) and the CRC5 field (10101B). Step2: Eight byte configuration description request was followed with appropriate headers and trailers.
Figure4.12 Simulation snapshot when receiving configuration descriptor request It is similar to figure4.3 for the device descriptor with the only exception of the fourth byte of the request being 2 in stead of 1 and the CRC values. So the explanation at that section serves here too. Step3: A positive acknowledgement was sent back to the host by the trnsct module similar to figure4.4 Data Stage Step1: With the newly assigned device address and control endpoint, IN token was given (like figure4.5 but with addr=2 and end_pt=0) Step2: The 62 byte configuration descriptor that tells every information about the FPGA to the host was sent out from the ROM memory and transmitted by prefixing sync and data PID byte and suffixing CRC16 and EOP.
Figure4.13 Simulation snapshot when transmitting configuration descriptor The configuration descriptor as stated in table2.6, it contains functional, interface, and endpoint descriptors and the explanation of the above figure is similar with that of figure4.6. Step3: The host replies with the acknowledgment packet (similar to figure 4.7) Status stage Step1: the host will transfer out token (with address=2 and end_pt=0) followed by zero data packet (data PID).
Fig 4.14 out token with address=2 and end_pt=0 The only difference with figure4.8 is the address field here is 2(0000010B) Step2: the host returns ACK to complete the configuration descriptor related transactions and transfers similar to figure4.7. Result: And this shows the basic enumeration process completed, the host knows about the capability and behavior of the FPGA and the FPGA is given a USB device address and user application data can be started to exchange. Phase2: Application communication Case1: Data transfer from host to device. Step1: An OUT token with device address two and data end point (one) was given as stimuli.
Figure4.15 Simulation snapshot when receiving OUT token with address=2 and end_pt=1 At t1 of figure4.15 the sync byte is detected (line3, 4, 18) and at t2 the PID for OUT token (225) is received as can be seen in line 8. 130 and 24 are the address and endpoint and CRC fields (10000010B and 00011000B) this is because the last seven bit of 130 are (0000010B) and the first bit (1) is the least significant bit of the end point, the last three bit of the 24 (00011000B) are the most significant bits of the endpoint address (000) the remaining five most bits are the CRC (00011B). Hence the end point is (0001B) which signifies it is bulk transfer and data is to be sent to the device. As explained in the previous figures, the token_crc_bfr_sig initially (11111) should be updated each non PID byte received and must be (01100B)if the CRC is to pass as shown in line 12 and this is confirmed by the assertion of pkt_rx_cmpl (line 7) at t6. T4 to t5 of line 3 and 4 shows the receiving of EOP signals and line 17 through 22 shows the changes to the FSM of the different components through the whole time interval. Step2: Some data bytes followed by the ASCII value of the return key was given as stimuli.
Figure4.16 Simulation snapshot when receiving user data input At t1, sync is detected, at t2 data PID (195) is received and then some sample data bytes (3, 4, 5, 6, 7, 8, 9 followed by 13(enter)) are received in the time interval from t3 to t4 with two byte CRC (117 and 87 as shown in line 9). The address of the device (line 15) is the assigned address by the host in the set address stage and the end point is (line 16) data endpoint (0001B) and the transaction type is OUT (line 10). Rx_actv (line3) remains high from the time of detection of sync (t1) to the time of detection of EOP (t7) where as rx_vld (line 7) is asserted at each byte boundaries for one clock cycle. Line 18 through 22 shows the events of the state machines (detailed at chapter three). Step3: The FPGA replies with acknowledgement handshake similar to figure 4.4. Result: The USB_FPGA module puts the data byte into receiving buffer and the application starts to fetch and put it in its RAM and when it detects the enter key , the application sends back the received data in its memory in reversed order and the fpga_usb module puts this data in its transmit buffer.
Case2: Data transfer from device to host Step1: Then an IN token with device address 2 and end point 1 was fed to the simulation.
Figure4.17 Simulation snapshot when receiving IN token with address=2 and end_pt=1 Similar to figure 4.15, the difference is the token PID here is IN (105) in stead of OUT (225). Step2: The FPGA transmits the data in its transmit buffer (the reverse order of the bytes which was inputted in figure4.16) with the essential USB header and trailer fields.
Figure4.18 Simulation snapshot when transmitting from transmit buffer According to the above figure, bytes will be transmitted from the transmit buffer to the host. After sync is transmitted at t0, data PID follows at t1 then the already filled transmit buffer by the fpga application will start to be fetched byte by byte. Hence bytes (9, 8, 7, 6, 5, 4, 3, 13(enter), 10(new line feed)) followed by CRC (91, 152) will be transmitted as can be seen in lines 6,7,13 and 14. Tx_vld (line4) will be high starting t0 to t5 (where last byte will be loaded to trnsmtr module) while transmitting (line3) will be high thought the transmission (t6 where EOP is already sent). Tx_rdy (line 5) will be asserted each time new byte is needed. Data_crc_bfr_sig (line10) keep calculating the CRC values each time new non PID byte is transmitted and finally attach and transmitted the last value (line14). As explained in detail at chapter three, line 15 to 20 shows the state changes of the USB components. Step3: Final acknowledgement is given to the device by the host for successful receiving of the data (similar to figure4.7) Phase3: Abnormal Conditions Case1: When setup token with wrong CRC5 is received
Figure4.19 setup token with mismatched CRC value In figure4.19 at the interval between t4 and t5, line 8 is not showing the right CRC5 residue which is 45. This means the calculated CRC and the attached filed do not match resulting all the state machines to go to their idle and waiting states (line 15 to 20). That is why pkt_rx_cmpl (line12) will never be asserted and transct component dont assert the transaction types (line10 and 11). So if data (request or user) comes after this token, the device receives it but does not process it and acknowledge it as well. Hence the host is supposed to retransmit the data starting from the token packet. Case2: when a token with Unknown PID or erroneous PID is received by the device
Figure4.20 a token packet with Unknown PID type As can be seen in figure4.20 above, after sync is detected at t1 (line 3 and 4) the next byte is the PID (line 7 between t2 and t3) and the packet type should be recognized from it by the pkt module. But the PID here is 29 (00011101B) which the last four bits are not the negation of the first four bits. Thus the CRC buffer signals (line 8 and 9) dont vary although the rcvr module keeps receiving till the detection of EOP (line3 and 4) as a result the trnsct module also cant decide the transaction type (line 10, 11, and 18). So the transfer will fail, until the host retransmits the whole data with the right PID when it does not receive the acknowledgement packet. Case3: When unsupported request is sent by the host (like in figure4.3 but with brequest value of 00000010B), the device will reply with stall packet like in the following figure.
Figure4.21 stall handshake packet is returned for unsupported requests The above snapshot shows when the stall PID is transmitted from the device to the host. This is done when the device got setup request like in figure4.3, 4.6 or 4.9 but with supported request types. In the line 8 between t1 and t2, 30 (00011110B) is a stall handshake packet. And the rest of the lines and time intervals are similar with the previous diagrams explanations. Case4: Wrong sync pattern
Figure4.22 wrong sync pattern
In the interval of t0 to t1 (line 3 and 4) of figure4.22, bits are being received but sync is not detected so far therefore state machine (line 7 to 13) will no change. But at t2, it is detected so rx_actv will be asserted (line6) and rvcr module (line8) will go to strip_sync_state and starts receiving valid byte and asserts rx_vld (line5 at t3).
4.3 FPGA Test Procedures and Results

The B-connector (the connector to the device side) of standard USB cable was cut off and the four wires was plugged in to the pins of the A2 expansion connector of the FPGA while the A-connector is plugged in to the computer. The red wire which is for +5V dc power was plugged to pin2 and the black ground wire (pin1) is plugged to the ground pin of the A2 expansion connector. This enabled the FPGA to be powered directly from the USB port without using the AC power adapter. The green wire of the cable which is dedicated for data+ is connected to pin6 while the white wire for data- is connected to the pin7 of the expansion connector as it was given in the user constraint file. And a 1.5 Kohm pull-up resistor is connected from the data+ to a 3.3V voltage output which is the pin3 of the expansion connector according to the USB specification for full speed transceivers. Then the USB VHDL code was synthesized, translated, mapped, placed and routed to generate the bitstream file which was downloaded using Jtag cable and the FPGA was programmed. The result was detection of a malfunctioning USB device by the host computer because the enumeration failed. To diagnose the problem, there were not the necessary hardware logic analyzer tools in the labs or elsewhere nor are digital oscilloscopes that can be programmed to capture and store high frequencies of voltage transitions with in micro and nano seconds for latter display. Some soft wares from the internet, that were supposed to analyze USB traffic, were used but most of them work if the enumeration is successful by communicating with driver soft wares. So they were not a great help for the problem. Lots of trials were made to figure out at which point things went wrong by changing parameters which were guessed to be a potential problem sources as follow. Measured the output voltage of the pin3 that drives the pull-up resistor and it was 3.3V as expected. Changed USB cable, computer and operating systems (used Linux), no difference result was found. Changed the FPGA from Xilinx XC3S200 supplied by the advisor to Xilinx XC3S1000 which was bought personally.
Doing lots of changing around clocking. Some mentioned as follow: o Generate the 48MHz clock for the USB protocol and 12MHz clock for receiving and transmitting bits using Xilinxs DCM (digital clock managers). o Generate the 12Mhz clock from the 48MHz clock using logics o Tried to adjust clock delay, clock phase shift, clock jitters, clock skews and clock periods. o Avoid using DCM and getting the 48 MHz clock from the direct FPGAs 50MHz oscillator by specifying a period for 48MHz in the time constraint.
Re writing some codes in different forms like from process (sequential) to concurrent assignments. Inserting a debug vector signals in to each components of the protocol then associating it with the seven LEDs of the FPGA at different steps. Some lights up and some changes too fast to detect by normal human vision. Changing lots of parameters in the code like descriptor values reset and initialize timers and so on. Every time single change is made it needs to do every step from checking syntax to programming the FPGA and testing which takes long time.
Some of the above changes result in no detection of the USB where as some results the following message to be displayed by the host.
Some FPGA development forums were consulted and what was recommended by most of them is to use one of the hardware USB analyzer logics like CATC tools which could not be found easily.
Chapter Five CONCLUSION AND FUTURE WORKS

5.1 CHALLENGES
Doing this thesis was not smooth as initially expected. The user friendly USB system is so vast and difficult for developers to understand. It covers lots of parts and layers in addition the vagueness of the USB specification documents in which it needs another clarification in related references. To switch from software programming languages like java and C++ to hardware language like VHDL suddenly is very effort paying and some times despairing, to understand the behavior of VHDL language took long time, it needs a lot of thinking always with time reference in mind, getting unexpected results in the simulation for theoretically right code was very common although thanks to its flexibility there is always other ways to do the same thing. Removing and adding bit stuffing and synchronizing the result with the whole system was great overhead though finally handled. And finally the biggest challenge was to make the FPGA work as expected in the code when it is plugged to the computer. Although the FPGA can draw power from the computer using the USB power wire and make some communication but full data transfer could not succeed due to the absence of hardware troubleshooting tools, hence further progress was impossible.
5.2 SUMMARY AND CONCLUSION

The individual modules of the UTMI and USB protocol have been designed, written and verified functionally using VHDL simulator. The simulation has been successfully carried out. The UTMI transmitter and receiver are capable of converting parallel data into serial and serial into parallel, performing bit stuffing and destuffing, NRZI encoding and decoding, detecting and generating of sync pattern and EOP, bit transmitting and receiving. The SIE packet and transaction components are able to verify CRC checks for data and tokens packets, generate and send hand shake packets, calculate and attach CRC fields to out going data, identifies transaction types. The control module is able to parse host requests and reply with appropriate action like sending device and configuration descriptors, setting device address, replying with configuration status and as well as with stall handshake packet for unsupported features. The fpga_usb module implements 512byte memory and stores the descriptor and buffers temporary received and to be transmitted data until the application takes it. Simple VHDL application is developed for testing purpose which receives data bytes from hyper terminal software and returns in reverse order. The design has been synthesized using FPGA technology from Xilinx. This design is tested in two FPGA devices, XC3S200 device with package ft256 and XC3S1000 device with package ftg256, both spartan3 family and speed grade 4. It uses existing driver and client software hence neither special driver nor application client was needed to be developed in the host side. The code was downloaded and programmed to the above device and tested using windows XP; however the enumeration step can not be successfully executed by the host for unknown reasons although the FPGA was detected as malfunctioned USB device and it manages to get power from the USB system. Due to the lack of appropriate digital USB logic analyzers and traffic capturer hardware tools, the implementation result was not as expected.
5.3 RECOMMENDATION FOR FUTURE WORKS

If the necessary troubleshooting tools are found, amending this code to be used as intended is the primary recommendation of this work and additionally as follow. The USB is developed for only full speed mode with 8 bit UTMI; it can be further extended to support high speed mode and 16 bit UTMI data interface. And every standard USB requests, where some of them are stalled in this implementation, can be handled. Some additional work can also be done to make it support both high speed and full speed. And the different USB test mode features and flow control mechanisms are not supported here hence they can be incorporated in future works. Currently the FPGA gets power when the power pin of the USB cables are plugged in the ground and 5V pins of the FPGA. However the remote wakeup mode and the USB power Suspend and resume features for saving power when the FPGA is idle are not implemented. So in future it can be included with little effort.
5.4 RESEARCH APPLICATION AND CONTRIBUTIONS

Although the target application of this work is intended to control the FPGA using USB interface, with appropriate modification of the descriptors and data end points and by developing application software on the host side, it can also used be for any of the USB devices in market like mouse, printer, key board, scanner, flash memories, joystick, video cameras, mobiles, speakers and other vast USB systems.
Bibliography
1. USB-IF, Universal Serial Bus Specification, revision 2.0 , April 2000 2. Intel, USB 2.0 Transceiver Macrocell Interface (UTMI) Specification, Version 1.05, Intel Corporation, November 2001. 3. USB-IF, Universal Serial Bus Class Definitions for Communication Devices. 4. Jan Axelson, USB Complete: Everything You Need to Develop USB Peripherals, Third Edition, Lakeview Research LLC, Madison WI 53704, 2005. 5. Don Anderson, USB System Architecture, MINDSHARE, INC., ADDISON-WESLEY DEVELOPERS PRESS, 2001. 6. John Hyde, USB design by example: a practical guide to building IO devices, Intel university press. 7. Steve Kilts, Advanced FPGA Design: Architecture, Implementation, and Optimization, Spectrum Design Solutions, Minneapolis, Minnesota, John Wiley & Sons, Inc, 2007. 8. Volnei A. Pedroni, Circuit Design with VHDL, MIT Press Cambridge, Massachusetts London, England, 2004 9. PONG P. CHU, RTL HARDWARE DESIGN USING VHDL Coding for Efficiency, Portability, and Scalability, Cleveland State University, A JOHN WlLEY & SONS, INC., PUBLICATION, 2006. 10. Douglas L. Perry, VHDL Programming by Example, Fourth Edition, McGraw-Hill press, 2002. 11. Karen Parnell & Nick Mehta, Programmable Logic Design Quick Start Hand Book, Second edition, Xilinx, January 2002. 12. IEEE, VHDL Interactive Tutorial, 2002. 13. Bryan Mealy, the low-carb VHDL Tutorial, 2004. 14. W. D. Bishop, VHDL tutorial, Department of Electrical and Computer Engineering University of Waterloo, 2006. 15. Xilinx, Spartan-3 FPGA Family: Complete Data Sheet, Xilinx, Inc. 16. Xilinx, ISE 8.1 i Quick Start Tutorial, Xilinx, Inc. 17. Xilinx, ISE In-Depth Tutorial, Xilinx, Inc. 18. Xilinx, Spartan-3 Starter Kit Board User Guide. 19. Xilinx, Spartan-3 Starter Kit Board User Guide, Xilinx, Inc. 20. Xilinx, Using Digital Clock Managers (DCMs) in Spartan-3 FPGAs, Xilinx, Inc 21. Xilinx, Using Block RAM in Spartan-3 Generation FPGAs, Xilinx, Inc. 22. Xilinx, Spartan-3 FPGA Family Data Sheet, Product Specification, DS099 December 4, 2009, Xilinx, Inc. 23. Xilinx, XST User Guide vS.Ii, Xilinx, Inc.
24. W. Wolf, FPGA-Based System Design, Prentice Hall, 2004. 25. IEEE, IEEE Standard VHDL Language Reference Manual (IEEE STD 1076-2001), Institute of Electrical and Electronics Engineers, 2001. 26. Blake Henry, Designing an FPGA to USB Interface, Bitwise Systems, Embedded Systems Conference e Silicon Valley 2007, April 2007. 27. Universal Serial Bus Specification Revision 1.1 Sep 1998 (Compac, Intel, Microsoft, NEC). 28. Pavel Kubalk, Ji Buek, FPGA IMPLEMENTATION OF USB 1.1 DEVICE CORE, CTU Prague, Faculty of Electrical Engineering Department of Computer Science and Engineering. 29. David Fritz, Spartan 3 FPGA Tutorial, Digital Logic Design, Oklahoma State University, Revision A, June 2005. 30. ThesyconR System software & Consulting GmbH, USB CDC/ACM Class Driver For Windows 2000, XP and Vista , Reference Manual, Version 1.82 May 20, 2009. 31. Atmel, Migrating from RS-232 to USB Bridge Specification, Application Note, revision 1.1, 22 Dec 2003. 32. Linux Kernel Documentation : USB gadget_serial.txt, updated 8-May-2008 for v2.3 33. Haiqian Yu Memory , Architecture for Data Intensive Image Processing Algorithms in reconfigurable Hardware, North Eastern University, Graduate School of Engineering, August 2003. 34. USB_IF, Universal Serial Bus Class Definitions for Communications Devices, Revision 1.2, November 16, 2007. 35. Joris van Rantwijk, USB 1.1 serial data transfer core, April 2007. 36. Xilinx, Spartan-3 Starter Kit Board User Guide, Xilinx, Inc. 37. Mary Shaw, Writing Good Software Engineering Research Papers, Carnegie Mellon University, 2003. 38. Henrik Lfgren, Design of an FPGA-based HD-Video measurement system, Department of Electrical Engineering, Institutionen fr systemteknik, 2008 39. K. Babulu and K. Soundara Rajan, FPGA implementation of UTMI with USB 2.0 specifications, Sai Spurthi Institue of technology, 2008. 40. Ando Ki, FPGA-Based Simulation for Rapid Prototyping, Dynalith Systems, march 2007.
Frequently accessed websites: (between May 2009 to January 2010) 1. www.usb.org 2. www.opencore.org 3. www.fpga4fun.com 4. www.Xilinx.com 5. www.digitalcoredesign.org 6. www.deeps.org 7. www.techtutorials.info 8. www.usbmadesimple.co.uk 9. www.beyondlogic.org 10. www.fpgaz.com 11. http://www.sourceforge.net/projects/usbp/ 12. www.jungo.com/ 13. www.derepas.com 14. http://esd.cs.ucr.edu

Haftu Hailezgy

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Haftu Hailezgy

Hochgeladen von

Copyright:

Verfügbare Formate

Addis Ababa University School of Graduate Studies Faculty of Technology

Department of Electrical and Computer Engineering

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

46 46 47 47 52 55 60 65 71 76 79 79 79 101 103 103 104 105 105 106 108 A1

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

Terms and Abbreviations

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

CHAPTER ONE INTRODUCTION

USB Interface protocol implementation on FPGA

1.2 OVERVIEW OF FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

1.7 THESIS OUTLINE

USB Interface protocol implementation on FPGA

CHAPTER TWO BACKGROUND

Figure2.1. Block diagram of USB controller

USB Interface protocol implementation on FPGA

2.1.1 USB SPECIFICATION [1, 4, 5]

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

Figure2.6 EOP signaling

USB Interface protocol implementation on FPGA

Figure2.8 Enumeration Process

USB Interface protocol implementation on FPGA

Each phase contains either token or data or handshake packets.

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

set_cnf_rqst get_intrfc_rqst set_intrfc_rqst

00001001 00001010 00001011

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

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

USB Interface protocol implementation on FPGA

00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000

Table2.2 Descriptor types and values i. Device descriptor

USB Interface protocol implementation on FPGA

Figure2.14 OUT transaction IN (to the host)

USB Interface protocol implementation on FPGA

2.1.2 UTMI SPECIFICATION [2]

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

Figure2.18 Full speed device with pull up resistor connected to D+

2.1.3 CDC-ACM SPECIFICATION

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA

USB Interface protocol implementation on FPGA