Project 4: Pseudo USB Simulation Introduction to UNIVERSAL SERIAL BUS (USB) STANDARD

Transcription

1 Project 4: Pseudo USB Simulation Introduction to UNIVERSAL SERIAL BUS (USB) STANDARD The Universal Serial Bus is a fast, bi-directional, low cost, dynamically attachable serial interface. The motivation for the Universal Serial Bus comes from these interrelated considerations. The Universal Serial Bus provides a ubiquitous link that can be used across a wide range of PC to telephone interconnects. The USB supports transfer rates up to 12Mbs for the real-time data of voice, audio, and compressed video. The USB offers protocol flexibility for mixed-mode data transfers and asynchronous messaging. The USB simplifies I/O interfaces by allowing plug and play of keyboard, mouse, and joystick. Self identifying of peripherals and automatic mapping of function to driver. The USB supports up to 127 physical devices and allows the proliferation of peripherals such as telephone/fax/modem adapters, answering machines, scanners, PDA s, keyboards, mice, etc. Signal integrity is enhanced by using differential drivers, receivers and shielding. CRC protection over control and data fields. Error handling/fault recovery mechanism built into protocol. Self-recovery in protocol, using time-outs for lost or broken packets. Support for identification of faulty devices. The range of data traffic workloads that can be serviced over a Universal Serial Bus is shown below. As can be seen, a 12Mbs bus comprehends the mid-speed and low-speed data ranges. Bus Topology Overview The USB is a cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible peripherals. The attached peripherals share USB bandwidth through a host scheduled token based protocol. The bus allows peripherals to be attached, configured, used, and detached while the host and other peripherals are in operation. This is referred to as dynamic (or hot) attachment and removal.

2 The Universal Serial Bus connects USB devices with the USB host. The USB physical interconnect is a tiered star topology. A hub is at the center of each star. Each wire segment is a point-to-point connection between the host and a hub or function, or a hub connected to another hub or function. There is only one host in any USB system. The USB interface to the host computer system is referred to as the host controller. A root hub is integrated within the host system to provide one or more attachment points. USB Hubs and Functions Device Descriptions Two major divisions of device classes exist: hubs and functions. Only hubs have the ability to provide additional USB attachment Points. Functions provide additional capabilities to the host. Figure 3 shows a typical hub. Attachment points are referred to as ports. Each hub converts a single attachment point into multiple attachment points. The upstream port of a hub connects the hub towards the host. Each of the other downstream ports of a hub allows connection to another hub or function. Hubs can detect attach and detach at each downstream port and enable the distribution of power to downstream devices. Each downstream port can be individually enabled and configured as either full or low speed. The hub isolates low speed ports from full speed signaling. A function is a USB device that is able to transmit or receive data or control information over the bus. A function is typically implemented as a separate peripheral device with a cable that plugs into a port on a hub. Before being used, a function must be configured by the host. This configuration includes allocating USB bandwidth and selecting function specific configuration options.

3 Bus Protocol All bus transactions involve the transmission of up to three packets. Each transaction begins when the host controller, on a scheduled basis, sends a USB packet describing the type and direction of transaction, the USB device address, and endpoint number. This packet is referred to as the Token Packet. The USB device that is addressed selects itself by decoding the appropriate address fields. In a given transaction, data is transferred either from the host to a device or from a device to the host. The direction of data transfer is specified in the token packet. The source of the transaction then sends a Data Packet or indicates it has no data to transfer. The destination in general responds with a Handshake Packet indicating whether the transfer was successful. The USB data transfer model between a source or a destination on the host and an endpoint on a device is referred to as a pipe. Data Transfer Format Data are transferred in packets. Packets will have: Start of Packet Sync Pattern (8 bits, 7 zeros + 1 one) Packet ID (PID) identifies type of packet. 8 bits total, but only 4 unique bits Address field - 11 bits. 7 bits for USB device (so 128 possible USB devices on bus, host is always address 0), 4 bits for internal use by USB device. Frame number field (11 bits); incremented by host Data Payload (up to 1023 bytes for high-speed connection) CRC bits: 5 bits for address field, and 16 bits for data field

4 EOP strobe: single ended 0 (160ns-175 ns for high speed, 1.25 us to 1.75 us for high speed) Not all packets sent over USB bus have all of these fields (always have SOP, EOP and PID). Packet without data field is a token packet. The table describes the packet type. Transaction Formats Packet transaction format varies depending on the endpoint type. There are four endpoint types: bulk, control, interrupt, and isochronous. Our project will only concern with bull transaction format. Bulk transactions use a three-phase transaction consisting of token, data, and handshake packets as shown in Figure below. The data phase may be replaced with a handshake resulting in a two-phase transaction in which no data is transmitted. When the host wishes to receive bulk data, it issues an IN token. The function endpoint responds by returning either a DATA packet or, should it be unable to return data, a NAK or STALL handshake. A NAK indicates that the function is temporarily unable to return data, while a STALL indicates that the endpoint is permanently stalled and requires host software intervention. If the host receives a valid data packet, it responds with an ACK handshake. If the host detects an error while receiving data, it returns no handshake packet to the function. When the host wishes to transmit bulk data, it first issues an OUT token packet followed by a data packet. The function then returns one of three handshakes. ACK indicates that the data packet was received without errors and informs the host that that it may send the next packet in the sequence. NAK indicates that the data was received without error but that the host should resend the data because the function was in a temporary condition

