Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Interface

PCI Express verification underscores need to plan

Posted: 03 Apr 2006 ?? ?Print Version ?Bookmark and Share

Keywords:levent caglar? cadence design systems? cadence? pci express-based design? design?

PCI Express-based designs are textbook examples of a complex verification problem. Using a compliance checklist can kick-start verification planning. But you also need a well-planned verification methodology that addresses these questions: What compliance items are verified? Have you covered all compliance scenarios? Can you provide a progress report to your manager?

These challenges are not new for verification engineers. But complex verification projects force the extended team to do more planning to avoid getting lost in the 1,300+ item compliance checklist.

An extensive checklist can serve as a compliance verification plan to identify how to co-relate compliance items to the data automatically provided by the verification environment. This involves mapping English definitions to a mechanism. Often, we underestimate the workload and get confused between checking a single scenario and proving that a specific feature works in all scenarios.

Let's look at PCI Express compliance checklist item TXN.2.1#2. Permitted Fmt[1:0] and Type[4:0] field values shown in Table 2-3 of the Base Specification. All other encodings are reserved. Fmt and Type fields determine the transaction layer packet (TLP) kind and use correct decoding. An assertion must be written to gauge the validity of these values. Without a metric or indicator that reports the types of TLPs generated and transmitted by the DUT, however, this assertion is almost meaningless. Moreover, the total possible combinations have 128 values and only 25 are valid. Thus, basing the compliance solely on this assertion will give you false confidence.

It's necessary to track all the possible cases where this assertion is evaluated. Functional coverage is one way of achieving this. You can define functional coverage to track the values of Fmt and Type for all transmitted TLPs.

Now, you have created the necessary infrastructure: an assertion, plus functional coverage that checks the validity of the field values and tracks all TLPs transmitted by the DUT. This will provide immediate and consistent feedback with metrics.

For complex PCI Express problems, plan ahead and write the specs in a way that can easily be converted to a verification plan. Next, analyze the concerns in the verification plan and implement the assertion, functional and code coverage infrastructure. Finally, map the planning items to the implemented infrastructure.

There you have ita traceable, predictable verification environment that can assess and refocus the verification effort accordingly.

- Levent Caglar
Sr. Verification Application Specialist
Cadence Design Systems Inc.

Article Comments - PCI Express verification underscores...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top