Section 1. Introduction

: This documentation is specific to the development of the Covered tool. For usage-specific information, please consult the Covered User's Guide which is accessible via tarball download or off of the Covered homepage.

: Welcome to Covered development! Since you are reading this document, it is assumed that you are either on the development team, looking to join the team, or are just interested in some of the "under the hood" technical details about how Covered is intended to get the job done. This document will seek to specify the overall project development plan; coding methodologies; project communication guidelines; programs/utilities needed for code development and documentation generation; the code's "big picture"; the nitty-gritty details for all structures, functions and defines; testing procedure; and some odds and ends information. This document will serve as a technical reference as well as the "Covered constitution" on programming guidelines for this project.

: But first of all, what is the purpose of this project? Covered is a Verilog code coverage analyzation utility that allows a user to examine the effectiveness of a suite of diagnostics, testing a design-under-test (DUT). The goal of Covered is to allow the user to determine the amount of verification "done-ness" by examining several metrics: line, toggle, memory, combinational logic, FSM state/state transition, and assertion coverage. Each of these metrics are useful for finding logic that is currently unexercised, bits that are not toggled on/off, memory locations that have not been written/read, untested logical conditions, untraveled state machine states and/or state transitions, and unhit OVL cover assertions. Covered is not intended to inform the user if the logic works correctly, however.

: The key to answering these questions about coverage is done in two ways. First, a concise summary report is generated to indicate percentages of cases for each metric that were hit (tested) or missed (untested). This quick reference can give the user a sense of how far along a testsuite is and also how useful (in terms of added coverage) a diagnostic is to the testsuite. Second, a verbose/detailed report is generated to show the user exactly what logic was not tested and potentially why it was not tested. This information is important to help the diagnostic writer understand how to test the design better.

: By using the information contained in the summary and verbose reports, a design tester can feel more confident about the effectiveness of a testsuite (as it relates to the amount of code that it tests) and they can be guided to areas of the logic that still require testing in a more focused fashion.

Go To Section...