|
Our passion to achieve high quality silicon led us down a new road when it came time for functional verification of a project larger than any previous ASIC in our team's history. In this paper we describe why our functional verification methodology yielded functionally robust silicon that has our customers begging for production parts.
Although we could endlessly blather about our design verification methodology, if our ASIC came back from the fab showing no life or demonstrating mediocre quality, well, the blather would be meaningless, right? But that's not what happened. We plugged our ASIC onto a demonstration board and it worked. After rigorous silicon validation we realized that we have hit the goal to produce robust functional silicon with no surprises! We passionately pursued this goal while deploying Cadence's Specman eRM verification methodology on this PCI Express Switch ASIC project. We would love to take you back into the Lab where we have all 4 ports on our PCI Express switch pumping a huge amount of traffic and driving 8 simultaneous videos on the LCD. Seeing it work is worth a million words and achieving robust functional silicon is priceless!
Our Challenge
The PCI Express Switch project was launched in 2004. It would be a chip much larger and much more complicated than projects tackled in our team's history. Also, the PCI Express protocol presents its own challenges and complexities over its precursor, the PCI protocol. The switch would be our first 3+ million gate design with multiple physical layer interfaces, or PHYs , on-chip and containing a large number of memories. Since it was a platform development effort it had additional challenges to support deployment of future flavors with feature variations such as configurable number of ports and throughput levels. Coupled with the physical complexity, came a tremendous amount of behavioral complexity. Meeting PCI Express compliance would become a major effort especially if we wanted our first silicon to be marketable. Just getting the device powered up and initialized, traversing all the power-up states and combinations, is a phenomenal verification effort in itself. And with that begs the question, "How do we verify the millions of combinations of states that this device can go into?"
For the most part, verification efforts on previous projects utilized directed test cases. Directed tests are typically created to exercise a very specific feature, often re-using identical initialization patterns from other tests to get the DUT to a known state, then injecting a single, basic transaction—all of this done with the checking built into the test. However, given the enormity of the problem, we did not have the time or resources needed to write each test to exercise each individual feature.
We were also concerned that after design changes we would not be sure if the tests are still hitting their intended target? Changes in the design might make directed tests ineffective and require them to be modified. The bottom line was that we did not want to get tied down writing directed tests.
The areas we didn't think about also concerned us; corner case scenarios reflecting an unthinkable combination of events could become a show-stopping bug. It was quickly apparent that we needed some type of test generation automation system which would create more stimulus combinations from each simulation, but de-coupled from the checkers whose responsibility were to enforce proper DUT behavior. The environment would need to be intelligent, create behavior in a realistic manner and know what it can and cannot do. It was also important to have a flexible test development flow that allowed us to create a general flow of events which mimicked the normal chip behavior while also providing the ability to randomize interesting behaviors, effectively creating different flavors of that flow.
Because we were planning to take advantage of automated test generation, the understanding of what functional behavior the tests exercised, and more importantly the combinations of features it exercised, would be a cornerstone to our verification process. Functional coverage would be our driving force and our measurement of completeness. This is how would we know if the tests were still hitting their target.
Using a bottom up approach, verifying the individual modules first and then moving vertically upward to verify the entire chip, we felt was a good approach. Thus, we needed to develop module based verification environments that could be easily reused at the chip level. Also, we needed an environment that could be reused and reconfigured to verify derivatives of this switch. This would help us scatter initial development costs over a family of similar products by avoiding having to recreate the verification environment every time.
|
