July 3, 2006 -- Despite USB’s almost ten-year existence and positive end-user experience, adding this type of functionality to your product can be a rather complex design task. Many experienced design teams have underestimated the complexity of USB and have paid the price in seeing their entire project grind to a screeching halt.

The reason for this misperception stems from the belief that USB integration is a trivial process. It’s not! The overlapping specifications from the base USB 2.0 specification to the desirable On-the-Go (OTG) supplemental creates extra software, hardware, and system challenges that are far more complicated than most design teams realize.

For the successful integration of USB intellectual property (IP) into your design, you should consider IP that includes hardware, software, and system components. Hardware is built from a transceiver (PHY) and link controller (digital IP) that supports USB devices on the bus with a host controller or embedded subsystem. The software can be similarly built, but its complexity can increase dramatically due to the many new variables it may have to deal with, such as incorporating the latest OTG functionality or partial OTG implementation, as in the case of a limited embedded host.

The fastest path to integration often means using silicon-proven designs with proven IP (make sure you get and take advantage of fully supported IP). Following this path reduces the complexity of USB’s labyrinth of overlapping requirements that involve a number of complex topics such as power delivery and monitoring, stringent signal quality requirements at different speeds and protocols, and various other burdens related to potential backward compatibility and performance requirements. No design can be isolated from these types of issues if error-free integration is expected. This article reveals some of the common missteps design teams make when integrating USB IP and offers a few suggestions on how to avoid future mistakes. Some of the more common missteps include:

Failing to adopt and follow standard engineering best practices Not establishing a sound architectural plan Undefined expectations among the design team Failure to recognize and appreciate the complexity of the task Not using fully supported IP components Overlooking test and validation until the final implementation stage

Building and following engineering best practices

Common mistakes can be avoided by building a solid engineering foundation based on a number of factors that are often overlooked in the rush to meet tight product development schedules. One of the most problematic mind sets is when the team feels pressured and doesn’t follow best engineering practices. In this situation, the attitude of “just good enough” replaces the more precise checklist or “by the book” engineering processes. A less experienced design team may not know, or not have the experience gained from a first-time success to appreciate, the merits of following a disciplined and documented process.

Assumptions based on past use are another way to lull design teams into complacency. Prior success might help predict future success, but it should never be a reason to skip test and validation steps particularly with new designs. At the same time, attempting to use or reuse any hardware or software IP component that isn’t fully supported invites trouble and is an unwise practice. A successful engineering team might be comfortable using some portion of a past design, but the design will usually come with conditional support or no support clause. Not being aware of certain conditions surrounding design or IP reuse can devastate a schedule and ultimately throw the project’s success.

A clear focus on essential requirements during all phases of development is the only way to plan for a successful project. There are no shortcuts and design teams who try to reduce budget overhead pay a stiff price in the end.

Establishing a sound architectural plan

Initial planning phases must not only include a clear understanding of each respective engineering hardware or software tasks at the silicon, board, and system level, but also to take into consideration the inner-dependency each has on the other. Everyone knows a functional house or building design requires a good set of architectural plans. Yet it’s surprising how many SOC designers build complex ASICs without similar attention to the overall architecture. The best components in the world may not work well together if the overall system, sub-system, or SOC architecture isn’t taken into full consideration.

For example, the best time to employ a reality filter is during the architectural phase where the software, hardware, and system architects resolve complex system performance requirements. This is accomplished by dismissing theoretical performance numbers and focusing instead on real world and application-dependent data transfer rates. USB’s maximum bandwidth of 480MBps or 60MBps is never achieved in real applications once you factor out hardware and software overhead. The typical, highly optimized performance will be around the 38MBps. A more typical and easy-to-achieve maximum sustainable USB transfer would be in the 10 to 15 MBps range whereas higher transfer rates will often require architectural system considerations and extra hardware resources. The key element in this process is finding the acceptable balance of system hardware and software resources, and silicon resources (measured in gate count, clock rate, and power consumption).

