Stats

  • Locked Locked
  • Replies 5
  • Subscribers 65
  • Views 11300
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Enabling code coverage deeper into SV function calls

efisherdukosi

Hi all, 

I have a package of functions, many functions have a test case associated with them that exercises that function over most of its input variables.

The design also contains two RTL modules (encode and decode) with normal clock, reset, input and output data ports which act as wrappers calling functions from the package.

- The decoder module for example takes encoded input data, calls three functions from the package and registers the decoded output data. The combination of the decoder called functions is tested over any 1 bit error, and multiple 2 bit errors over a large variety of data inputs toggling all bits of the input encoded data.

However code coverage results viewed by IMC seems to concentrate only on the two RTL modules in the design database and ignores code coverage of the functions that have their own test cases. Consequently I get 100% block coverage and 100% toggle coverage for the two RTL blocks, but I get 0% code coverage for any of the functions. This is despite the coverage database being a merger of all of my test cases, many of which provide a function with test data and expected results data. All test cases pass.

Statement coverage is enabled, select_coverage -all is also used.

I thought it may need set_subprogram_scoring and set_expr_scoring however these have no effect.

In IMC, the package is shown, as is the testbench. For the two RTL modules (encode and decode) it shows 100% expression coverage, but never goes into the functions that are called. I'd have thought it would explore into the called function and show that line xyz of that function wasn't covered etc. I seriously doubt the function was actually 100% covered, I was expecting something like 95% and the need to add another test case for some combination of 2 errors etc I'd have forgotten.

Any ideas?

Thanks

  • in reply to StephenH

    Hi, yes, I have set_sub_program_scoring set to -all.

    Could this be an issue with the test cases for the functions presenting their test vectors directly to the functions rather than via the two clocked RTL blocks?

    As an example, my 1 error injected decoder test case, calls the encoding functions, injects an error into the encoded data and then calls the decoding functions. 

    Effectively, while I have a DUT for the testbench formed of the encoder/decoder pair, each function is called as a separate DUT for its test case. Test case tc_fun1 calls fun1() for example, it doesn't pass data to the testbench encoder/decoder pair, that is performed later.

    Despite that, the test case does exercise that function pretty comprehensively.

  • in reply to efisherdukosi

    The -all option means "used and unused functions in modules".

    You specifically have to add the -svpackages option for coverage of functions in packages.

    Please can you share a small example that represents your problem, or if that's not possible, consider filing a support case at support.cadene.com so that you can share more confidential details there. 

  • in reply to StephenH

    Hi Stephen, unfortunately -svpackages had no effect.

    To control the coverage we have a -covfile cov.ccf, this includes the following. Being new to these options I am wondering if something is preventing function coverage within the included packages.

    select_coverage -all

    select_functional

    set_implicit_block_scoring -off

    set_explicit_block_scoring -off

    set_code_fine_grained_merging

    set_toggle_scoring -sv_enum

    set_toggle_scoring -sv_mda 16 -regeot

    set_parameterized_module_coverage

    set_libcell_scoring -enable_vy

    set_expr_scoring -max_expr_terms 2048

    set_expr_coverable_operators -bitwise -relational -reduction -logical_not

    set_expr_coverable_statements -all

    set_statement_scoring

    set_branch_scoring

    set_fsm_scoring -hold_transition on

    set_subprogram_scoring -all -svpackages

    set_refinement_resilience

    set_optimize -top_expr_non_scorable

    set_optimize -prune_covergroup

    For the encoder (running the test case for the encoder function), the tool reports that all blocks, statements, expression and toggle for the decoder RTL module are covered. But.. this is for the encoder module itself and does not descend into the function call despite -svpackages being set above.

    Clicking on toggle coverage for the encoder RTL module, I get a very high figure of 100%. Inspecting this (below). This is a bit of a misnomer. The tool shows that for the function call in question, ecc_hamming_encode(), the signal i_din and output signal w_ecc_out show 100% toggle coverage. But the tool never descends into that ecc_hamming_encode function which is some 60+ lines. 

  • in reply to efisherdukosi

    SOLUTION:

    There were two issues. My testbench for functions, effectively side stepped the main testbench that passed signals to the encode/decode pair that were the main DUT. This was done to allow me to test individual functions that may or may not have signals that are ports of those top level modules. However this presented issues with tools discovering toggling behavior etc.

    The set_subprogram_scoring needed both the -all and -svpackage options. There seems to be some versions/documents that state this to be -svpackages, with an 's' and some with -svpackage, without the 's'.

    For some reason, the select_coverage -all at the top of the cov.ccf file presented an issue too, but this may be installation specific. If  replaced with select_coverage -block -expression -toggle, this seemed to work correctly.

    Rather than code coverage being reported in dut.encoder.encoder_function, the code coverage of the package was shown separately from the main TB and DUT. The package reports 81% covered in my case, however it does provide not-covered warnings for functions that are unused by the current DUT. So in all a bit of a mixture. The package's code coverage will be artificially a bit too low as some of those functions are not needed for the current DUT.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.