TRIBHUVAN UNIVERSITY
Institute of Engineering
Department of Electronics and Computer Engineering
"USB
Box"
By
Santosh Pradhan (059BEX436)
Sabin C. Shrestha (059BEX432)
Soyuz Upadhya (059BEX440)
Sushil Shrestha (059BEX445)
December 2006
i
Acknowledegments
It was surely a rollercoaster ride full of joyous moments and disappointments. The report
might have implied only five of us involved in this hardship. But the truth is it wouldn't
have been what it is if we had to do it all by ourselves.
It was the supervision of Associate Professor Dr. Subarna Shakya under whom we've
achieved so much that it couldn't be described in mere words. Valuable suggestions of our
project co-ordinator Associate Professor Rajendra Lal Rajbhandari, internal examiner
Mr. Bikram Dangol and external examiner Mr. Om Bikram Thapa proved to be highly
beneficiary. Under the guidance of Mr. Kamal Nepal, we were able to operate ProtoMat
92s and fabricate the PCB and thanks to Mr. Sanjeeb Prasad Pandey, willing to help us in
anyway, anyhow possible.
Not only the faculty members, our friends have also contributed their efforts. We'd like to
thank Saurav for the click we needed to get started. Jagadish for his part in realization of
state machines. Om for providing the character maps without which we would have had a
nightmarish task of generating characters. Nijjal, Prabin, Prajwal, Prashwish, Rajesh,
Sandip, Ujjwal, Vivid for always being with us thereby raising the comfort level. Piyush,
Manoj, Sudeep, Suraj and extremely talented Mohan for their morale boosting support
and Dr. Rekha Roka Magar for her technical assistance.
Many thanks to Cypress Semiconductors for providing us with free samples of host
controller chip. To our queries Mr. Dave Van den Bout from XESS Corp. promptly
responded with equal enthusiasm. Thank you very much Mr. Bout.
Finally we'd like to thank our families for their love, care, understanding and financial
assistance in time of dire need.
Thank you to all of you and God bless you all !
Project Members
ii
Abstract
“Big things come in small packages.” And why not if you’re talking about the pen drive.
A pen drive is a solid state storage device. Its capacity ranges from few megabytes to
gigabytes. It is a USB drive for which there are USB ports at the CPU so that you can
plug it into the computer. Storing and retrieving data from USB drives is as easy as
putting a cherry on a cake. So without any shadow of a doubt, the pen drives have
become a household name and are the most popular removable storage media.
Our project revolves round the USB drive. The objective is simple, yet profound. Our aim
is to design an interface through which the content of pen drives could be displayed
without having to plug it into the computer. Because of limited time and resources we had
to narrow down our project to text file only.
VHDL is the platform on which we are working for our dreams to change into reality.
The basic thing that should be done to achieve something like this is to use a memory on
which the content of the pen drive is written temporarily and then it is refreshed onto the
displaying unit. This may sound very simple but involves lots of tedious calculations and
colossal hard work. More is explained as we go further into this report.
Keywords: USB, Mass Storage Class, Bulk only Transport, USB Host Controller, FPGA,
State machines in VHDL, Character generation
iii
List of Figures
Fig 1.1-1 USB Mass-Storage Device
3
Fig 1.1-2 Connection via USB
3
Fig 1.1-3 USB Flash Drives
4
Fig 2.1-1 USB Receptacles
6
Fig 2.1-2 USB cable plugs from left to right: series-A, series B, mini-A, and mini-B. 6
Fig 2.1-3 Illustration of NRZI coding
9
Fig 2.1-4 Bit stuffing procedure
10
Fig 2.1-5 USB host, device and endpoints
12
Fig 2.1-6 Device State diagram
13
Fig 2.1-7 Hierarchy of Descriptors
20
Fig 2.2-1 Command/Status flow in Mass storage class complaint devices
24
Fig 2.4-1 SL811HS USB Host/Slave Controller Functional Block Diagram
27
Fig 2.5-1 XSA-50 Programmer's model
30
Fig 2.6-1 Structural Modeling using VHDL
33
Fig 3.1-1 Architecture of our project
35
Fig 3.2-1 State diagram for USB, Mass Storage and Host Controller Driver
36
Fig 3.2-2 Implementation of USB, Mass storage and Host controller driver
37
Fig 3.2-3 Overview of Character Generator
39
Fig 3.2-4 Memory Map
40
Fig 3.2-5 Frame buffer organization
40
Fig 3.2-6 Schematic
42
Fig 3.2-7 PCB
43
Fig D-1 XSA Board SDRAM controller interface
1
Fig D-2 SDRAM controller non-pipelined read operation.
2
iv
Fig D-3 SDRAM controller non-pipelined write operation.
3
Fig D-4 VGA timing information
4
Fig D-5 VGA controller interface
5
v
List of Tables
Table 2.1-1 Visible Device States
14
Table 2.1-2 List of possible Packet IDs.
17
Table 2.4-1 SL811 memory map
28
Table B-1 Device Descriptor
1
Table B-2 Configuration Descriptor
3
Table B-3 Interface Descriptor
4
Table B-4 Endpoint Descriptor
6
Table B-5 String Descriptor
7
Table B-6 Format of setup data
8
Table B-7 Standard Request Codes
8
Table B-8 Command Block Wrapper
9
Table B-9 Command Status Wrapper
10
Table B-10 READ (10) command format, fields other than LBA and transfer length
are not used and set to zero
10
Table B-11 READ CAPACITY (10) command format
11
Table B-12 Structure of parameter data returned in response to READ CAPACITY
(10)
11
vi
List of Abbreviations
Addr
ASCII
ASIC
CBW
CDB
CPLD
CRC
CSW
DIP
ENDP
EoP
EP
FAT
FPGA
GND
HID
INCITS
LBA
LSB
MSB
NRZI
PCB
PID
PLCC
SCSI
SDRAM
SE0
SE1
SIE
SoP
Sync
TQFP
USB
VGA
VHDL
VHSIC
Address
American Standard Code for Information Interchange
Application Specific Integrated Circuit
Command Block Wrapper
Command Descriptor Block
Complex Programmable Logic Device
Cyclic Redundancy Check
Command Status Wrapper
Dual Inline Package
Endpoint
End of Packet
Endpoint
File Allocation Table
Field Programmable Gate Array
Ground
Human Interface Device
International Committee for Information Technology Standards
Logical Block Address
Least Significant Bit/Byte
Most Significant Bit/Byte
Non Return to Zero Inverted
Printed Circuit Board
Packet Identifier
Plastic Leaded Chip Carrier
Small Computer System Interface
Synchronous Dynamic Random Access Memory
Single Ended Zero
Single Ended One
Serial Interface Engine
Start of Packet
Synchronizing
Thin Quad Flat Package
Universal Serial Bus
Video Graphics Adaptor
VHSIC Hardware Description Language
Very High Speed Integrated Circuit
vii
Table of Contents
Acknowledegments
i
Abstract
ii
List of Figures
iii
List of Tables
v
List of Abbreviations
vi
Table of Contents
vii
Chapter 1
Introduction
1
1.1 Background..............................................................................................................................2
1.2 Objectives 4
1.3 Report Organization.................................................................................................................4
Chapter 2
Literature Review
2.1 USB
5
6
2.1.1 USB Physical Interface.............................................................................................................6
2.1.2 Electrical Characteristics...........................................................................................................7
2.1.3 Signaling...................................................................................................................................8
2.1.4 Coding .....................................................................................................................................9
2.1.5 Hosts and Devices...................................................................................................................10
2.1.6 USB Devices and Functions....................................................................................................11
2.1.7 USB Device States..................................................................................................................13
2.1.8 USB Transfers........................................................................................................................14
2.1.9 USB Protocol..........................................................................................................................16
2.1.10 Descriptors............................................................................................................................19
2.1.11 Enumeration..........................................................................................................................22
2.2 Mass storage class..................................................................................................................24
2.2.1 Responding to Commands.......................................................................................................24
2.3 SCSI Commands....................................................................................................................25
2.4 SL811HS 26
2.4.1 Architecture Overview............................................................................................................27
2.4.2 Basic Operations with SL811HS.............................................................................................28
2.4.3 Packaging Information............................................................................................................29
2.5 XSA-50
2.6 VHDL
29
31
2.6.1 History and Features...............................................................................................................31
2.6.2 VHDL Terms..........................................................................................................................31
2.6.3 Describing Structure...............................................................................................................32
2.6.4 Describing Behavior...............................................................................................................33
Chapter 3
Design & Implementation
34
3.1 Design Overview....................................................................................................................35
3.2 A Brief Description................................................................................................................36
viii
3.2.1 USB, Mass Storage and Host Controller Driver.......................................................................36
3.2.2 Character Generator................................................................................................................39
3.2.3 VGA Controller......................................................................................................................41
3.2.4 SDRAM Controller.................................................................................................................41
3.2.5 Devices and Development Platform used................................................................................41
3.2.6 Schematic and PCB of the SL811HS Host controller board.....................................................41
3.3 Possible Future implementation............................................................................................44
Chapter 4
Conclusion and Recommendation
45
Conclusion 46
Recommendation..........................................................................................................................46
Appendices
47
Appendix A VHDL codes for controllers......................................................................................1
Appendix B USB Descriptors, Mass Storage Class Command Structures and SCSI Command
details.....................................................................................................................1
USB Standard Descriptors.................................................................................................................1
USB Standard requests......................................................................................................................8
Mass Storage Class Command Structures..........................................................................................9
Relevant SCSI Commands...............................................................................................................10
Appendix C Relevant parts of SL811HS datasheet......................................................................1
Appendix D SDRAM and VGA Controller modules from XESS Corp......................................1
SDRAM Controller...........................................................................................................................1
VGA Controller.................................................................................................................................3
Appendix E Descriptors returned by USB flash drives locally available.....................................1
Appendix F Exemplary USB trace of communication between host and a mass storage device1
References
1
ix
Chapter 1
Introduction
1.1
Background
A glimpse at the cover must have certainly made you guess what the project is all about.
Yes, this is all about Universal Serial Bus, USB in short. The title USB Box, however,
seems a little vague. Well, what we have tried to create here is an interface with the help
of which one can have access to the content of a USB drive without having to hook it
onto a computer. But before going on further into the matter, we’d like to discuss
something about USB and mass-storage device.
USB was designed from the ground up to be an interface for communicating with many
types of peripherals without the limits and frustrations of older interfaces. Every recent
PC and Macintosh computer includes USB ports that can connect to standard peripherals
such as keyboards, mice, scanners, cameras, printers, and drives as well as custom
hardware for just about any purpose. USB is a likely solution any time you want to use a
computer to communicate with a device outside of the computer. The interface is suitable
for mass-produced, standard peripheral types as well as small-volume designs, including
one-of-a-kind projects.
A mass-storage device is electronic hardware that stores information and supports a
protocol for sending and retrieving the information over a hardware interface. The
information can be anything that can be stored electronically: executable programs,
source code, documents, images, spreadsheet numbers, database entries, data logger
output, configuration data, or other text or numeric data. Mass-storage devices typically
store information in files. A file system defines how the files are organized in the storage
media.
A mass-storage device can provide access to data for just about any purpose. Every time
you load an application or save a file on a PC, you’re using a mass-storage device. A
computer’s hard drive is a mass-storage device, as are flash, CD, and DVD drives.
Devices with dedicated functions- data loggers, robots, and other embedded systems can
use mass storage as well. Every mass-storage device contains a microcontroller,
microprocessor, or other intelligent hardware that knows how to access the contents of the
storage media. A USB device controller enables a mass-storage device to share its data
with other computers. For example, a data logger can collect data in the field and then
connect to a PC, where an application reads the data from the logger’s storage media. So
2
what we’ve got here is USB and a mass-storage device and when combined, a magic is
created; the name of the magic being USB mass-storage device.
USB mass-storage device (or storage device for short) can be special-purpose device with
storage capabilities. For example, a camera can capture images and store the images in
files. A data logger can collect and store sensor readings in files. A robotic device can
receive files containing configuration parameters. With the addition of a USB massstorage interface, any of these devices can use USB to exchange files with PCs and other
USB hosts.
USB mass-storage device must support the USB protocols required for all USB devices
as well as class-specific mass-storage protocols. The storage device transfers data using
bulk transfers. These provide the fastest transfers on an otherwise idle bus but have no
guaranteed timing or bus bandwidth.
Storage Media
Media Controller
Fig 1.1-1
Device CPU or
Microcontroller
USB Device
Controller
USB Mass-Storage Device
A storage device should have one mass-storage master at a time. The master, or massstorage host, is the computer that reads and writes to the storage media. Special-purpose
mass-storage devices can function as masters on their own and can also permit a PC or
other USB host to function as the master.
USB Mass-Storage
Device
Fig 1.1-2
USB
USB Host
Connection via USB
USB Flash drives are the most popular storage device. They are commonly known as pen
drives and the capacity ranges from 32 MB to 2 GB (as per availability).
3
Fig 1.1-3
1.2
USB Flash Drives
Objectives
The primary objective of this project is to read a predefined sector from a USB Flash
drive and display the text contained in it.
1.3
Report Organization
Chapter 1 gives a brief background of the use and features of a USB Flash drive,
objective of the project and organization of this report. Chapter 2 provides review of
relevant literature related to USB, Mass storage class, SCSI command set, SL811HS Host
controller, XSA50 the FPGA development board and VHDL.
Appendix A contains VHDL codes for controllers; due to large volume of complete code,
its soft copy shall be provided upon request. Details on USB standard are in Appendix B.
In Appendix C datasheet of the Host controller chip SL811HS is given. Appendix D
contains information on SDRAM and VGA controllers. Appendix E summarizes our
survey on locally available USB Flash drives and finally Appendix F contains an example
USB trace of communication between host and a Mass storage device.
4
Chapter 2
Literature Review
2.1
USB
2.1.1
USB Physical Interface
USB connectors
All devices have an upstream connection to the host and all hosts have a downstream
connection to the device. Upstream and downstream connectors are not mechanically
interchangeable, thus eliminating illegal loopback connections at hubs such as a
downstream port connected to a downstream port. There are commonly two types of
connectors, called type A and type B which are shown below.
Fig 2.1-1
USB Receptacles
Type A plugs always face upstream. Type A sockets will typically find themselves on
hosts and hubs. For example type A sockets are common on computer main boards and
hubs. Type B plugs are always connected downstream and consequently type B sockets
are found on devices.
Fig 2.1-2
USB cable plugs from left to right: series-A, series B, mini-A, and mini-B.
6
2.1.2
Electrical Characteristics
USB Speed
The USB transfers signal and power over a four-wire cable(VBUS, D+, D-, GND). The
signaling occurs differentially over two wires on each point-to-point segment. In USB
Specification 1.0, there were two operating speeds defined: Low speed and Full speed.
With Revision 2.0, one more speed was added – High speed. The operating speeds are
characterized by their raw signaling rate

