0-In Announces Breakthrough Deep Counterexample Technology to Find the Toughest RTL Bugs Before Silicon.Business Editors/High-Tech Writers SAN JOSE, Calif.--(BUSINESS WIRE)--Jan. 27, 2003 Today 0-In Design Automation, the Assertion-Based Verification Company, announced a new formal verification technology called "deep counterexample" (DCE DCE - Data Circuit-terminating Equipment DCE - Distributed Computing Environment (OSF) DCE - Damascus Cutting Effect DCE - Data Capture Equipment DCE - Data Carrier Equipment DCE - Data Circuit Equipment DCE - Data Collection Event DCE - Data Communications Equipment DCE - Database Consultants Europe DCE - Dead Code Elimination DCE - Defense Combat Evaluation DCE - Defense Coordinating Element (MSCA) DCE - Delhi College of Engineering) technology. DCE technology eliminates essentially all tough bugs BUGS - Basic UXO (Unexploded Ordnance) Gathering System BUGS - Bayesian Inference Using Gibbs Sampling BUGS - Binary Units Generating Stress :-) BUGS - Birmingham University Guild of Students (Birmingham University's student union) BUGS - Bristol University Gas Scintillator of three critical bug types in complex ASICs and System-on-Chip (SoC) devices. The new technology is available in 0-In Confirm, a new product that is included in V2.0 of 0-In's Assertion-Based Verification (ABV ABV - Above ABV - absolute boundary value ABV - Abuja, Nigeria (airport code) ABV - Accredited Business Valuation specialist ABV - Afferent Branchial Vein ABV - Aggregate Breeding Value ABV - Air Blast Valve ABV - Air Bleed Valve ABV - Alcohol By Volume ABV - Alternative Boost Vehicle ABV - Annual Buy Value ABV - Assault Breacher Vehicle ABV - Auxiliary Building Ventilation) Suite. (See today's release entitled "0-In Announces New Products Based on Breakthrough Formal Verification Algorithms" for product details). Despite using more than half of total project resources for functional verification, most SoC devices have corner-case bugs in first silicon. Detecting, diagnosing and fixing such bugs is a difficult and time-consuming process that can cost millions of dollars and frequently causes chips to miss their market windows. 0-In's breakthrough DCE technology helps design and verification teams reach functional verification closure by finding tough RTL design bugs that are missed by every other verification method. Verifying bug fixes A revised program file or patch that corrects a software bug. See bug, patch and hot fix. with formal methods (mathematics, specification) formal methods - Mathematically based techniques for the specification, development and verification of software and hardware systems. Referentially transparent languages are amenable to symbolic manipulation allowing program transformation (e.g. changing a clear inefficient specification into an obscure but efficient program) and proof of correctness. Oxford FM archive. is faster and more predictable than with simulation alone. 0-In's DCE technology exhaustively verifies assertions to a much greater depth than any other commercially available formal verification product. In addition to finding tough bugs before tape-out, DCE technology can be used to verify that late-stage bug fixes are correct. Eliminating common bug types To achieve first-silicon success, designers must detect and eliminate various types of bugs. 0-In provides a full suite of ABV tools that address the following five bug types: 1. Control-logic corner-case bugs 2. Data loss across clock domains 3. Interface bugs (non-compliance and omission) 4. Low-probability, data-dependent bugs 5. Simulation-to-synthesis mismatches 0-In's ABV Suite combines effective assertion specification, easy assertion maintenance, efficient assertion checker simulation, leading-edge static and dynamic formal algorithms, and unique DCE technology to find essentially all of these bugs in complex chip designs. 0-In's DCE technology, focuses on three of these bug types: control-logic corner-case bugs, interface bugs (non-compliance and omission), and low-probability, data-dependent bugs. (See today's related releases for information on how 0-In handles data loss across clock domains and simulation-to-synthesis mismatches.) Control-logic corner-case bugs Many bugs that end up in silicon are due to a combination of control-logic corner cases that are not exercised during simulation. For example, a processor might fail when a particular instruction is in a specific pipeline stage at the same time that a data FIFO is full and a cache miss A failure to find the required instruction or data in the cache. In such a case, the item is read from main memory. See cache. occurs and a specific interrupt arrives. Only formal verification, with its ability to exhaustively explore all possible interactions of corner-case behaviors, can reliably detect this type of bug before first silicon. 0-In Confirm is the first product that is able to find essentially all such bugs pre-silicon. Interface bugs (non-compliance and omission) Bugs associated with complex interfaces can be very difficult to find, especially because the interface rules may not be fully understood by the design team. 0-In's ABV suite provides an effective solution for interface verification. 0-In's CheckerWare library provides a rich selection of protocol monitors, each of which captures all the rules of a single standard interface protocol in a format that is compatible with both simulation and formal verification. 0-In Check adds these monitors to simulation, allowing detection of any protocol violations. After simulation, 0-In Search and 0-In Confirm bring the power of formal verification to bear on the interface design using the same protocol monitors. 0-In Confirm uses DCE technology to find tough interface bugs that simulation misses, including bugs of non-compliance (i.e., protocol behavior implemented incorrectly) and bugs of omission (i.e., protocol behavior not implemented at all). Bugs of omission are particularly difficult to find using simulation because the test writer may be completely unaware of the omitted behavior and may fail to create any tests for it. Low-probability, data-value bugs Low-probability, data-value bugs require a specific data value to occur on a wide input variable during a specific cycle. These bugs require highly improbable stimuli and are unlikely to be detected in simulation using hand-written or pseudo-random tests. 0-In Confirm uses DCE technology to home in on exactly the right value in exactly the right cycle, exposing essentially all low-probability, data-value bugs. About 0-In 0-In Design Automation, Inc. (pronounced "zero-in") develops and supports functional verification products that help verify multi-million gate application-specific integrated circuit (ASIC) and system-on-chip (SoC) designs. The company delivers a comprehensive assertion-based verification (ABV) solution that provides value throughout the design and verification cycle -- from the block level to the chip and system level. Twelve of the 15 largest electronics companies have adopted 0-In tools and methodologies in their integrated circuit (IC) design verification flows. 0-In was founded in 1996 and is based in San Jose, Calif. For more information, see http://www.0-in.com. Note to Editors: 0-In(R) and CheckerWare(R) are registered trademarks of 0-In Design Automation, Inc. |
|
||||||||||||

Printer friendly
Cite/link
Email
Feedback
Reader Opinion