TRIBHUVAN UNIVERSITY

Transcription

1 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

2 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

3 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

4 List of Figures Fig USB Mass-Storage Device 3 Fig Connection via USB 3 Fig USB Flash Drives 4 Fig USB Receptacles 6 Fig USB cable plugs from left to right: series-a, series B, mini-a, and mini-b. 6 Fig Illustration of NRZI coding 9 Fig Bit stuffing procedure 10 Fig USB host, device and endpoints 12 Fig Device State diagram 13 Fig Hierarchy of Descriptors 20 Fig Command/Status flow in Mass storage class complaint devices 24 Fig SL811HS USB Host/Slave Controller Functional Block Diagram 27 Fig XSA-50 Programmer's model 30 Fig Structural Modeling using VHDL 33 Fig Architecture of our project 35 Fig State diagram for USB, Mass Storage and Host Controller Driver 36 Fig Implementation of USB, Mass storage and Host controller driver 37 Fig Overview of Character Generator 39 Fig Memory Map 40 Fig Frame buffer organization 40 Fig Schematic 42 Fig PCB 43 Fig D-1 XSA Board SDRAM controller interface 1 Fig D-2 SDRAM controller non-pipelined read operation. 2 iv

5 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

6 List of Tables Table Visible Device States 14 Table List of possible Packet IDs. 17 Table 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

7 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

8 Table of Contents Acknowledegments Abstract List of Figures List of Tables List of Abbreviations Table of Contents i ii iii v vi vii Chapter 1 Introduction Background Objectives Report Organization...4 Chapter 2 Literature Review USB USB Physical Interface Electrical Characteristics Signaling Coding Hosts and Devices USB Devices and Functions USB Device States USB Transfers USB Protocol Descriptors Enumeration Mass storage class Responding to Commands SCSI Commands SL811HS Architecture Overview Basic Operations with SL811HS Packaging Information XSA VHDL History and Features VHDL Terms Describing Structure Describing Behavior...33 Chapter 3 Design & Implementation Design Overview A Brief Description...36 viii

9 3.2.1 USB, Mass Storage and Host Controller Driver Character Generator VGA Controller SDRAM Controller Devices and Development Platform used Schematic and PCB of the SL811HS Host controller board 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

10

11 Chapter 1 Introduction

12 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

13 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 Device CPU or Microcontroller USB Device Controller Fig 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 USB USB Host Fig 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

14 Fig USB Flash Drives 1.2 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

15 Chapter 2 Literature Review

16 2.1 USB 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 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 USB cable plugs from left to right: series-a, series B, mini-a, and mini-b. 6

17 2.1.2 Electrical Characteristics USB Speed The USB transfers signal and power over a four-wire cable(v BUS, 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 V BUS and GND wires on each segment to deliver power to devices. V BUS 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

18 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

19 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) 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 Illustration of NRZI coding 9

20 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 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

21 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 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

22 Host Bus USB Device EP0 In [Addr][Endpoint][Direction] Addr = 2 EP0 Out EP1 In Function EP1 Out USB Device EP0 In EP0 Out Addr = 3 EP1 In EP1 Out Function EP.. In EP.. Out Fig 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

23 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 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 Power Interruption Bus Activity Reset Reset Default Bus Inactive Bus Activity Suspended Address Assigned Address Bus Inactive Bus Activity Suspended Device Deconfigured Device Configured Configuration Bus Inactive Bus Activity Suspended Fig Device State diagram 13

24 The table below describes the above mentioned states. Attached Powered Default Address Configure d Suspende d No Yes No Yes Yes No Yes Yes Yes No Yes Yes Yes Yes No -- Yes Yes Yes Yes Yes No Yes Yes Yes Table Visible Device States State Device is not attached to the USB. Other attributes are not significant. Device is attached to the USB, but is not powered. Other attributes are not significant. 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. 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. 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 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

25 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

26 acceptable. Only full- and high-speed devices can do isochronous transfers. Mass-storage devices don t use isochronous transfers 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

