Coverage collection of algorithmic IP conducted in the sequence

Hi,

I am looking for ideas/papers, for the next case:
Started working on legacy IP - Imaging and video processing IP.
All the blocks in the IP have a reference model handled by an algorithms team, let’s call it frame_simulator.
Not a C code, nor SystemVerilog based reference-model.
Something complex involving lots of tools developed in-house.

Problem is that the functional coverage is collected based on values/points of interest from the sequences(uvm_sequence) :(
Not from monitor, nor from reference-model (since no RM is present for the verification engineers).
Same values of registers are injected both to RTL and the frame_simulator, and both receive same frames.
Eventually, output of simulator is compared with the RTL output collected.

Looking for any ideas to change this horrible idea of collecting coverage from the sequences.
Reaching members of Verification Academy to hear/exchange ideas.

Thanks in advance,
Michael

In reply to Michael54:

If we will be collecting coverage from the RTL itself - maybe it sometimes referred as “white-box coverage” or “RTL coverage”, will it be a good idea?

In reply to Michael54:

This, like code coverage, is considered a necessary but not sufficient metric. It might be too optimistic. A typical argument on relying on sequence/stimulus coverage is:

The DUT is in Mode “A” and a sequence is requesting it to go to Mode “B”, but the DUT refuses the request for a valid reason.

So you need to add at least two more functional coverpoints, one for the case where the request was refused, and another for when it is accepted. You can only determine that by looking at the output of the DUT.

In reply to dave_59:

Thank you very much Dave for the answer! :)

I have few questions, will appreciate your help:

  1. Where can I find all required metrics?
    And which are considered as sufficient/not-sufficient?
    Maybe also some kind of prioritization among the metrics?
  2. The quote you have mentioned, where it was taken from?
  3. We are looking for some code examples for the RTL coverage, syntax, best practices.
    Maybe you have some examples we can use to learn from? Or some papers/blog posts? Most of examples in the Coverage cookbook are for functional coverage.

Thank you in advance,
Michael

In reply to Michael54:

So as your coverage is collected from Sequences, that means yyour environment vertical reuse it broken. You cannot use your test env. in higher levels like top or integration level.

Is this the main reason why you want to collect covergae from monitor?
If there is other reason can you please explain.

Now about how to change.
I guess the interest points you cannot get from interface, hence the monitor is not able easily measure the coverage using only interface object. Is my assumption right?

If yes,
So here you have following choices

  1. implement all the logic in monitor using only interface object
  2. do white-box covergae as you said. Than from monitor you need to use bind command and do binding the coverage collectors to RTL. This would take tons of time, but can work.
  3. Ask RTL developer to generate some interface signals for you, where you can easily measure the coverage. Or you manually add your blocks in RTL to measure coverage.