Functional coverage constraints

Coverage
,
1

Hi, I am going through the Functional coverage concepts in cookbook. I got a doubt when I read this paragraph

Functional Coverage should be based on observation:
The stimulus side of the testbench should be used to drive the DUT, the stimulus side should not be used for coverage because the DUT or the stimulus may not work correctly resulting in false coverage. Instead the functional coverage should be based on what is observed to happen at the DUT outputs in the testbench. In a UVM testbench, the functional coverage would be based on the content of analysis transactions. This has implications on the design of the testbench and the analysis transactions.

My question is, while writing the covergroups only the output signals can be included or both output & input signals can be included as coverpoints?

For example: I have a dual port synchronous RAM, it has clock, data_in, read_address, write_address, reset as inputs and data_out as output. While I write my functional coverage model, can I include the input signals for functional coverage?

2

In reply to kireeti1192:

Yes you can include the input signals for functional coverage, it means you have generated enough data to check the toggling of various input ports, various input conditions.Like in your case different addresses could be exercised,reset.You can even create crosses for your case.

3

In reply to svats:

In reply to kireeti1192:
Yes you can include the input signals for functional coverage, it means you have generated enough data to check the toggling of various input ports, various input conditions.Like in your case different addresses could be exercised,reset.You can even create crosses for your case.

In this paragraph, it is written that the stimulus side should not be used for coverage:

Functional Coverage should be based on observation:
The stimulus side of the testbench should be used to drive the DUT, the stimulus side should not be used for coverage because the DUT or the stimulus may not work correctly resulting in false coverage. Instead the functional coverage should be based on what is observed to happen at the DUT outputs in the testbench. In a UVM testbench, the functional coverage would be based on the content of analysis transactions. This has implications on the design of the testbench and the analysis transactions.

4

In reply to kireeti1192:
IMHO, the cookbook wording is a bit strong. The problem is when people rely on input functional coverage without following through on functional verification. For your example, it not enough to cover the fact that you applied reset to your RAM, but that the reset actually changed the contents of the RAM correctly.

I’ve seen many places where input coverage gets captured for sending different configurations to the DUT, but there is no test verifying that the DUT actually went into that mode. In some cases you have to look into the DUT (whitebox) to figure that out, but sometimes that is not possible.

5

In reply to dave_59:

Thanks Dave.
QI:
For instance, I have verified all functionalities of RAM with multiple testcases. Then I have started functional coverage model. Now while writing the covergroups can I include both input and output variables in coverpoints?

Q2:
Input variables are reset, write_addr, read_addr, data_in. Output variable data_out.

I have written coverage model in two ways. In theses two models which is better?:
1:
covergroup address_covered@(posedge clk);
ADDR:coverpoint read_addr;//read_addr is a input varilable
endgroup
covergroup write_data_covered@(posedge clk);
DATA_IN:coverpoint data_in;
endgroup
covergroup read_data_covered@(posedge clk);
DATA_OUT:coverpoint data_out;
endgroup

2:
covergroup writing_to_ram@(posedge clk);
ADDR:coverpoint write_addr;
DATA_IN:coverpoint data_in;
endgroup

covergroup reading_from_ram@(posedge clk);
ADDR:coverpoint read_addr;
DATA_OUT:coverpoint data_out;
endgroup