Verifying PCI Express design IP

Verifying PCI Express design IP
By Vice president of marketing Denali Software, Inc., Palo Alto, Calif., EE Times
July 18, 2003 (11:35 a.m. EST)
URL: http://www.eetimes.com/story/OEG20030718S0030

The PCI Express standard is a new serial interconnect architecture that supports a range of devices for chip-to-chip, board-to-board and adapter interfaces used computing and communications applications. Widespread convergence on this standard has ASIC designers, tool vendors and IP vendors all scrambling to achieve first-time success with the new wave of chips that incorporate PCI Express technology. The standard is specified in a document containing 700 pages of text and diagrams, and despite the best efforts of the PCI-SIG, it is still subject to human interpretation. Verification of these designs is now emerging as a major challenge.

Compliance and interoperability are two important concepts when considering PCI Express design verification. "compliance" measures how well your design conforms to a particular revision of the specification, while "interoperability" is a measure of how well your device will work with other devices in the final s ystem. Interoperability verification can be especially difficult for developers of more generalized or open systems in where the number of interfacing devices is large and/or unknown. In either case, there is a significant risk of interoperability errors since the common specification is subject to human interpretation. This is further complicated by the fact that many developers are choosing to support a subset of the specification at first, planning for more complete support on a later spin or rev of the design. Potentially differing interpretations of the specification, lack of visibility into interfacing devices, and differing subset implementations all contribute to the verification problem.

Although the PCI-SIG relies on market-driven solutions for pre-silicon compliance verification, it does take an active role in supporting post-silicon interoperability testing. These "test-fests" enable vendors to test their completed chips against other designs to validate interoperability. In support of de sign compliance, the PCI-SIG does offer a compliance checklist for the various device types (endpoint, switch, and root complex) defined in the PCI Express architecture. The checklist is a set of textual assertions that serve as a design guide for developing compliant devices. When used for RTL verification, these assertions essentially represent the "easiest 10percent" of the checks necessary for functional verification.

While not comprehensive, the compliance checklist contains well over one thousand yes/no checks. Several hundred of these are directly applicable to verifying functionality, while others define electrical requirements and valid device configurations options. An example of a single compliance check for functionality looks something like:

For xN Links where N is 8 or more, if an END or EDB Symbol is placed in a Lane K, where K does not equal N-1, and is not followed by a STP or SDP Symbol in Lane K+1 (i.e. there is no TLP or DLLP immediately following), then PAD Symbols must b e placed in Lanes K+1 to Lane N-1.

There is no automated method for translating the compliance checklist into any of the popular languages for formal or functional verification like 'e', SystemC, Sugar, or Vera. Even so, the much larger task is actually developing the remaining majority of assertions outside of those derived from the compliance checklist. Developing a reasonably complete set of checks requires expert interpretation of the PCI Express specification and a solid understanding of verification methodologies. The best commercial tools for PCI Express design verification employ thousands of run-time assertions-not counting the several hundreds of checks used to verify valid device configurations and register settings.

Consider the robust error handling features defined in the PCI Express standard. The PCI Express specifications impose a very comprehensive scheme for device error detection and recovery in all three layers of the architecture. This means that once you've performed exh austive verification to show that your design functions correctly, you must then simulate the many ways in which other interfacing devices could incorrectly interact with your design. Once again, intimate knowledge of the specification is required. For example, there are known issues in the specification that allow for perfectly legal error negotiation to result in an ambiguous state within the link training state machine. These could easily go undetected if your BFM does not model this detail, or if your data generation scheme does not exercise the condition.

These fundamental topics only scratch the surface of verifying a complex interface such as PCI Express, especially for IP vendors that need to provide exhaustive verification for all possible variations of a configurable PCI Express core. All of this points to the value of commercial verification IP for standard interfaces. It requires a dedicated verification IP vendor to translate an expert understanding of the specification into an integrate d verification suite that can be leveraged across the entire base of designs that utilize the standard. We have seen a number of point solutions emerge in the past few years, but for the most part, these are simulation models written in a specific verification language and can only be leveraged in a proprietary verification environment or product.

The significance of verifying interoperability means that a large part of the solution value can be only realized when the verification IP is platform and language independent, and can be leveraged across all EDA verification environments. Platform independent solutions play a key role in the industry-wide transition to complex new chip interface standards such as PCI Express technology. Driven by the need to verify compliance and interoperability, verification IP is rapidly emerging as a successful segment in the semiconductor industry.