- Section 2.1. Project Goals for Usability
- The goals of the Covered project as it pertains to its users are as follows:
- Have the ability to parse all legal Verilog, Verilog-2001 and SystemVerilog code as defined by their individual LRMs.
- Generate concise, human-readable summary reports for line, toggle, memory, combinational, FSM state and arc, and assertion coverage in which a user may quickly discern the amount of coverage achieved.
- Generate concise, human-readable verbose reports for line, toggle, memory, combinational, FSM state and arc, and assertion coverage in which a user may easily discern why certain coverage results did not achieve 100% coverage. Verbose reports should contain all information necessary for diagnosing the cause for lack of coverage without being excessive in the amount of information provided to aid in readability.
- Allow the ability to easily merge generated Coverage Description Database (CDD) files to allow users to accumulate coverage results for a particular design.
- Have the ability to parse designs, generate coverage results, and generate reports via command-line calls and through the use of a GUI.
- Provide sufficient user documentation to understand how to use the tool and understand its output.
- Provide users with additional ways to get questions answered and submit bug reports/ enhancement requests via the following mechanisms: FAQ, bug reporting facility, mailing list, user manual, and Homepage "News" section.
- Section 2.2. Project Goals for Development
- The goals of the Covered project as it pertains to ease in development are as follows:
- Write source code using C language using standard C libraries for cross-platform compatibility purposes.
- Maintain sufficient amount of in-line documentation to understand purpose of functions, structures, defines, variables, etc.
- Use autoconf and automake to generate configuration files and Makefiles that will be able to compile the source code on any *NIX-like operating system.
- Use CVS for project management and file revision purposes, allowing outside developers to contribute to source code.
- Use the Doxygen utility for generating documentation from source files that is used for development reference.
- Develop self-checking, self-contained diagnostic regression suite to verify new and existing features of code to assure that new releases are backwards compatible to older versions of the tool and that new features have been tested adequately prior to tool releases to the general public.
- Provide sufficient development documentation to allow new and existing developer's to understand how Covered works, the procedures/practices used in the development process and other development-specific information.
- Provide developer's with a means of communicating project ideas, status or other announcements to other project developers via the following mechanisms: CVS, mailing lists, and bug reporting facility.
- Section 2.3. Project Goals for Distribution
- The goals of the Covered project as it pertains to ease in project releases and distributions are as follows:
- Provide source code in tarball format (tar'ed and gzip'ed) which will be accessible via the Covered homepage.
- Provide any links to RPMs, Debian packages, etc. that others provide for the project.
- Generate new releases/information on a timely basis so that users of the tool do not question whether development is still occurring with the project.
- Generate stable releases for users.
- Generate development releases in CVS for branching and regression purposes.
- Verify that user documentation does not become stale but rather is synchronized with the current release.
- Go To Section...
-
Generated on Sun Nov 21 00:55:42 2010 for Covered by
1.6.3