Upload
others
View
23
Download
0
Embed Size (px)
Citation preview
www.semargroups.org,
www.ijsetr.com
ISSN 2319-8885
Vol.02,Issue.10,
September-2013,
Pages:1031-1036
Copyright @ 2013 SEMAR GROUPS TECHNICAL SOCIETY. All rights reserved.
USB Receiver/Transmitter for FPGA Implementation LEVAKU JYOTHI
1
M.Tech, ECE Dept, Srinivasa Institute of Technology and
Science, Kadapa, AP-INDIA.
E-mail: [email protected].
G.VENKATA SURESH BABU2
Assoc Prof, ECE Dept, Srinivasa Institute of Technology and
Science, Kadapa, AP-INDIA.
E-mail: [email protected]
Abstract: The paper is a study of USB standard based on
authors own concept of specialized digital architecture
providing USB communication. Presented module
connects peripheral device with a computer via USB
cable. In accordance with functionality, the design was
partitioned to three units. UTMI block deals with USB
cable, time frame synchronization and serial transmission.
PIE block, divided to two parts, is responsible for packet
construction/extraction and byte oriented communication
with the peripheral system. Each module is controlled by
the dedicated Finite State Machine. The architecture was
implemented in VHDL, verified and synthesized. Design
complexity arises questions about feasibility of USB
interface application in specialized devices and low
volume segments of electronic devices, especially when
compared to traditional RS232/UART interfaces.
Keywords: USB, UTMI block, VHDL, RS232/UART
interfaces.
I. INTRODUCTION
Universal Serial Bus (USB) interface since its
introduction has gained huge interest and scale of
application. In spite of this popularity, details and
capabilities of protocol remain unknown to some digital
circuit’s designers. One of the reasons is surprisingly high
level of functional and structural complexity of USB
interface [1]. Analysis of some details especially when
compared with the other serial data transmission systems,
supported by observation of the market trends may lead to
creative ideas opening the new paths in contemporary
digital communication. This paper presents the authors
own concept of USB receiver/transmitter architecture.
The concept was implemented in hardware description
language to provide model for simulations.
Simultaneously the code is synthesizable, and may be
physically implemented in programmable logic devices.
At this stage the full functionality is not ready; however
significant part is available for embedding in any digital
system that requires high speed communication with
computer.
II. USB PROTOCOL OVERVIEW
USB protocol provides communication between
computer and peripheral device. Its construction is based
on 3 layers:
Functional, which covers high-level relations
between a computer program and a peripheral
device,
Logic, responsible for the flow of data stream,
Physical, including wires, connections, analog
devices.
Physical connection consists of 4 wires – 2 for power
and 2 for bi-directional differential data transmission. The
same set of wires may be shared by up to 127 peripheral
devices (USB2.0). The master functionality of host
includes control of the time division multiple access to
communication channel. Depending on character (speed)
of the peripheral device this time division may be based
on frames or micro-frames. For a single frame 1 ms is
allotted whilst for micro-frame it is 125 μs. The begin of
each frame is determined by the specific Start of Frame
packet sent by host. The rest of frame space may be used
for transmission of other packets, which may contain
control, symbols or payload. Each peripheral device is
recognized by its unique endpoint number (ENDP) and
this number is used to allocate a frame in a time scale.
Time division multiple access enables concurrent
communication of host with several devices. Whilst the
frames organize the time space for transmission, the data
is transmitted in packets [1,2]. General structure of USB
packet is presented in Fig. 1. The start and end of packet
are determined by the 8-bit SYNC and EOP patterns
respectively. PID is the 8-bit packet identifier. Depending
on transmission type, the PAYLOAD field may contain
various kinds of data and some more specific fields (e.g.
LEVAKU JYOTHI, G.VENKATA SURESH BABU
International Journal of Scientific Engineering and Technology Research
Volume. 02,IssueNo.10, September-2013, Pages:1031-1036
address, frame number). For packets containing data the
length of PAYLOAD field may reach 8192 bits. For
control packets it is shorter, e.g. 8 bit. CRC is the result of
cyclic redundancy check calculated for the payload field
only.
In the typical communication scenario the host -
computer, starts transmission by sending some data to the
peripheral device. In the very begin the transmission
parameters (e.g. speed, kind of packets to be transmitted)
are clarified and then the transmission may start.
Figure1. USB packet construction
There are 4 main types of transmission:
Control transmission, used for setting up the devices.
Ischronous transmission used for real time
transmission of data (to/from e.g. camera,
microphone, and speaker).
Interrupt transmission, used for very fast transmission
of small data structures (e.g. from a mouse).
Bulk transmission, asynchronous, designed for huge
amount of data, optimized for speed and protection of
data integrity (e.g. flash memory, hard disk).
III. ARCHITETURE
USB interface in the peripheral device consists of two
main blocks - the USB Transceiver Macrocell Interface
(UTMI) and the Parallel Interface Engine (PIE). UTMI
interacts with the cable and PIE with the digital system
embedded in the peripheral device. Consequently the
UTMI block deals with SYNC and EOP patterns, whilst
PIE constructs packets and deals with the PID field.
Communication between the 2 modules is provided by 3
groups of signals. In the first group there are data in and
data out – separate signals for data transmission in both
directions. The second group – TX valid and TX ready
controls the transmission in the direction from peripheral
device to the computer, i.e. from PIE to UTMI. The third
group consists of 3 signals – RX active, RX valid and RX
error, which control the process of data transmission from
the computer to the peripheral device, i.e. from UTMI to
PIE.
A. UTMI block
General schematic of UTMI block is presented in Fig. 2.
According to the functionality it is divided to parts
responsible for transmitting and receiving the data.
Separate part provides two clocks - 60 and 480 MHz. On
the receiver side the incoming serial data (480 MHz) is
recovered from the nonreturn to zero inverted (NRZI)
shape and stored in the deserializer shift register. Then it
is sent to 8-bit data out bus. Finite State Machine controls
the process and drives all the RX signals communicating
with PIE block. The transmitter part collects the data
coming in parallel from PIE (8-bit data out bus, 60 MHz),
serializes the stream, codes it to NRZI shape and sends
serially to the cable, with the frequency of 480 MHz. This
Figure2. USB Transceiver Macrocell Interface (UTMI)
block.
functionality is controlled by another branch of the Finite
State Machine, dependent on the TX valid signal coming
from PIE. Simultaneously the FSM is responsible for
sending the TX ready signal to PIE. Additional function of
receiver and transmitter parts is recognition and
construction of the SYNC and EOP patterns respectively
[3,4]. Schematic of the UTMI FSM is presented in Fig. 3.
During typical receive operation the FSM transits from
SWAIT idle state to RSYNC when the SYNC pattern sent
by a computer is detected in a shift register. The next state
is RDATA_LOAD. In this state the stream of data is
continuously deserialized and sent to the 8-bit data in bus,
until the EOP signal is recognized. (The erroneous
detection of SYNC and EOP is avoided by bit
stuffing/unstuffing). After detection of EOP, the FSM
transits to REOP state where the receive operation is
finished. If there are no errors detected, the next state is
SWAIT. The other branch of FSM controls the transmit
process. PIE module may generate a request to transmit
data to a computer, by setting the TX valid signal to ‘1’. If
the UTMI is not busy e.g. receiving data from computer
or dealing with errors, i.e. the FSM is in the SWAIT state,
it may transit to the TSYNC_LOAD state. In this single
clock cycle state the SYNC pattern is loaded to the serial
output buffer. Then the FSM transits to the TSYNC state,
USB Receiver/Transmitter for FPGA Implementation
International Journal of Scientific Engineering and Technology Research
Volume. 02,IssueNo.10, September-2013, Pages:1031-1036
Where the SYNC pattern is transmitted serially to the
USB cable. In the next state - DATA_SENDING, the
regular transmission takes place. PIE block sends
consecutive bytes via the 8-bit data out bus with 60 MHz
frequency and UTMI serializes them for 480 MHz output.
When the PIE block decides to stop the transmission, it
switches the TX valid signal back to ‘0’. The FSM
transits to TEOP state where the EOP pattern is loaded to
the buffer and then shifted out. The next state is SWAIT
again. Switching the TX valid line to ‘0’ during the
transmission causes the FSM transit to the SERROR state.
Figure3. Finite State Machine controlling the USB
Transceiver Macro-cell Interface (UTMI) blocks.
B. PIE block
Parallel Interface Engine provides byte oriented
communication between UTMI and the peripheral device
functional blocks. On the receiver side it extracts and
deals with special parts of packet – Packet Identifier
(PID) and CRC coming from the cable, via UTMI. The
transmit functionality contains preparation of CRC-5 and
CRC-16 codes, General schematic of PIE block
interconnection is presented in Fig. 4. Its architecture was
divided to two parts – PACKET and TRANS, controlled
by two separate Finite State Machines. The key
functionality of PACKET module is extraction, analysis
and construction of packets, in particular PID and CRC
fields. Schematic of the appropriate FSM is presented in
Fig. 5. Receive and transmit functions are realized in two
different branches accessible from the common NONE
state. The receive sequence starts from the detection of
SYNC pattern in the UTMI, signaled by the high state of
RX active and RX valid lines. In the next state – RPID,
the packet identifier (PID) is recognized. PID determines
the content of the packet and consequently further
sequence of states. For packets containing data the next
state would be RPID_DATA, whilst for special packets
like token or “start of frame”, the next states are
RPID_TOKEN and RPID_SOF respectively. Regardless
of the branch taken, the low state of RX active line from
UTMI signals end of transmission. In the next state –
RCHECK, the CRC code which has been calculated on-
line is compared with the incoming one attached to the
end of packet. Depending on CRC result the next state is
either RFIN where the transmission is closed or the
SERROR where the alerts about invalid data are
generated.
The other branch of FSM controls data transmission
functionality, with alternative sequences depending on the
kind of packet to be sent (data or various kinds of control
again). Behavior of the TRANS Module strongly depends
on control packets received by UTMI block and
recognized by PACKET module. TRANS module
performs dialog with the computer, but on the higher level
of abstraction, consequently variety of its reactions is
more complicated. Depending on the requested action –
receive or transmit, the Finite State Machine, presented in
Fig. 6, transits form the IDLE state to SOUT or SIN states
respectively. SOUT starts the receive operation. The basic
sequence of states WAIT_4_PID_DATA, RPID_DATA,
RDATA, and RECEIVING_DATA leads to collection of
bulky data. Final stage of receive operation requires
handshake response sent to the computer in the form of
acknowledgment or not acknowledgement packets. This
action is performed in the two alternative branches with
WAIT2_ACK/TACK and WAIT2_TNAK/TNAK
sequences respectively. After sending the handshake the
Finite State Machine goes back to the IDLE state.
Alternative branch of the FSM controlling TRANS
module starts from the SIN state.
The next state is WAIT2T_PID_DATA, where the
TRANS module sets the TX valid signal to ‘1’ requesting
UTMI block to send the SYNC pattern to the USB cable.
If the UTMI is able to do it, it responds with a TX ready
signal (via the PACKET block) and the next state is
TPID_DATA. In this state the TRANS block sends the
packet identifier to 8-bit data out bus. Simultaneously it
sets the TX valid signal to inform the prospective
peripheral system that the transmission may start. In the
next TPID_DATA state the main transmission takes place
until the peripheral system resets the Ready line to ‘0’
(typically after sending all the data) and then the
PACKET module sets the TX fin signal to ‘1’ (after
transporting the last byte of packet to UTMI). The next
state is WAIT_4_ACK. All the blocks wait for
appropriate handshake packet, which must be sent by the
computer. If the appropriate PID is recognized the next
LEVAKU JYOTHI, G.VENKATA SURESH BABU
International Journal of Scientific Engineering and Technology Research
Volume. 02,IssueNo.10, September-2013, Pages:1031-1036
state is IDLE. If any other PID is received the next state is
SERROR. This state may be reached from most of the
states when further step of transmission is impossible, e.g.
because some device is busy. Depending on the reason,
the appropriate alerts may be sent to the peripheral or to
PACKET and UTMI blocks.
IV. IMPLEMENTATION
Presented architecture, was implemented in VHDL [5].
The code was partitioned to 3 main entities, containing
the 3 Finite State Machines as described in the previous
section. All the logic signals and operations refer to the
std_logic_1164 package from the IEEE library [6]. The
design is full synchronous with 2 clock domains.
Verification plan covered individual tests of all the blocks
and a few scenarios of data exchange engaging the whole
design. Eventually the code was successfully synthesized
using Xilinx ISE tools [7,8].
Figure4. Parallel Interface Engine (PIE) block structure and
connection Schematic.
Figure 5. Finite State Machine controlling PACKET module of Parallel Interface Engine block.
USB Receiver/Transmitter for FPGA Implementation
International Journal of Scientific Engineering and Technology Research
Volume. 02,IssueNo.10, September-2013, Pages:1031-1036
Figure6. Finite State Machine controlling TRANS module of Parallel Interface Engine block.
V. CONCLUSIONS
Selected details of construction and functionality of
USB protocol were presented. Introduction was followed
by author’s proposal of dedicated hardware containing the
most of data transmission mechanisms. The design was
partitioned to three modules forming a system of bi-
directional, sequential data flow. Each module,
responsible for specific stage of data processing is
controlled by its own Finite State Machine. The other
imaginable solutions are splitting the architecture in
accordance with direction of data transmission, to the two
parts – receive and transmit, controlled by e.g. two Finite
State Machines or implementation of all the functionality
in a single automaton. Selected approach brings some risk
of deadlock caused by cross-dependencies of the three
automata. Its key advantage however is preservation of
natural concurrency of operation of the three modules.
Functionality of USB interface quite often requires
simultaneous processing of various parts of transmitted
data. USB is nowadays probably the most commonly used
interface between computer and peripherals. There is
constantly growing number of low-cost devices, whose
great advantage shall be ease of use. Detailed analysis of
protocol mechanisms, accompanying presented project
led to the surprising conclusion that these mechanisms are
very complicated. Variety of sequential actions and
reactions that must be performed to provide the plug and
play operation of the target device requires substantial
effort devoted to both design and verification of the
prospective module. This level of complication is hard to
justify. And it forces digital design teams to buy and reuse
the appropriate Intellectual Property modules rather than
develop their own versions and integrate them with the
application specific architectures, e.g. on the Hardware
Description Language code level. This practice remains in
total opposition to the old RS232 serial interface, where
the design of UART modules used to be a popular task for
students and young engineers starting their careers in
digital electronic design. Another functional difference
between USB and RS232 is the need for software drivers
providing the computer operating system’s supervision
and communication with the USB equipped device.
Problems with drivers compatibility and installation are
LEVAKU JYOTHI, G.VENKATA SURESH BABU
International Journal of Scientific Engineering and Technology Research
Volume. 02,IssueNo.10, September-2013, Pages:1031-1036
well known for all users of niche products and made them
skeptical about the plug and play myth. These problems
are rarely observed for massive products where the
vendors are able to (technically speaking) buy the
compatibility with e.g. Microsoft Windows systems. The
third issue and limitation for individual constructions of
USB interfaces and their embedding in the designs
implemented in low-cost programmable logic devices is
relatively high clock frequency of the serial transmission.
480 MHz remains quite high and difficult to reach in the
low cost programmable circuits available nowadays (A.D.
2011/2012). Continuous development and growing speed
of FPGA circuits will eventually enable implementation
of architectures working with this speed. Before that time
however, the faster version of USB may become the new
standard. These three issues rise serious questions about
the sense of continuous growth of variety and volume of
USB based devices on the market. Seems like the reliable
(unlikely to crash), designer friendly and user friendly
RS232-UART solution was replaced by much faster USB
for the price of more frequent crashing, problems with
drivers, and loosing open character of design. This
replacement is extensively supported by personal
computer vendors, removing RS232 from main boards as
obsolete. The little and desperate exception from this
trend is “RS232 over USB” concept based on popular off-
the-shelf FT232 circuit which enables connection of
classic UART interface with RS232 dedicated computer
software via the USB socket. This approach is extensively
used by developers of specialized devices and in some
low-cost products. For the higher speeds however, at this
stage, there is no escape from purchasing USB cores
developed by small group of the design houses and then
either fabricated as separate chips or embedded in the
higher quality programmable logic devices.
VI. REFERENCES
[1] Universal Serial Bus Specification, rev. 2.0,
(www.usb.org), 2000.
[2] J. Axelson, USB Complete. Everything You Need to
Develop Custom USB Peripherals, Third Edition,
Lakeview Research LLC, 2005.
[3] USB 2.0 Transceiver Macrocell Interface (UTMI)
Specification, Version1.05, Intel Corporation, 2001.
[4] Jang Jin Nam, USB 2.0 PHY Design Compatible to
UTMI Specification, 2003.
[5] IEEE Standard, VHDL Language Reference Manual,
(IEEE Std 1076), 2000 Edition.
[6] IEEE Standard nr 1076, VHDL Language Reference
Manual.
[7] Xilinx ISE Web Pack, ver 12.3, www.xilinx.com,
2011.
[8] Xilinx Spartan-3 Family Complete Data Sheet,
(www.xilinx.com),
Xilinx Inc. 2007,
Authors Profile:
Levaku Jyothi ,M.Tech
Research Scholar, Srinivasa
Institute of Technology and
Science, Kadapa, AP-INDIA,
E-mail: [email protected]
G.VENKATA SURESH BABU,
M.Tech, Assoc Prof, Srinivasa
Institute of Technology and
Science, Kadapa, AP-INDIA,
Experience: 9Years
E-mail: [email protected].