Validation of USB Peripheral Checklist A challenging Requirement for SoC

1Maneesh Kumar Pandey,

2Neeraj Jian

Freescale Semiconductor Pvt Ltd

Noida, India 1, 2

(maneesh.pandey; neeraj.jain)

@freescale.com

3Amit Sinha,

4Shwetank Shekhar

Freescale Semiconductor Pvt Ltd

Noida, India 3, 4

(B10813; shwetank.shekhar)

@freescale.com

Abstract— As of now semiconductor companies only ensure

peripheral checklist in design and perform compliance testing at

silicon.

Compliance tests are essential to verify if design targets are met

according to the planned specification. USB implementer’s forum

(USB- IF) has instituted a compliance program which provides

reasonable measures of acceptability. Test equipment vendors

provide ready- to-use compliance test suites which have been

used for several years but the reality is that surprises and issues

have also been consistent at real silicon making life of post silicon

activities quite difficult. Simple traditional designs might not face

suffocating issues but in current high speed complex designs,

problems (electrical or logical) are inevitable. Unpredictability of

such issues impacts cycle time to such an extent that companies

have no choice but to delay their date of deliverables which could

result in financial or market share loss.

To avoid these unexpected problems we need to perform low

level testing.

This paper describes case studies of some issues which

escaped compliance testing and were observed at silicon only

after validating the tests given in peripheral checklist. It also

elaborates the challenges faced in checklist validation.

Keywords—USB 2.0 Compliance Testing, Peripheral Checklist,

System on chip (SoC), USB-IF

I. INTRODUCTION

In recent times USB has successfully replaced serial and parallel ports as the connection of choice for both device manufacturers and end users. Cable length and device expansion were major limitations with older serial and parallel connections but those limitations are successfully resolved in USB. Amazingly, it allows 127 devices (attached to the ports with the help of multiple hubs) to be connected to a single host. Ability of the host to talk directly or through hubs to the devices allows this incredible expansion capability.

The Universal Serial Bus (USB) specification [15] defines the product design targets at the level of interfaces and mechanisms. To complement the specification and enable measurement of compliance in real products, the USB-IF has instituted a Compliance Program that provides reasonable measures of acceptability. Products that pass this level of acceptability are added to the Integrators List and have the right to license the USB-IF Logo. [9]

USB 2.0 comprises three different data transfer rates—low-speed, full-speed, and hi-speed. The flexibility inherent in USB is a direct result of the specifications, stringent regulations and compliance testing mandated by the USB-IF. [5] [6]

When USB [8] is incorporated in any silicon, we first go for compliance testing [7] to validate electrical specifications and protocols of USB2.0 through either in-house testing or some prescribed USB-IF lab. Some of the products have USBPHY inside (UTMI [12]) the design and others have outside (ULPI [16]). Compliance testing is also a kind of requirement from USB-IF for compliance certification of a particular product. Checklist should be sent with compliance setup to compliance testing lab. These checklists could be categorized in three types:

Peripheral Checklist [13]

System Checklist [14]

peripheral silicon checklist [18]

Checklists are a simple set of questions capturing design implementation that are difficult to test. Checklists should be used during the design phase as a 'memory jogger' to make sure products are designed to be compliant. By checking these items, one indicates that the product design has met its requirements.

This paper deals about the reason for performing the peripheral checklist and challenge faced during the same.

This paper is organized in 5 sections. Section II highlights requirements for validation of Peripheral check List with the help of couple of issues. Section III describes challenges faced in validation of peripheral checklist explained through few case studies. Section IV concludes and summarizes the paper.

978-1-4799-1205-6/13/$31.00 ©2013 IEEE

203

II. REQUIREMENT OF PHERIPHERAL CHECKLIST TESTING

AT USB PRODUCT

USB-IF says “It is the vendor’s responsibility to ensure that

their device complies with the checklist items.” [13] [14]

Compliance testing is necessary for USB-IF certification of products. In compliance testing, PHY, Controller and Linux firmware are involved and if there is any issue, failure report is generated.

Figure 1: Basic Setup of Compliance Testing

The compliance test setup is illustrated in Figure 1. In a typical test, HS-OPT is connected to the embedded host and presents a specific VID/PID combination. Upon detecting the VID/PID combination, the embedded host enters into test mode. The termination switch on the HS Test fixture is then flipped and the oscilloscope is used to take measurements on the embedded host [11].

Designer ensures all the checklist specifications are covered in his design as per USB-IF compliance checklist criteria [13]. But there are practical scenarios where silicon fails either at compliance or application level testing in spite of many checks made at design. These failures could be due to several reasons. Here we will discuss the two scenario faced at system level for problem formulation and that will help to explain the need for validation of peripheral checklist.

A. USB Data Transfer Error

In one of the scenario there was a requirement to read 2 GB of data from USB stick. This application level test was failing as timeout error (as shown in figure 2 of CATC dump) even though compliance tests were passing.

As shown in Figure 2, transaction (7499) shows the read operation in which Host sends an ACK (acknowledgement) after receiving the DATA packet sent by Device.

Figure 2: CATC dumps of USB read time out

After debugging it was observed that some time host does not send ACK packet as shown in transaction (7507 & 7514) of figure 2, generating time out error. [10]

B. Delayed STP for SOF transmission

The problem comes when following sequence of operations is

performed.

USB controller is configured in Host mode

HS reset signaling happened properly

When SOF packet is transmitted, STP is delayed one clock cycle causing an extra byte being transmitted.

The above behavior is captured in two snapshots with,

a. Controller (see Figure 3) : STP delayed

