TABLE OF CONTENTS | Note | Simulation must be managed. |
In "Revision Control" on page 61, I described how tools can help manage source code. In "Issue Tracking" on page 66, I described how issues and bugs can be tracked to ensure they are resolved. In this chapter, I address the simulation management issues. I describe how to debug your testbenches efficiently using transaction-level models. Often overlooked but important topics, such as terminating your simulation, reporting errors and determining success or failure are covered. We also discuss configuration management: How do you know you are simulating what you think you are simulating?
This section demonstrates how transaction-level models can benefit a design project. These benefits can be realized only if the model is written with the proper perspective. This section also shows how to model exceptions properly and explains how to demonstrate a transaction-level model to be equivalent to an RTL model.
| Note | Testbenches need a model to be debugged. |
You have decided which testcases and functional coverage measurements are needed to verify a design functionally. Your best verification engineers are developing the verification harness, self-checking structure and random-generators. Hardware design engineers are working furiously on the RTL model, but it will not be available for several weeks. Meanwhile, the verification harness and self-checking structure continue to be written. When all is said and done, the amount of code written for the verification will surpass the amount of RTL code. You are looking at writing thousands of lines of code without being...
