Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIES Vol No. 8, Issue No.

1, 049 - 053

AN IMPROVISED METHODOLOGY FOR HARDWARE-SOFTWARE COVERIFICATION OF USB SUBSYSTEM

Ms Priyamvada Deshpande, Dr. Ambedkar Institute of Technology, Bangalore, India,

priyamvada.vd@gmail.com

Dr. M.K. Srivas, Texas Instruments, Bangalore, India,

mksrivas@ti.com

Mrs Akalpita Kulkarni, Dr. Amdedkar Institute of Technology, Bangalore, India,

akalpita_gd@yahoo.com

Keywords: SoC, IP sub-system, USB, TB environment.

I.

INTRODUCTION

Verification of an SoC can be done at different levels: IP and IP sub-system, chip-level, and HW/SW co verification of SoC[2]. This paper describes difficulties involved in verifying IPs at lower level by taking USB IP subsystem as an example. It is very much cost effective to carry out the verification at lower levels rather than doing at SoC level, which requires lot of effort, cost and time. However doing verification at IP level alone has certain disadvantages such as test bench complexity, inaccuracy and lack of stress testing due to limitations of the test bench. On the other hand verification carried out at SoC level consumes more time, effort and cost. By the time a bug has been detected, the chip might have gone for fabrication. Verifying an IP has many requirements to develop the test bench. It requires processor, Bus Functional Modules (BFMs), Interfaces, Transaction generator, Monitor and Scoreboard. Verification at It has disadvantages Considering the disadvantages at each level,
ISSN: 2230-7818

IJ

With the increase in the complexity of the electronic devices, functional verification has become major bottleneck in the design and verification [1]. Hence among various phases in a SoC development cycle, verification is a crucial phase. A general agreement is that verification consumes 60-70% of a SoC development cycle. With the huge capacity of silicon technology, verification has become more important compared to the past [2].

@ 2011 http://www.ijaest.iserp.org. All rights Reserved.

ES
A. Bus Topology B. Interface

Abstract: The overall cost of verification can be reduced and quality can be improved if system and software(SW) scenario testing can be done earlier in the System On Chip (SoC) development cycle, for example, at Intellectual Property (IP) and sub-system levels. This is especially so for IP sub-systems such as Universal Serial Bus (USB) that is driven by embedded SW. This paper describes the challenges involved in building a test-bench (TB) for effective stress testing of USB at IP level and one way of building a test-bench (TB) environment with several infrastructure components including a software layer, which is essential for effective stress testing of the IP. We also describe various complex scenarios that can be implemented in the test bench for the effective stress testing of USB IP subsystem.

Section II gives a brief description of USB 2.0 and section III describes the challenges involved in USB verification. Section IV describes sub-system level test-bench built for verification of USB. Section V gives the results and extensions made to the testbench. Section VI gives the conclusion and future works. II. USB SUB SYTEM

USB is a serial bus which helps in data transfer between a host and several devices. The attached peripherals share USB bandwidth through a host scheduled, token based protocol. Peripherals can be attached, configured and detached while host and other peripherals are in operation. USB 2.0 is an improvised version of USB 1.1. High speed mode and two additional protocols: Session Request Protocol (SRP) and Host Negotiation Protocol (HNP) are the key features of USB 2.0. This section describes the features of USB 2.0.

It has a tiered star topology where a hub is at the center of each star. There can be point-to-point communication between a hub and a device or between a hub and a hub. It can support a maximum of 127 devices and 7 tiers can be included. There can be only one host in a USB subsystem. The USB interface in the host system is called Host controller. USB devices can be one of the following: hub- which provides an additional attachment points to the USB and functionswhich provide capabilities to the system such as joystick or speakers[4].

effective verification can be done at IP level by HW/SW co-verification. This paper describes a testbench in which verification of USB IP can be done at subsystem level. The proposed method will describe the test bench architecture and explain working of USB by taking normal data transfer between a host and a device as an example. This paper also includes details on how the basic test bench can be extended to support complex scenarios, its advantages and its future scopes.

