Introduction
On the way to taping out its first PCI Express based SOC, ClearSpeed came face-to-face with the many difficulties of ensuring PCI Express protocol compliance within time and budget constraints. PCI Express is a complex protocol with an extremely large coverage space. From a management perspective, there is simply not an alternative but to apply a metrics-driven verification process to ensure protocol compliance. Unfortunately, even with thousands of tests covering the relevant scenarios, significant coverage holes remain, making this approach unpredictable and costly. The alternative, a general random test approach, isn't sufficiently predictable.
ClearSpeed has come to realize that the ideal approach yields significant benefits: it minimizes engineering effort while maximizing test deployment control. ClearSpeed got a head-start by using commercial PCIe Verification IP supplied by Cadence. The VIP, called a UVC, includes the Compliance Management System (CMS) which partitions and maps the coverage space to the PCIe specification. CMS also provides a compliance test suite in the form of constrained-random tests (called sequences) to automatically achieve high functional coverage for each PCIe specification section. ClearSpeed then built its own constrained random test suite on top of the UVC's. Associated coverage is analyzed after each test group run, resulting in clear understanding of where coverage holes lie and guiding where new tests must be directed to reach uncovered scenarios. This approach also has provided ClearSpeed with an invaluable project management tool since it helps them to understand and report on verification status. ClearSpeed now regularly tracks coverage, bug statistics, and test failures in each of the main specification areas.
The methodology, tools used, and implementation guidelines employed will be described including the best practices learned along the way. The paper will also describe the technical and business benefits that have accrued using this approach and how they will be deployed throughout our company going forward.
Background
The ClearSpeed product range includes chips, accelerator cards, rack modules, software and support. ClearSpeed's chips, accelerator cards and rack modules are all designed to work with industry-standard x86-based systems. ClearSpeed chips are programmed in C and ClearSpeed offers the customer a complete IDE that works together with all the standard software development tools. This is diagrammed in Figure 1.
1. Overview of the ClearSpeed products.
Click here for a larger version
Figure 2 shows the architecture of ClearSpeed's CSX700.
2. ClearSpeed's current CXS700 architecture.
Click here for a larger version
Key:
HDP = Hardware Debug Port
CCBR = ClearSpeed Connect Bridge
BMON = Bus Monitor
ISU = Interrupt Service Unit
The main changes from the previous CXS600 chip are as follows:
- Two processor cores ("MTAPs") on one chip.
- A standard PCIe interface on the chip (vs. a proprietary PCIx-based interface).
- Several improvements to the MTAP.
Overall verification needs and strategy
Figure 1 above shows the architecture of the ClearSpeed product. Ensuring the quality of this complex product leads to the following features that required verification.
- Close integration of driver code with the chips.
- Integration with a number of software libraries and applications.
- Compatibility with a range of host (OS and chipset) environments.
- High performance and low power.
Regarding the chip itself the primary verification challenge was the newly introduced PCIe interface.
In order to accomplish these verification challenges, ClearSpeed employs a state-of-the-art verification strategy appropriate to the complex design under test. There are some major themes that can be readily identified in the overall verification strategy:
- ClearSpeed have been Specman users for a number of years and so the verification strategy is simulation-based with a coverage-driven pseudo-random approach.
- A hierarchical simulation strategy is used, starting at blocks and moving outwards.
- Co-simulation with software is important to help demonstrate the correctness of our product (where we regard the combination of hardware and software as our product) and also gives us a good head-start on Silicon bring-up when the chip returns. This can have a huge effect on our time-to-market.<;/li>
- The software co-simulation is also performed hierarchically, starting with drivers and moving out to applications.
- Verification re-use between blocks and hierarchy.
- The use of verification IP. This has the advantage of leveraging existing knowledge from domain experts and can potentially accelerate the development of the test bench.
The overall guiding verification principle is to derive the signoff criteria from business and technical objectives at the start of the chip development. Those signoff criteria are objective and can be measured using the appropriate metrics. This provides a number of advantages including the following.
- The ability for all interested parties to agree in advance the objectives for verification.
- The ability to track progress towards verification signoff during the project.
- The ability to measure the confidence at the tapeout.
In keeping with this, the CSX700 verification signoff criteria were defined in advance. The key metrics selected were as follows.
- Functional coverage targets:
- Achieve coverage of 100% in the priority 1 coverage targets.
- Achieve at least 95% coverage in all other coverage targets and review all un-hit coverage targets.
- All system level tests written and running.
- The prototype PCIe working in all available PCIe servers.
- Review the bug discovery rate to ensure that (in conjunction with functional coverage) we were approaching a point where we believed all the most important bugs had been discovered.
- Review any outstanding known unfixed issues and assess their impact.
We now discuss the PCIe verification strategy within the context of the overall verification strategy outlined above.
|