High Speed - 480Mbits/s: for high performance devices like webcams, fast storage
devices, communication devices

Full Speed - 12Mbits/s: fastest speed for USB 1.x complaint device, all high speed
devices must support full speed, (at least return descriptors) to be complaint with
USB 1.x hosts.

Low Speed - 1.5Mbits/s: for Human Interface devices (HIDs) like mice, keyboard,
joystick which do not require high speeds and need to be economical.
Speed Detection
At the host side D+ and D- lines are provided with resistors of 15k to ground. Thus with
no devices attached, the lines are pulled down. Full speed devices have a pull-up resistor
of 1.5k at D+ line whereas low speed devices have that pull-up at D- line. So when a full
speed device is attached, the D+ line level is raised whereas D- line level is raised when a
low speed device is attached giving an indication of the device speed. High speed devices
start off as a full speed device and declare their speed during reset.
USB Cable
The cable also carries VBUS and GND wires on each segment to deliver power to devices.
VBUS is nominally +5 V at the source. The USB allows cable segments of variable lengths,
up to several meters, by choosing the appropriate conductor gauge to match the specified
IR drop and other attributes such as device power budget and cable flexibility. In order to
provide guaranteed input voltage levels and proper termination impedance, biased
terminations are used at each end of the cable. The terminations also permit the detection
of attach and detach at each port and differentiate between high/full-speed and low-speed
devices.
7
2.1.3
Signaling
The USB specification defines bus states that correspond either to signal voltages on the
bus or conditions that these voltages signify.
Low-speed and Full-speed Bus States
Low and full speed support the same bus states, though some are defined differently
depending on the speed of the cable segment. A low-speed segment is a segment between
a low-speed device and its nearest hub. A full-speed segment is any other segment that
carries data at low- or full-speed bit rates.
Differential 0 and Differential 1
When transferring data, the two states on the bus are Differential 0 and Differential 1. A
Differential 0 exists when D- is higher than D+ by 200 mV. A Differential 1 exists when
D+ is higher than D- by 200 mV. The Differential 0s and 1s don’t translate directly into
voltage levels, but instead indicate either a change in logic level, no change in logic level,
or a bit stuff.
Single-Ended Zero
The Single-Ended-Zero (SE0) state occurs when both D+ and D- are logic low. The bus
uses the Single-Ended-Zero state when entering the End-of-Packet, Disconnect, and Reset
states.
Single-Ended One
The complement of the Single-Ended Zero is the Single-Ended One (SE1). This state
occurs when both D+ and D- are logic high. This is an invalid bus state and should never
occur.
Data J and Data K
In addition to the Differential 1 and 0 states, which are defined by voltages on the lines,
USB also defines two Data bus states, J and K. These are defined by whether the bus state
is Differential 1 or 0 and whether the cable segment is low or full speed: For low speed
device a differential 0 signifies a Data J, differential 1 a Data K state and for full speed
the opposite.
8
Idle
In the Idle state, no drivers are active. On a full-speed segment, D+ is more positive than
D-, while on a low-speed segment, D- is more positive than D+. Shortly after device
attachment, a hub determines whether a device is low or full speed by checking the
voltages on the Idle bus at the device’s port.
Start-of-Packet
The Start-of-Packet (SOP) bus state exists when the lines change from the Idle state to the
K data state. Every transmitted low- or full-speed packet begins with a Start of Packet.
End-of-Packet
The End-of-Packet (EOP) state exists when a receiver has been in the Single-Ended-Zero
state for at least one bit time, followed by a Data J state for at least one bit time. Every
transmitted low- or full-speed packet ends with an End of Packet.
Reset
When a Single-Ended Zero has lasted for 10 milliseconds, the device must be in the Reset
state. A device may enter the Reset state after the Single- Ended Zero has lasted for as
little as 2.5 microseconds. A full-speed device that is capable of high-speed
communications performs the high-speed handshake during the Reset state. On exiting
the Reset state, a device must be operating at its correct speed and must respond to
communications directed to the default address (00h).
2.1.4
Coding
All data on the bus is encoded. The encoding format, called Non-Return to Zero Inverted
(NRZI) with bit stuffing, ensures that the receiver remains synchronized with the
transmitter without the overhead of sending a separate clock signal or Start and Stop bits
with each byte. In NRZI encoding, a “1” is represented by no change in level and a “0” is
represented by a change in level. The bits transmit least-significant-bit (LSB) first.
Fig 2.1-3
Illustration of NRZI coding
9
In order to ensure adequate signal transitions, bit stuffing is employed by the transmitting
device when sending a packet on USB. A zero is inserted after every six consecutive ones
in the data stream before the data is NRZI encoded, to force a transition in the NRZI data
stream. This gives the receiver logic a data transition at least once every seven bit times to
guarantee the data and clock lock. The receiver must decode the NRZI data, recognize the
stuffed bits, and discard them.
Fig 2.1-4
2.1.5
Bit stuffing procedure
Hosts and Devices
Every USB communication is between a host and a device. The host is in charge of the
bus. Devices communicate only when requested to do so by the host. A USB host is a
equipment that contains USB host-controller hardware, a root hub with one or more USB
ports, and program code to manage communications and events on the bus. The hostcontroller hardware formats data for transmitting on the bus and converts received data to
a format that host software can understand. The host controllers also perform functions
related to managing communications on the bus. The root hub has one or more connectors
for attaching devices. The root hub, in combination with the host controller, detects newly
attached and removed devices, carries out requests received from the host, and passes
data between devices and the host controller.
10
A USB host can be a desktop or notebook computer, a handheld, or any embedded system
that contains host-controller hardware and software.
A USB device contains USB device-controller hardware and a microcontroller, CPU, or
other intelligent hardware. Some devices contain a microcontroller with an on-chip USB
device controller, while other devices use a microcontroller or CPU that interfaces to a
USB controller on a separate chip. The hardware that implements the low-level USB
protocols in the device controller is called the serial interface engine (SIE). Program code
in a USB device is typically firmware stored in non-volatile memory. Some devices
manage USB communications entirely in hardware and require no programming for the
USB communications.
Host Responsibilities

Detect devices

Provide power

Manage traffic on the bus

Exchange data with the peripherals
Device Responsibilities

Detect the bus voltage

Manage power

Respond to standard requests

Exchange data with the host

Implement the device’s function
2.1.6
USB Devices and Functions
When we think of a USB device, we think of a USB peripheral, but a USB device could
mean a USB transceiver device used at the host or peripheral, a USB Hub or Host
Controller IC device, or a USB peripheral device. The standard therefore makes
references to USB functions which can be seen as USB devices which provide a
capability or function such as a Printer, Zip Drive, Scanner, Modem or other peripheral.
11
Host
Bus
USB Device
EP0 In
EP0 Out
[Addr][Endpoint][Direction]
Function
Addr = 2
EP1 In
EP1 Out
USB Device
EP0 In
EP0 Out
Addr = 3
EP1 In
Function
EP1 Out
EP.. In
EP.. Out
Fig 2.1-5
USB host, device and endpoints
Most functions will have a series of buffers, typically 8 bytes long. Each buffer will
belong to an endpoint - EP0 IN, EP0 OUT etc. Say for example, the host sends a device
descriptor request. The function hardware will read the setup packet and determine from
the address field whether the packet is for itself, and if so will copy the payload of the
following data packet to the appropriate endpoint buffer dictated by the value in the
endpoint field of the setup token. It will then send a handshake packet to acknowledge the
reception of the byte and generate an internal interrupt within the semiconductor/microcontroller for the appropriate endpoint signifying it has received a packet. This is
typically all done in hardware. The software now gets an interrupt, and should read the
contents of the endpoint buffer and parse the device descriptor request.
Endpoints
All bus traffic is to or from device endpoints. An endpoint serves as a buffer for received
data or data waiting to transmit. Typically an endpoint is a block of data memory or a
register in the device controller. Every device must have endpoint zero, which is the
default endpoint used for control transfers. Endpoint zero is bidirectional.
A device can have up to 30 additional endpoint addresses. Each of these endpoint
addresses has a number (1 to 15), a direction (IN or OUT) and support one of the four
12
transfer types. The direction is defined from the host’s perspective: an IN endpoint
provides data to send to the host and an OUT endpoint stores data received from the host.
Device hardware or firmware configures each endpoint address for a specific USB
transfer type. The number of available endpoints and supported transfer types vary with
the device controller. A mass-storage device must have one IN endpoint and one OUT
endpoint in addition to endpoint zero.
2.1.7
USB Device States
When a USB device is introduced to a host it is applied with power, assigned an address,
configured before it is ready to use. Every device passes through these ‘states’ formerly
defined here.
Attached
Hub Reset
Hub Configured
Bus Inactive
Powered
Suspended
Bus Activity
Power Interruption
Reset
Bus Inactive
Default
Reset
Suspended
Bus Activity
Address
Assigned
Bus Inactive
Address
Suspended
Bus Activity
Device
Configured
Device
Deconfigured
Bus Inactive
Configuration
Suspended
Bus Activity
Fig 2.1-6
Device State diagram
13
The table below describes the above mentioned states.
Attached
Powered
Default
Address
Configure
d
Suspende
d
No
--
--
--
--
--
Device is not attached to the
USB. Other attributes are not
significant.
Yes
No
--
--
--
--
Device is attached to the USB,
but is not powered. Other
attributes are not significant.
Yes
Yes
No
--
--
--
Device is attached to the USB
and powered, but has not been
reset.
--
Device is attached to the USB
and powered and has been
reset, but has not been assigned
a unique address. Device
responds at the default address.
--
Device is attached to the USB,
powered, has been reset, and a
unique device address has been
assigned. Device is not
configured.
No
Device is attached to the USB,
powered, has been reset, has a
unique address, is configured,
and is not suspended. The host
may now use the function
provided by the device.
Yes
Device is, at minimum,
attached to the USB and is
powered and has not seen bus
activity for 3 ms. It may also
have a unique address and be
configured for use. However,
because the device is
suspended, the host may not use
the device’s function.
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
--
--
Table 2.1-1
2.1.8
--
No
Yes
--
State
Visible Device States
USB Transfers
USB is designed to handle many types of peripherals with varying requirements for
transfer rate, response time, and error correction. There are four different types of transfer
USB supports. The four types of data transfers each handle different needs, and a device
can support the transfer types that are best suited for its purpose.
14
Control transfers enable the host to learn about a device, set a device’s address, and
select configurations and other settings. Control transfers can also send vendor-specific
requests that transfer data for any purpose. All USB devices must support control
transfers. A control transfer has two or three stages. In the Setup stage, the host sends a
request. In the Data stage, the host or device sends data. Some requests don’t have a Data
stage. In the Status stage, the receiver of data in the Data stage returns status information.
If there is no Data stage, the device returns the status information. The other transfer
types don’t have stages. A class specification or vendor-specific protocol determines the
length of a transfer.
Bulk transfers are intended for situations where the rate of transfer isn’t critical. If the
bus is very busy, bulk transfers are delayed, but if the bus is otherwise idle, bulk transfers
are the fastest. Only full- and high-speed devices can do bulk transfers. Bulk data
typically consists of larger amounts of data, such as that used for printers or scanners.
Bulk data is sequential. Reliable exchange of data is ensured at the hardware level by
using error detection. Devices aren’t required to support bulk transfers(which means to
have a bulk type endpoint), but a specific device class might require them. All mass
storage devices support Bulk transfers.
Interrupt transfers are for devices that must receive or send data periodically. A limitedlatency transfer to or from a device is referred to as interrupt data. Other than control
transfers, interrupt transfers are the only way that low-speed devices can transfer data.
Keyboards and mice use interrupt transfers to send keypress and mouse-movement data.
Interrupt transfers can use any speed. As with Bulk transfers Devices aren’t required to
support interrupt transfers, but a specific device class might require them. Mass-storage
devices rarely use interrupt transfers except for some full-speed floppy drives, which use
interrupt transfers to report the status of a received command.
Isochronous transfers have guaranteed delivery time but no error correcting. Data that
might use isochronous transfers includes audio or video to be played in real time. USB
isochronous data streams are allocated a dedicated portion of USB bandwidth to ensure
that data can be delivered at the desired rate. The USB is also designed for minimal delay
of isochronous data transfers. Isochronous is the only transfer type that doesn’t support
automatic re-transmitting of data received with errors, so occasional errors must be
15
acceptable. Only full- and high-speed devices can do isochronous transfers. Mass-storage
devices don’t use isochronous transfers.
2.1.9
USB Protocol
USB is packet based, all data is transmitted in packets with well defined fields. A set of
packets forms a transaction, which is the basis of data transmission. The USB protocol
has provisions for error detection and recovery.
Error Detection and Recovery
For error detection CRCs are used, 5-bit CRCs are used for addresses and 16 bit CRC for
data. CRCs are generated at the transmitter and verified by the receiver. A receiver is
required to return a handshake (usually ACK) if it positively verifies the CRC and no
handshake if it received a corrupt CRC. The transmitter not receiving a handshake within
a certain timeout assumes failed or corrupt transmission and may retransmit the packet.
Since retransmission is involved, data duplication may occur in case handshake gets
corrupted, to correct this, data toggles are used.
Transactions
Each transfer consists of one or more transactions. Each USB transaction consists of a