27 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 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 Packet Identifier 0001 OUT Token Token Data Handshake Special 1001 IN Token 0101 SOF Token 1101 SETUP Token 0011 DATA DATA DATA MDATA 0010 ACK Handshake 1010 NAK Handshake 1110 STALL Handshake 0110 NYET (No Response Yet) 1100 PREamble 1100 ERR 1000 Split 0100 Ping Table 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

28 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

29 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 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

30 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 bnumintefaces Interface Descriptor Interface Descriptor Interface Descriptor Interface Descriptor bnumendpoints bnumendpoints bnumendpoints bnumendpoints Endpoint Descriptor Endpoint Descriptor Endpoint Descriptor Endpoint Descriptor Endpoint Descriptor Endpoint Descriptor Endpoint Descriptor Endpoint Descriptor Fig 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

31 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

32 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 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

33 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

34 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 Responding to Commands Ready Command Transport (CBW) Data Out (from host) Data In (to host) Status Transport (CSW) Fig 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

35 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

36 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

37 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+ D- USB Root Hub Serial Interface Engine RAM Buffers and Control Registers nwr nrd Processor Interface ncs nrst Clock Generator D0-D7 X1 X2 Fig 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

38 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 USB-A/B Host Control Register USB-A/B Host Base Address USB-A/B Host Base Length USB-A/B Host PID, Device Endpoint (Write)/USB Status (Read) USB-A/B Host Device Address (Write)/Transfer Count (Read) Control Register1 Interrupt Enable Register Reserved Register Status Register SOF Counter LOW (Write)/HW Revision Register (Read) SOF Counter HIGH and Control Register2 Memory Buffer Table SL811 memory map Address 00h / 08h 01h / 09h 02h / 0Ah 03h / 0Bh 04h / 0Ch 05h 06h 07h 0Dh 0Eh 0Fh 10h-FFh 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

39 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 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

40 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 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

41 2.6 VHDL 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 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 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

42 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 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

43 description. Note that each of the entities G, H and I might also have a structural description. (a) (b) Fig 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

44 Chapter 3 Design & Implementation

45 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 Port 0 1 Dual Port #2 Port USB + Mass Storage Driver + Host Controller Driver Flash controller Character Generator VGA Controller SL811HS + USB Port Flash Monitor Fig Architecture of our project 35

46 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 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 Successful Enumeration No_device Invalid_device Stand_by Reset Device Detachment Fig State diagram for USB, Mass Storage and Host Controller Driver 36

47 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 FPGA SDRAM Controller Flash controller driver state machine SL 811 controller SL USB port Fig 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

48 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: 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: 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: 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: A 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

49 3.2.2 Character Generator Implementation Data Bus Address Bus RAM Host Logic Data Address Address Frame Buffer Read Data Data Charcter Map 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 Overview of Character Generator The resolution of the display is 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

50 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 h Frame Buffer 07540h 07530h Character Bitmaps 10000h 07C40h ASCII text Fig 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 0032h 0064h A1 B A2 B2 A3 B3 0284h 0252h A14 B14 50 A13 B13 Fig 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

51 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 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. 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 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 respectively 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 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

52 5V 9 VDC J1 D2 0.1 C7 D1 I n O u t 7805 U2 0.1 C5 G n d 3.3V I n O u t 317 U3 330 R9 0.1 C6 3.3V A d j C3 0.1 C4 0.1 C8 R8 POT SL811SH U1 U S B A R e c e p t a c l e V 15k R4 22 R2 15k R3 22 pf C1 22 R1 12 MHz X1 1M R6 3.3V M/S DATA- DATA+ CM CLK/X1 X2 VDD VDD1 VDD2 S L S H 11 USBGND 22 GND1 17 GND 15 nrst 16 INTRQ nwr nrd ncs ndrq ndack A0 D7 D6 D5 D4 D3 D2 D1 D V d a t a T o F P G A B o a r d 22 pf 100 C2 R7 Title USB Box HC Board Author File Document C:\Program Files\TinyCAD\tCad1.dsn Revision Date Sheets of 1 Fig Schematic 42

53 Fig PCB 43

