Stats

  • Locked Locked
  • Replies 3
  • Subscribers 64
  • Views 16182
  • 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

SV Functional Coverage : Instruction sequence?

archive

Hi all,

When verify a CPU, I encounter a SV functional coverage problem.
I'd like to check whether there are some back-to-back instructions sequence happened that I am interested in.
Like the instruction sequence:
...
Inst_1 R1, R2
Inst_4 R3, R4
Inst_9 R2, R2
...
But how to define the cover_group? AFAIK, there are control coverage and data coverage, shall I combine them together to get the Instruction sequence coverage?

Another questions that always confused me: I have a transaction generator and monitor(which connected input driver). Shall I get coverage from transaction generator directly or from the monitor connected input driver? IMHO, they are the same. But, what's your opinion?

Any suggestions are welcome!

Best regards,
Davy


Originally posted in cdnusers.org by davyzhu
Parents

  • It seems to me that this kind of temporal (multi-cycle) coverage is exactly the kind of thing that SVA (or PSL) cover directives were designed to pick up. For example:

    cover property ( @(posedge clk) op == Inst_1 ##1 op == Inst_4 ##1 op == Inst_9 );

    Doing this in a covergroup would be more difficult. If you only need 1 cycle of memory, you could use some helper code and a cross product.

    reg [15:0] last_op;
    always @(posedge clk) last_op <= op;

    covergroup cg @(posedge clk)
    coverpoint op1: op;
    coverpoint op2: last_op;
    cross opxlast: op1, op2; // Only bin the pairs of interest and discard the rest
    endgroup

    As to your question about which to instrument, I too don't see any difference unless there was a way for the driver to swallow or otherwise alter an input transaction.


    Originally posted in cdnusers.org by TAM
Reply

  • It seems to me that this kind of temporal (multi-cycle) coverage is exactly the kind of thing that SVA (or PSL) cover directives were designed to pick up. For example:

    cover property ( @(posedge clk) op == Inst_1 ##1 op == Inst_4 ##1 op == Inst_9 );

    Doing this in a covergroup would be more difficult. If you only need 1 cycle of memory, you could use some helper code and a cross product.

    reg [15:0] last_op;
    always @(posedge clk) last_op <= op;

    covergroup cg @(posedge clk)
    coverpoint op1: op;
    coverpoint op2: last_op;
    cross opxlast: op1, op2; // Only bin the pairs of interest and discard the rest
    endgroup

    As to your question about which to instrument, I too don't see any difference unless there was a way for the driver to swallow or otherwise alter an input transaction.


    Originally posted in cdnusers.org by TAM
Children
No Data

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.