Page 49

Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIES Vol No. 8, Issue No. 1, 049 - 053

USB interface can be explained with electrical and mechanical interfaces. The signal and power are transferred over a four wire cable consisting of: VDD, D+, D- and GND. Packets are transferred over D+ and D- wires whereas VDD and GND deliver power to the devices. USB 2.0 supports three data rates: High speed (480 Mbps), Full speed (12 Mbps) and Low speed (1.5 Mbps). USB physical topology consists of connecting the downstream hub port to the upstream port of another hub or to a device. All devices have an upstream connection. Upstream and downstream connectors are not mechanically interchangeable. C. Bus Protocol USB is a polled bus and host controller initiates all transactions. Most bus transactions involve transmission of three packets. They are token packet, data packet and handshake packet. Each transaction is initiated by host controller. On scheduled basis, it sends a packet describing the type and direction of transfer, device address and end point number. This packet is referred as token packet. Device then selects itself by decoding the appropriate address fields. Data is transferred either from host to device or from a device to host. The direction of data transfer is specified in the token packet. The source of the transaction then sends the data packet or indicates it has no data packets to send. The destination responds with a handshake packet to indicate whether the transaction was successful. D. Data Flow Types

but reliable delivery of data. These transfers include error detection and retransmission of data. Isochronous Transfers: These occupy a prenegotiated amount of USB bandwidth. These usually contain time sensitive information, but they do not include error detection and retransmission. E. Operation This section describes the operation of USB for normal data transfer between a host and a device. Always a session is started by USB host. It waits for VBUS signals (avalid and vbusvalid) to rise and enters into full speed mode.

IJ

ISSN: 2230-7818

USB supports data and control exchange between host and the device as a set of either unidirectional or bi-directional pipes. USB data transfer takes place between the host software and a particular endpoint on a USB device. End points can be described as sources or sinks of data. Endpoints occur at the end of the USB communication channel. USB 2.0 supports 16 end points. All devices must support endpoint zero. This endpoint receives all of the device control and status requests during enumeration and throughout the duration when the device is operational on the bus. Endpoints 1-15 are used for data transfers. USB architecture supports four basic types of data transfers: Control Transfers: These are used to configure a device at the time of attachment and for other device specific purposes. Bulk Transfers: These are generated or consumed in relatively large and bursty quantities. Bulk data rate is sequential. Reliable data exchange is ensured by using error detection and invoking a limited number of retries. Interrupt Transfers: These are used for timely

@ 2011 http://www.ijaest.iserp.org. All rights Reserved.

ES

III. CHALLENGES IN USB VERIFICATION Verification of USB can be done at IP level, IP subsystem level and at SoC level. A. IP level Verification At IP level verification (usually at RTL level), USB IP will be provided by the IP vendors. It is the responsibility of the verification engineer to build the test-bench for the verification. The block diagram of a test-bench for verification of USB at IP level is given in figure 1[3]. A processor is required to configure USB for data transfers and for USB to operate in various modes. To store data and instructions, data and instruction memory associated with the processor are required. Interconnect such as OCP (Open Core Protocol) is required to connect the memories and processor with the USB. Interconnects come as separate IPs. So they have to be integrated into the environment. A USB host can be verified only when there is a device from or to
Page 50

It then waits for device connection and generates connect interrupt when device gets connected.

Device in the meantime waits to see its connection registered on linestate. Once its connection is registered, it enters into full speed mode. Host then starts sending reset to the device and enters into high speed mode. Host starts high speed mode handshake by sending chirps J (linestate 01) and K (linestate -10). After the handshake, device enters into high speed mode and generates reset interrupt. After the above configuration, endpoints are enabled and packets are transferred between the enabled endpoints.

Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIES Vol No. 8, Issue No. 1, 049 - 053

