![]() |
![]() |
![]() |
![]() 11 |
|||
|
||||||
Due to Covered's method of abstracting coverage from a dumpfile, a partial "resimulation" of the design is needed to obtain proper statistics for line, combinational logic and FSM metrics. Therefore, accurately resimulating what occurred in the actual simulation is a requirement for obtaining correct results. This can be easily achieved so long as the design doesn't contain any code that could result in potential race conditions. |
||||||
To avoid this problem Covered performs automatic race condition checking on the specified design after parsing has been completed but before simulation/scoring is performed. All statement blocks in the design that don't adhere to certain coding guidelines are removed from coverage consideration by Covered. By following these coding guidelines, a design should be void of race condition scenarios that would lead to faulty simulation results. The following coding guidelines are applied by Covered when checking for race conditions: |
||||||
Coding Guidelines to Eliminate Race Conditions |
|
|||||
If Covered detects a block as violating any one of the above mentioned coding guidelines, it will do one of two things depending on options specified to the score command by the user. |
||||||
|
||||||
The first mode of operation is the recommended mode of operation as this will allow Covered to continue calculating coverage information for the design while still providing accurate coverage information for the logic that is still under consideration. The second mode of operation is meant to allow the user to use Covered as a race-condition checking tool. |
||||||
Even though race condition information is displayed (assuming the -rS option was not specified in the score command-line) during the scoring process, it may be convenient to view this information in a generated report as well. Because of this need, Covered saves all race condition information to the CDD file for use in using the report command. By specifying 'r' in the -m option to the report command (race condition report output is not turned on by default), the statement blocks which were eliminated from coverage consideration will be output to the coverage report file. Summary coverage will contain the total number of statement blocks eliminated for each module. Verbose coverage will contain each eliminated statement block, organized by module, specifying both the starting line of the eliminated statement block and the reason for why the statement block was removed. |
||||||
Though highly discouraged, Covered does have a means to skip the race condition checking step altogether for situations where the user does not believe race conditions to exist in their design and does not want Covered to automatically throw out those procedural blocks for Covered consideration. The advantages to doing this are: |
||||||
|
||||||
Of course, with these advantages comes a risk. If code is deemed to not contain any race conditions but does indeed contain one or more, the coverage numbers may be flawed, and these types of "errors" are not assumed to be Covered bugs. With all of that said, to ignore race condition checking completely, simply add the '-rI' option to the score command-line. | ||||||
[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 ] License: GPL This Manual was originally created with ManStyle. |