The designer has to transmit large
volumes of data between his FPGA application and the PC. The USB interface is
one of the solutions to this problem. The USB interface conforms to the
requirements of simplicity and universal usage, which comes from its widespread
presence in current PCs. In order to use the USB, one has to add a USB core and
a USB transceiver to the application board.
USB cores are being implemented with
every emerging processor. The USB IP core that interfaces the Microblaze
processor is also available. However they are commercial IP’s and are not for
free.
Alternatives to USB core
The USB IP core is the controller that
is required if, for example, you wish to use your USB mouse or USB memory
stick. Our controller is the device that acts as a bridge between the
Microblaze processor and other USB devices. If it is not present then there is
no way that you can utilize USB devices. To be able to interface your processor
with a USB device, three options are available:
1. Buy a standard chip or product
2. Buy a commercial core
3. Design the USB core
Buy a standard chip or product
In this solution, an extra chip will
be added to the design. This third party chip will have a microcontroller and
other logic that will act as a mediator between the processor and the USB
devices.
Since we are trying to add a USB core
to the Microblaze soft CPU on the FPGA, using this design option would be
unwise since we would end up using another chip leaving us with a bulky and
costly design.
Buy a commercial core
Another solution would be to purchase
a ready made USB core that will be mapped and downloaded into the FPGA. What we
are actually purchasing is the VHDL code that describes the USB IP. This
solution is fast and not risky since the purchased USB core ensures high
performance according to USB standards. This solution is usually pursued by
design companies that require a USB interface with the processor. However,
purchasing the IP core ourselves would do us no good since we wish to design a
noncommercial IP core, one that will be used freely in AUB labs.
Design the USB core
In this solution, the USB core is
designed in VHDL and implemented in the FPGA. This solution is the most tedious
of all. It requires a lot of work since familiarity with the exhaustive details
of the USB protocol is needed.
USB CORE:
The USB core will be written with respect to
simple portability to other developed devices. Special attention will be
devoted to the minimum resources needed to transfer large amount of
data from and to the PC. The second
important point is the maximum transfer rate achieved by the USB core.
The first two parts are the receiver and the
transmitter implementing the low level of the USB communication protocol. Next
part deals with the control of the middle level of communication protocol such
as handshaking. The final part is the microcontroller interface used for the
communication with the external microcontroller.
Receiver
The receiver processes the data coming
from the external USB physical layer transceiver and stores it at various
places depending on the type of the packet received.
The top level of the receiver consists
of two parts. The first part processes the input data stream and analyzes its
structure. The second part is the receiver controller, which uses the
information about the structure to deliver the data to the corresponding
storage area. The data received at the primary inputs has the form of a serial
signal that is asynchronous to the system clock. Therefore the first block to
which the data is routed performs synchronization to the system clock. The
synchronization is done using a digital PLL state machine. The data is decoded
from the NRZI form in the process of
synchronization.
In the next step the stuffed bits in
the data stream are detected and marked for removal. The start and the end of
the packet are detected and signaled for further processing. The serial data is
then converted to parallel. The parallel data is examined in order to determine
the packet type.
The packet types recognized at this
level are: the token, the data and the handshake. The type of the packet is
determined using the PID field, which is the first byte after the
synchronization sequence.
The data and token packets are secured
against transmission errors by a 16-bit and 5-bit CRC, respectively. If the
packet is a token, the received bytes are stored in a temporary register. After
the CRC is confirmed to be valid, the packet is transferred to the token
register and its information can be used during the current transaction. If the
packet type is data, we check whether there is free space in the buffer of the
destination endpoint and whether this data packet is a valid part of a running
transaction. If these conditions are fulfilled, the data is written into the
corresponding endpoint buffer. Otherwise the data is received but discarded.
The data is checked for possible errors using
the 16-bit CRC.
Transmitter
The transmitter is used for packet
sending. The transmitter is divided into four blocks. The first block, the
nearest to the main control implements the control endpoint
buffers and sends its contents to the
parallel/serial block. The data stored at each buffer is sent after the send
command is received. The commands are received from the main
control.
The write operations to the buffers
are performed by the microcontroller interface. Data is sent to the
parallel/serial
block by bytes. The first and the last
byte marked in order to detect start and end of packet. The parallel/serial
block is used for making serial data from received bytes. The generated
serial data is sent to the CRC16
block. The CRC16 block generates a 16-bit control checksum. This block is
unused when a handshake packet is sent. The last block included in
the transmitter is the NRZI coder,
which performs the bit stuffing and NRZI coding. This block controls the
external USB transceiver. Coded and stuffed data is sent outside of the
FPGA. The transmitter is designed with
respect to the maximum time allowed for generating the first bit of the
response to the received command.
Transmitter buffers
The minimum length of the packet to
reach the maximum transfer rate is 64-bytes. If the USB driver is not written
effectively then the max packet length is very important. It is due to the
number of packets transmitted in 1 ms. For example, if the length of packet is
1023 we transferred 9 packets. That means 9288 bytes per 1 ms. By using 64-byte
packets we can transfer 150 packets, i.e. 9600 bytes. In other words using
64-byte packets is faster than 1023-byte packets. Because of the short time
interval between two consecutively transferred packets the double-buffering
technique must be used. It means while the first buffer is being filled the
second buffer is waiting to be sent. The 64-byte buffers are implemented as a
distributed RAM.
Main controller
The main controller manages the middle
level of the USB protocol, such as handshaking. The communication on this level
is based on transactions consisting of token, data and acknowledges parts. Some
of the transactions do not include the data part. Each small part of the
transaction is received as a separate packet. The error checking of the packet
is performed in the receiver and the information signal is sent to the main
controller. The receiver block takes care of the CRC checking and the
corresponding response is prepared in the main controller block. The response
must be generated immediately after the packet is received to achieve the
maximum allowed time given by the USB specification. The main controller
consists of a state machine. The actual state depends on the type of the token
and on the position in each transaction. Each endpoint has a few parameters
such as the transfer type or the status register that defines its current
state. These parameters are stored in structures. When data has been sent or
received the interrupt signal is generated and the type of this interrupt is
placed into the status register. The status register can be read
by the external microcontroller.
Microcontroller interface
The microcontroller interface block
takes care of the communication between the USB core and the microcontroller.
The register field used for filling or reading buffers and setting basic
parameters of transfer is implemented in this block. By using the select
endpoint command, the actual endpoint for read or write operations can be
selected. Because of the external microcontroller, input registers must be used
to prevent metastable states. Input buffers add other delays.
USB physical layer
The USB core needs only one external
circuit implementing the physical layer. The external circuit used is the
PDIUSBP11A. The USB core is independent on type of used the USB transceiver and
can be replaced by another one. The USB core will be tested only for full speed
baud rate because of simplicity the USB core. The USB transceiver is
permanently receiving serial data and sending them to the USB receiver block.
It means that every packet is received, even the packet sent by the USB
transmitter. Unexpected packets in the USB receiver are ignored and information
about received packet is not generated. In other words idle packets are
dropped.
External microcontroller
In order to make testing of the USB
core simpler, an external microcontroller can be used. It enables an easy way
of making changes at the higher level of the USB protocol like setting the
length of the sent packet. The program
can be written in the C language. Before data can be transmitted, initial
communication (i.e. enumeration) has to be performed and transmission
parameters must be set. For keeping information about transfer parameters it is
necessary to use a table for each endpoint and pipe. Implementing tables in the
microcontroller is simple. The solution with microcontroller is better than a
hardware state machine because of the complexity of the protocol layer. It
means the microcontroller is a suitable solution because of its simple
enhancement and adequate parameters. A simple microcontroller core could be
used for initial communication and a simple state machine for the data
transmission. Due to the fact that the microcontroller is external to the FPGA,
the read and write operations were slowed down. In order to test the maximum
throughput of the core, we have to skip filling the buffer. Instead we will
send a large amount of identical packets only by repeatedly validating the
transmit buffer. This is enabled by the fact that the transmit buffer is not
cleared after sending.
USB driver for PC
The USB core will be tested under MS
Windows. It is necessary to use a driver to transfer data. The driver must be
written as a WDM driver. It ensures the usability under Windows 98/2000/XP. The
driver can be adopted from the Bulk USB driver in the Microsoft Driver
Development Kit. The driver must be modified to improve transfer rate. Namely
the length of buffers must be increased and round on multiple length of the
packet. After the test passed the best
length of driver buffer can be determined.
USB CONNECTOR
It is simply a physical port we will
be using to connect our FPGA to PC or a hub. We can use any of the available
connectors.
FPGA
using
Actel’s A3P060 as it is a flash FPGA.
It
does not require an external boot PROM.
Cost
is very less.
Pins
are sufficient for our project.
USB Transceiver:
The PDIUSBP11A is a one chip generic USB
transceiver. It is designed to allow 5.0V or 3.3V programmable and standard
logic to interface with the physical layer of the Universal Serial Bus. It is
capable of transmitting and receiving serial data at both full speed (12Mbit/s)
and low speed (1.5Mbit/s) data rates.
JTAG:
JTAG cable is a simple cable that connects one
control device (usually computer) with JTAG port on the target board or device.
JTAG cables usually have some interface or at least buffer to amplify signals.
All JTAG cables have TDI, TDO, TCK, TMS and TRST signal. These are part of the
IEEE 1149 standard. However, there is no standard for cable headers. Each
family of devices might have different JTAG pinout.
0 comments:
Post a Comment