Lots of planning and up-front work during the architectural planning stage will pay huge dividends later. To be successful, the architectural team must have a deep understanding and respect for the overall task and interdependencies because the complexity of hardware, software, and the system is often exponential, rather than additive. This is part of knowing and defining essential requirements during every phase of development. It’s why developing a comprehensive test strategy early in the product development is so important.

Managing design team expectations

Arbitrary or undefined expectations can quickly lead to big disappointments. Design teams need to pay particular attention to properly managing expectations. Performance expectations can be chock-full of disappointment. Overlooking or not addressing system DMA requirements during the architectural phase often results in lower than expected system performance that cannot easily be fixed in software or hardware as most managers assume. USB has a number of functional configuration issues and operational modes that must be clearly understood and defined early in the design process. Trying to change imperfections later in the implementation process can be very difficult or even impossible without redesigning large parts of the design.

Recognizing and appreciating the complexity of the task

With a well-devised and agreed upon strategy in place, the design team can test its architectural assumptions during the architectural phase, and use parts of this test to validate design elements and other important implementation tests later in the design phase. The graphic below illustrates the facets involved in hardware/software/system (HW/ SW/ System) planning.

Implementing fully supported IP

USB IP package design source files, test environments, and other system test resources, when used together, help development teams successfully implement USB interfaces into their SOC designs. Such packages can provide a wealth of information regarding essential implementation requirements at the hardware, software, and system levels. Design teams should seek out such information to help create early development and prototyping systems as it can be extremely difficult, or even impossible, to add the necessary hooks or probe capabilities to a fully implemented ASIC. Without such expanded probe capability, it’s often impossible to find the root cause of a hardware, software, or system problems.

Test and validate throughout all design phases

To avoid project delays, it’s critical to have clearly defined test strategies and use these strategies throughout each phase of development, even if a particular test isn’t required until later in the product release process. For example, the root cause of intermittent software failures early in the bring-up process can be caused by poor signal quality on the differential +/- data signal pair that makes up two of the four wires in the USB cable or other complex RF and/or analog anomalies.

Thinking these tests are optional, or only important at the very end of the design process, is a fallacy that has ruined a number of product introduction plans. While a product’s actual certification status may be a marketing option, the tests that lead to certification are never optional. When USB IF signal quality testing is perceived as the final product release test and left as a last step or skipped altogether, the design team can waste weeks of time debugging and fixing non-existent software problems or unusual corner case failures. Some managers or design team members justify such endeavors as making their design more robust, but in actuality, such failure may never be revealed in normal operation or occur so rarely that it will never be a problem. Such tangential tasks, like patching software for a hardware problem, are often a total waste of time as the real problem or root cause is actually something that is easily identified and fixed and you don’t have to worry about the software patch causing a problem somewhere else!

The time to think about test and validation isn’t at the final product implementation phase or just before it’s handed over to manufacturing. You have to think about and use tests and validate design assumptions beginning at the architectural design phase – followed by careful use of these tests throughout design implementation and system integration.

This article covered a variety of topics to help design teams successfully plan the integration of USB IP into their designs. The topics range from architectural and management issues to what to look for when considering third-party IP. It cannot be emphasized enough how important it is to pay close attention to development platform capabilities and being able to fully probe for problems during any product development phase – even after the product’s been shipped – to more easily enhance some aspect of the product’s performance. Having an up-front architectural analyses and a solid validation platform are indispensable for flushing out and solving performance issues throughout all phases of the USB IP integration cycle.

By Cary Snyder.

Cary is a Product Specialist in Mentor Graphics IP Division (IPD). He has a broad technical background and is a major contributor to many of the IP industry’s success stories. Before Mentor, Cary worked at VTM, Inc., where he supported technical requirements for the USB-IF and other industry forums including DLNA and SATA, and prior work with PCI SIG. Cary also has a long history of IP conception, creation, and debugging. He spearheaded Xilinx's entry into the world of IP and has made valuable contributions to other IP companies and products.