Published on

IJERA (International journal of Engineering Research and Applications) is International online, ... peer reviewed journal. For more detail or submit your article, please visit www.ijera.com

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Krunal Kapadiya / International Journal of Engineering Research and Applications(IJERA) ISSN: 2248-9622 www.ijera.comVol. 3, Issue 3, May-Jun 2013, pp.551-556551 | P a g eVerification of USB 3.0 Device IP using Universal VerificationMethodologyKrunal Kapadiya(Department of Electronics & Communication Engineering, Gujarat Technological University, Ahmedabad –382424, India,)ABSTRACTVerification of integrated USB 2.0 – USB3.0 Device IP by developing device referencemodule connected to XDC side and ready to useUSB 3.0 Host Verification IP connected tophysical layer. Device reference module has beensupporting AHB-XDC in addition to Generic-XDC path.Keywords – AHB (Advanced High-PerformanceBus), AXI (Advanced Extensible Interface), IP(Intellectual Property), SV (System-Verilog), USB(Universal Serial Bus), UVM (UniversalVerification Methodology), XDC (ExtensibleDevice Controller).I. INTRODUCTIONUniversal Serial Bus (USB) is an industrystandard developed in the mid-1990s that defines thecables, connectors and communications protocolsused in a bus for connection, communication andpower supply between computers and electronicdevices. USB 3.0 utilized a dual-bus architecturethat provides backward compatibility with USB 2.0.It provides for simultaneous operation of superspeedand non-superspeed (USB 2.0 speeds) informationexchanges.Verification of integrated USB 2.0 - USB 3.0 DeviceIP by developing device reference modulesupporting Generic-XDC and AHB-XDC pathsconnect to XDC side of USB 3.0 Device IP andready to use USB 3.0 Host Verification IP atphysical layer of USB 3.0 Device IP. Verificationarchitecture includes uvm_test, uvm_env,uvm_agent, uvm_driver, uvm_scoreboard, etc.components of universal verification methodologywith SystemVerilog.II. OVERVIEW OF USBThe design architecture of USBis asymmetrical in its topology, consisting of a host,a multitude of downstream USB ports, andmultiple peripheral devices connected in a tiered-startopology. Additional USB hubs may be included inthe tiers, allowing branching into a tree structurewith up to five tier levels. A USB host mayimplement multiple host controllers and each hostcontroller may provide one or more USB ports. Ifhub device present, up to 127 devices may beconnected to a single host controller [1]. USBdevices are linked in series through hubs. One hub isknown as the root hub which is built into the hostcontroller.A physical USB device may consist of severallogical sub-devices that are referred to as devicefunctions. A single device may provide severalfunctions, for example, a webcam (video devicefunction) with a built-in microphone (audio devicefunction). This kind of device is called compositedevice. An alternative for this is compound device inwhich each logical device is assigned a distinctiveaddress by the host and all logical devices areconnected to a built-in hub to which the physicalUSB wire is connected.USB device communication is basedon pipes (logical channels). A pipe is a connectionfrom the host controller to a logical entity, found ona device, and named an endpoint. Because pipescorrespond 1-to-1 to endpoints, the terms aresometimes used interchangeably. A USB device canhave up to 32 endpoints, though USB devicesseldom have this many endpoints. An endpoint isbuilt into the USB device by the manufacturer andtherefore exists permanently, while a pipe may beopened and closed.There are two types of pipes: stream and messagepipes. A message pipe is bi-directional and is usedfor control transfers. Message pipes are typicallyused for short, simple commands to the device, and astatus response, used, for example, by the buscontrol pipe number 0. A stream pipe is a uni-directional pipe connected to a uni-directionalendpoint that transfers data usingan isochronous, interrupt, or bulk transfer: Isochronous transfers: at some guaranteed datarate (often, but not necessarily, as fast aspossible) but with possible data loss (e.g., real-time audio or video). Interrupt transfers: devices that needguaranteed quick responses (bounded latency)(e.g., pointing devices and keyboards). Bulk transfers: large sporadic transfers usingall remaining available bandwidth, but with noguarantees on bandwidth or latency (e.g., filetransfers).An endpoint of a pipe is addressable with tuple(device_address, endpoint_number) as specified in a
  2. 2. Krunal Kapadiya / International Journal of Engineering Research and Applications(IJERA) ISSN: 2248-9622 www.ijera.comVol. 3, Issue 3, May-Jun 2013, pp.551-556552 | P a g eTOKEN packet that the host sends when it wants tostart a data transfer session. If the direction of thedata transfer is from the host to the endpoint, anOUT packet (a specialization of a TOKEN packet)having the desired device address and endpointnumber is sent by the host. If the direction of thedata transfer is from the device to the host, the hostsends an IN packet instead. If the destinationendpoint is a uni-directional endpoint whosemanufacturers designated direction does not matchthe TOKEN packet (e.g., the manufacturersdesignated direction is IN while the TOKEN packetis an OUT packet), the TOKEN packet will beignored. Otherwise, it will be accepted and the datatransaction can start. A bi-directional endpoint, onthe other hand, accepts both IN and OUT packets.Endpoints are grouped into interfaces and eachinterface is associated with a single device function.An exception to this is endpoint zero, which is usedfor device configuration and which is not associatedwith any interface. A single device functioncomposed of independently controlled interfaces iscalled a composite device. A composite device onlyhas a single device address because the host onlyassigns a device address to a function.When a USB device is first connected to a USBhost, the USB device enumeration process is started.The enumeration starts by sending a reset signal tothe USB device. The data rate of the USB device isdetermined during the reset signaling. After reset,the USB devices information is read by the host andthe device is assigned a unique 7-bit address. If thedevice is supported by the host, the devicedrivers needed for communicating with the deviceare loaded and the device is set to a configured state.If the USB host is restarted, the enumeration processis repeated for all connected devices.The host controller directs traffic flow to devices, sono USB device can transfer any data on the buswithout an explicit request from the host controller.In USB 2.0, the host controller polls the bus fortraffic, usually in a round-robin fashion. Thethroughput of each USB port is determined by theslower speed of either the USB port or the USBdevice connected to the port.High-speed USB 2.0 hubs contain devices calledtransaction translators that convert between high-speed USB 2.0 buses and full and low speed buses[2]. When a high-speed USB 2.0 hub is plugged intoa high-speed USB host or hub, it will operate inhigh-speed mode. The USB hub will then either useone transaction translator per hub to create afull/low-speed bus that is routed to all full and lowspeed devices on the hub, or will use one transactiontranslator per port to create an isolated full/low-speed bus per port on the hub.Because there are two separate controllers in eachUSB 3.0 host, USB 3.0 devices will transmit andreceive at USB 3.0 data rates regardless of USB 2.0or earlier devices connected to that host. Operatingdata rates for them will be set in the legacy manner.III. RELATED WORKI proposed my solution on Universal SerialBus. Currently USB 3.0 Device IP is not capable forcertain functionality which needed at XDC side. i.e.above protocol layer. There are different ways toverify the USB 3.0 Device IP at XDC side.The USB 3.0 Device IP connected to USB 3.0 HostVIP through PIPE (USB 3.0) [3] / ULPI (USB 2.0)[4] interface. The USB 3.0 Device IP core connectedto application through back-end interfaces. Back-endinterfaces are CFG, Master TX, Slave TX, MasterRX and Slave RX.Data transfer between USB 3.0 device core andapplication occurs through following paths: Generic-XDC AHB-XDC AXI-XDCFig. 1. USB 3.0 Device IP VerificationThe verification environment should support any onetype of path (Generic-XDC/ AHB-XDC or AXI-XDC) via define switch on XDC side and shouldsupport USB 3.0 PIPE and USB 2.0 ULPI interfaceon USB 3.0 physical layer. In current architecture,Generic-XDC and AHB-XDC paths are supported.
  3. 3. Krunal Kapadiya / International Journal of Engineering Research and Applications(IJERA) ISSN: 2248-9622 www.ijera.comVol. 3, Issue 3, May-Jun 2013, pp.551-556553 | P a g eAXI-XDC path would be supported in futureversion.USB 3.0 Verification IP can be configured to workas a Host model to verify Device DUT. And theUSB 3.0 Device core connected to applicationthrough Generic-XDC/ AHB-XDC/ AXI-XDC path.The USB 3.0 Host VIP generates the data/ transfertraffic to USB 3.0 Device DUT. Scoreboard is a partof usb3dev_env, ensures the data integrity betweenthe USB Host VIP environment and USB Controlenvironment through USB 3.0 Device DUT for bothtransmit and receive paths.USB 3.0 VIP configured as active host and passivedevice and XDC environment instantiated in theusb3dev_env, which instantiated in uvm_test. In topmodule, USB 3.0 Device IP connected as DUT andrun_test() method would be called [3].Fig. 2. Verification Architecture using UVMThe USB 3.0 VIP connected to USB 3.0 DeviceDUT through USB 3.0 PIPE/ USB 2.0 ULPIinterface and USB 3.0 Device DUT connected toGeneric-XDC environment or AHB-XDCenvironment or AXI-XDC environment throughGeneric-XDC or AHB-XDC interface or AXI-XDCenvironment respectively. The memory managerwould be instantiated and used by USB Controlenvironment.In top module, following interfaces are instantiated: USB SS interfaces: Active Host and PassiveDevice Common interface Generic-XDC interfaces: XDC-CFG, XDC-Master, XDC-Slave AHB-XDC interfaces: AHB-CFG, AHB-Master-TX, AHB-Master-RX, AHB-Slave-TXand AHB-Slave-RXIn top module, the AHB Add-ON and AXI Add-ONmodule would connect XDC interface to AHBinterface and AXI interface respectively. The topmodule is having the functionality to multiplexbetween the Generic-XDC, AHB-XDC and AXI-XDC paths. The XDC interface directly connectedfrom USB 3.0 Device DUT to XDC environment.The AMBA-AHB interface connected from USB 3.0Device DUT to AHB environment through AHB-XDC Add-ON. The AMBA-AXI interfaceconnected from Device DUT to AXI environmentthrough AXI-XDC Add-ON.XDC Environment works as follows: Interrupt request (IRQ) signal sent from USB3.0 Device DUT. Device initialization configuration registerswould be written. Memory would be allocated by memorymanager through backdoor access in case ofbulk-IN transfer. Endpoint address mapping would be donethrough memory manager. Host would send the burst length for bulk-OUTtransfer to device. Bulk-OUT from host would transfer to mappedendpoint of the device.After completing transfers, the transfers onPIPE/ULPI or XDC interface would be sent toscoreboard to compare with expected transfers.After the allocation of memory as per endpointsaddress map, burst-length would be provided totransfer the data. For big data, the transfer would bedone in segments for which memory pre-allocationwould be done. e.g. 4 GB data transfer could bedone in segments of 112KB data.The XDC environment is the verificationcomponent, which interfaces from an XDC of USB3.0 Device IP to the application. The XDCenvironment contains the functionality to read datafrom and write data to registers located at DeviceDUT through Generic-XDC path. When the USB3.0 VIP connected as host, first of all it initiates thedefault enumeration process. The process ofidentifying and configuring a USB device is referredto as USB device enumeration. At the end ofenumeration process, the device is ready to do anytransfer with the device as per the test-cases writtenby user.The usb3dev_env environment is having the instanceof XDC environment, USB Control environment andUSB Scoreboard.
  4. 4. Krunal Kapadiya / International Journal of Engineering Research and Applications(IJERA) ISSN: 2248-9622 www.ijera.comVol. 3, Issue 3, May-Jun 2013, pp.551-556554 | P a g eThe CFG, Master-TX, Master-RX, Slave-TX, Slave-RX and Common interfaces passed throughassign_vi() method of XDC environment and USBControl environment in assign_vi() method ofusb3dev_env.The mailboxes regarding request and responsepackets of CFG, Slave-TX and Slave-RX insideUSB Control Xactor and CFG driver, Slave-TXdriver and Slave-RX driver connected inusb3dev_env environment.3.1. Generic-XDC EnvironmentThe XDC environment contains the functionality toread/write on XDC-CFG, XDC-Master and XDC-Slave interfaces.Fig. 3. Generic-XDC EnvironmentThe XDC-agent and XDC-driver regarding XDC-CFG, XDC-Master-TX, XDC-Master-RX, XDC-Slave-TX and XDC-Slave-RX instantiated. TheGeneric-XDC interfaces passed hierarchicallythrough assign_vi() method from uvm_test tousb3dev_env to environment to respective agent torespective driver.The XDC-CFG driver gets the XDC-CFG packetfrom request mailbox and drive accordingly onXDC-CFG interface. In case of read, it also puts theXDC-CFG packet on response mailbox after readingdata.The XDC-Master-TX driver drives the signal onXDC-Master-TX interface with data read frommemory in top module.The XDC-Master-RX driver samples the signal onXDC-Master-RX interface and writes the data tomemory in top module.The XDC-Slave-TX driver gets the XDC-Slave-TXpacket from request mailbox and drive accordinglyon XDC-Slave-TX interface.The XDC-Slave-RX driver gets the XDC-Slave-RXpacket from request mailbox and drive accordinglyon XDC-Slave-RX interface. It put the XDC-Slave-RX packet on response mailbox after reading data.Fig. 4. Waveform of read/write on XDC-CFGinterface and command on XDC-Slave-TXinterface3.2. AHB-XDC EnvironmentThe AHB-XDC environment contains thefunctionality to read/write on AHB-CFG, AHB-Master-TX, AHB-Master-RX, AHB-Slave-TX andAHB-Slave-RX interfaces.The AHB-Agent and AHB-driver regarding AHB-CFG, AHB-Master-TX, AHB-Master-RX, AHB-Slave-TX and AHB-Slave-RX instantiated. Therespective AHB-XDC interfaces passed usinguvm_config_db #(virtual ahb_if)::set() method torespective AHB-XDC driver.The AHB-Master-BFM instantiated in driverregarding AHB-CFG, AHB-Slave-TX and AHB-Slave-RX. The AHB-Slave-BFM instantiated indriver regarding AHB-Master-TX and AHB-Master-Rx.The AHB-CFG driver gets the XDC-CFG packetfrom request mailbox from USB Control Xactor. Itcalls AHB read/write method as per read/writepacket, which will convert XDC-CFG packet toAHB-CFG packet. Those AHB read/write methodputs converted AHB-CFG packet to mailbox ofAHB-CFG BFM.The AHB-Master-TX driver gets the address andsize of data from request mailbox in AHB-Master-TX BFM. It reads the data from the memory as peraddress and puts data on request mailbox in AHB-Master-TX BFM, which drives the data on signalson AHB-Master-TX interface.The AHB-Master-RX driver gets the address, dataand size of data from request mailbox on AHB-Master-RX BFM, which samples the data on signals
  5. 5. Krunal Kapadiya / International Journal of Engineering Research and Applications(IJERA) ISSN: 2248-9622 www.ijera.comVol. 3, Issue 3, May-Jun 2013, pp.551-556555 | P a g eon AHB-Master-RX interface. It writes the data tothe memory as per address.Fig. 5. AHB-XDC EnvironmentThe AHB-Slave-TX driver gets the XDC-Slave-TXpacket from request mailbox from USB ControlXactor. It calls AHB write method, which convertXDC-Slave-TX packet to AHB-Slave-TX packet.That AHB write method puts converted AHB-Slave-TX packet to mailbox of AHB-Slave-TX BFM.The AHB-Slave-RX driver gets the XDC-Slave-RXpacket from request mailbox from USB ControlXactor. It calls AHB read method, which convertXDC-Slave-RX packet to AHB-Slave-RX packet.That AHB read method puts converted AHB-Slave-RX packet to mailbox of AHB-Slave-RX BFM.Fig. 6. Waveform of read/write on AHB-CFG interfaceand command on AHB-Slave-TX interface3.3. USB Control EnvironmentThe agent and driver regarding USB device controlinstantiated. The mailboxes and packets regardingXDC-CFG, XDC-Slave-TX and XDC-Slave-RXalso instantiated.The common interface passed hierarchically throughassign_vi() method from uvm_test to usb3dev_envto USB control environment to USB control agent toUSB control driver.The device in/out analysis port regarding USBscoreboard packet connected to analysisimplementation port of USB scoreboard. Theinstantiated memory manager used to allocatememory as per starting address and memory size.The USB control Xactor read or initialize allcommon registers. Then wait for IRQ signal to begenerated from DUT. If IRQ received, read registersand check special type and store it on queue. Thenprocess further if no other task is pending.The methods to send packet to read/write on XDC-CFG, XDC-Slave-TX and XDC-Slave-RX interfacesare putting or getting on respective mailboxes.The interrupt handler takes care of IRQ handling andDMA request to master and event request to slave.3.4. USB ScoreboardThe USB scoreboard used to compare the transfersmade by USB control environment and USB HostVerification environment.As analysis implementation ports for Host/DeviceIn/Out instantiated, write() method for each analysisimplementation port gets implemented.While bulk-out transfer, USB protocol-data packetreceived from USB host verification environmentwritten into write() method implemented for host-out, where extracted scoreboard packet packed tohost-out queue [5]. And scoreboard packet receivedfrom USB control xactor written into device-inqueue of write() method implemented for device-in.While bulk-in transfer, USB protocol-data packetreceived at host verification environment writteninto write() method implemented for host-in, whereextracted scoreboard packet packed to host-inqueue. And scoreboard packet received from USBcontrol xactor written into device-out queue ofwrite() method implemented for device-out.After getting all scoreboard packets in the formqueue, run_phase() method [6] having scoreboardIN/OUT methods. Scoreboard IN method comparesthe data of scoreboard packet for each sequencenumber from host-in queue and device-out queue.Scoreboard OUT method compares the data ofscoreboard packet for each sequence number fromhost-out queue and device-in queue.In report_phase() method, errors will be fired andtest-case fails in case of mismatch of payload dataand/or payload size. Otherwise test-case passes incase of correct match of payload data and payloadsize.
  6. 6. Krunal Kapadiya / International Journal of Engineering Research and Applications(IJERA) ISSN: 2248-9622 www.ijera.comVol. 3, Issue 3, May-Jun 2013, pp.551-556556 | P a g e3.5. Test-case Simulation Flow During build_phase() method, setting numberof active/passive host/device, endpoints,interfaces, configuration, etc. Setting SCSIcommand as default_sequence of protocolsequencer of host_agent. Updating EP IN/OUTtable. During connect_phase() method, passing theinterface declared in top to usb3dev_env usingassign_vi() method or uvm_config_db #()::set()method. During end_of_elaboration_phase() method,configuring interface and configurationdescriptor, setting BULK/INT/ISO IN/OUTendpoint descriptors. During run_phase() method, requesting to 1)set device address 2) get device descriptor 3)get configuration descriptor 4) setconfiguration no. 1. Executing BULK/INT/ISOIN/OUT transfers. Set SCSI write command with packet size toSCSI sequence. Allocates endpoint OUT memory with 32bytes, in which it allocates the memory usingmemory allocation method memory manager ofcontrol Xactor, which returns the memory startaddress and total memory size. Bulk-OUT transfer with 32 bytes, in which itset transfer and executes bulk transfer fromhost’s protocol BFM. Wait for transfer to complete from XDC, inwhich it inserts delay till memory size reducesto zero. Send scoreboard packet to scoreboard tocompare, in which it call method of controlXactor, which forms the scoreboard packet andwrite in TLM analysis port connected toscoreboard. If command with proper packet size has beentransferred, allocates endpoint OUT memorywith packet size, in which it allocates thememory using memory allocation methodmemory manager of control Xactor, whichreturns the memory start address and totalmemory size. Bulk-OUT transfer with packet size, in which itset transfer and executes bulk transfer fromhost’s protocol BFM. Wait for transfer to complete from XDC, inwhich it inserts delay till memory size reducesto zero. Send scoreboard packet to scoreboard tocompare, in which it call method of controlXactor, which forms the scoreboard packet andwrite in TLM analysis port connected toscoreboard.IV. CONCLUSIONBy verifying the USB 3.0 Device IP, onegets in-depth protocol knowledge of USB 3.0specification. As DUT with integrated AHB-XDCadd-on, one also gets the in-depth protocolknowledge of AMBA AHB specification.Verification using randomization techniquesupported by SystemVerilog and UniversalVerification Methodology helps the USB 3.0 DeviceIP becomes more robust and stable as per USB 3.0specification. By developing environment fromscratch to verify the USB 3.0 Device IP, one gets theexposure to SystemVerilog and UniversalVerification Methodology, which is de-factostandard of verification language and methodologyrespectively.As Generic-XDC provides byte-enable combinationsincluding single byte to eight bytes and AHB-XDCprovides byte-enable combinations including singlebyte, half-word, word and double-word [7], AHB-XDC simulation has overhead over Generic-XDCsimulations.V. ACKNOWLEDGMENTSI am grateful to Mr. Umesh Patel (Director– ASIC) and Mr. Manish Desai (Sr. MemberTechnical Staff) of Sibridge Technologies,Ahmedabad for providing guidelines andencouragement. I feel motivated and encouragedevery time I attend their meeting.REFERENCES[1] Universal Serial Bus 3.0 Specification, June 2011.[2] Universal Serial Bus Specification Revision 2.0,April 2000.[3] PHY Interface for the PCI Express and USB 3.0Architectures (PIPE), April 2009.[4] UTMI Low Pin Interface (ULPI), October 2009.[5] IEEE 1800-2012 Standard for SystemVerilog –LRM.[6] Universal Verification Methodology (UVM) 1.1User’s Guide, May 2011.[7] AMBA Specification 2.0, May 1999.