USB Receiver/Transmitter for FPGA Implementation

Przemyslaw M. Szecwka, Kamil J. Pyrzynski*

Faculty of Microsystem Electronics and Photonics, Wroclaw University of Technology Wroclaw, Poland przemyslaw.szecowka@pwr.wroc.pl * ) now with Openreach, Manchester, UK
AbstractThe paper is a study of USB standard based on authors own concept of specialized digital architecture providing USB communication. Presented module connects peripheral device with a computer via USB cable. In accordance with functionality, the design was partitioned to three units. UTMI block deals with USB cable, time frame synchronization and serial transmission. PIE block, divided to two parts, is responsible for packet construction/extraction and byte oriented communication with the peripheral system. Each module is controlled by the dedicated Finite State Machine. The architecture was implemented in VHDL, verified and synthesized. Design complexity arises questions about feasibility of USB interface application in specialized devices and lowvolume segments of electronic devices, especially when compared to traditional RS232/UART interfaces.

physical, including wires, connections, analog devices. Physical connection consists of 4 wires 2 for power and 2 for bi-directional differential data transmission. The same set of wires may be shared by up to 127 peripheral devices (USB 2.0). The master functionality of host includes control of the time division multiple access to communication channel. Depending on character (speed) of the peripheral device this time division may be based on frames or micro-frames. For a single frame 1 ms is allotted whilst for micro-frame it is 125 s. The begin of each frame is determined by the specific Start of Frame packet sent by host. The rest of frame space may be used for transmission of other packets, which may contain control, symbols or payload. Each peripheral device is recognized by its unique endpoint number (ENDP) and this number is used to allocate a frame in a time scale. Time division multiple access enables concurrent communication of host with several devices. Whilst the frames organize the time space for transmission, the data is transmitted in packets [1,2]. General structure of USB packet is presented in Fig. 1. The start and end of packet are determined by the 8-bit SYNC and EOP patterns respectively. PID is the 8-bit packet identifier. Depending on transmission type, the PAYLOAD field may contain various kinds of data and some more specific fields (e.g. address, frame number). For packets containing data the length of PAYLOAD field may reach 8192 bits. For control packets it is shorter, e.g. 8 bit. CRC is the result of cyclic redundancy check calculated for the payload field only.
SYNC PID PAYLOAD CRC EOP

I. INTRODUCTION Universal Serial Bus (USB) interface since its introduction has gained huge interest and scale of application. In spite of this popularity, details and capabilities of protocol remain unknown to some digital circuits designers. One of the reasons is surprisingly high level of functional and structural complexity of USB interface [1]. Analysis of some details especially when compared with the other serial data transmission systems, supported by observation of the market trends may lead to creative ideas opening the new paths in contemporary digital communication. This paper presents the authors own concept of USB receiver/transmitter architecture. The concept was implemented in hardware description language to provide model for simulations. Simultaneously the code is synthesisable, and may be physically implemented in programmable logic devices. At this stage the full functionality is not ready, however significant part is available for embedding in any digital system that requires high speed communication with computer. II. USB PROTOCOL OVERVIEW USB protocol provides communication between computer and peripheral device. Its construction is based on 3 layers: functional, which covers high-level relations between a computer program and a peripheral device, logic, responsible for the flow of data stream,

Figure 1. USB packet construction

In the typical communication scenario the host - computer, starts transmission by sending some data to the peripheral device. In the very begin the transmission parameters (e.g. speed, kind of packets to be transmitted) are clarified and then the transmission may start. There are 4 main types of transmission: control transmission, used for setting up the devices, ischronous transmission, used for real time transmission of data (to/from e.g. camera, microphone, speaker), interrupt transmission, used for very fast transmission of small data structures (e.g. from a mouse),

 bulk transmission, asynchronous, designed for huge amount of data, optimized for speed and protection of data integrity (e.g. flash memory, hard disk). III. ARCHITETURE USB interface in the peripheral device consists of two main blocks - the USB Transceiver Macrocell Interface (UTMI) and the Parallel Interface Engine (PIE). UTMI interacts with the cable and PIE with the digital system embedded in the peripheral device. Consequently the UTMI block deals with SYNC and EOP patterns, whilst PIE constructs packets and deals with the PID field. Communication between the 2 modules is provided by 3 groups of signals. In the first group there are data in and data out separate signals for data transmission in both directions. The second group TX valid and TX ready controls the transmission in the direction from peripheral device to the computer, i.e. from PIE to UTMI. The third group consists of 3 signals RX active, RX valid and RX error, which control the process of data transmission from the computer to the peripheral device, i.e. from UTMI to PIE. A. UTMI block General schematic of UTMI block is presented in Fig. 2. According to the functionality it is divided to parts responsible

for transmitting and receiving the data. Separate part provides two clocks - 60 and 480 MHz. On the receiver side the incoming serial data (480 MHz) is recovered from the nonreturn to zero inverted (NRZI) shape and stored in the deserializer shift register. Then it is sent to 8-bit data out bus.
RECEIVER

decoder

FSM 1
TRANSMITTER

coder

FSM 2