Token Packet (Header defining what it expects to follow)

Optional Data Packet (Containing the payload)

Status Packet (Used to acknowledge transactions and to provide a means of error
correction)
USB is a host centric bus. The host initiates all transactions. The first packet, also called a
token is generated by the host to describe what is to follow and whether the data
transaction will be a read or write and what the device’s address and designated endpoint
is. The next packet is generally a data packet carrying the payload and is followed by a
handshaking packet, reporting if the data or token was received successfully, or if the
endpoint is stalled or not available to accept data.
Before going on into the matter of the packets, we should first have a brief idea about the
packet fields which when combined in certain order forms a packet. Packet fields are
described hereafter.
16
USB Packet Fields
Sync
All packets must start with a sync field. The sync field is 8 bits long, which is used to
synchronize the clock of the receiver with the transmitter. The SYNC pattern used for
low-/full-speed transmission is required to be 3 KJ pairs followed by 2 K’s i.e. the bit
pattern “00000011”.
PID
PID stands for Packet ID. This field is used to identify the type of packet that is being
sent. The following table shows the possible values.
Group
PID Value
Token
Data
Handshake
Special
Table 2.1-2
Packet Identifier
0001
OUT Token
1001
IN Token
0101
SOF Token
1101
SETUP Token
0011
DATA0
1011
DATA1
0111
DATA2
1111
MDATA
0010
ACK Handshake
1010
NAK Handshake
1110
STALL Handshake
0110
NYET (No Response Yet)
1100
PREamble
1100
ERR
1000
Split
0100
Ping
List of possible Packet IDs.
There are 4 bits to the PID, however to insure it is received correctly, the 4 bits are
complemented and repeated, making an 8 bit PID in total. The resulting format is shown
below.
17
ADDR
The address field specifies which device the packet is designated for. Being 7 bits in
length allows for 127 devices to be supported. Address 0 is not valid, as any device which
is not yet assigned an address must respond to packets sent to address zero.
ENDP
The endpoint field is made up of 4 bits, allowing 16 possible endpoints. Low speed
devices, however can only have 2 endpoint additional addresses on top of the default pipe
(4 Endpoints Max).
CRC
Cyclic Redundancy Checks are performed on the data within the packet payload. All
token packets have a 5 bit CRC while data packets have a 16 bit CRC.
EOP
End of packet. Signaled by a Single Ended Zero (SE0) for approximately 2 bit times
followed by a J for 1 bit time.
USB Packet Types
USB has four different packet types. Token packets indicate the type of transaction to
follow, data packets contain the payload, handshake packets are used for acknowledging
data or reporting errors and start of frame packets indicate the start of a new frame.
Token Packets
There are three types of token packets.

In – Informs the USB device that the host wishes to read information.

Out - Informs the USB device that the host wishes to send information.

Setup – Used to begin control transfers.
Token Packets must conform to the following format.
18
Data Packets
For full/low speed there are two types of data packets each capable of transmitting 0 to
1023 bytes of data – Data0 and Data1. These differ in the data toggle value and alternate
in subsequent Data packet. Since retransmission is the only method of error correction,
duplication of data may occur if for some reason handshake returned by receiver is lost.
Use of Data toggles help to detect duplication of packets.
Data packets have the following format.
Handshake Packets
There are three types of handshake packets which consist simply of the PID.

ACK – Acknowledgment that the packet has been successfully received.

NAK – Reports that the device can neither send nor receive data temporarily. Also
used during interrupt transaction to inform the host there is no data to send.

STALL – The device finds it’s in a state that it requires intervention from the host.
Handshake Packets have the following format.
Start of Frame Packets
The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms
±500ns.
2.1.10
Descriptors
The host computer uses control transfers to request the device’s descriptors, which are
data structures that contain information about a device’s capabilities and requirements.
The descriptors enable the host computer to select an appropriate driver for the device.
The descriptors also provide information the driver needs to communicate with the
device. Every USB device must have descriptors and the ability to send the descriptors to
the host on request. The USB specifications define the descriptors. Descriptors are
19
fetched by the host by issuing a Control transfer to Endpoint 0 with GetDescriptor
Standard Request.
All USB devices have a hierarchy of descriptors. The more common USB descriptors are:

Device Descriptors

Configuration Descriptors

Interface Descriptors

Endpoint Descriptors

String Descriptors
Device Descriptor
bNumConfiguration
Configuration
Descriptor
Configuration
Descriptor
bNumIntefaces
Interface
Descriptor
Interface
Descriptor
bNumEndpoints
Endpoint
Descriptor
Endpoint
Descriptor
bNumIntefaces
Interface
Descriptor
bNumEndpoints
Endpoint
Descriptor
Fig 2.1-7
Endpoint
Descriptor
Interface
Descriptor
bNumEndpoints
Endpoint
Descriptor
Endpoint
Descriptor
bNumEndpoints
Endpoint
Descriptor
Endpoint
Descriptor
Hierarchy of Descriptors
Device Descriptors
The device descriptor contains information about the device, its configurations and any
classes the device belongs to as a whole. A USB device can only have one device
descriptor. Device descriptors are 12h bytes long. For its format as specified by the USB
Specification refer to Appendix B.
Configuration Descriptors
Each device has at least one configuration that defines the device’s features and abilities.
Multiple configurations are allowed but rare. The configuration descriptor contains
information about the device’s use of power and the number of interfaces supported. The
20
core Configuration descriptor is 09h bytes long, apart from this, request for configuration
descriptor also returns interface descriptors and endpoint descriptors associated with this
configuration. For its format refer to Appendix B.
Interface Descriptors
The interface descriptor describes a specific interface within a configuration. A
configuration provides one or more interfaces, each with zero or more endpoint
descriptors describing a unique set of endpoints within the configuration. An interface
descriptor is always returned as part of a configuration descriptor. Interface descriptors
cannot be directly accessed with a Get_Descriptor request. The interface descriptor is
where a device specifies the mass-storage function. A configuration can have multiple
interfaces that are active at the same time. Each interface has its own interface descriptor
and subordinate descriptors. For its format refer to Appendix B.
Endpoint Descriptors
Each endpoint specified in an interface descriptor has an endpoint descriptor. Endpoint
descriptors define the type, address and maximum packet size for the endpoint. Each
endpoint descriptor is 07h bytes long and as with interface descriptors, it is accessed by
the configuration descriptor. For its format refer to Appendix B. Endpoint zero never has
a descriptor because every device must support endpoint zero, the device descriptor
contains the maximum packet size, and the USB specification defines everything else
about the endpoint.
String Descriptors
A string descriptor contains descriptive text. Support for most string descriptors is
optional. Common string descriptors include Manufacturer name, Product Name and
Serial number. Strings are encoded in Unicode encoding and may support multiple
languages. Each string descriptor has an index. A request for String descriptor with index
00h returns the list of language codes available.
Every mass-storage device that uses the bulk-only transport protocol must have a string
descriptor that contains a serial number. In this case serial number must have at least 12
characters and must contain only characters in the range 0–9 (0030h–0039h) and A–F
(0041h–0046h). Note that lower-case text, hyphens, and many other characters are not
21
allowed. The last 12 characters must be different from the last 12 characters of the serial
number of any device with the same values in the idVendor and idProduct fields in the
device descriptor. The serial number enables a host to retain properties such as the drive
letter and access policies after a user moves a device to another port or attaches multiple
devices with the same Vendor ID and Product ID. For its format refer to Appendix B.
2.1.11
Enumeration
Enumeration is the process of determining what device has just been connected to the bus
and what parameters it requires such as power consumption, number and type of
endpoint(s), class of product etc. The host will then assign the device an address and
enable a configuration allowing the device to transfer data on the bus. When a USB
device is attached to or removed from the USB, the host uses a process known as bus
enumeration to identify and manage the device state changes necessary. When a USB
device is attached to a powered port, the following actions are taken:

The hub to which the USB device is now attached informs the host of the event
via a reply on its status change pipe. At this point, the USB device is in the
Powered state and the port to which it is attached is disabled.

The host determines the exact nature of the change by querying the hub.

Now that the host knows the port to which the new device has been attached, the
host then waits for at least 100 ms to allow completion of an insertion process and
for power at the device to become stable. The host then issues a port enable and
reset command to that port.

The hub performs the required reset processing for that port. When the reset signal
is released, the port has been enabled. The USB device is now in the Default state
and can draw no more than 100 mA from VBUS. All of its registers and state have
been reset and it answers to the default address.

The host assigns a unique address to the USB device, moving the device to the
Address state.

Before the USB device receives a unique address, its Default Control Pipe is still
accessible via the default address. The host reads the device descriptor to
determine what actual maximum data payload size this USB device’s default pipe
can use.
22

The host reads the configuration information from the device by reading each
configuration zero to n-1, where n is the number of configurations. This process
may take several milliseconds to complete.

Based on the configuration information and how the USB device will be used, the
host assigns a configuration value to the device. The device is now in the
Configured state and all of the endpoints in this configuration have taken on their
described characteristics. The USB device may now draw the amount of VBUS
power described in its descriptor for the selected configuration. From the device’s
point of view, it is now ready for use.

When the USB device is removed, the hub again sends a notification to the host.
Detaching a device disables the port to which it had been attached. Upon receiving
the detach notification, the host will update its local topological information.
A common Windows enumeration is basically the same as the generic enumeration but
differs in details the steps involved are summarized as:

The host or hub detects the connection of a new device via the device's pull up
resistors on the data pair. The host waits for at least 100ms allowing for the plug
to be inserted fully and for power to stabilize on the device.

Host issues a reset placing the device in the default state. The device may now
respond to the default address zero.

The MS Windows host asks for the first 64 bytes of the Device Descriptor.

After receiving the first 8 bytes of the Device Descriptor, it immediately issues
another bus reset.

The host now issues a Set Address command, placing the device in the addressed
state.

The host asks for the entire 18 bytes of the Device Descriptor.

It then asks for 9 bytes of the Configuration Descriptor to determine the overall
size.

The host asks for 255 bytes of the Configuration Descriptor.

Host asks for any String Descriptors if they were specified.
23
2.2
Mass storage class
The USB mass storage class is suitable for high capacity non-volatile storage devices.
The class is further classified into different sub-divisions based on the transfer types they
use. Almost all the USB mass storage devices (pen drives) conforms to the Bulk-Only
Transport protocol which is covered by the Bulk-Only Transport Specification. Also they
accept a subset of SCSI commands (defined by various documents of the SCSI
architecture) with sectors LBA addressable. The Bulk-Only Transport protocol requires
the presence of one Bulk IN and one Bulk Out endpoint. The conformity to the above
mentioned class is declared in the interface descriptor as Class 08h (Mass storage),
Subclass 06h (SCSI Transparent Command set) and Protocol 50h (Bulk-Only Transport).
We here try to summarize the constructs defined in these documents.
2.2.1
Responding to Commands
Ready
Command
Transport
(CBW)
Data Out
(from host)
Data In
(to host)
Status Transport
(CSW)
Fig 2.2-1
Command/Status flow in Mass storage class complaint devices
Command/Data/Status Flow
In mass-storage communications, the USB host sends a command block, the host or
device may send data, and the device returns status. When reading or writing blocks of
24
data, the host identifies the locations to read or write to by specifying a logical block
address (LBA) without any care about files, directories, or data clusters in the media.
In the bulk-only transport protocol, a successful communication has two or three phases.

Command transport

Data transport (not used for some commands)

Status transport
In the command-transport phase, the host sends a command block in a structure called a
Command Block Wrapper (CBW). In the data-transport phase, the host or device sends
data. Some commands don’t have a data-transport phase. In the status-transport phase, the
device sends status information in a structure called a Command Status Wrapper (CSW).
Command Block Wrapper
The host sends the CBW to the device’s bulk OUT endpoint. The CBW contains a
command block and other information about the command. The CBW is of 31 bytes. On
receiving a CBW, a device should check that the structure is valid and has meaningful
content. Details are provided in Appendix B.
After receiving a CBW, depending on the command, the device must prepare to receive
data from the host on the bulk OUT endpoint or prepare to send data or a CSW to the host
on the bulk IN endpoint.
Command Status Wrapper
The device sends the status information in a structure called Command Status Wrapper.
On receiving a CSW, a host should check that the structure is valid and has meaningful
content. Details are provided in Appendix B.
2.3
SCSI Commands
SCSI commands originated as a protocol for devices that use the Small Computer
Systems Interface (SCSI) parallel interface. The commands provide a framework for
obtaining information about a storage device, controlling the device’s operation, and
reading and writing blocks of data in the storage media. Storage devices that use other
hardware interfaces, including USB, also use SCSI commands. The SCSI commands
25
cover a wide range of device types and functions. Most devices need to support only a
small number of the commands.
Each command travels in a structure called the command descriptor block (CDB), or
command block for short. The first byte of the CDB is the code that identifies the
command. Several sources provide specifications for commands used by mass-storage
devices. The INCITS Technical Committee T10 maintains these specifications.
Most USB flash drives implement a subset of the SCSI Primary and SCSI Block
commands. A minimal set includes:

INQUIRY

READ CAPACITY(10)

READ(10)

REQUEST SENSE

TEST UNIT READY

WRITE(10) (for writable devices)
We will be implementing only READ(10) to request a LBA addressed sector and possibly
READ CAPACITY to query number of sectors and size of a sector. Details on READ(10)
and READ CAPACITY are provided in Appendix B.
2.4
SL811HS
Cypress SL811HS is intended to provide USB functionality to embedded systems. It can
be used to implement either host or device. Its general features are:

USB Host/Slave controller for embedded systems with a standard microprocessor
bus interface.

Supports both full-speed (12 Mbps) and low-speed (1.5 Mbps) USB transfer

Operates as a single USB host or slave under software control

Low-speed 1.5 Mbps, and full speed 12 Mbps, in both master and slave modes

Automatic detection of either low- or full-speed devices