54 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 1 st partition and searches for a specific file (plain text) in root directory. Identifies the clusters containing the file and requests for sector retrieval. 44

55 Chapter 4 Conclusion and Recommendation

56 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

57 Appendices

58

59 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 : in std_logic; rst_i : in std_logic; --host side hrom_nrd : in std_logic; hrom_data : out std_logic_vector(7 downto 0); hrom_done : out std_logic; --rom side rom_nce : out std_logic; rom_noe : out std_logic; rom_nwe : out std_logic; -- always HI rom_nrst : out std_logic; -- always HI rom_data : in std_logic_vector(7 downto 0)); end component; end package; 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, nearly_done, read); signal cur_state, next_state : rom_states :=idle; begin -- no need to write or reset rom_nwe <= HI; rom_nrst <= HI; A-1

60 -- 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, rom_data, data_r) begin hrom_done <= LO; rom_noe <= HI; timer <= 0; next_state <= cur_state; data_x <= data_r; case cur_state is when idle => if hrom_nrd = LO then timer <= 1; next_state <= read; end if; when done => hrom_done <= HI; next_state <= idle; when nearly_done => next_state <= done; when read => timer <= 6; rom_noe <= LO; data_x <= rom_data; next_state <= 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

61 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

62 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 <= dout_r; a_zero_x <= a_zero_r; timer <= 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 <= 31; SLnRST <= LO; next_state <= reset1; when reset1 => timer <= 31; next_state <= done; when done => hsldone <= HI; next_state <= idle; when write => SLnWR <= LO; SLnCS <= LO; SLd811 <= hsldin; timer <= 4; A-4

63 next_state <= write1; when write1 => SLnCS <= LO; SLd811 <= hsldin; next_state <= readwr; when read => SLnRD <= LO; SLnCS <= LO; timer <= 4; next_state <= read1; when read1 => SLnRD <= LO; SLnCS <= LO; dout_x <= SLd811; next_state <= readwr; when readwr => timer <= 5; next_state <= 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