which data transfers happen. We need to model a device using BFMs. The data which is to be transferred needs to be generated by a traffic generator. Hence we require a traffic generator and associated software, which can generate the traffic for stress testing of USB. A transceiver is required to transfer the data between the host and the device. This transceiver must also to be integrated in the test-bench. Scoreboard/Checkboard is required to compare the received data and the actual transmitted data. Some peripherals can be turned off, when they are not in use for reducing the power consumption. This requires a power management block, which turns off the clocks of the peripherals when they are not in use. A power management block has to be developed and integrated into the environment.

B. IP Subsystem level Verification IP subsystem level verification is in between IP level and SoC level verification. The test-bench consists of all the required components for verification, but it will not be as large as in case of SoC level verification. A test-bench for verification of USB at subsystem level is described in next section. C. SoC level Verification USB IP can be verified at SoC level as well. In this level of verification, test-bench will be consisting of all the required components mentioned in figure 1, but it will be having an overhead of other IPs, which is not required for USB verification. Thus the effort, time and cost of verification increase. Also, if a bug is detected at this level, much efforts are required for debugging.

Figure 1: IP level test-bench

IJ
ISSN: 2230-7818

The test-bench shown in above figure becomes complex than the USB RTL. The development of test-bench itself requires lot of efforts. At IP level, this type of test-bench becomes very complex and hence, the test-bench will be simplified. This limits the stress testing of USB IP. The simplified test-bench will not be accurate, since it will be consisting of BFMs and E Verification Components (eVCs). The stress testing cannot be done for longer and complex scenarios. Also, it cannot be ported for hardware acceleration, since the BFMs and eVCs used in the test-bench are not in RTL. Effective stress testing of USB not only involves verification of packet transfers, but also verification of complex scenarios such as SRP, HNP, Suspend-resume and Remote wakeup. It also involves variation of different parameters such as number of endpoints, number of packets, direction of transfer, timing of different events and payload size. Test-case generation should be randomized with the packet generator and variation of parameters also should be randomized. This makes the test-bench much more complex and without testing these features, verification of USB is incomplete.

A simple subsystem level test-bench for effective stress testing of USB IP is shown in figure 2. Figure 3 shows the USB packet generation tool. This test-bench consists of a processor. Processor has data and instruction memory associated with it. This processor is memory mapped internally with the USB registers. Thus we can program these registers for configuring USB. Processor and memories are connected to USB with interconnects such as OCP. The transceiver which can be on-chip or off-chip enables data transfer between host and device. The transceiver, interconnect, USB and processor are all different IPs at RTL.

@ 2011 http://www.ijaest.iserp.org. All rights Reserved.

ES

The test-bench also has USB packet generation tool, which generates randomized test-cases for different scenarios. The software contains a constraint file, which indicates the weights associated with each parameters such as number of endpoints, number of packets, direction of transmission, payload size and protocol type. These actual test-cases and constraint files are represented in E language. The tool generates complementary C and H files for Host and Device with the help of Specman and the E files. C file consists of actual test-case and H file will include different parameters. C file also includes scoreboard which compares the actual result with the expected
Page 51

IV. SUBSYTEM LEVEL TESTBENCH

Figure 2: Subsystem level test-bench

Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIES Vol No. 8, Issue No. 1, 049 - 053

result. Generated C and H files will be compiled. Precompiled RTL will be simulated with C and H files as inputs.

interrupt. Now, host enters into high speed mode and sends reset signaling to device. After high speed handshake, device enters into high speed mode and generates reset interrupt. Then data packets are transferred between host and device. C test-case should be modified for configuration of registers to request for a session. The test case should monitor for various interrupts such as session request, connect and reset. The test-bench RTL has to be modified to force VBUS signals according to the required conditions. The packet generation tool should randomize additional parameters such as different timing at which VBUS signals can be forced. The tool should generate a separate test-case for SRP and for variation of each parameter. B. Host Negotiation Protocol

Figure 3: USB packet generation tool

V. EXTENSIONS TO THE TESTBENCH AND RESULTS

IJ
ISSN: 2230-7818

