 |

WHAT'S
HOT

Cadence SoC Functional Verification Kit online product demo
More »
SpeedBridge adapters for PCI Express, SATA, USB, PCI-X and Multi-Ethernet
More »
Plan-to-Closure Methodology reduces verification risk in any language
More »

UPCOMING
EVENTS

Cadence at DVCon 2008

SUBSCRIBE
Get on the mailing list of this
quarterly newsletter.
More »
FEEDBACK
We'd like to hear your comments
or questions about this newsletter.
More »
|
|
December 2007 Volume 6, Issue 4 |
| |
Verifying Checkers in an e Verification Component (eVC)
By
Sidhesh Patel, ASIC Verification Engineer, eInfochips
|
| |
e Verification Components (eVCs) have pre-defined checkers for checking whether any protocol violation has occurred or not. The checker itself, however, can have bugs (i.e., a checker fires wrongly or not at all, even though a violation has occurred). Overcoming this challenge requires verifying the checkers to ensure that they are all bug free and working correctly within your verification environment.
The most common method for verifying eVC checkers is to provide hookup in the BFM to inject violations, instead of working according to protocol. In other words, the required checker fires whenever the violation occurs. However, is this the best method for checker verification? Is there a better method for performing the same task? Let's take a deeper look at various options.
Example: According to protocol, master should assert IRDY when FRAME deassert.
Method 1: Normal method to verify checker for above rule.
The above method allows you to easily create violations, but it does come with a few drawbacks:
- It may add non-required code in your design
- It may also lead to a bug insertion in your design
- For creating all possible violations for the same check, you will require more than one hookup and its related coding in the BFM for each checker
Method 2: Generate violation with external entity/virtual sequence/monitor.
This method has many advantages and will help you avoid the drawbacks listed in method 1.
- Your violation code is an external entity, which will not add extra overhead to your design
- You can easily create various possible scenarios for violation of same checker
By following a few of these easy steps, you will find that verifying your checkers within your verification IP will help you streamline your overall verification environment development.
|
|
|
|
Unsubscribe
Cadence respects your online time and privacy. To unsubscribe from all future Cadence email communications, please reply to this message and type "UNSUBSCRIBE" in the subject line.
Cadence Design Systems, Inc.
2655 Seely Avenue
San Jose, CA 95134 |