OSC.

FREQUENCY MULTIPLIER

Figure 2. USB Transceiver Macrocell Interface (UTMI) block

RECEIVER TRANSMITTER

Figure 3. Finite State Machine controlling the USB Transceiver Macrocell Interface (UTMI) block

Finite State Machine controls the process and drives all the RX signals communicating with PIE block. The transmitter part collects the data coming in parallel from PIE (8-bit data out bus, 60 MHz), serializes the stream, codes it to NRZI shape and sends serially to the cable, with the frequency of 480 MHz. This functionality is controlled by another branch of the Finite State Machine, dependent on the TX valid signal coming from PIE. Simultaneously the FSM is responsible for sending the TX ready signal to PIE. Additional function of receiver and transmitter parts is recognition and construction of the SYNC and EOP patterns respectively [3,4]. Schematic of the UTMI FSM is presented in Fig. 3. During typical receive operation the FSM transits from SWAIT idle state to RSYNC when the SYNC pattern sent by a computer is detected in a shift register. The next state is RDATA_LOAD. In this state the stream of data is continuously deserialized and sent to the 8-bit data in bus, until the EOP signal is recognized. (The erroneous detection of SYNC and EOP is avoided by bit stuffing/unstuffing). After detection of EOP, the FSM transits to REOP state where the receive operation is finished. If there are no errors detected, the next state is SWAIT. The other branch of FSM controls the transmit process. PIE module may generate a request to transmit data to a computer, by setting the TX valid signal to 1. If the UTMI is not busy e.g. receiving data from computer or dealing with errors , i.e. the FSM is in the SWAIT state, it may transit to the TSYNC_LOAD state. In this single clock cycle state the SYNC pattern is loaded to the serial output buffer. Then the FSM transits to the TSYNC state, where the SYNC pattern is transmitted serially to the USB cable. In the next state DATA_SENDING, the regular transmission takes place. PIE block sends consecutive bytes via the 8-bit data out bus with 60 MHz frequency and UTMI serializes them for 480 MHz output. When the PIE block decides to stop the transmission, it switches the TX valid signal back to 0. The FSM transits to TEOP state where the EOP pattern is loaded to the buffer and then shifted out. The next state is SWAIT again. Switching the TX valid line to 0 during the transmission causes the FSM transit to the SERROR state. B. PIE block Parallel Interface Engine provides byte oriented communication between UTMI and the peripheral device functional blocks. On the receiver side it extracts and deals with special parts of packet Packet Identifier (PID) and CRC coming from the cable, via UTMI. The transmit functionality contains preparation of CRC-5 and CRC-16 codes, General schematic of PIE block interconnection is presented in Fig. 4. Its architecture was divided to two parts PACKET and TRANS, controlled by two separate Finite State Machines. The key functionality of PACKET module is extraction, analysis and construction of packets, in particular PID and CRC fields. Schematic of the appropriate FSM is presented in Fig. 5. Receive and transmit functions are realized in two different branches accessible form the common NONE state. The receive sequence starts from the detection of SYNC pattern in the UTMI, signaled by the high state of RX active and RX valid lines. In the next state RPID, the packet

identifier (PID) is recognized. PID determines the content of the packet and consequently further sequence of states. For packets containing data the next state would be RPID_DATA, whilst for special packets like token or start of frame, the next states are RPID_TOKEN and RPID_SOF respectively. Regardless of the branch taken, the low state of RX active line from UTMI signals end of transmission. In the next state RCHECK, the CRC code which has been calculated on-line is compared with the incoming one attached to the end of packet. Depending on CRC result the next state is either RFIN where the transmission is closed or the SERROR where the alerts about invalid data are generated. The other branch of FSM controls data transmission functionality, with alternative sequences depending on the kind of packet to be sent (data or various kinds of control again).

PACKET

TRANS

Figure 4. Parallel Interface Engine (PIE) block structure and connection schematic

Behavior of the TRANS module strongly depends on control packets received by UTMI block and recognized by PACKET module. TRANS module performs dialog with the computer, but on the higher level of abstraction, consequently variety of its reactions is more complicated. Depending on the requested action receive or transmit, the Finite State Machine, presented in Fig. 6, transits form the IDLE state to SOUT or SIN states respectively. SOUT starts the receive operation. The basic sequence of states WAIT_4_PID_DATA, RPID_DATA, RDATA, and RECEIVING_DATA leads to collection of bulky data. Final stage of receive operation requires handshake response sent to the computer in the form of acknowledgment or not acknowledgement packets. This action is performed in the two alternative branches with WAIT2_ACK/TACK and WAIT2_TNAK/TNAK sequences respectively. After sending the handshake the Finite State Machine goes back to the IDLE state. Alternative branch of the FSM controlling TRANS module starts from the SIN state. The next state is WAIT2T_PID_DATA, where the TRANS module sets the TX valid signal to 1 requesting UTMI block to send the SYNC pattern to the USB cable. If the UTMI is able to do it, it responds with a TX ready signal (via the PACKET block) and the next state is TPID_DATA. In this state the TRANS block sends the packet identifier to 8-bit data out bus. Simultaneously it sets the TX valid signal to inform the prospective peripheral system that the transmission may start. In the next TPID_DATA state the main transmission takes place until the peripheral system resets the Ready line to 0

