 |
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 |
| |
Implementing Error Injection Capabilities in the Verification Environment
By
Sidhesh Patel,
ASIC Verification Engineer,
eInfochips
|
| |
Error injection is a technique that helps users identify the worst cases around the DUT (Device Under Test), and check how it behaves. Error injection has become an essential part of the overall verification process. By properly implementing error injection users should be capable of generating errors from the TX (transmission) side and be able to predict the response at RX (receiver) side.
However some issues may come up when implementing Error injection capabilities:
- Generally it is easy to drive errors, but it can be difficult to make a response predictor at receiver side.
- Because of the many kinds of erroneous packets in serial packet protocol, it can be difficult to make TX and RX in synchronization throughout simulation, and as a result there might be unwanted score boarding issues during simulation.
To overcome such problems, RX should be smart enough to catch the proper packets, and recognize the types of errors (if any) and do the score boarding properly.
As shown in the block diagram, we should have a Configuration module in verification at the global level that will give information to the TX and RX (like which packet to send, good or bad—if bad packet, then which error to inject and what will be the response from DUT). After all initial configurations, the Driver starts driving the erroneous packets to the DUT and the DUT drives the response while the monitor captures the response and helps with the configuration module. The monitor tags that packet with information required for the score board to precede packets (with errors).
In the case of serial Ethernet packet transmission, we generate an Ethernet packet that doesn't have a SOP (Start of Packet) encoded it into 10 bit codes, and then send it to DUT. The DUT (which is XAUI (10 bit data) -> XGMII (8 bit data) converter) samples this packet and drives error code (/E/), which is 8'hFE on the output interface for each data in the packet (as per protocol). The configuration module monitor will be asked to check whether the DUT drives 8’hFE on the output interface. Ideally, when receiving the 8’hFE the monitor should shout with errors (because it is capturing error patterns from DUT), but with the help of the configuration module monitor it will shout if it doesn't receive the error pattern (from the DUT) since it is expected because the input packet had no SOP.
Advantages over traditional methodologies
Using this kind of configuration module for injecting errors or generating good packets has been helpful for score boarding of all kinds of packets. This technique has the ability to avoid synchronization issues between the TX and RX. It also controls over the checkers written inside the monitor. Verification engineers only need to configure the type of packet and type of error from the test case, all the remaining effort is taken care of by the configuration module (as per protocol). The bottom line is that verification engineers won’t have to look into the environment to set the expectations each and every time.
Conclusion
By using the configuration module (for driving good or erroneous packets) verification engineers’ jobs become much easier because they don’t have to bother with driving logic, the smart logic of response predictor, and most important the synchronization issues between TX and RX each and every time. With proper error injection integration within the environment, overall verification development becomes much more manageable for the test engineer.
|
|
|
|
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 |