8-bit bidirectional data, port I/O

On-chip SIE and USB transceivers

On-chip single root HUB support
26

256-byte internal SRAM buffer, ping-pong operation

Operates from 12- or 48-MHz crystal or oscillator (built-in DPLL)

5 V-tolerant interface

Auto-generation and verification of SOF and CRC5/16

Auto-address increment mode, saves memory Read/Write cycles
EMBED Visio.Drawing.6
Master/Slave
Controller
Interrupt
Controller
INTR
D+
USB
Root Hub
Serial Interface
Engine
RAM Buffers
and
Control Registers
D-
nWR
nRD
Processor
Interface
Clock
Generator
X1
Fig 2.4-1
2.4.1
nCS
nRST
D0-D7
X2
SL811HS USB Host/Slave Controller Functional Block Diagram
Architecture Overview
The SL811HS microprocessor interface provides an 8-bit bidirectional data path along
with appropriate control lines to interface to external processors or controllers. The
control lines, Chip Select, Read and Write input strobes and a single address line, A0,
along with the 8-bit data bus, support programmed I/O or memory mapped I/O designs
27
SL811HS has a 256 byte internal memory of which 00h-0fh correspond to control
registers and 10h-ffh can be used as memory buffer.
The description of SL811HS registers are as follows:
Register Name
Address
USB-A/B Host Control Register
00h / 08h
USB-A/B Host Base Address
01h / 09h
USB-A/B Host Base Length
02h / 0Ah
USB-A/B Host PID, Device Endpoint (Write)/USB Status (Read)
03h / 0Bh
USB-A/B Host Device Address (Write)/Transfer Count (Read)
04h / 0Ch
Control Register1
05h
Interrupt Enable Register
06h
Reserved Register
07h
Status Register
0Dh
SOF Counter LOW (Write)/HW Revision Register (Read)
0Eh
SOF Counter HIGH and Control Register2
0Fh
Memory Buffer
10h-FFh
Table 2.4-1
2.4.2
SL811 memory map
Basic Operations with SL811HS
The SL811HS microprocessor interface provides an 8-bit bidirectional data path along
with appropriate control lines to interface to external processors or controllers. The
control lines, Chip Select, Read and Write input strobes and a single address line, A0,
along with the 8-bit data bus, support programmed I/O or memory mapped I/O designs.
Basic read/write from/to the SL811HS memory can be done as:

To read from any location first write the address with A0 pin low, then perform
read operation with A0 high.

To write to any location first write the address with A0 pin low, then perform
write operation with A0 high.
SL811HS supports auto address incrementing so there is no need to set the address every
time if we are sequentially accessing the memory. eg.:

Write 10h to SL811HS in address cycle (A0 is set LOW)

Write 55h to 811 in data cycle (A0 is set HIGH) -> Write 55h to location 10h
28

Write aah to 811 in data cycle (A0 is set HIGH) -> Write aah to location 11h

Write bbh to 811 in data cycle (A0 is set HIGH) -> Write bbh to location 12h
To transfer an OUT packet using SL811HS

Write the contents of DATA packet into memory location 10h and above.

Write the starting address of the DATA packet contents into 01h, the number of
bytes to be transmitted into 02h, the PID(OUT) and Device Endpoint no. in 03h,
the device address in 04h.

Write out direction, data toggle bit, arm and enable in 00h.

Wait for the operation to complete; the status of the operation is reported at 0dh.
To transfer an IN packet using SL811HS

Write the starting address for buffer into 01h, PID(OUT) and Device Endpoint no.
in 03h, the expected number of bytes to be received into 02h, the device address in
04h

Write in direction data toggle bit, arm and enable in 00h.

Wait for the operation to complete; the status of the operation is reported at 0dh.

If operation is successfully completed the contents of the DATA packet returned
by the device will be located at the address written into 01h.
2.4.3
Packaging Information
SL811HS is available in two packages: 28 pin PLCC (SL811HS) or 48 pin
TQFP(SL811HST-AC), for ease of use we chose 28 pin PLCC. For other details refer to
the datasheet of SL81HS in Appendix C.
2.5
XSA-50
The XSA-50 from XESS Corp is our development platform. XSA-50 is based upon
Spartan II FPGA XC2S50, a 50KGate FPGA from Xilinx. Spartan II FPGAs have built-in
SRAM to store configuration information. These can be configured through the parallel
interface provided on the board, managed by XC9572XL CPLD. Apart from the parallel
interface, CPLD can also be programmed to create interface to the on-board Flash and
SDRAM. The board has 128 KB of Flash (Atmel AT49F001-90TC) for non-volatile
29
configuration and general purpose data. Flash is directly accessible to both CPLD and
FPGA and can be read from or written to during runtime. To fulfill the need for a bigger
and faster memory there is 8 MB SDRAM (Hynix HY57V641620HGT-H) organized into
4M × 16 bits. The board is clocked by a 100 MHz programmable oscillator (Dallas
DS1075) and has a PS/2 interface, VGA interface (using 2-bit DAC for each channel)
along with 4 DIP switches, a push button and a 7-segment LED display. The board is
housed on a 88-pin prototyping header which allows easy access to the FPGA pins.
The following figure gives a programmer's model of the board.
Fig 2.5-1
XSA-50 Programmer's model
We will be using controllers for SDRAM and VGA (provided by XESS Corp); we here
presenting a brief overview of these controllers in Appendix D.
30
2.6
VHDL
2.6.1
History and Features
VHDL is a hardware description language. It describes the behavior of an electronics
circuit or system, from which physical circuit or system can be then be attained.
VHDL stands for VHSIC(Very High Speed Integrated Circuits) Hardware Description
Language. Its first version was VHDL 87 and later VHDL 93 and 2002. VHDL was the
first HDL to be standardized by IEEE through the IEEE 1076 standard. An additional
standard, the IEEE 1164, was later added to introduce a multi-valued logic system.
Contrary to regular computer programming languages, VHDL statements are concurrent
which better models digital logic. VHDL is intended for circuit synthesis as well as
circuit simulation. VHDL has its roots in simulation and is not fully synthesizable.
However, the constructs that are synthesizable can be used to configure CPLDs and
FPGAs. Furthermore, the VHDL code can be submitted to a foundry for a fabrication of
an ASIC chip. VHDL is designed to fill a number of needs in the design process. Firstly,
it allows description of the structure of a design, which is how it is decomposed into subdesigns, and how those sub-designs are interconnected. Secondly, it allows the
specification of the function of designs using familiar programming language forms.
Thirdly, it allows a design to be simulated before being manufactured, so that designers
can quickly compare alternatives and test for correctness without the delay and expense
of hardware prototyping.
2.6.2
VHDL Terms
Entity. All designs are expressed in terms of entities. An entity is the most basic building
block in a design. The uppermost level of the design is the top-level entity. If the design is
hierarchical, then the top-level description will have lower-level descriptions contained in
it. These lower-level descriptions will be lower-level entities contained in the top-level
entity description.
Architecture. All entities that can be simulated have an architecture description. The
architecture describes the behavior of the entity. A single entity can have multiple
31
architectures. One architecture might be behavioral while another might be a structural
description of the design.
Configuration. A configuration statement is used to bind a component instance to an
entity-architecture pair. A configuration can be considered like a parts list for a design. It
describes which behavior to use for each entity, much like a parts list describes which part
to use for each part in the design.
Package. A package is a collection of commonly used data types and subprograms used
in a design. Think of a package as a toolbox that contains tools used to build designs.
Driver. This is a source on a signal. If a signal is driven by two sources, then when both
sources are active, the signal will have two drivers.
Attribute. An attribute is data that are attached to VHDL objects or predefined data about
VHDL objects. Examples are the current drive capability of a buffer or the maximum
operating temperature of the device.
Generic. A generic is VHDL’s term for a parameter that passes information to an entity.
For instance, if an entity is a gate level model with a rise and a fall delay, values for the
rise and fall delays could be passed into the entity with generics.
Process. A process is the basic unit of execution in VHDL. All operations that are
performed in a simulation of a VHDL description are broken into single or multiple
processes.
2.6.3
Describing Structure
A digital electronic system can be described as a module with inputs and/or outputs. The
electrical values on the outputs are some function of the values on the inputs. Figure a
shows an example of this view of a digital system. The module F has two inputs, A and
B, and an output Y. Using VHDL terminology, we call the module F a design entity, and
the inputs and outputs are called ports.
One way of describing the function of a module is to describe how it is composed of submodules. Each of the sub-modules is an instance of some entity, and the ports of the
instances are connected using signals. Figure b shows how the entity F might be
composed of instances of entities G, H and I. This kind of description is called a structural
32
description. Note that each of the entities G, H and I might also have a structural
description.
(a)
Fig 2.6-1
2.6.4
(b)
Structural Modeling using VHDL
Describing Behavior
In many cases, it is not appropriate to describe a module structurally. One such case is a
module which is at the bottom of the hierarchy of some other structural description. For
example, if you are designing a system using IC packages bought from an IC shop, you
do not need to describe the internal structure of an IC. In such cases, a description of the
function performed by the module is required, without reference to its actual internal
structure. Such a description is called a functional or behavioral description.
To illustrate this, suppose that the function of the entity F in fig a is the exclusive-or
function. Then a behavioral description of F could be the Boolean function
Y <=
( A AND ( NOT B) ) OR ( ( NOT A ) AND B )
More complex behaviors cannot be described purely as a function of inputs. In systems
with feedback, the outputs are also a function of time. VHDL solves this problem by
allowing description of behavior in the form.
33
Chapter 3
Design & Implementation
3.1
Design Overview
The project focuses on interfacing a USB Flash disk to our FPGA board and at least read
a sector from the disk to RAM on FPGA. To keep things realizable we have broken the
project into two parts:

USB, Mass storage and Host controller driver – interfaces USB flash drive to
FPGA and uploads a pre-defined sector onto the board RAM.

Character generator – decodes ASCII characters stored in RAM and displays on
the monitor.
To keep things as simple and procedural as possible, we present a block diagram and a
couple of state diagrams. The block diagram, shown below, helped us in great deal to
break the project into many sub-tasks.
SDRAM
SDRAM Controller
Dual Port Module #1
Port 0
Port 1
FPGA
Dual Port #2
Port 0
1
USB + Mass
Storage Driver +
Host Controller
Driver
SL811HS +
USB Port
Flash
controller
Character Generator
VGA
Controller
Monitor
Flash
Fig 3.1-1
Port
Architecture of our project
35
3.2
A Brief Description
The basic thing to be done here is to read the content of the USB drive and display on the
monitor. To achieve this, the content of the drive should be first written on the memory
(SDRAM) and from the memory it is displayed onto the screen.
There are many parts which may sound very complicated, but are not much of a
headache. SDRAM and VGA interface are available in XSA-50. SDRAM controller,
Dual Port modules and VGA controller are provided by XESS. These units can be used
without any extraordinary ability as such. Thus the sections which are of much greater
concern are:

USB, Mass Storage and Host Controller Driver

Character Generator
3.2.1
USB, Mass Storage and Host Controller Driver
Operation
The operation of this part is neatly summarized by the following state diagram.
Device Detected
Device_just_in
Invalid Class Subclass
Protocol Speed
No_device
Reset
Fig 3.2-1
Invalid_device
Successful
Enumeration
Stand_by
Device Detachment
State diagram for USB, Mass Storage and Host Controller Driver
36
The driver enters the Reset state on startup where it resets ’811 and initializes it, then it
moves on to the No_device state where ’811’s status register is continuously polled for
device insert detection. Once device is detected it is checked for the validity. The speed of
the device is detected, flash disks must at least be capable of full speed so low speed
devices are rejected i.e. driver moves on to invalid_device state otherwise it advances to
device_just_in state. Here a request for the configuration descriptor is issued and class,
subclass and protocol declared in first interface descriptor are checked. If it is confirmed
that the device inserted is a USB Flash drive, enumeration takes place. Successful
enumeration will lead to Standby state where a read command is issued to retrieve a
predefined sector and written into SDRAM onboard XSA-50. Whenever device
detachment is detected, the driver moves on to reset state.
Implementation
We present a block diagram of the implementation of the driver.
XSA - 50
SDRAM
Flash
SDRAM Controller
Flash
controller
FPGA
driver state machine
SL 811 controller
SL 811 + USB port
Fig 3.2-2
Implementation of USB, Mass storage and Host controller driver
The flash drive attaches to the USB port which is handled by ’811. To interface the ’811
we devised the SL811 controller taking into consideration the timing requirements of the
chip. Similarly to access the onboard Flash we wrote a flash controller. The SDRAM
37
controller was provided as a pre-built module by XESS Corp. The flash contains packets
for USB standard device requests and Mass storage command structures. The driver state
machine governs the operation of the driver. It takes required steps to make USB transfers
via ’811.
Steps undertaken by the state machine

Issue USB Reset: maintain SE0 state for more than 20 ms.

Issue Get descriptor request: send a SETUP packet to Addr 0, EP0 with
following data:
80 06 00 02 00 00 20 00
This will result in 32 bytes of the configuration descriptor, interface descriptor and
first bulk endpoint.

Check class, subclass and protocol: declared in the interface descriptor, these
positively confirm that the device inserted is a flash drive.

Set Address: send a SETUP packet to Addr 0, EP0 with following data:
00 05 07 00 00 00 00 00
and complete the status stage by sending an IN packet to the same endpoint and
ACKing the Zero packet the device returns. This will set the device address as 7.

Set Configuration: send a SETUP packet to Addr 7, EP0 with following data:
00 09 01 00 00 00 00 00
and complete the status stage. This is to set the configuration of the device to 01h.

Send CBW: send an OUT packet to Addr 7, EP2 with following data:
55 53 42 43 27 32 36 45 00 20 00 00 80 00 0A 28
00 00 00 00 05 00 00 01 00 00 00 00 00 00 00
this contains a READ(10) command which instructs the device to be ready to
return contents of sector 5

