09/02/2020 Achieve PCIe compliance and interoperability in your IP core-based design - Embedded.

com

Achieve PCIe compliance and interoperability in your IP core-

based design
embedded.com/achieve-pcie-compliance-and-interoperability-in-your-ip-core-based-design

Embedded Staff July 11, 2008

Since its inception more than five years ago, PCIe technology hasbecome the dominant
interconnect protocol across virtually all marketsegments. Today, all of the major chipset vendors
are implementing PCIetechnology into their chipsets.

The quick adoption of PCIetechnology has resulted in a market flooded with

manydifferentimplementations of the PCIe specification. While, theoretically, eachof these
implementations should be compliant with the specification andinteroperate with all other
implementations, the reality is thatnon-compliant and non-interoperable devices do make their
way to themarketplace.

When one considers the high cost of fixing a non-compliant ornon-interoperable device once it
reaches silicon, much less once it hasbeen released to the market, assuring pre-silicon
compliance andinteroperability of a device becomes one of the most importantchallenges to any
PCIe development process.

Recognizing this enormous cost, the EDA industry has come forth witha myriad of solutions
capable of managing this obstacle. Thesesolutions include advanced verification and assertion
languages,functional coverage tools, and protocol specific models and compliancetest suites.

Given the wide range of solutions made available by the EDAindustry, selecting the best solution
to assure pre-silicon complianceand interoperability of a device requires a thorough
understanding ofthe issues that cause devices to be deemed noncompliant ornon-interoperable.

Figure1: If two devices are known to interoperate with a third device, thenthe first
two should be indirectly interoperable with each other.

https://www.embedded.com/achieve-pcie-compliance-and-interoperability-in-your-ip-core-based-design/ 1/4
09/02/2020 Achieve PCIe compliance and interoperability in your IP core-based design - Embedded.com

Challenges
As one reads the PCIe BaseSpecification, or any specification for that matter,assumptionsare
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 theirspecifications, these specifications remain open to interpretation,
andassumptions are made as developers read the specification.

In the best-case scenario, these assumptions are consistent amongstdevelopers and with the
intent of the author of the specification, whomin this case is the PCI-SIG. In reality, this
consistency is oftenabsent. More commonly, differing assumptions exist between developers.

In this case, the resolution of these differences comes only afterextensive discussions, which
oftentimes require the guidance of theauthor of the specification.

In the worst-case scenario, all developers make the sameassumptions, which are, unfortunately,
inconsistent with the intent ofthe author of the specification. In this case, the resulting devicedoes
not match the intent of the specification.

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

Assumptions are identified and resolved as more developers reviewand use the solution. The
result is that as a solution gains wideracceptance in the industry, more confidence can be placed
in theaccuracy of the solution.

As devices continue to grow in size and complexity, the task ofenumerating, much less verifying,
all possible scenarios becomesextremely difficult. And it becomes increasingly probable that
somefeatures 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 optionalfunctionality, this is not an issue unique to the PCIe specification.

In response to this industry-wide issue, coverage-drivenverification methodologies have been

developed and successfully proven.These methodologies generally involve the placement of
assertions intothe device and the verification environment.

Once the assertions are placed, random stimulus is applied to thedevice, and coverage statistics
are collected. As such, to be useful ina coverage-driven verification methodology, any pre-silicon
compliancesolution must include a robust set of assertions, along with a facilityfor the collection of
coverage statistics.

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

https://www.embedded.com/achieve-pcie-compliance-and-interoperability-in-your-ip-core-based-design/ 2/4
09/02/2020 Achieve PCIe compliance and interoperability in your IP core-based design - Embedded.com

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

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

As such, a presiliconcompliance solution that provides a complete, self-containedverification

environment is instrumental in filling this gap, providedthe solution can be easily integrated with
the device.

Additionally, given the limited resources generally applied to thistask, any issues identified by the
solution must be easily debugged andresolved.

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

For a device to be fully interoperable, it must be able to do thiswith all possible devices on the
market. Interoperability in apre-silicon environment is extremely difficult. Indirectinteroperability is
an alternative option.

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

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

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

https://www.embedded.com/achieve-pcie-compliance-and-interoperability-in-your-ip-core-based-design/ 3/4
09/02/2020 Achieve PCIe compliance and interoperability in your IP core-based design - Embedded.com

Figure2: If three devices are interoperable with a pre-silicon compliancesolution,

then all three devices are indirectly interoperable with eachother.

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

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

Joshua Filliater is anApplications Engineer at Denali Software, Inc.

https://www.embedded.com/achieve-pcie-compliance-and-interoperability-in-your-ip-core-based-design/ 4/4