Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
7.IJAEST Vol No 8 Issue No 1 an Improvised Methodology for Hardware Software Co Verification of USB Subsystem 049 053

7.IJAEST Vol No 8 Issue No 1 an Improvised Methodology for Hardware Software Co Verification of USB Subsystem 049 053

Ratings: (0)|Views: 5|Likes:
Published by helpdesk9532

More info:

Published by: helpdesk9532 on Jul 13, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Ms Priyamvada Deshpande, Dr. M.K. Srivas, Mrs Akalpita Kulkarni,Dr. Ambedkar Institute of Technology, Texas Instruments, Dr. Amdedkar Institute of Technology,Bangalore, India, Bangalore, India, Bangalore, India,
 Abstract: T 
he overall cost of verification can be reduced andquality 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 IntellectualProperty (IP) and sub-system levels. This is especially so forIP sub-systems such as Universal Serial Bus (USB) that isdriven by embedded SW. This paper describes thechallenges involved in building a test-bench (TB) foreffective stress testing of USB at IP level and one way of building a test-bench (TB) environment with severalinfrastructure components including a software layer,which is essential for effective stress testing of the IP. Wealso describe various complex scenarios that can beimplemented in the test bench for the effective stress testingof USB IP subsystem.Keywords: SoC, IP sub-system, USB, TB environment.
INTRODUCTIONWith the increase in the complexity of theelectronic devices, functional verification has becomemajor bottleneck in the design and verification
Hence a
mong various phases in a SoC developmentcycle, verification is a crucial phase. A generalagreement is that verification consumes 60-70% of aSoC development cycle. With the huge capacity of silicon technology, verification has become moreimportant compared to the past
.Verification of an SoC can be done at differentlevels: IP and IP sub-system, chip-level, and HW/SWco verification of SoC
. This paper describesdifficulties involved in verifying IPs at lower level bytaking USB IP subsystem as an example. It is verymuch cost effective to carry out the verification atlower levels rather than doing at SoC level, whichrequires lot of effort, cost and time. However doingverification at IP level alone has certain disadvantagessuch as test bench complexity, inaccuracy and lack of stress testing due to limitations of the test bench. Onthe other hand verification carried out at SoC levelconsumes more time, effort and cost. By the time a bughas been detected, the chip might have gone for fabrication. Verifying an IP has many requirements todevelop the test bench. It requires processor, BusFunctional Modules (BFMs), Interfaces, Transactiongenerator, Monitor and Scoreboard. Verification at Ithas disadvantagesConsidering the disadvantages at each level,effective verification can be done at IP level byHW/SW co-verification. This paper describes a test- bench in which verification of USB IP can be done atsubsystem level. The proposed method will describethe test bench architecture and explain working of USB by taking normal data transfer between a host and adevice as an example. This paper also includes detailson how the basic test bench can be extended to supportcomplex scenarios, its advantages and its future scopes.Section II gives a brief description of USB 2.0and section III describes the challenges involved inUSB verification. Section IV describes sub-systemlevel test-bench built for verification of USB. SectionV gives the results and extensions made to the test- bench. Section VI gives the conclusion and futureworks.II.
USB SUB SYTEMUSB is a serial bus which helps in datatransfer between a host and several devices. Theattached peripherals share USB bandwidth through ahost scheduled, token based protocol. Peripherals can be attached, configured and detached while host andother peripherals are in operation. USB 2.0 is animprovised version of USB 1.1. High speed mode andtwo additional protocols: Session Request Protocol(SRP) and Host Negotiation Protocol (HNP) are thekey features of USB 2.0. This section describes thefeatures of USB 2.0.A.
 Bus Topology
 It has a tiered star topology where a hub is atthe center of each star. There can be point-to-pointcommunication between a hub and a device or betweena hub and a hub. It can support a maximum of 127devices and 7 tiers can be included. There can be onlyone host in a USB subsystem. The USB interface in thehost system is called Host controller. USB devices can be one of the following: hub- which provides anadditional attachment points to the USB and functions-which provide capabilities to the system such as joystick or speakers
Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIESVol No. 8, Issue No. 1, 049 - 053ISSN: 2230-7818@ 2011 http://www.ijaest.iserp.org. All rights Reserved.Page 49
USB interface can be explained with electricaland mechanical interfaces. The signal and power aretransferred over a four wire cable consisting of: VDD,D+, D- and GND. Packets are transferred over D+ andD- wires whereas VDD and GND deliver power to thedevices. USB 2.0 supports three data rates: High speed(480 Mbps), Full speed (12 Mbps) and Low speed (1.5Mbps). USB physical topology consists of connectingthe downstream hub port to the upstream port of another hub or to a device. All devices have anupstream connection. Upstream and downstreamconnectors are not mechanically interchangeable.
 Bus Protocol
USB is a polled bus and host controller initiates all transactions. Most bus transactions involvetransmission of three packets. They are token packet,data packet and handshake packet. Each transaction isinitiated by host controller. On scheduled basis, it sendsa packet describing the type and direction of transfer,device address and end point number. This packet isreferred as token packet. Device then selects itself bydecoding the appropriate address fields. Data istransferred either from host to device or from a deviceto host. The direction of data transfer is specified in thetoken packet. The source of the transaction then sendsthe data packet or indicates it has no data packets tosend. The destination responds with a handshake packet to indicate whether the transaction wassuccessful.
 Data Flow Types