Receive sector data: send IN packets to Addr 7, EP1, 8 packets will be necessary
to transfer a sector with 512 bytes and one more packet to take in the CSW. Also
need to keep track of the data toggles.
38
3.2.2
Character Generator
Implementation
Data Bus
Host Logic
Address Bus
RAM
Address
Frame Buffer
Data Address
Charcter Map
Read Data
Data
Data
Data
Data
Character Map
Address
Decode
Pixel Data
Pixel Data
Pixel Data
Load Frame Buffer
Frame Buffer Address
Pixel Data
VGA Controller
Frame Buffer Address
Pixel Data
Display
Fig 3.2-3
Overview of Character Generator
The resolution of the display is 800 × 600 with pixel depth of 1 bit width i.e. a typical
DOS standard black and white display. Each character is displayed by 8 × 14 pixels.
Therefore 100 characters (including all special and white space characters) can be
displayed on a line.
39
RAM is divided into 3 segments: Frame buffer, Character map and Data segment. Frame
buffer extends from 0000h to 7530h of the RAM. Character map extends from 7540h to
7B60h. Data are stored from 8000h onwards.
00000h
Frame Buffer
07530h
07540h
Character Bitmaps
07C40h
10000h
ASCII text
Fig 3.2-4
Memory Map
Host Logic defines various states involved in displaying characters onto the display unit.
Data stored in the RAM from the USB drive is read and is send to decoder. The decoder
outputs character map address on the address bus, according to the data read from the
RAM. Pixel data corresponding to the data is read into the data bus and then written to the
frame buffer of the RAM.
0000h
A1
0032h
B1
A2
50
0064h
B2
50
A3
0284h
A14
Fig 3.2-5
B3
0252h
B14
50
A13
B13
Frame buffer organization
VGA controller continuously reads the frame buffer and refreshes the VGA display as
accordingly. The VGA controller operates on scan line method. It sends the VGA display
device the first 8 pixels out of 8 × 14 pixels of the characters of the line to be displayed in
the first scan line. The second 8 pixels of the 8 × 14 pixels of the character, to be
40
displayed on the line, are displayed on the second scan line. After displaying all 14 scan
lines, next line of characters is displayed in the same fashion.
3.2.3
VGA Controller

It is the interface between displaying unit and frame buffer in SDRAM.

A frame buffer is at certain location in SDRAM. VGA controller reads the content
of frame buffer and periodically refreshes the monitor.

3.2.4
It is available as an independent module from XESS Corp.
SDRAM Controller

It is the interface between displaying unit and frame buffer in SDRAM.

It is available as an independent module from XESS Corp.
3.2.5
Devices and Development Platform used
We will be developing our project on XSA-50 FPGA board, USB physical layer protocol
is managed by SL811HS, state machines and drivers will be implemented as firmware
written in VHDL. For VHDL coding, simulation and downloading we are using Xilinx
Webpack 7.1i, ModelSim 5.8b and XSTools 4.0.6 respectively.
3.2.6
Schematic and PCB of the SL811HS Host controller board
A PCB was designed in order to mount the SL811HS chip and for USB port to fit into.
freePCB 1.319 was used to design the PCB, then fabricated using our department's very
own LPKF ProtoMat 92s PCB Prototyping machine. Due to alignment problems, single
sided PCB was used. On the PCB, the host controller SL811HS, in a PLCC package, was
hand soldered on the copper side and all other components were mounted on the
component side. The following figure shows the schematic diagram of the circuit and it is
followed by the designed PCB.
41
5V
9 VDC
Out
317
U3
0.1
C5
D1
3.3V
In
330
R9
0.1
C6
3.3V
100
470
0.1
C3
0.1
C4
0.1
C8
M/S
8
12
SL811SH
U1
VDD2
27
VDD
28
POT 1
VDD1
R8
nWR
nRD
nCS
5V
nDRQ
U S B A R e c e p t a c le
nDACK
1
22
2
3
15k
R4
R2
15k
R3
10
22
9
DATA-
A0
DATA+
S L811S H
R1
D7
D6
4
D5
3.3V
D4
7
CM
D3
22 pF
100
C2
R7
INTRQ
nRST
D0
5
4
6
3
3.3V
2
1
26
T o F P G A B o a rd
25
24
23
21
20
19
18
d a ta
16
15
X2
GND
14
GND1
12 MHz
X1
1M
R6
D1
17
C1
CLK/X1
22
13
USBGND
D2
22 pF
11
0.1
C7
7805
U2
G nd
D2
Out
A dj
J1
In
Title
USB Box HC Board
U
Author
File
Document
C:\Program Files\TinyCAD\tCad1.dsn
Revision
1.0
Fig 3.2-6
Date
Sheets
1 of 1
Schematic
42
Fig 3.2-7
PCB
43
3.3
Possible Future implementation
Our original goal was to be able to interface a USB Flash disk, display its directory tree,
and display the contents of a selected file on a monitor. However, due to limited time,
inexperience in VHDL and resources on the FPGA, we realized that goal was extremely
difficult to attain. We had conceptualized the FAT and File System Parser which needs to
perform the following steps

Requests Sector 0 to the Host Controller and upon receiving, reads the partition
table.

Reads boot record of 1st partition and searches for a specific file (plain text) in root
directory.