b. ULPI driver [16] (see Figure4) : STP comes

properly

Going by the ULPI protocol PHY behaves properly

in both the cases but controller misbehaves as NXT is lowered

for one cycle in the second data byte. [17]

Figure 3: STP delayed for SOF transmission

204

Figure 4: SOF packet Transmission from ULPI driver

From the above seen issues at system level we identified that it is very important as well as necessary to test peripheral checklists at silicon.

Moreover some checklist items are difficult to test. That however does not means, the silicon is excused from meeting those requirements.

In practice some issues are normally found while validating peripheral checklist at silicon but these issues are not caught while running compliance testing.

III. CHALLENGES FACED IN TESTING OF PHERIPHERAL

CHEKLIST [13]

We will describe here couple of issues, which were found

while performing checklist at silicon. These issues were not reflected while running compliance/application tests.

A. Full Speed Common mode receiver Sensitivity

Compliance test doesn’t specify any test for Full Speed or Low Speed (FS/LS) differential receiver sensitivity. FS/LS differential receiver has an input sensitivity of at least 200mV amplitude and dc offset between 0.8 and 2.5 volts common mode. If this specification is somehow not met in the design, it is impossible to discover it in compliance testing because this doesn’t cover such scenario. The solution to capture such issues missed out in compliance testing lies within peripheral checklist.

The above described FS receiver sensitivity issue was found during testing of peripheral checklist item ST4.

B. Full Speed Time Out (FS20)

A device expecting a response to a transmission will

invalidate the transaction if it does not see start-of-packet

(SOP) transition within timeout period after the end of the

transmission (after SE0-to-J state transition in the EOP). This

can occur between an IN token and the following data packet

or between a data packet and the handshake packet [15]. The

device expecting the response will not time out before 16 bit

times but will timeout before 18 bit times (measured at the

data pins of the device from the SE0-to- J transition at the end

of the EOP).Time out period should be 18 full speed bit time

but in our case it is more than 70 full speed bit time.

This time-out issue was captured during validation of

peripheral checklist test FS20.

C. In signal and system test (ST6):

The input impedance of D+ and D- without termination and pull up resistors should be more than 300kΩ but value at silicon was 50 Ohm. This was observed using setup shown in figure4.

This issue was captured during validation of peripheral checklist test ST6.

Figure 5: Setup for measurement the impedance

D. In Power Delivery Test (P8):

Host must have a total of at least 120uF of low ESR bypass capacitance at its downstream port. This is according to standalone host specification. But it was observed to be 6.5uF in our set-up. This was not implemented at our board that’s why we changed our application board with 120uF to meet the checklist specification.

This issue was captured during validation of peripheral checklist test P8.

E. In State and Signal Test (ST5):

Device pull-up was active when VBUS was 0.7V instead of 1.17V. Resistor combination connected to the VBUS at our board was changed to meet this requirement.

IV. CONCLUSION & FUTURE WORK

Above analysis and case-studies suggest that performing

peripheral checklist validation in addition to compliance

testing at silicon is of utmost importance and help us to

produce bug free SOC .Though one cannot deny the

significant level of effort needed to establish peripheral

checklist validation setup but the fact is one can capture

205

several bugs escaping compliance testing and deliver a healthy

silicon to customer.

The scope of this paper is limited to peripheral, system and

peripheral silicon checklist. The same can be extended for

HUB , OTG & Embedded Host checklist. [1]

REFERENCES

[1] Compliance Checklist for USB On-The-Go and Embedded Host Supplement Revision 2.0 July 1, 2011 Version 1.0

[2] USB USB-IF USB 2.0 Electrical Test Specification Revision 1.03, Version 1.03, January 2005 at www.usb.org.

[3] Embedded High speed host electrical test procedure revision 1.0 by USB-IF.

[4] USB-IF Hi-speed Device Compliance Test Summary by USB-IF.

[5] Universal Serial Bus Implementers Forum Full and Low Speed Electrical and Interoperability Compliance Test Procedure, version: 1.3

[6] Universal Serial Bus Implementers Forum Host High-speed Electrical Test Procedure, version: 1.0

[7] Universal Serial Bus Implementers Forum Device High-speed Electrical Test Procedure, version: 1.0

[8] M. Inc. and D. Anderson. Universal Serial Bus System Architecture, 2nd Edition. Addison-Wesley Developer’s Press, Reading, Massachusetts 2001

[9] USB-IF Compliance Updates http://compliance.usb.org/index.html

[10] Maneesh Kumar Pandey, Shwetank Shekhar, Gaurav Agrawal, Nitin Saxena, “An Approach for In-House USB2.0 Electrical Compliance Testing on nanoscale SoC“ unpublished

[11] Maneesh Kumar Pandey, Shwetank Shekhar, Gaurav Agrawal, Nitin Saxena, “Novel USBPHY-IP Validation Framework” Unpublished

[12] USB 2.0 Transceiver Macrocell Interface (UTMI) Specification, Version 1.05, March 29, 2001.

[13] USB Compliance Checklist Peripherals (Excluding Hubs) For the 2.0 USB Specification Checklist Version 1.09 January 16, 2012

[14] USB Compliance Checklist Systems For the 2.0 USB Specification Checklist Version 1.07 January 17, 2012

[15] USB 2.0 Specification, April 27, 2000

[16] ULPI Specification, Revision 1.0, February 2, 2004

[17] UTMI+ Specification, Revision 1.0, February 2, 2004

[18] USB Compliance Checklist Peripherals (Excluding Hubs) For the 2.0 USB Specification Checklist Version 1.08 December 18, 2001

206