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.|
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.
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 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.
|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.