5 preventing it from accepting the data at this time (e.g., buffer full). If the endpoint was stalled, STALL is returned to indicate that the host should not retry the transmission because there is an error condition on the function. If the data packet was received with a CRC or bit stuff error, no handshake is returned. Project Description The goal of this project is to write a VHDL model for a system that is somewhat similar in nature to USB (Universal Serial Bus) standard. Our VHDL Models will present a VERY abstract view of a USB network Pseudo USB simulation Features: Totally event driven, i.e., no global clock Communication is bi-directional Network structure is a tree structure that consists of a root node, hubs, and endpoints Data type is a resolved data type using a record structure Pseudo USB Models root.vhd: models the root node hub.vhd : models a hub, has an upstream port and 2 downstream ports endpoint.vhd: models an endpoint Data packet will contain a packet ID, an address (destination), and a payload that is an 80- character string. Packet ID identify its types of POUT, PIN, PACK, ERR, NONE.

6 Pseudo USB Protocol Root: Root initiates all transactions. Root will either send a PIN or POUT packet with a destination (address) field set. The architecture of Root is provided as root_a.vhd. The root_a.vhd illustrates describe the behavior of the root. In order to complete project- 4, you need to download root_a.vhd code and try your best to understand what the root is doing. The root_a.vhd code does the following: Loops sending POUT packets to addresses 1 to 32. If a PACK is received, know that there is an ENDPOINT at that address Prints out data from ACK packet to screen

7 Sends a PIN packet to the endpoint with the data from the PACK packet modified Send a POUT packet to the endpoint to verify that the endpoint stored the new data, then wait for the PACK response and print returned data to console. HUB does the following: On downstream ports, any packets of type PACK or NONE should be echoed to upstream port. PACK packet can only come from an endpoint On upstream port, any packet that is not a PACK packet should be echoed to both downstream ports Use HUBDELAY generic for delay time through hub. Endpoint: At endpoint, if packet destination field matches endpoint address, endpoint process packet else ignore packet. If POUT packet is received, endpoint responds with ACK packet and places local data (initially set to MANUF string) in ACK packet. If PIN packet is received, endpoint copies packet payload ( data field) into local data, and responds with ACK packet; the data field of this ACK packet is a don t care. Releasing the bus (root & hub & endpoint): To simulate releasing the bus, after either a POUT, PIN, or PACK packet is sent, send a packet of type NONE to release the bus Packets Resolve: A signal between a hub and an endpoint/root will only have 2 drivers. To resolve the two drivers, look at the packet type. A packet type of NONE resolved with POUT/PIN/PACK will return POUT/PIN/PACK A packet type of NONE resolved with NONE will return NONE A packet type of POUT/PIN/PACK resolved with POUT/PIN/PACK will return a packet of type ERR (this should not happen if it does, then you have a packet collision which should never happen). What do you need to do? Complete the resolution function for pkt data type Complete architectures for ENDPOINT and HUB Test your design with tb_a.vhd and tb_b.vhd I may test your codes with other configurations! Sample simulation result with tb_b.vhd should be like below: # Found Endpoint 3, data is Cypress Mouse # Modifying Endpoint # Modified Endpoint data: Cypress MouseFOUND # Found Endpoint 5, data is Xtreme Speakers # Modifying Endpoint # Modified Endpoint data: Xtreme SpeakersFOUND # Found Endpoint 10, data is MS Natural Keyboard

8 # Modifying Endpoint # Modified Endpoint data: MS Natural KeyboardFOUND # Found Endpoint 25, data is JoyPad # Modifying Endpoint # Modified Endpoint data: JoyPadFOUND # Finished Scan for Endpoints Project Report: Your report must contain the VHDL codes usbpkg.vhd, hub.vhd, endpoint.vhd, and the results of your simulations as seen on the ModelSim transcript window. The VHDL codes must be commented wherever necessary. You do not need to synthesize your VHDL codes. Place a printout of your project report in Dr. Song s mailbox by 5:00 pm on November 29, In addition, the codes to [email protected] by 5:00 pm on November 29, Do not send any attachments. Paste and format the source codes on the body of the with the subject line as ECE x81: Project 4, <last names of the project group members>.