Pre Silicon Validation Whitepaper | Verification And Validation | Central Processing Unit

Pre-silicon Validation

Alakesh Chetia, Sr. VP, Business Development Robert Birch, Chief Technology Officer TransEDA

Technical Backgrounder

Introduction Pre-silicon validation is generally performed at a chip, multi-chip or system level. The objective of pre-silicon validation is to verify the correctness and sufficiency of the design before sending the design for fabrication. This approach typically requires modeling the complete system, where the model of the design under test may be RTL, and other components of the system may be behavioral or bus functional models. By subjecting the design under test (DUT) to real-world-like input stimuli, pre-silicon validation aims to: • • • • Validate design sufficiency Validate design correctness. Verify implementation correctness. Uncover unexpected system component interactions.

Results Checking While it may be relatively easy to generate activity or stimulate the different ports or interfaces of a chip, the difficult part is to implement an automated results or data checking strategy. A system-level pre-silicon validation environment should relieve test writers from maintaining or keeping track of the data in test code to make the task easily manageable for a multi-ported system. Keeping track of the data becomes arduous when different agents in a system interact on the same address segments. Automated Test Generation The test creation and/or generation methodology is critical in building a system level pre-silicon validation environment capable of generating real-world-like stimuli. The test generation methodology is closely interrelated to the results checking strategy. A dynamic test generator and checker are more effective in creating very interesting, reactive test sequences. They are more efficient because errors can be detected as they happen. In a generate/run/post-process method, one may run a simulation for eight hours, only to find during the post-process checking that an error occurred 20 minutes into the simulation, with the balance of the simulation time being useless. An automated test generation tool should be capable of handling directed testing, pseudo-random testing and reactive testing. In directed testing, users specify the sequence of events to generate. This is efficient for verifying known cases and conditions. Pseudo-random testing is useful in uncovering unknown conditions or corner cases.

To achieve the goals outlined above a system level environment is required with special emphasis for handling the following situations. Concurrency Most complex chips have multiple ports or interfaces and there is concurrent, asynchronous and independent activity at these ports in a real system. A system-level verification environment should be able to create and handle such real-world concurrency to qualify as a pre-silicon validation environment. Concurrency needs to be handled in both the test controller and the bus/interface models used. Some models will return data when a transaction completes, so the test controller or environment can do data checking. Other models require the expected data to be provided up front so the model can do data checking when the transaction completes. Such behavior impacts the test checking methodology and the amount of concurrency that can be generated.


© 2001 TransEDA

the system must be tested with all possible variations in cycle timing that is allowed by the device specification. So. Further. Robust. Also. To fully validate adherence to a bus protocol. and to randomly vary delays and cycle relationships. which includes such items as bus functional models (BFMs) and protocol monitors.Pseudo-random test generation. Sometimes models generate or respond to signals on the bus with the same timing and do not provide programmable controllability. the test code or an additional layer of abstraction needs to handle such situations making the test writing more difficult and time consuming. Reactive test generation implies a change in test generation when a monitored event is detected during simulation. but not automatically handle deferred transactions and retries. where transactions are generated from user-defined constraints. An Architecture for Pre-silicon Validation We present here a case study of a pre-silicon validation environment set up to verify several versions of a bridge device connecting CPU with memory and I/O interfaces. it runs the risk of making the same wrong assumptions. is greatly enhanced with robust. a higher abstraction (such as transaction level) is required in the model API so that system level tests can be generated or created easily it is equally important to provide in the API low level signal timing control. a processor BFM may simply drive transactions on the bus. This means that the test generator should be able to change the timing of the models. High-quality Verification IP The quality of verification. Dynamic test generation also facilitates reactive test generation. can be interspersed with blocks of directed sequences of transactions at periodic intervals to re-create real-life traffic scenarios in a pre-silicon validation environment. For example. high-quality verification IP. the rate of maturity of an internally developed model is much slower than a commercial model that has been used by multiple independent design groups. and therefore the probability of shippable first-pass silicon. In such a case. such as data latencies and wait states. while on one hand. the models need to operate in a mode that fits into a pseudo-random test methodology. Simulation Enviornment CPU Model Communication Layer Test Templates Test Controller & Data Checker CPU I/F Custom Logic I/O I/F Mem I/F I/O I/F Memory Model Coverage Metrics PCI Model AGP Model . While this is sometimes required for proprietary interfaces. Whether the design team builds or buys the verification IP. Models must operate at the appropriate level of abstraction. A common mistake is to require the project group that develops the RTL to also create the verification IP used to verify the RTL. concurrency and programmable controllability. they must ensure that the models can fit into the test generation and checking strategy that is adopted. Models that load and execute a pre-compiled test sequence do not work in an environment where one can dynamically generate and check tests.

* Configurable and Extensible: It is easily configurable and extensible allowing pre-silicon validation of multiple different configurations. for a user specified sequence. * Bus Protocol Monitors: The intelligent bus protocol monitors provide dynamic protocol checking and can be used in automated test generation environments. * Test Controller and Data Checker: The intelligent test controller utilizes BFMs and transaction generators to create constraint-based concurrent sequences of transactions at the different interfaces of the DUT. Being a dynamic test generator it can handle reactive test generation as well. Salient Features Some of the major features and characteristics of this environment are as follows: * Concurrency: It handles multiple concurrent. It is done automatically and transparently. The controller can generate transactions pseudo-randomly. * Robust.Verification components The major components of this pre-silicon validation environment are: * Bus Functional Models: The intelligent BFMs provide a transaction-level API. * Leveraging Design and Application Knowledge: It leverages application-specific knowledge so that only the pertinent application space is tested. and are designed to handle concurrency and parallelism. * Reusing the Test Environment: This architecture allows easy test and environment reuse. * Ease of Use: It is easy to use and intuitive without requiring the learning of a new language or methodology. High-quality Verification IP: The intelligent models and monitors provide appropriate level of abstraction and controllability for effective system level pre-silicon validation. An example application outlined the pre-silicon validation of a bridge device noting the use of BFMs. which can be used to provide dynamic feedback to user tests or automated test controllers. They are extensible to accommodate user-defined sequences. the controller provides for automated and dynamic data checking. monitors and an intelligent test controller and data checker. This makes it suitable to be used in an automated test generation environment. * Automated Test Generation: The intelligent test controller and data checker can handle user specified directed tests with automated data checking and/or automatically generate pseudo-random sequences of transactions with automated data checking. or a mix of both. It provides a consistent programmer’s view. They provide dynamic bus state information. Conclusion Pre-silicon validation requires a well thought out and proven strategy and helps achieve shippable first-pass silicon. The test writer does not need to write code to do data checking. Replacing the appropriate models and monitors easily validated subsequent generations of the DUT. It also offers a high degree of controllability for the model behavior to emulate a real device with real operating characteristics through programmable delay registers and configuration registers. * Results Checking: It has a built-in shadow memory system to handle automatic results checking. asynchronous and independent generation of transaction sequences at the different interfaces of the DUT. . The key features to consider about a system-level pre-silicon validation environment are concurrency. In addition to test stimuli generation. It can also perform specific tasks or dynamically reload input constraints upon a certain event occurring during simulation. high-quality verification IP. automated test generation and results checking and. intelligent models and monitors comprising proven.

Sign up to vote on this title
UsefulNot useful