USB supports data and control exchange between host and the device as a set of either uni-directional 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 describedas sources or sinks of data. Endpoints occur at the endof the USB communication channel. USB 2.0 supports16 end points. All devices must support endpoint zero.This endpoint receives all of the device control andstatus requests during enumeration and throughout theduration 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 configurea device at the time of attachment and for other device specific purposes.
Bulk Transfers: These are generated or consumed in relatively large and burstyquantities. Bulk data rate is sequential.Reliable data exchange is ensured by usingerror detection and invoking a limited number of retries.
Interrupt Transfers: These are used for timely but reliable delivery of data. These transfersinclude error detection and retransmission of data.
Isochronous Transfers: These occupy a pre-negotiated amount of USB bandwidth. Theseusually contain time sensitive information, butthey do not include error detection andretransmission.
This section describes the operation of USBfor normal data transfer between a host and a device.
Always a session is started by USB host. Itwaits for VBUS signals (avalid and vbusvalid)to rise and enters into full speed mode.
It then waits for device connection andgenerates connect interrupt when device getsconnected.
Device in the meantime waits to see itsconnection registered on linestate. Once itsconnection is registered, it enters into fullspeed mode.
Host then starts sending reset to the deviceand enters into high speed mode. Host startshigh speed mode handshake by sending chirpsJ (linestate – 01) and K (linestate -10).
After the handshake, device enters into highspeed mode and generates reset interrupt.
After the above configuration, endpoints areenabled and packets are transferred betweenthe enabled endpoints.III.
CHALLENGES IN USB VERIFICATIONVerification of USB can be done at IP level, IPsubsystem level and at SoC level.
 IP level Verification
At IP level verification (usually at RTL level),USB IP will be provided by the IP vendors. It is theresponsibility of the verification engineer to build thetest-bench for the verification. The block diagram of atest-bench for verification of USB at IP level is givenin figure 1
.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 instructionmemory associated with the processor are required.Interconnect such as OCP (Open Core Protocol) isrequired to connect the memories and processor withthe USB. Interconnects come as separate IPs. So theyhave to be integrated into the environment. A USB hostcan be verified only when there is a device from or to
Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIESVol No. 8, Issue No. 1, 049 - 053ISSN: 2230-7818@ 2011 http://www.ijaest.iserp.org. All rights Reserved.Page 50
which data transfers happen. We need to model adevice using BFMs. The data which is to be transferredneeds to be generated by a traffic generator. Hence werequire a traffic generator and associated software,which can generate the traffic for stress testing of USB.A transceiver is
required to transfer the data betweenthe host and the device. This transceiver must also to be integrated in the test-bench. Scoreboard/Check- board is required to compare the received data and theactual transmitted data. Some peripherals can be turnedoff, when they are not in use for reducing the power consumption.
This requires a power management block, which turns
off the clocks of the peripheralswhen they are not in use. A power management block has to be developed and integrated into theenvironment.The test-bench shown in above figure becomes complex than the USB RTL. Thedevelopment of test-bench itself requires lot of efforts.At IP level, this type of test-bench becomes verycomplex and hence, the test-bench will be simplified.This limits the stress testing of USB IP. The simplifiedtest-bench will not be accurate, since it will beconsisting 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 usedin the test-bench are not in RTL.Effective stress testing of USB not onlyinvolves verification of packet transfers, but alsoverification of complex scenarios such as SRP, HNP,Suspend-resume and Remote wakeup. It also involvesvariation of different parameters such as number of endpoints, number of packets, direction of transfer,timing of different events and payload size. Test-casegeneration should be randomized with the packetgenerator and variation of parameters also should berandomized. This makes the test-bench much morecomplex and without testing these features, verificationof USB is incomplete.
 B. IP Subsystem level Verification
IP subsystem level verification is in betweenIP level and SoC level verification. The test-benchconsists of all the required components for verification, but it will not be as large as in case of SoC levelverification. A test-bench for verification of USB atsubsystem 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 beconsisting of all the required components mentioned infigure 1, but it will be having an overhead of other IPs,which is not required for USB verification. Thus theeffort, time and cost of verification increase. Also, if a bug is detected at this level, much efforts are requiredfor debugging.IV.
SUBSYTEM LEVEL TESTBENCHA 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. Thistest-bench consists of a processor. Processor has dataand instruction memory associated with it. This processor is memory mapped internally with the USBregisters. Thus we can program these registers for configuring USB. Processor and memories areconnected to USB with interconnects such as OCP.The transceiver which can be on-chip or off-chipenables data transfer between host and device. Thetransceiver, interconnect, USB and processor are alldifferent IPs at RTL.The test-bench also has USB packetgeneration tool, which generates randomized test-casesfor different scenarios. The software contains aconstraint file, which indicates the weights associatedwith each parameters such as number of endpoints,number of packets, direction of transmission, payloadsize and protocol type. These actual test-cases andconstraint files are represented in E language. The toolgenerates complementary C and H files for Host andDevice with the help of Specman and the E files. C fileconsists of actual test-case and H file will includedifferent parameters. C file also includes scoreboardwhich compares the actual result with the expectedFigure 1: IP level test-benchFigure 2: Subsystem level test-bench
Ms.Priyamvada Deshapande* et al. / (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIESVol No. 8, Issue No. 1, 049 - 053ISSN: 2230-7818@ 2011 http://www.ijaest.iserp.org. All rights Reserved.Page 51

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->