Home > Community > Forums > Functional Verification > SV Functional Coverage : Instruction sequence?

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 SV Functional Coverage : Instruction sequence? 

Last post Mon, Jun 25 2007 1:20 AM by archive. 3 replies.
Started by archive 25 Jun 2007 01:20 AM. Topic has 3 replies and 1300 views
Page 1 of 1 (4 items)
Sort Posts:
  • Mon, Jun 25 2007 1:20 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    SV Functional Coverage : Instruction sequence? Reply

    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
    • Post Points: 0
  • Mon, Jun 25 2007 6:24 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: SV Functional Coverage : Instruction sequence? 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
    • Post Points: 0
  • Mon, Jun 25 2007 7:41 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: SV Functional Coverage : Instruction sequence? Reply

    Hi TAM,

    Thanks a lot :)

    There is another problem according to your code. From the code, we know that the transition coverage is given at signal layer. Can I do transition coverage in transaction layer.
    For example,
    I have two command list

    At signal layer,
    (cmd1 => cmd2 => cmd3) will trig transition_1_2_3
    (cmd4 => cmd5 => cmd6) will trig transition_4_5_6

    At transaction layer,
    (transition_1_2_3 => transition_4_5_6) will trig
    transition_1_2_3_4_4_6

    Can I do this in cover_group?

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
  • Tue, Jun 26 2007 5:05 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: SV Functional Coverage : Instruction sequence? Reply

    I wouldn't want to try to do that in a covergroup. Covergroups capture their values on a clock edge. That means that you need to write your own state machines to capture behavior over time. In my example, I wrote a simple one that looked back one instruction fetch. When you get more complicated as in your second example, then you'll end up writing some pretty complex state machines (which themselves would need to be debugged). So I would recommend for those that you use SVA. You can describe a complex sequence very easily in SVA and the simulator will build the state machine for you.

    assert property ( @(posedge clk)
    cmd1 ##1 cmd2 ##1 cmd3 |=> trans1 ##1 trans2 ##1 trans3 );

    This will check for correct behavior ( trans1-2-3 following cmd 1-2-3 ) and the cover report will tell you whether you tested it or not.


    Originally posted in cdnusers.org by TAM
    • Post Points: 0
Page 1 of 1 (4 items)
Sort Posts:
Started by archive at 25 Jun 2007 01:20 AM. Topic has 3 replies.