64 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 dout end component; : out std_logic_vector(21 downto 0); -- address to memory : out std_logic_vector(15 downto 0) -- data to memory ); end package chargen_pkg; architecture arch of chargen is constant DATA_WIDTH : natural := 16; -- memory data width constant ADDR_WIDTH : natural := 22; -- 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 :integer; signal uploflag_x, uploflag_r,uplo_x,uplo_r` :std_logic; signal logic_x,logic_r : 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

65 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 <= tempdata_r; addr <= 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 <= NO; wr <= NO; addr_x <= addr_r; nextln_x <= nextln_r; state_x <= state_r; frame_x <= frame_r; BEG_FRAME_x <= BEG_FRAME_r; uflag14_x <= uflag14_r; flag_x <= flag_r; uplo_x <= uplo_r; uploflag_x <= uploflag_r; tempdatalo_x <= tempdatalo_r; tempdataup_x <= tempdataup_r; tempadd_x <= tempadd_r; letter_x <= letter_r; tempwrite_x <= tempwrite_r; i_x <= i_r; readata_x <= readata_r; donow <= NO; letter_x <= letter_r; nextaddr_x <= nextaddr_r; nextframe_x <= nextframe_r; logic_x <= logic_r; case state_r is A-7

66 when INIT => if rstt=hi then addr_x <= 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 <= NO; tempwrite_x <= din; flag_x <= 1; tempadd_x <= addr_r+1; uploflag_x <= up; uflag14_x <= 0; uplo_x <= up; i_x <= i_r+1; nextln_x <= nextln_r+1; if nextln_r = 49 then BEG_FRAME_X <= BEG_FRAME_R + 701; nextln_x <= 0; else BEG_FRAME_x <= BEG_FRAME_r + 1; end if; state_x <= decode; end if; else logic_x <= YES; state_x <= STOP; end if; when decode=> if(uploflag_r = up) then letter_x <= tempwriteup_r; elsif (uploflag_r = lo) then letter_x <= tempwritelo_r; end if; nextaddr_x <= 0; state_x <= 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

67 letter_x <= letter_r-1; state_x <= 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 <= YES; else rd <= NO; readata_x <= din; state_x <= INTreadec; end if; when INTreadec=> if (uploflag_r = up) then if (uplo_r = up) then tempdatalo_x <= readataup_r; else tempdatalo_x <= readatalo_r; end if; uploflag_x <= lo; state_x <= decode; end if; if (uploflag_r = lo) then if(uplo_r = up) then tempdataup_x <= readataup_r; else tempdataup_x <= readatalo_r; end if; addr_x <= frame_r; frame_x <= 50+frame_r; uploflag_x <= up; state_x <= fwrite; end if; when fwrite=> if done = NO then wr <= YES; else if (flag_r <= 7) then if (uplo_r = up) then uplo_x <= lo; state_x <= decode; else uplo_x <= up; flag_x <= flag_r+1; uflag14_x <= uflag14_r+1; state_x <= decode; end if; else addr_x <= tempadd_r; frame_x <= BEG_FRAME_r; state_x <= read; end if; A-9

68 end if; when STOP => if rstt = HI then rd <= NO; wr <= NO; donow <= YES; else state_x <= INIT; end if; end arch; 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; A-10

69 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

70 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

71 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 6 iconfiguration 7 bmattributes 8 bmaxpower Table B-2 Identifier for Set Configuration and Get Configuration requests. Use 01h for the first configuration. Index of string descriptor for the configuration. Set to 00h if there is no string descriptor. 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. The amount of bus power the device requires, expressed as (maximum milliamperes / 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

72 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. 6 binterfacesubclass 7 binterfaceprotocol 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. 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. 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

73 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

74 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 Table B-4 Maximum NAK rate for high-speed bulk OUT endpoints. Otherwise ignored for bulk endpoints. 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 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 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

75 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 Table B-5 blength. The number of bytes in the descriptor. bdescriptortype. The constant STRING (03h). For string descriptor zero, an array of 1 or more Language Identifier codes. For other string descriptors, a Unicode string. String Descriptor 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: A 006D 006F In the string descriptor, each Unicode character transmits LSB first: A 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

76 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 = 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 brequest Table B-6 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

77 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 04h dcbwtag 32 08h dcbwdatatransferlength 32 12h bmcbwflags 8 13h Reserved (MSB) 4 Zero bcbwlun 4 14h Reserved(MSB) 3 Zero. bcbwcblength 5 The value h, which identifies the structure as a CBW. The LSB (55h) transmits first on the bus. A value that associates this CBW with the CSW the device will send in response. The number of bytes to be transferred in the datatransport phase. 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. For devices with multiple LUNs, specifies the LUN the command block is directed to. Otherwise the value is zero. The length of the command descriptor block in the CBWCB field in bytes. Valid values are h CBWCB 128 The command block for the device to execute. 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

78 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 04h dcswtag 32 08h dcswdataresidue 32 12h bcswstatus 8 Table B-9 The value h, which identifies the structure as a CSW. The LSB (55h) transmits first on the bus. The value of the dcbwtag in a CBW received from the host. 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. 00h = command passed. 01h = command failed. 02h = phase error. Host should perform a reset recovery 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 Operation code (28h) 1 RDPROTECT DPO FUA Reserved FUA_NV Obsolete 2 5 Logical Block Address (4 bytes Big endian) 6 Reserved Group Number 7 8 Transfer Length (number of sectors to transfer, 2 bytes Big endian) 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

79 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 Operation code (25h) 1 Reserved Obsolete 2 Logical Block Address (4 bytes Big endian) 5 6 Reserved 7 8 Reserved PMI 9 Control Table B-11 READ CAPACITY (10) command format Byte/Bit Number of Logical Blocks (4 bytes Big endian) Size of a logical block in bytes (4 bytes Big endian) Table B-12 Structure of parameter data returned in response to READ CAPACITY (10) B-11

80

81 Appendix C Relevant parts of SL811HS datasheet C-1

82

83 Appendix D from XESS Corp. SDRAM and VGA Controller modules 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

84 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

85 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

86 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 = 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

87 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