(typically after sending all the data) and then the PACKET module sets the TX fin signal to 1 (after transporting the last byte of packet to UTMI). The next state is WAIT_4_ACK. All the blocks wait for appropriate handshake packet, which must

be sent by the computer. If the appropriate PID is recognized the next state is IDLE. If any other PID is received the next state is SERROR. This state may be reached from most of the states when further step of transmission is impossible,

RECEIVER TRANSMITTER

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

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

e.g. because some device is busy. Depending on the reason, the appropriate alerts may be sent to the peripheral or to PACKET and UTMI blocks. IV. IMPLEMENTATION Presented architecture, was implemented in VHDL [5]. The code was partitioned to 3 main entities, containing the 3 Finite

State Machines as described in the previous section. All the logic signals and operations refer to the std_logic_1164 package from the IEEE library [6]. The design is full synchronous with 2 clock domains. Verification plan covered individual tests of all the blocks and a few scenarios of data exchange engaging the whole design. Eventually the code was successfully synthesized using Xilinx ISE tools [7,8].

V. CONCLUSIONS Selected details of construction and functionality of USB protocol were presented. Introduction was followed by authors proposal of dedicated hardware containing the most of data transmission mechanisms. The design was partitioned to three modules forming a system of bi-directional, sequential data flow. Each module, responsible for specific stage of data processing is controlled by its own Finite State Machine. The other imaginable solutions are splitting the architecture in accordance with direction of data transmission, to the two parts receive and transmit, controlled by e.g. two Finite State Machines or implementation of all the functionality in a single automaton. Selected approach brings some risk of deadlock caused by cross-dependencies of the three automata. Its key advantage however is preservation of natural concurrency of operation of the three modules. Functionality of USB interface quite often requires simultaneous processing of various parts of transmitted data. USB is nowadays probably the most commonly used interface between computer and peripherals. There is constantly growing number of low-cost devices, whose great advantage shall be ease of use. Detailed analysis of protocol mechanisms, accompanying presented project led to the surprising conclusion that these mechanisms are very complicated. Variety of sequential actions and reactions that must be performed to provide the plug and play operation of the target device requires substantial effort devoted to both design and verification of the prospective module. This level of complication is hard to justify. And it forces digital design teams to buy and reuse the appropriate Intellectual Property modules rather than develop their own versions and integrate them with the application specific architectures, e.g. on the Hardware Description Language code level. This practice remains in total opposition to the old RS232 serial interface, where the design of UART modules used to be a popular task for students and young engineers starting their careers in digital electronic design. Another functional difference between USB and RS232 is the need for software drivers providing the computer operating systems supervision and communication with the USB equipped device. Problems with drivers compatibility and installation are well known for all users of niche products and made them skeptical about the plug and play myth. These problems are rarely observed for massive products where the vendors are able to (technically speaking) buy the compatibility with e.g. Microsoft Windows systems.

The third issue and limitation for individual constructions of USB interfaces and their embedding in the designs implemented in low-cost programmable logic devices is relatively high clock frequency of the serial transmission. 480 MHz remains quite high and difficult to reach in the lowcost programmable circuits available nowadays (A.D. 2011/2012). Continuous development and growing speed of FPGA circuits will eventually enable implementation of architectures working with this speed. Before that time however, the faster version of USB may become the new standard. These three issues rise serious questions about the sense of continuous growth of variety and volume of USB based devices on the market. Seems like the reliable (unlikely to crash), designer friendly and user friendly RS232-UART solution was replaced by much faster USB for the price of more frequent crashing, problems with drivers, and loosing open character of design. This replacement is extensively supported by personal computer vendors, removing RS232 from main boards as obsolete. The little and desperate exception from this trend is RS232 over USB concept based on popular off-the-shelf FT232 circuit which enables connection of classic UART interface with RS232 dedicated computer software via the USB socket. This approach is extensively used by developers of specialized devices and in some low-cost products. For the higher speeds however, at this stage, there is no escape from purchasing USB cores developed by small group of the design houses and then either fabricated as separate chips or embedded in the higher quality programmable logic devices. REFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] Universal Serial Bus Specification, rev. 2.0, (www.usb.org), 2000. J. Axelson, USB Complete. Everything You Need to Develop Custom USB Peripherals, Third Edition, Lakeview Research LLC, 2005. USB 2.0 Transceiver Macrocell Interface (UTMI) Specification, Version 1.05, Intel Corporation, 2001. Jang Jin Nam, USB 2.0 PHY Design Compatible to UTMI Specification, 2003. IEEE Standard, VHDL Language Reference Manual, (IEEE Std 1076), 2000 Edition. IEEE Standard nr 1076, VHDL Language Reference Manual. Xilinx ISE Web Pack, ver 12.3, www.xilinx.com, 2011. Xilinx Spartan-3 Family Complete Data Sheet, (www.xilinx.com), Xilinx Inc. 2007,