The subsystem level test-bench described in previous section supports only basic scenarios. Certain extensions have to be made to support for complex scenarios like variation of different parameters, SRP, HNP and suspend-resume scenarios. In this section we will describe about extensions to be made for the test bench to support the features of USB OTG (On The Go), SRP and HNP.

When a session is started, B-device enters into peripheral mode. However it can request to become a host by configuring the register bits. When A-Device next enters into suspend mode, it will generate host request interrupt and then it gets disconnected. BDevice detects this, generates disconnect interrupt and enters into host mode. A-Device gets connected now as peripheral and B-Device detects this and generates connect interrupt. Now B-device enters into high speed mode and sends reset signaling to the A-Device. After high speed handshake, A-device will enter into high speed mode and generates reset interrupt. Then the data packets are transferred between A-Device and BDevice. Configurations of registers for host request, monitoring various interrupts requires changes in C test-case. The tool should generate different test-case for HNP and for variation of each parameter. It should also randomize the generation of test-cases for normal data transfers, SRP, HNP and variation of parameters. VI. CONCLUSION Above described subsystem level test-bench can be used for effective stress testing of USB IP. The test-bench has all the requirements for verification of USB. Since it does not contain any BFMs, this test-bench is accurate. It does not have overhead as in case of SoC level verification. Hence, the cost, effort and time of verification are reduced. It can be ported for hardware acceleration, since it has all the components at RTL. The packet generation tool generates and randomizes different test-cases for different scenarios and also varies parameters. Hence effective stress testing of USB for longer duration is done. This test-bench can also be effectively used for quick reproduction of various bugs. It is also very effective in detecting the bugs. Detection of bugs at this level is very useful, as they can be debugged
Page 52

A. Session Request Protocol

To conserve power, USB OTG allows VBUS to only be powered up when required and to be turned off when the bus is idle.. A host always starts a session, enters into Host mode and turns on VBUS. When a USB OTG device requires starting a session, it will request host to start it.

USB OTG device can request for a session by configuring the register bits. Host detects this and generates session request interrupt. Device waits until the VBUS lines are discharged. Once both host and device are in session end condition, host starts the session, since device had requested for start of a session. Then host makes VBUS signals high after charging and driving of VBUS. Then device gets connected, host identifies this and generates connect

@ 2011 http://www.ijaest.iserp.org. All rights Reserved.

ES

According to the protocol, always host acts as A-Device and device acts as B-Device. A prominent feature of USB OTG is that a B-Device can request the control of bus and become an A-Device.

Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIES Vol No. 8, Issue No. 1, 049 - 053

quickly and easily. Now, the test-bench has been extended to support SRP and HNP, in future it can be extended to support suspend resume scenarios. A power management module for turning off the devices when they are idle can be integrated in the test-bench. This helps in lowering the power consumption. The testbench can also be extended to support different configurations. This can be extended to support not only USB OTG, but also USB HS (High speed) HOST and TLL (Transceiver Less Logic). In USB HS HOST configuration, Save-Restore (SAR) scenario also can be verified by integrating SAR blocks and power management block. REFERENCES

[2] Chen Wenwei; Zhang Jinyi; Li Jiao; Ren Xiaojun; Liu Jiwei, Study On a Mixed Verification Strategy for IP-Based SoC Design, 27-29 June 2005. [3] Xiaobin Chu, Tiejun Lun, Yu Zong, Functional Verification of USB Mass Storage, Proceedings of the International MultiConference of Engineers and Computer Scientists 2008 Vol II IMECS 2008, 19-21 March, 2008, Hong Kong. [4] March 2001, "USB 2.0 Transceiver Macrocell Interface (UTMI) Specification", Intel Corporation. [5] http://www.beyondlogic.org/usbnutshell/

IJ
ISSN: 2230-7818 @ 2011 http://www.ijaest.iserp.org. All rights Reserved. Page 53

ES

[1] Puhar, P.; Zemva, A, Functional Verification of a USB Host Controller,3-5 Sept. 2008.