Achieve PCIe compliance and interoperability in your IP core-based design

Since its inception more than five years ago, PCIe technology has become the dominant interconnect protocol across virtually all market segments. Today, all of the major chipset vendors are implementing PCIe technology into their chipsets.
The quick adoption of PCIe technology has resulted in a market flooded with many different implementations of the PCIe specification. While, theoretically, each of these implementations should be compliant with the specification and interoperate with all other implementations, the reality is that non-compliant and non-interoperable devices do make their way to the marketplace.

When one considers the high cost of fixing a non-compliant or non-interoperable device once it reaches silicon, much less once it has been released to the market, assuring pre-silicon compliance and interoperability of a device becomes one of the most important challenges to any PCIe development process.

Recognizing this enormous cost, the EDA industry has come forth with a myriad of solutions capable of managing this obstacle. These solutions include advanced verification and assertion languages, functional coverage tools, and protocol specific models and compliance test suites.

Given the wide range of solutions made available by the EDA industry, selecting the best solution to assure pre-silicon compliance and interoperability of a device requires a thorough understanding of the issues that cause devices to be deemed noncompliant or non-interoperable.


Challenges
As one reads the PCIe Base Specification, or any specification for that matter, assumptions are made as to how the device is intended to behave.

Although standards bodies such as the PCI-Special Interest Group (SIG) take great strides to remove all ambiguity from their specifications, these specifications remain open to interpretation, and assumptions are made as developers read the specification.

In the best-case scenario, these assumptions are consistent amongst developers and with the intent of the author of the specification, whom in this case is the PCI-SIG. In reality, this consistency is often absent. More commonly, differing assumptions exist between developers.

In this case, the resolution of these differences comes only after extensive discussions, which oftentimes require the guidance of the author of the specification.

In the worst-case scenario, all developers make the same assumptions, which are, unfortunately, inconsistent with the intent of the author of the specification. In this case, the resulting device does not match the intent of the specification.

Therefore, it is critical for any pre-silicon compliance solution to have identified and resolved all assumptions made in the development of the said solution.

Assumptions are identified and resolved as more developers review and use the solution. The result is that as a solution gains wider acceptance in the industry, more confidence can be placed in the accuracy of the solution.

As devices continue to grow in size and complexity, the task of enumerating, much less verifying, all possible scenarios becomes extremely difficult. And it becomes increasingly probable that some features of the device will not be covered in the verification process.

Although the PCIe specification details hundreds of registers, multiple complex state machines and a plethora of optional functionality, this is not an issue unique to the PCIe specification.

In response to this industry-wide issue, coverage-driven verification methodologies have been developed and successfully proven. These methodologies generally involve the placement of assertions into the device and the verification environment.

Once the assertions are placed, random stimulus is applied to the device, and coverage statistics are collected. As such, to be useful in a coverage-driven verification methodology, any pre-silicon compliance solution must include a robust set of assertions, along with a facility for the collection of coverage statistics.

Verifying IP cores
With the rapid adoption of PCIe technology, PCIe design cores are quickly becoming commodity parts. Generally, there is little value to be added to a device by building a PCIe design core from scratch when a wide variety of PCIe design cores are available from many vendors, each offering its own set of features.

Ideally, all PCIe design cores on the market should be bug-free; however, that is not always the case. Therefore, the challenge for any development team using a PCIe design core is to determine how to deal with a core that has presumably been verified.

Most development teams either do not have or do not wish to allocate resources to the verification of a pre-verified PCIe design core.

As such, a presilicon compliance solution that provides a complete, self-contained verification environment is instrumental in filling this gap, provided the solution can be easily integrated with the device.

Additionally, given the limited resources generally applied to this task, any issues identified by the solution must be easily debugged and resolved.

Interoperability testing
Interoperability is defined as the ability of a device to communicate with all other devices. In the PCIe domain, this implies that two devices are interoperable if, and only if, the devices can correctly manage their connection and exchange transactions.

For a device to be fully interoperable, it must be able to do this with all possible devices on the market. Interoperability in a pre-silicon environment is extremely difficult. Indirect interoperability is an alternative option.

The concept of indirect interoperability states that, given three devices, if the first two devices are known to interoperate with the third device, then the first two should be interoperable with each other (Figure 1, above ).

Applying this concept, a pre-silicon compliance solution provides an assurance that the device will be interoperable with all other devices using the same solution (Figure 2 below).

As a given solution gains wider acceptance throughout the industry and is used to assure pre-silicon compliance with a wider array of devices, this wider array of devices will be known to interoperate with each other.



As the cost of a silicon re-spin grows with each passing day, it becomes critical to assure pre-silicon compliance and interoperability for all PCIe devices. The sources of compliance and interoperability bugs are complex and often go unnoticed.

The only way to mitigate the risk of producing a non-compliant or non-interoperable device is to address each of these sources with a widely accepted and easily integrated solution containing advanced verification features.

Joshua Filliater is an Applications Engineer at Denali Software, Inc.