Shortening Verification Time Using the CoverAll ™ Toolset to Automate Assertion Based Verification - Logical and functional bugs continue to be the leading cause of costly silicon re-spins. These bugs generally fall into three
categories. First, the function wasn’t tested. Second, the function wasn't checked. Lastly, the function wasn't tested or
checked because it wasn’t defined. Many people have spent countless hours trying to address the first case, testing everything. The problem is not the inability to write enough tests or to randomly stimulate everything. The problem is the ability to define what to test and to prove that it has all been tested. Until now, someone had to translate the high level specification into a verification plan, execute it, and hope there’s enough coverage in the plan to ensure a working device. The second case, checking for correct behavior, usually occurs when one engineer designs a function and another verifies it. The designer fails to convey enough information about how the logic is supposed to work to allow it to be accurately checked. The difficulty is to come up with a way to check the RTL without just rewriting it in a different language. The problem with this approach is obvious; the bug will be in both representations. Until now, this has been the major obstacle in checking functionality.
The last case, not tested and not checked occurs because the function is not defined, the inputs don’t function as described and the specification did not define what happens in that case. The designer designs only what’s defined and the verification engineer tests only what’s defined. But what happens when the inputs do not work as specified? Does a packet get dropped when dropping packets is not allowed OR does it lock up… Oh no! (re-spin bug). Until now, it was up to the architect writing the specification to cover all cases, even the invalid ones. Solid Oak Technologies has developed a methodology which solves these three issues, using tools designed to automate the solution and shorten the time to verification complete. Today a designer can completely define a function with flow diagrams and timing diagrams utilizing Solid Oak’s easy to enter and modify graphics tool, CoverAll™, compile them in seconds, and have a complete set of assertions and coverage statements to verify the function to 100% coverage. How does this address all three issues? read more
|The Importance of Path Coverage in Completely Defining Functional Coverage - What determines when an ASIC is ready for tape out or an FPGA is ready for production? The basis for this decision has evolved as new methodologies and tools have evolved. Code coverage was one of the early metrics used to determine when testing was complete. While easily integrated into the flow, code coverage quickly proved to be an inadequate metric. Functional coverage has become the frontrunner for determining verification complete. The arduous task of defining functional coverage presents the next obstacle. In modern flows, engineers have to translate the high level specification into a verification plan, execute it, and hope there’s enough coverage (and time) in the plan to ensure a working device. Solid Oak Technologies has developed a methodology using tools designed to automate the creation of the functional coverage metrics and shorten the time to verification complete. Today a designer can completely define a function with flow diagrams and timing diagrams utilizing Solid Oak’s easy to enter and modify graphics tool, CoverAll™, compile them in seconds, and have a complete set of assertions and path covers. read more