Identifies the clusters containing the file and requests for sector retrieval.
44
Chapter 4
Conclusion and
Recommendation
Conclusion
We had a daunting task ahead of us when we began the project. It seemed a very vague
prospect. But the determination was high and there was an intensifying desire to achieve
the goal.
USB is gaining its popularity day by day. Its popularity can be attributed to its versatile
nature. During this project, we have acquired a considerable knowledge regarding USB.
We have thoroughly applied USB protocols in our project. We now are well acquainted
with many USB parameters like descriptors, processes like enumeration, mass storage
class and many more.
We have tried to create a stand-alone device with the help of which use of CPU can be
limited to some extent. The system can be devised with firmware implementing device
like microcontroller with host controller IC.
PCB was a must for our project since the host controller IC used was surface mount type.
The fabrication of PCB was materialized in our very own institution using LPKF
ProtoMat 92s PCB prototyping machine, which was not in use since nobody knows when.
FPGA logic within XSA-50 was interfaced with memory devices like RAM, flash RAM,
VGA devices, keyboard. In order to interface with flash, flash controller was designed
and implemented successfully. Moreover, timing signals required to synchronize the
VGA signals and memory read/write sequences were analyzed.
Recommendation
File system parser is a highly desirable improvement. With this feature deployed in the
host logic and keyboard interface, our system would be able to read out any file from a
pen drive. Along with this addition of write feature is another welcome improvement. A
good user interface is also lacking and needs a facelift.
As such this project can find many applications. A standalone, lightweight Flash drive
reader is an immediate application. Another possible use may be to provide a cheap and
easily available mass storage and easy distribution of firmware upgrades for embedded
devices.
46
Appendices
Appendix A VHDL codes for controllers
Flash RAM controller
-------------------------------------------------------------------------------- Module Name:
rom_controller - Behavioral
-- Project Name:
USB BOX
-- Target Device: XC2S50
-- Tool versions:
-- Description:
controller for flash ram, allows to read data in flash
-- Additional Comments:
-- keep address stable and hrom_nRD low until done is asserted
-- data is latched at hrom_data until next read
------------------------------------------------------------------------------library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use work.common.all;
package romcntrl is
component rom_controller is
Port (
clk
:
rst_i
:
--host side
hrom_nRD
:
hrom_data
:
hrom_done
:
--rom side
rom_nCE
:
rom_nOE
:
rom_nWE
:
rom_nRST
:
rom_data
:
end component;
end package;
in
in
std_logic;
std_logic;
in
out
out
std_logic;
std_logic_vector(7 downto 0);
std_logic;
out
out
out
out
in
std_logic;
std_logic;
std_logic; -- always HI
std_logic; -- always HI
std_logic_vector(7 downto 0));
architecture Behavioral of rom_controller is
signal timer, counter
:
integer range 0 to 7;
signal data_x, data_r
:
std_logic_vector(rom_data'range) :=
(others=>'0') ;
type rom_states is (idle,
done,
signal cur_state, next_state
:
nearly_done,
rom_states
read);
:=idle;
begin
-- no need to write or reset
rom_nWE
<=
HI;
rom_nRST
<=
HI;
A-1
-- seven segment LEDS share the data bus of flash use hrom_nRD to
disable LED outputs in host logic
rom_nCE
<=
hrom_nRD;
hrom_data
<=
data_r;
comb:
process (cur_state, hrom_nRD,
begin
hrom_done
<=
rom_nOE
<=
timer
<=
next_state <=
data_x
<=
rom_data, data_r)
LO;
HI;
0;
cur_state;
data_r;
case cur_state is
when idle =>
if hrom_nRD = LO then
timer
<=
next_state <=
end if;
1;
read;
when done =>
hrom_done
next_state
<=
<=
HI;
idle;
when nearly_done =>
next_state
<=
done;
when read =>
timer
rom_nOE
data_x
next_state
<=
<=
<=
<=
6;
LO;
rom_data;
nearly_done;
end case;
end process comb;
seq:
process (clk, rst_i)
begin
if rst_i=HI then
cur_state
<=
idle;
else
if rising_edge(clk) then
data_r
<=
data_x;
if (counter = timer) then
counter
<=
0;
cur_state
<=
next_state;
else
counter
<=
counter+1;
end if;
end if;
end if;
end process seq;
end Behavioral;
A-2
SL811 Controller
-------------------------------------------------------------------------------- Module Name:
sl811_controller - Behavioral
-- Project Name:
USB BOX
-- Target Device: XC2S50
-- Description:
controller for SL811HS USB host controller
------------------------------------------------------------------------------library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
package slcntrl is
component sl811_controller is
Port (
clk
: in std_logic;
rst_i
: in std_logic;
-- host side
hSLdIn
: in std_logic_vector(7 downto 0);
hSLrd
: in std_logic;
hSLwr
: in std_logic;
hSLreset
: in std_logic;
hSLaddr
: in std_logic;
hSLdOut
: out std_logic_vector(7 downto 0);
hSLdone
: out std_logic;
-- device side
SLd811
: inout std_logic_vector(7 downto 0);
SLnRD
: out std_logic;
SLnWR
: out std_logic;
SLnCS
: out std_logic;
SLnRST
: out std_logic;
SLa0
: out std_logic);
end component sl811_controller;
end package;
architecture Behavioral of sl811_controller is
signal timer, counter
:
integer range 0 to 31;
signal a_zero_x, a_zero_r:
std_logic:=HI;
signal dOut_x, dOut_r
:
std_logic_vector (hSLdOut'range)
:=(others => 'Z');
type sl_states is (
idle,
reset,
reset1,
done,
write,
write1,
read,
read1,
readwr);
signal cur_state, next_state : sl_states :=idle;
begin
SLa0
<=
a_zero_r;
A-3
hSLdOut
<=
dOut_r;
comb:
process (cur_state,
hSLdIn, hSLrd, hSLwr, hSLreset, hSLaddr, SLd811,
a_zero_r, dOut_r)
begin
hSLdone
<=
LO;
SLd811
<=
(others=>'Z');
SLnCS
<=
HI;
SLnRD
<=
HI;
SLnWR
<=
HI;
SLnRST
<=
HI;
dOut_x
a_zero_x
timer
<=
<=
<=
dOut_r;
a_zero_r;
0;
next_state
<=
cur_state;
case cur_state is
when idle =>
if hSLreset = HI then
next_state <=
reset;
else
if hSLaddr = HI then
next_state <=
write;
a_zero_x
<=
LO;
else
if hSLwr=HI then
next_state <=
write;
a_zero_x
<=
HI;
else
if hSLrd=HI then
next_state <=
read;
a_zero_x
<=
HI;
end if;
end if;
end if;
end if;
when reset =>
timer
SLnRST
next_state
<=
<=
<=
31;
LO;
reset1;
when reset1 =>
timer
next_state
<=
<=
31;
done;
when done =>
hSLdone
next_state
<=
<=
HI;
idle;
when write =>
SLnWR
SLnCS
SLd811
timer
<=
<=
<=
<=
LO;
LO;
hSLdIn;
4;
A-4
next_state
<=
write1;
when write1 =>
SLnCS
SLd811
next_state
<=
<=
<=
LO;
hSLdIn;
readwr;
when read =>
SLnRD
SLnCS
timer
next_state
<=
<=
<=
<=
LO;
LO;
4;
read1;
when read1 =>
SLnRD
SLnCS
dOut_x
next_state
<=
<=
<=
<=
LO;
LO;
SLd811;
readwr;
when readwr =>
timer
next_state
<=
<=
5;
done;
end case;
end process comb;
seq:
process (clk, rst_i)
begin
if rst_i=HI then
cur_state
<=
idle;
else
if rising_edge(clk) then
a_zero_r
<=
a_zero_x;
dOut_r
<=
dOut_x;
if (counter = timer) then
counter
<=
0;
cur_state
<=
next_state;
else
counter
<=
counter+1;
end if;
end if;
end if;
end process seq;
end Behavioral;
A-5
Character Generator
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use IEEE.numeric_std.all;
use WORK.common.all;
package chargen_pkg is
component chargen
port(
clk
: in std_logic;
-- master clock input
rst
: in std_logic;
-- reset
rstt
: in std_logic;
-- scroll to next line
donow
: out std_logic;
-- start VGA controller
begun
: in std_logic;
-- memory operation begun
done
: in std_logic;
-- memory operation done
dIn
: in std_logic_vector(15 downto 0); -- data from memory
rd
: out std_logic;
-- memory read control signal
wr
: out std_logic;
-- memory write control signal
addr
: out std_logic_vector(21 downto 0); -- address to memory
dOut
: out std_logic_vector(15 downto 0) -- data to memory
);
end component;
end package chargen_pkg;
architecture arch of chargen is
constant DATA_WIDTH :
natural := 16;
constant ADDR_WIDTH :
natural := 22;
-- memory data width
-- memory address width
subtype byte is std_logic_vector(7 downto 0);
signal
uflag14_x, uflag14_r,flag_x, flag_r,i_x,
i_r,nextln_x,nextln_r,nextaddr_x,nextaddr_r
signal
uploflag_x, uploflag_r,uplo_x,uplo_r`
signal
logic_x,logic_r
:
:integer;
:std_logic;
std_logic :='0';
type charStates is (
INIT,
read,
fwrite,
decode,
INTdecode,
INTreadec,
readec,
STOP
);
signal state_r, state_x : charStates;
signal
addr_r, addr_x, frame_r, frame_x, BEG_FRAME_r, BEG_FRAME_x,
tempadd_r, tempadd_x
: unsigned(addr'range);
signal
nextframe_x,nextframe_r :
unsigned(addr'range):=TO_UNSIGNED(16#00_0000#, addr_x'length) ;
signal
letter_x, letter_r
:
byte;
A-6
signal
tempdata_x, tempdata_r,readata_x, readata_r, tempwrite_x,
tempwrite_r
:
std_logic_vector(DATA_WIDTH-1 downto 0);
alias tempwriteup_x: byte is tempwrite_x (tempwrite_x'left downto
tempwrite_x'left-7);
alias tempwritelo_x: byte is tempwrite_x (tempwrite_x'left-8 downto 0);
alias tempdataup_x: byte is tempdata_x
(tempdata_x'left downto
tempdata_x'left-7);
alias tempdatalo_x: byte is tempdata_x (tempdata_x'left-8 downto 0);
alias readataup_x : byte is readata_x
(readata_x'left downto
readata_x'left-7);
alias readatalo_x : byte is readata_x
(readata_x'left-8 downto 0);
alias tempwriteup_r: byte is tempwrite_r (tempwrite_r'left downto
tempwrite_r'left-7);
alias tempwritelo_r: byte is tempwrite_r (tempwrite_r'left-8 downto 0);
alias tempdataup_r: byte is tempdata_r
(tempdata_r'left downto
tempdata_r'left-7);
alias tempdatalo_r: byte is tempdata_r
(tempdata_r'left-8 downto 0);
alias readataup_r : byte is readata_r
(readata_r'left downto
readata_r'left-7);
alias readatalo_r : byte is readata_r
(readata_r'left-8 downto 0);
begin
dout
addr
<=
<=
tempdata_r;
std_logic_vector(addr_r);
combinatorial: process(logic_r,state_r, dIn, begun, done,
flag_r,
uflag14_r,uploflag_r,uplo_r,addr_r,frame_r,BEG_FRAME_r,tempd
ataup_r,tempdatalo_r, tempwrite_r, tempadd_r, i_r, letter_r,
nextln_r)
begin
rd
wr
addr_x
nextln_x
state_x
frame_x
BEG_FRAME_x
uflag14_x
flag_x
uplo_x
uploflag_x
tempdatalo_x
tempdataup_x
tempadd_x
letter_x
tempwrite_x
i_x
readata_x
donow
letter_x
nextaddr_x
nextframe_x
logic_x
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
NO;
NO;
addr_r;
nextln_r;
state_r;
frame_r;
BEG_FRAME_r;
uflag14_r;
flag_r;
uplo_r;
uploflag_r;
tempdatalo_r;
tempdataup_r;
tempadd_r;
letter_r;
tempwrite_r;
i_r;
readata_r;
NO;
letter_r;
nextaddr_r;
nextframe_r;
logic_r;
case state_r is
A-7
when INIT =>
if rstt=HI
addr_x
then
<=
TO_UNSIGNED
(16#00_8000#,addr_x'length) +
nextframe_r;
BEG_FRAME_x <=
TO_UNSIGNED(16#00_0000#,
addr_x'length);
frame_x
<=
TO_UNSIGNED(16#00_0000#,
addr_x'length);
i_x
<=
0;
logic_x
<=
YES;
nextln_x
<=
0;
nextframe_x
<=
TO_UNSIGNED(16#00_0032#,
addr_x'length) +
nextframe_r;
state_x
<= read;
else
state_x
<= INIT;
end if;
when read=>
if i_r <=2100
then
if done = NO then
rd
<=
YES;
else
rd
<=
tempwrite_x
<=
flag_x
<=
tempadd_x
<=
uploflag_x
<=
uflag14_x
<=
uplo_x
<=
i_x
<=
nextln_x
<=
if nextln_r = 49 then
BEG_FRAME_X <=
nextln_x
<=
else
BEG_FRAME_x <=
end if;
state_x
<=
end if;
else
logic_x
<= YES;
state_x
<=
STOP;
end if;
when decode=>
if(uploflag_r = up) then
letter_x
elsif (uploflag_r = lo) then
letter_x
end if;
nextaddr_x
state_x
NO;
dIn;
1;
addr_r+1;
up;
0;
up;
i_r+1;
nextln_r+1;
BEG_FRAME_R + 701;
0;
BEG_FRAME_r + 1;
decode;
<=
tempwriteup_r;
<=
tempwritelo_r;
<=
<=
0;
INTdecode;
when INTdecode=>
if (letter_r>x"0") then
addr_x<=TO_UNSIGNED(16#7540#,addr_x'length)+
uflag14_r+nextaddr_r;
nextaddr_x
<=
nextaddr_r+7;
A-8
letter_x
state_x
<=
<=
letter_r-1;
INTdecode;
else
addr_x<=TO_UNSIGNED(16#7540#,addr_x'length) +
uflag14_r+nextaddr_r;
state_x
<=
readec;
end if;
when readec =>
if done = NO then
rd
else
rd
readata_x
state_x
end if;
<=
YES;
<=
<=
<=
NO;
dIn;
INTreadec;
when INTreadec=>
if (uploflag_r = up) then
if (uplo_r = up) then
tempdatalo_x
else
tempdatalo_x
end if;
uploflag_x
state_x
end if;
if (uploflag_r = lo) then
if(uplo_r = up) then
tempdataup_x
else
tempdataup_x
end if;
addr_x
frame_x
uploflag_x
state_x
end if;
<=
readataup_r;
<=
readatalo_r;
<=
<=
lo;
decode;
<=
readataup_r;
<=
readatalo_r;
<=
<=
<=
<=
frame_r;
50+frame_r;
up;
fwrite;
when fwrite=>
if done = NO then
wr
<= YES;
else
if (flag_r <= 7) then
if (uplo_r = up) then
uplo_x
<=
state_x
<=
else
uplo_x
<=
flag_x
<=
uflag14_x
<=
state_x
<=
end if;
else
addr_x
<=
frame_x
<=
state_x
<=
end if;
lo;
decode;
up;
flag_r+1;
uflag14_r+1;
decode;
tempadd_r;
BEG_FRAME_r;
read;
A-9
end if;
when STOP =>
if rstt = HI then
rd
wr
donow
else
state_x
end if;
<=
<=
<=
NO;
NO;
YES;
<=
INIT;
when others =>
state_x <= INIT;
end case;
end process;
update : process(clk)
begin
if clk'event and clk = '1' then
if (rst = YES) then
state_r
<= INIT;
else
frame_r
<=
frame_x;
BEG_FRAME_r
<=
BEG_FRAME_x;
uflag14_r
<=
uflag14_x;
flag_r
<=
flag_x;
uplo_r
<=
uplo_x;
uploflag_r
<=
uploflag_x;
i_r
<=
i_x;
tempdataup_r
<=
tempdataup_x;
tempdatalo_r
<=
tempdatalo_x;
tempwrite_r
<=
tempwrite_x;
readata_r
<=
readata_x;
tempadd_r
<=
tempadd_x;
letter_r
<=
letter_x;
nextln_r
<=
nextln_x;
nextaddr_r
<=
nextaddr_x;
logic_r
<=
logic_x;
nextframe_r
<=
nextframe_x;
addr_r
<=
addr_x;
state_r
<=
state_x;
end if;
end if;
end process;
end arch;
A-10
Appendix B USB Descriptors, Mass Storage Class
Command Structures and SCSI Command details
USB Standard Descriptors
The details presented here give emphasis to devices of the Mass storage class.
Device Descriptor Format
Byte
Field
Description
0
bLength
Descriptor size in bytes (12h)
1
bDescriptorType
The constant DEVICE (01h)
2
bcdUSB
USB specification release number (BCD).
For USB 2.0, byte 2 = 00h and byte 3 = 02h
4
bDeviceClass
Class code. For mass storage, set to 00h.
5
bDeviceSubclass
Subclass code. For mass storage, set to 00h.
6
bDeviceProtocol
Protocol Code. For mass storage, set to 00h.
7
bMaxPacketSize0
Maximum packet size for endpoint zero.
8
idVendor
Vendor ID. Obtained from USB-IF.
10
idProduct
Product ID. Assigned by the product vendor.
12
bcdDevice
Device release number (BCD). Assigned by the vendor.
14
iManufacturer
Index of string descriptor for the manufacturer.
15
iProduct
Index of string descriptor for the product.
16
iSerialNumber
Index of string descriptor containing the serial number
17
bNumConfigurations
Number of possible configurations. Typically 01h.
Table B-1
Device Descriptor
bLength. The length in bytes of the descriptor. Always 12h.
bDescriptorType. The constant DEVICE (01h).
bcdUSB. The USB specification version that the device and its descriptors comply with in
BCD (binary-coded decimal) format. If the version’s value is thought of as a decimal
number, the upper byte represents the integer, the next four bits are tenths, and the final
four bits are hundredths. Version 2.0 is 0200h. A 2.0 device does not have to be high speed.
Any new full-speed mass-storage device should comply with the latest version of the
specification.
B-1
bDeviceClass. For devices whose function is defined at the device level, this field specifies
the device’s class. Many devices, including mass-storage devices, specify their class in the
interface descriptor and set the bDeviceClass field in the device descriptor to 00h.
bDeviceSubclass. A subclass within bDeviceClass. If bDeviceClass is 00h this field is also
00h.
bDeviceProtocol. A protocol defined by a class or subclass.
bMaxPacketSize0. The maximum packet size for endpoint zero. Full-speed devices may
use 08h, 10h, 20h, or 40h. High-speed devices must use 40h.
idVendor. Members of the USB-IF and others who pay an administrative fee receive the
rights to use a unique Vendor ID. Every device descriptor must have an assigned Vendor
ID in this field.
idProduct. The owner of the Vendor ID assigns a Product ID to identify the device. Each
Product ID is specific to a Vendor ID, so multiple vendors can use the same Product ID
without conflict.
bcdDevice. The device’s release number in BCD format. The owner of the Vendor ID
assigns this value.
iManufacturer. Index to a string descriptor that contains a string describing the
manufacturer. This value is 00h if there is no manufacturer string descriptor.
iProduct. Index to a string descriptor that contains a string describing the product. This
value is 00h if there is no product string descriptor.
iSerialNumber. An index that points to a string containing the device’s serial number.
Every mass-storage device must have a serial number whose final 12 characters differ from
the final 12 characters in the serial number of any other device with the same Vendor ID
and Product ID. The only exception is devices that use the CBI protocol, which don’t
require serial numbers.
bNumConfigurations. The number of configurations the device supports. This value is
almost always 01h.
B-2
Configuration Descriptor Format
Byte
Field
Description
0
bLength
Descriptor size in bytes. Always 09h.
1
bDescriptorType
The constant CONFIGURATION (02h).
2
wTotalLength
The number of bytes in the configuration descriptor and all of
its subordinate descriptors.
4
bNumInterfaces
The number of interfaces in the configuration.
5
bConfigurationValue
Identifier for Set Configuration and Get Configuration
requests. Use 01h for the first configuration.
6
iConfiguration
Index of string descriptor for the configuration. Set to 00h if
there is no string descriptor.
7
bmAttributes
Self/bus power and remote wakeup settings.
If bit 6=1 : device is self powered.
=0 : device is bus powered.
If bit 5=1 : device supports remote wake up feature.
8
bMaxPower
The amount of bus power the device requires, expressed as
(maximum milliamperes / 2).
Table B-2
Configuration Descriptor
bLength. The length in bytes of the descriptor. Always 09h.
bDescriptorType. The constant CONFIGURATION (02h).
wTotalLength. The number of bytes in the configuration descriptor and all of its
subordinate descriptors. The subordinate descriptors include interface and endpoint
descriptors but do not include string descriptors.
bNumInterfaces. The number of interfaces in the configuration. The minimum is 1. A
device with multiple interfaces can perform multiple functions, such as mass storage and
human-interface device.
bConfigurationValue. Identifies the configuration in Get Configuration and Set
Configuration requests. Set to 01h for the first (or only) configuration.
iConfiguration. Index to a string descriptor that contains a string describing the
configuration. This value is zero if there is no configuration string descriptor.
bmAttributes. Bit 6 = 1 if the device is self-powered or zero if bus-powered. Bit 5 = 1 if
the device supports the remote wakeup feature, which enables a suspended USB device to
tell its host that the device wants to communicate. A USB device must enter the Suspend
state if there has been no bus activity, including Start-of-Frame markers, for 3 milliseconds.
If a suspended device requires action from the host, a device with remote wakeup enabled
B-3
can request the host to resume communications. Mass-storage devices typically don’t
support remote wakeup. Bits 0..4 must equal 0. Bit 7 must equal 1.
bMaxPower. Specifies how much bus current a device requires. The bMax-Power value
equals one half the number of milliamperes(mA) requested. If a device requires 200mA,
bMaxPower = 100. The maximum current a device can request is 500mA. If the requested
current isn’t available, the host can refuse to configure the device. Some battery-powered
hosts and all bus-powered hubs supply only 100mA per port. To enable a device to operate
entirely from bus power when attached to these hosts and hubs, bMaxPower must equal
32h or less.
Interface Descriptor Format
Byte
Field
Description
0
bLength
Descriptor size in bytes (09h).
1
bDescriptorType
The constant INTERFACE (04h).
2
bInterfaceNumber
Number identifying this interface.
3
bAlternateSetting
Set to 00h for the default setting.
4
bNumEndpoints
Number of endpoints supported, not counting endpoint zero.
5
bInterfaceClass
Class code. Mass storage = 08h.
bInterfaceSubclass
Subclass code. Mass-storage values:
01h: Reduced Block Commands (RBC).
02h: SFF-8020i, MMC-2 (ATAPI) (CD/DVD drives)
03h: QIC-157 (tape drives).
04h: USB Floppy Interface (UFI).
05h: SFF-8070i (ATAPI removable rewritable media
devices).
06h: SCSI transparent command set.
Use the SCSI INQUIRY command to determine the
peripheral device type. Recommended value for most
devices.
7
bInterfaceProtocol
Protocol code. Mass storage values:
00h: CBI with command completion interrupt transfers
01h: CBI without command completion interrupt
transfer
50h: bulk only. Recommended value for most devices.
8
iInterface
Index of string descriptor for the interface.
6
Table B-3
Interface Descriptor
bLength. The number of bytes in the descriptor. Always 09h.
bDescriptorType. The constant INTERFACE (04h).
bInterfaceNumber. Identifies the interface. Each interface must have a descriptor with a
unique value in this field.
B-4
bAlternateSetting. A single interface number can have alternate settings. Each setting has
its own interface descriptor with the same value in bInterfaceNumber and a unique value in
bAlternateSetting. Each setting also has its own endpoint descriptors. Only one setting is
active at a time. The default interface setting (bAlternateSetting = 00h) is active
immediately after the host has enumerated the device and selected a configuration. Massstorage host drivers typically support only the default setting.
bNumEndpoints. The number of endpoints an interface supports in addition to endpoint
zero. Set to 02h for a bulk-only mass-storage device.
bInterfaceClass. Set to 08h to specify the mass-storage class.
bInterfaceSubClass. In mass-storage devices, the bInterfaceSubClass field specifies either
an industry-standard command-block set or the SCSI transparent command set (06h). Each
device also specifies a peripheral device type (PDT) in response to a SCSI INQUIRY
command. Each PDT corresponds to a document that specifies a command set. Virtually all
new mass-storage designs should set bInterfaceSubClass = 06h. The device then declares
its command set in a single location, in the PDT value in the response to an INQUIRY
command. Devices that use other values for bInterfaceSubClass should be sure that the
value is compatible with the PDT returned in the INQUIRY response. The mass-storage
overview specification is somewhat confusing when it says that the contents of
bInterfaceSubclass specify “transport protocols and command code systems transported by
the interface.” In reality, bInterfaceSubclass names the command-code system, or
command blocks, that a device uses (either explicitly or by leaving the issue to the
INQUIRY command), and the bInterfaceProtocol field (described below) names the
transport protocol.
bInterfaceProtocol. In mass-storage devices, the bInterfaceProtocol field specifies a massstorage transport protocol. The transport protocol defines structures and specifies USB
transfer types for carrying mass-storage commands, data, and status information on the bus.
A device may use either of two protocols: bulk-only transport (BOT, sometimes called
BBB because all three phases use bulk transfers) or control/bulk/interrupt (CBI). The massstorage specification recommends using the bulk-only transport protocol (50h) for all new
devices. CBI is approved for use only with full-speed floppy drives.
iInterface. Index to a string descriptor that contains a string describing the interface. This
value is zero if there is no interface string descriptor.
B-5
Endpoint Descriptor Format
Byte
Field
Description
0
bLength
Descriptor size in bytes (07h).
1
bDescriptorType
The constant Endpoint (05h).
2
bEndpointAddress
Endpoint number and direction.
3
bmAttributes
Transfer type supported. Bulk = 02h.
4
wMaxPacketSize
Maximum packet size supported.
6
bInterval
Maximum NAK rate for high-speed bulk OUT endpoints.
Otherwise ignored for bulk endpoints.
Table B-4
Endpoint Descriptor
bLength. The number of bytes in the descriptor. Always 07h.
bDescriptorType. The constant ENDPOINT (05h).
bEndpointAddress. The endpoint number and direction. Bits 0..3 are the endpoint
number, which can be any value from 1 to 15 supported by the device’s hardware. Bit 7 is
the direction: Out = 0, In = 1. Bits 6..4 are unused and must be zero. For example, an
interface could use endpoint 1 OUT (01h) and endpoint 1 IN (81h), or endpoint 2 OUT
(02h) and endpoint 3 in (83h).
bmAttributes. Bits 1..0 specify the type of transfer the endpoint supports. Bits 7..2 are
zero. This field is 00h for Control endpoints, 01h for Isochronous endpoints, 02h for Bulk
endpoint and 03h for interrupt endpoints
wMaxPacketSize. The value in bits 10..0 is the maximum number of data bytes the
endpoint can transfer in a transaction. The allowed values vary with the device speed and
type of transfer. A full-speed bulk endpoint can have a maximum packet size of 08h, 10h,
20h, or 40h bytes. For best performance, use 40h. If a full-speed bulk endpoint’s
wMaxPacketSize is less than 40h, some host controllers schedule no more than one
transaction per frame. For high speed, the maximum packet size must be 200h. Bits 15..11
are zero for bulk endpoints.
bInterval. The host ignores this value for full-speed bulk endpoints and high-speed bulk
IN endpoints. For high-speed bulk OUT endpoints, the value indicates the endpoint’s
maximum NAK rate.
B-6
String Descriptor Format
Byte
Field
Size (bytes)
Description
0
bLength
1
Descriptor size in bytes
1
bDescriptorType
1
The constant String (03h)
2
bSTRING or wLANGID
Varies
For string descriptor zero, an array of 1 or more
Language Identifier codes. For other string
descriptors, a Unicode string.
Table B-5
String Descriptor
bLength. The number of bytes in the descriptor.
bDescriptorType. The constant STRING (03h).
wLANGID[0...n] or bString. When a host requests a String descriptor, the low byte of the
wValue field in the Setup stage is an index value. If the index value is zero, the host is
requesting language IDs. If the index value is greater than zero, the host is requesting the
string descriptor with that index.
String descriptor zero contains one or more 16-bit language ID codes that indicate the
languages that the strings are available in. The code for U.S. English is 0409h. This is
likely to be the only code supported by an operating system. The wLANGID value must be
valid for any of the other strings to be valid. Devices that return no string descriptors must
not return an array of language IDs. The USB-IF’s web site has a list of defined USB
language IDs.
For index values of 1 and higher, the bString field contains a Unicode string. With a few
exceptions, ANSI character codes 00h through 7Fh correspond to Unicode values 0000h
through 007Fh. For example, a product string for a product called “Gizmo” would contain
five 16-bit Unicode values that represent the characters in the product name:
0047 0069 007A 006D 006F
In the string descriptor, each Unicode character transmits LSB first:
47 00 69 00 7A 00 6D 00 6F 00
The strings are not null-terminated. The bLength field for a string descriptor that contains a
string equals (2 × number of characters in string) + 2.
B-7
USB Standard requests
Standard requests are issued by sending a SETUP packet at the default Control endpoint
with 8 bytes of data that identify and parameterize the request. The format of the 8 bytes to
be sent is as follows.
Offset
Field
Size
Value
Description
0
bmRequestType
1
Bitmap
Characteristics of request:
D7: Data transfer direction
0 = Host-to-device
1 = Device-to-host
D6...5: Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved
D4...0: Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4...31 = Reserved
1
bRequest
1
Value
Standard request code
2
wValue
2
Value
Word-sized field that varies according to request
4
wIndex
2
Index or
Offset
Word-sized field that varies according to request;
typically used to pass an index or offset
6
wLength
2
Count
Number of bytes to transfer if there is a Data stage
Table B-6
bRequest
Format of setup data
Value (decimal)
GET_STATUS
0
CLEAR_FEATURE
1
Reserved for future use
2
SET_FEATURE
3
Reserved for future use
4
SET_ADDRESS
5
GET_DESCRIPTOR
6
SET_DESCRIPTOR
7
GET_CONFIGURATION
8
SET_CONFIGURATION
9
GET_INTERFACE
10
SET_INTERFACE
11
SYNCH_FRAME
12
Table B-7
Standard Request Codes
B-8
Mass Storage Class Command Structures
Command Block Wrapper Format
A CBW is valid if all of the following are true.

The CBW is received after a CSW or reset.

The CBW is 31 bytes.

The dCBWSignature field has the correct value.
The contents are considered meaningful if all of the following are true.

All of the reserved bits are zero.

The bCBWLUN field contains a supported LUN value.
Offset
Name
Bits
Description
00h
dCBWSignature
32
The value 43425355h, which identifies the structure as
a CBW. The LSB (55h) transmits first on the bus.
04h
dCBWTag
32
A value that associates this CBW with the CSW the
device will send in response.
08h
dCBWDataTransferLength
32
The number of bytes to be transferred in the datatransport phase.
12h
bmCBWFlags
8
Specifies the direction of the data-transport phase.
Bit 7 = 0 for an OUT (host-to-device) transfer.
Bit 7 = 1 for an IN (device-to-host) transfer.
If there is no data-transport phase, bit 7 is ignored. All
other bits are zero.
13h
Reserved (MSB)
4
Zero
bCBWLUN
4
For devices with multiple LUNs, specifies the LUN the
command block is directed to. Otherwise the value is
zero.
Reserved(MSB)
3
Zero.
bCBWCBLength
5
The length of the command descriptor block in the
CBWCB field in bytes. Valid values are 1–16.
CBWCB
128
The command block for the device to execute.
14h
15h
Table B-8
Command Block Wrapper
Command Status Wrapper Format
A CSW is valid if all of the following are true.

The CSW is 13 bytes.

The dCSWSignature field has the correct value.

The value of dCSWTag equals the value in the dCBWTag field of a previously sent
CBW.
B-9
The contents are considered meaningful if either of the following is true.

The bCSWStatus field equals 02h.

The bCSWStatus field equals 00h or 01h and dCSWDataResidue is less than or
equal to dCBWDataTransferLength.
Offset
Name
Bits
Description
00h
dCSWSignature
32
The value 53425355h, which identifies the structure as
a CSW. The LSB (55h) transmits first on the bus.
04h
dCSWTag
32
The value of the dCBWTag in a CBW received from
the host.
32
For transfers where the host sends data to the device in
the data-transport phase, the difference between
dCBWDataTransferLength and the number of bytes the
device processed.
For transfers where the device sends data to the host in
the data-transport phase, the difference between
dCBWDataTransferLength and the number of valid
bytes the device has sent, excluding any pad bytes.
8
00h = command passed.
01h = command failed.
02h = phase error. Host should perform a reset
recovery
08h
dCSWDataResidue
12h
bCSWStatus
Table B-9
Command Status Wrapper
Relevant SCSI Commands
READ (10)
The READ(10) command requests a storage device to read specified logical block(s) and
transfer them to the data-in buffer. The command is 10 bytes long.
Byte/Bit
7
6
0
5
4
3
2
1
0
Reserved
FUA_NV
Obsolete
Operation code (28h)
1
RDPROTECT
2
DPO
FUA
Logical Block Address (4 bytes Big endian)
5
6
Reserved
7
Group Number
Transfer Length (number of sectors to transfer, 2 bytes Big endian)
8
9
Control
Table B-10
READ (10) command format, fields other than LBA and transfer length are not used
and set to zero
B-10
READ CAPACITY (10)
The READ CAPACITY (10) command requests that the device return transfer 8 bytes of
parameter data describing the capacity and medium format of the direct-access block
device to the data-in buffer.
Byte/Bit
7
6
5
4
3
0
Operation code (25h)
1
Reserved
2
1
0
Obsolete
Logical Block Address (4 bytes Big endian)
5
6
Reserved
7
8
Reserved
9
PMI
Control
Table B-11
Byte/Bit
2
7
0
6
READ CAPACITY (10) command format
5
4
3
2
1
0
Number of Logical Blocks (4 bytes Big endian)
3
4
Size of a logical block in bytes (4 bytes Big endian)
7
Table B-12
Structure of parameter data returned in response to READ CAPACITY (10)
B-11
Appendix C Relevant parts of SL811HS datasheet
C-1
Appendix D SDRAM and VGA Controller modules
from XESS Corp.
SDRAM Controller
The interface for the core is shown below:
Fig D-1 XSA Board SDRAM controller interface
Relevant signals are described below
rd/wr: Active-high input initiates a read/write of a single word from/to the SDRAM. It is
sampled on the rising clock edge and must be held high until the opBegun signal
indicating the read/write process has started.
opBegun: This synchronous output signal goes high to indicate the initiation of a read or
write operation.
earlyOpBegun: This asynchronous output signal goes high during the clock cycle
immediately preceding the activation of the opBegun signal.
done: This synchronous output signal goes high to indicate the completion of the
currently active read or write operation. It remains high for a single clock cycle.
D-1
hAddr: The address of the SDRAM word that is to be read or written is passed through
this input bus. The address value must be held stable until the opBegun signal goes high.
For XSA-50 hAddr is 22 bits wide.
hDIn: The data to be written to the SDRAM enters through this input bus. The data value
must be held stable until the opBegun signal goes high.
hDOut: The data read from the SDRAM comes out on this bus. This data must be
latched by the host-side logic on the rising clock edge after the done signal goes high.
sAddr: The row and column address fields for the SDRAM memory location are output
on this bus. For XSA-50 hAddr is 12 bits wide.
sData: The data word to be written to SDRAM exits the FPGA on this bidirectional bus
during write operations, and data from the SDRAM enters the FPGA on this bus during
read operations.
Operation of the SDRAM Controller
The SDRAM Controller can be used to read or write operation on two different modes,
viz. pipelined and non-pipelined. We will look only at the non pipelined case assuming
that the read operation accesses a memory location in the currently active bank and row
of the SDRAM.
Non-Pipelined Read Operation
The sequence of actions is summarized in this timing diagram:
Fig D-2 SDRAM controller non-pipelined read operation.
D-2
Non-Pipelined Write Operation
The sequence of actions is summarized in this timing diagram:
Fig D-3 SDRAM controller non-pipelined write operation.
In the previous sequence of actions, it was assumed the read/write operation was initiated
as soon as the read/write control signal was asserted. This is not the case when a row is
being refreshed or when the given address is not in the currently active bank or row of the
SDRAM. The initiation of the read/write operation is delayed, the earlyOpBegun and
opBegun signals are held low until the read/write operation is actually initiated.
VGA Controller
The VGA Controller describes the circuitry and the timing diagram of the video signals
that drives the VGA monitor. Also, the controller uses the data form the SDRAM using
SDRAM Controller for the displaying of the content on the video frame.
With the VGA generator, we can manage the timing for the horizontal and vertical sync
signals. Adjust the bit of digital-to-analog converter (DAC) for width of Red, Green and
Blue component. We can have 255-word pixel buffer for storing pixels. Also, the
selectable pixel width so that each word of memory can hold 1, 2, 4, 8 or 16 pixels.
Principles of VGA Signals
There are three signals -- red, green, and blue -- that send color information to a VGA
monitor. These three signals each drive an electron gun that emits electrons which paint
one primary color at a point on the monitor screen. Signal levels between 0 (completely
D-3
dark) and 0.7 V (maximum brightness) control the intensity of each color component,
which combine to make the color of a dot (or pixel) on the monitor screen.
Each analog color input can be set to one of four levels by two digital outputs using a
simple two-bit DAC. The four possible levels on each analog input are combined by the
monitor to create a pixel with one of 4 × 4 × 4 = 64 different colors. So the six digital
control lines let us select from a palette of 64 colors. To successfully draw an image on
screen we must send out correct pixel information along with synchronizing signals on
correct time. This is managed by the VGA controller module.
Fig D-4 VGA timing information
The interface of the VGA controller and links with SDRAM controller is shown below
D-4
Fig D-5 VGA controller interface
Relevant signals are described below
pixel_data_in: 16-bit data containing one or more pixels enters the pixel buffer through
this bus.
eof: This active-high output indicates when the display of a video frame has been
completed and pixels for the next frame can begin entering the buffer.
full: This active-high output indicates when the pixel buffer is full and no more space is
currently available for more pixels.
vsync_n: This active-low output drives the vertical sync input of a VGA monitor.
hsync_n: This active-low output drives the horizontal sync input of a VGA monitor.
blank: This active-high output signals when the red, green and blue video signals are
blanked.
r/g/b: This bus carries the data bits for the red/green/blue video component to a DAC
whose analog output is delivered to the VGA monitor.
D-5
Appendix E Descriptors returned by USB flash drives
locally available
Kingston Datatraveller (Silver, 128 MB)
Device Descriptor
12 01 00 02 00 00 00 40 30 09 32 65 00 01 01 02 03 01
Parameters inferred

Maximum packet size for Endpoint 0 is 40h = 64 bytes.

Vendor ID = 0930h, Product ID = 6532h

One configuration with value 01h
Configuration, Interface and Endpoint Descriptor
09
09
07
07
07
02
04
05
05
05
27
00
81
02
83
00
00
02
02
03
01
03
40
40
40
01
08
00
00
00
00 80 64
06 50 00
00
00
01
Parameters inferred

Bus powered device, Maximum power drawn = 200 mA @ 5VDC

Belongs to Mass storage class, accepts SCSI commands and implements BulkOnly Transport Protocol

Three endpoints

One Bulk IN endpoint at address 1 with maximum packet size 64 bytes.

One Bulk OUT endpoint at address 2 with maximum packet size 64 bytes.

One Interrupt IN endpoint at address 3 with maximum packet size 64 bytes.
Kingston Datatraveller 2.0 (White, 1 GB)
Device Descriptor
12 01 00 02 00 00 00 40 EC 08 16 00 00 02 01 02 03 01
Parameters inferred

Maximum packet size for Endpoint 0 is 40h = 64 bytes.

Vendor ID = 08ECh, Product ID = 0016h
F-1

One configuration with value 01h
Configuration, Interface and Endpoint Descriptor
09
09
07
07
02
04
05
05
20
00
81
02
00
00
02
02
01
02
40
40
01
08
00
00
00 80 2F
06 50 00
00
00
Parameters inferred

Bus powered device, Maximum power drawn = 94 mA @ 5VDC

Belongs to Mass storage class, accepts SCSI commands and implements BulkOnly Transport Protocol

Two endpoints

One Bulk IN endpoint at address 1 with maximum packet size 64 bytes.

One Bulk OUT endpoint at address 2 with maximum packet size 64 bytes.
Transcend JetFlash (512 MB)
Device Descriptor
12 01 00 02 00 00 00 40 8F 05 87 63 41 01 01 02 03 01
Parameters inferred

Maximum packet size for Endpoint 0 is 40h = 64 bytes.

Vendor ID = 058Fh, Product ID = 6387h

One configuration with value 01h
Configuration, Interface and Endpoint Descriptor
09
09
07
07
02
04
05
05
20
00
01
82
00
00
02
02
01
02
40
40
01
08
00
00
00 80 32
06 50 00
00
00
Parameters inferred

Bus powered device, Maximum power drawn = 100 mA @ 5VDC

Belongs to Mass storage class, accepts SCSI commands and implements BulkOnly Transport Protocol

Two endpoints

One Bulk IN endpoint at address 2 with maximum packet size 64 bytes.

One Bulk OUT endpoint at address 1 with maximum packet size 64 bytes
F-2
Appendix F Exemplary USB trace of communication
between host and a mass storage device
Host generated packet
SETUP
Address 0
DATA0
80 06 00 01 00 00 12 00
Device Generated packet
Endpoint 0
Host requests for device descriptor
ACK
IN
Address 0
Endpoint 0
DATA1
12 01 10 01 00 00 00 40
7D 0D 00 01 00 01 01 02
03 01
Device return device descriptor
ACK
OUT
Address 0
DATA1
(Zero Packet)
Endpoint 0
Status phase of control transfer
ACK
SETUP
Address 0
Endpoint 0
DATA0
00 05 03 00 00 00 00 00
Set address request to set device address to
3
ACK
IN
Address 0
DATA1
(Zero Packet)
Endpoint 0
Status phase
ACK
SETUP
Address 3
Endpoint 0
DATA0
80 06 00 02 00 00 09 00
Host requests first 9 bytes of configuration
descriptor
ACK
IN
Address 3
Endpoint 0
DATA1
09 02 27 00 01 01 00 80
32
Device complies; 27h bytes total size of
configuration descriptor
ACK
OUT
Address 3
DATA1
(Zero Packet)
Endpoint 0
Status phase, device NAKs; it is not ready
to receive the packet
NAK
OUT
Address 3
DATA1
(Zero Packet)
Endpoint 0
Host retries, this time successfully
ACK
F-1
SETUP
Address 3
Endpoint 0
DATA0
80 06 00 02 00 00 27 00
Host asks for full 27h bytes of descriptor
ACK
IN
Address 3
DATA1
09
32
50
FF
07
02
09
00
07
05
27
04
07
05
83
Endpoint 0
00
00
05
02
03
01
00
81
02
02
01
03
02
40
00
00
08
40
00
01
80
06
00
FF
Configuration descriptor
ACK
OUT
Address 3
Endpoint 0
DATA1
(Zero Packet)
ACK
SETUP
Address 3
Endpoint 0
DATA0
00 09 01 00 00 00 00 00
Set configuration request, sets configuration
to 01h
ACK
IN
Address 3
Endpoint 0
DATA1
(Zero Packet)
ACK
OUT
Address3
DATA0
55
08
00
00
53
00
00
00
42
00
00
00
Endpoint 2
43
00
00
00
E8
80
00
00
F8
00
00
00
1A 82
0A 25
00 00
00
Host sends a CBW with READ
CAPACITY(10) command
ACK
IN
Address 3
Endpoint 1
DATA0
00 00 F9 FF 00 00 02 00
Device returns no. of sectors: 0000F9FF,
Size of sector: 00000200(=512) bytes
ACK
IN
Address 3
Endpoint 1
DATA1
55 53 42 43 E8 F8 1A 82
00 00 00 00 00
CSW; transaction successful
ACK
OUT
Address3
DATA0
55
08
00
00
53
00
00
00
42
00
00
00
Endpoint 2
43
00
00
00
E8
80
00
00
F8
00
00
00
1A 82
0A 28
00 01
00
Host sends a CBW with READ (10)
command to retrieve sector 0
ACK
F-2
IN
Address 3
DATA0
31
E6
06
06
0E
4C
C1
00
C0
8E
B9
00
13
00
E0
8E
8E
D8
00
00
04
31
06
C0
Endpoint 1
D0
8E
01
60
BE
FF
B9
F3
BC
C0
F2
A1
2F
FF
43
A5
00
FC
A5
13
07
36
00
8E
7C
BF
EA
04
FF
4E
2D
D8
89
00
1B
FF
36
00
09
8F
first 64 bytes of sector 0
B4
72
A2
8B
4C
C0
3C
1E
second 64 bytes of sector 0
EE
89
74
DF
BB
EB
B8
0C
…
BE
BF
C9
49
70
6E
45
61
…
65
73
69
70
20
1E
7A
04
…
ACK
IN
Address 3
DATA1
06
08
FE
8A
00
00
61
80
87
88
81
00
31
8C
BE
74
00
16
E1
F6
C0
06
BE
0F
Endpoint 1
8F
89
3F
E6
8E
4E
07
80
06
00
00
01
D8
00
B3
3C
85
CD
89
C8
FA
FB
04
00
00
13
C8
A3
A3
8E
80
75
ACK
IN
Address 3
DATA0
81
CD
F5
18
06
07
F0
01
C6
18
81
80
AC
00
BF
02
10
8B
C6
3C
3C
B4
05
57
Endpoint 1
00
14
10
00
00
0E
00
CD
FE
8B
00
74
74
CD
BB
13
CB
4C
FE
F3
FE
10
00
5F
75
02
CB
BE
56
5E
7C
73
ACK
IN
Address 3
DATA1
31
F7
FE
89
6E
61
20
72
C0
06
7D
EE
76
72
74
72
CD
EB
81
EA
61
74
61
6F
Endpoint 1
13
D5
3D
00
6C
69
62
72
4F
BE
55
7C
69
74
6C
20
75
16
AA
00
64
69
65
6C
ED
07
75
00
20
6F
00
6F
ACK
IN
Address 3
DATA0
64
72
79
73
65
73
0E
80
69
61
73
73
72
79
1F
FC
6E
74
74
69
61
73
3A
02
Endpoint 1
67
69
65
6E
74
74
16
72
20
6E
6D
67
69
65
89
75
6F
67
00
20
6E
6D
00
80
70
20
4D
6F
67
00
75
FC
ACK
F-3
IN
Address 3
DATA1
76
FF
35
C0
1F
03
00
06
28
1E
00
E1
CA
00
93
81
80
85
8B
06
02
60
88
E1
Endpoint 1
FC
00
0E
0A
00
88
CC
3F
08
EB
39
0E
FF
F0
88
00
75
12
00
37
00
F6
E8
49
6B
8A
86
00
3F
26
C0
01
9C
36
CD
F8
00
8A
EC
CB
…
D2
F7
92
F6
08
76
00
01
…
00
00
00
00
00
00
00
AA
last 64 bytes of sector 0
ACK
IN
Address 3
DATA0
F7
00
26
88
36
E1
0B
00
26
00
37
D5
37
89
61
00
8B
52
00
88
00
E5
1F
00
Endpoint 1
00
A1
5A
F1
88
89
EA
00
01
35
93
C0
C6
4E
00
00
C3
00
F7
E1
FE
0C
00
00
81
40
F3
06
C4
88
00
80
ACK
IN
Address 3
DATA1
01
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
06
04
00
00
00
00
00
00
Endpoint 1
FE
BC
00
00
00
00
00
00
3F
00
00
00
00
00
00
00
02
00
00
00
00
00
00
00
3F
00
00
00
00
00
00
55
ACK
IN
Address 3
Endpoint 1
DATA1
55 53 42 43 E8 F8 1A 82
00 00 00 00 00
CSW; transaction sucessful
ACK
F-4
References
USB




USB Specification, Rev 2.0 April 27, 2000
USB in a Nutshell, www.beyondlogic.com
Jan Axelson - USB Complete
John Hyde - USB Design By Example
USB Mass Storage Class



USB Mass Storage Class Specification Overview, Rev 1.2
USB Mass Storage Class Bulk-Only Transport, Rev 1.0
Jan Axelson - USB Mass Storage Designing and Programming Devices and
Embedded Hosts
SCSI Command Set


SCSI-3 Primary Commands, T10 drafts rev 11a
SCSI-3 Block Commands, T10 drafts rev 8c
VHDL





Peter J Ashenden - Designers Guide to VHDL
Volnei A. Pedroni - Circuit Design using VHDL
Douglas L Perry - VHDL Programming By Example
Peter J Ashenden - The VHDL Cookbook
The Low-Carb VHDL Tutorial
XSA-50 and components






XSA Board v1.2 User Manual
Dave Vanden Bout - Application note: VGA Generator for XSA Boards
Dave Vanden Bout - Application note: XSA Board SDRAM Controller
Dave Vanden Bout - Application note: SDRAM Dualport Module
Atmel AT49F001 1Mbit Flash datasheet
Spartan-II 2.5V FPGA Family: Complete Data Sheet
SL811HS



SL811HS Datasheet
SL811HS Application Note
EZ811 development kit firmware examples
and whole lot of websites.
R1
Contact address

Raghu Rajbhandari
Currently Chakupat, Lalitpur
Tel: 2380199,

email: itsme_raghu@hotmail.com
Sabin Chandra Shrestha
Sa-bahal, New Road, Kathmandu
Tel: 9803167361,

email: sabincs@hotmail.com
Santosh Pradhan
Chhetrapati, Kathmandu
Tel: 4216173,

email: mzzzzb@yahoo.com
Soyuz Upadhayaya
Naya Bazar, Kathmandu
Tel: 9803087331,

email: soyuz_s@hotmail.com
Sushil Shrestha
Naya Bazar, Kathmandu
Tel: 9803030376,
email: sushil_god@yahoo.com
R2