below is copied from cache, the link is dead
http://www.eite.org/Labs/modeltech64_10.2c/htmldocs/modelsim_se_user/a_code_cov21.html
FEC Coverage Detailed Examples
Following are examples detailing the default coverage (FEC) report tables.
Example 19-3. FEC Coverage - Simple Expression
Let's examine the following FEC report table for the expression (a & b & c) when it receives input vectors {101, 011, 111}:
# ----------------Focused Expression View-----------------
# Line 31 Item 1 < tempreg1 <= (a & b & c);
# Expression totals: 2 of 3 input terms covered = 66.6%
#
# Input Term Covered Reason for no coverage Hint
# ----------- -------- ----------------------- --------------
# a Y
# b Y
# c N '_0' not hit Hit '_0'
#
# Rows: Hits FEC Target Matching input patterns
# --------- --------- -------------------- -------------------------
# Row 1: 1 a_0 { 011 }
# Row 2: 1 a_1 { 111 }
# Row 3: 1 b_0 { 101 }
# Row 4: 1 b_1 { 111 }
# Row 5: ***0*** c_0 { 110 }
# Row 6: 1 c_1 { 111 }
#
# NOTE:
# * Order of matching input pattern values: {a,b,c}
Each FEC report consists of two tables;
•The first table reports coverage on a per-input basis. For inputs that are not covered, the report gives a brief reason for the lack of coverage. The “Hint” column provides information on how to get the input covered. In the FEC report above, input 'c' was not covered because the coverage bin '_0' associated with this input (i.e. c_0) did not receive any hits. The hint says that to get 'c' FEC covered, an input pattern matching c_0 (i.e. {110}) must be applied to this expression during simulation. Matching input patterns are always strings of 1’s and 0’s separated by whitespace.
•The second table goes a step deeper and expands each input into its coverage bins. The table lists the Rows, Hits, FEC Target and Matching input patterns. The matching input patterns are always strings of 1’s and 0’s separated by whitespace.
In the FEC report above, consider the first row containing the FEC Target (or bin) of a_0: where a is the input and _0 is the value of that input. The full tag of a_0 indicates that this row delivers FEC testing when a's value is 0. This bin was incremented 1 time, since the input vector {011} was seen. By definition a is 0 for every input vector on the a_0 list. Similarly, the input vector for the a_1 list - row 2 in the table - was observed once. Again, by definition, the a_1 list vectors are identical to the a_0 list except with the 'a' bit equal to 1. This is always the case for each pair of FEC rows (non-short circuit logic only).
Walking through the truth table in this way, one can see how FEC ensures that each input a, b, and c has been shown to independently affect the expression output. For example, for the conditions of FEC to be satisfied, when an a_0 input vector flips to the corresponding a_1 vector - i.e., only bit 'a' changes to 1, with the other bits unchanged - the output value of the expression MUST also change.
In effect, this type of coverage metric can help determine if there is a functional bug in the logic that is feeding the targeted input (FEC Target). It is a powerful tool in that it helps minimize the risk that an expression is masking potential bugs in the logic feeding each of its inputs.
If FEC coverage indicates any bins are missed (such as c_0 in Row 3 of Example 19-3) you know that none of your tests ever produced a value of ‘1’ when other inputs are in a state that allow it to control the output. You should then work on the design/stimulus to improve FEC coverage. One method of raising FEC coverage numbers is to modify test stimulus such that appropriate patterns appear at the expression's inputs. The matching input vectors in the report can help in this process.
Figure 19-3. Focused Expression Report Sample