[sv-ec] RE: Updated version of 2506 (covergroup filtering)

Hi Scott,

I had something like below in my mind:

// IP declaration
package p1;
class c1;
  covergroup cg(ref a, b);
    cross a, b {
       bins b1 = myfunc();
    }
  endgroup
  function new(f1, f2);
     cg = new(f1, f2);
  endfunction

  virtual function int myfunc();
  endfunction
endclass
endpackage

// Testbench
module test;
  import p1::*;
  reg x, y;

  class c2 extends c1;
    virtual function int myfunc();
    endfunction
  endclass

  c2 o1 = new(x, y); // This will use the definition of myfunc() in derived class
  
endmodule

The other testbenchs can use the same package IP and redefine function myfunc
and use it to change cross coverage space.

What will be your recommendation in such scenarios?

Regarding the logic that you have mentioned about disallowing use of cross functions in with expression etc. we can
always put a restriction and say that it will lead to an error case.

One more point is about the BNF changes that you should address in your mantis if you are allowing function definition
in either cross scope of covergroup scope.

Regds,
Swapnajit

-----Original Message-----
From: Little Scott-B11206 [mailto:B11206@freescale.com]
Sent: Monday, April 25, 2011 6:38 PM
To: Swapnajit Chakraborti; sv-ec@eda.org
Cc: Fais Yaniv-RM96496; Michael Burns; Mehdi Mohtashemi
Subject: RE: Updated version of 2506 (covergroup filtering)

Hi Swapnajit:

I am not sure I understand your first argument. If the coverage model is in the IP and it needs to be changed then won't the IP need to be modified to either call a different function or update the function being called? It is unclear to me how you can modify the coverage model in the IP without modifying the IP.

We have discussed the pros and cons to putting these functions at the various levels in the committee meetings. If the functions are only going to be used within a cross it is felt that it would be best to put them in the cross "scope." If we allow functions at the covergroup level then I expect we should allow those functions to be used for other things like with expressions, etc. That opens up a slightly larger can of worms I believe.

Yes, I talked to users and they prefer the functions within the cross as this makes referencing the type much simpler. Their primary requirement is that they are able to access parameters and the like from within these functions.

Thanks,
Scott

> -----Original Message-----
> From: Swapnajit Chakraborti [mailto:swapnaj@cadence.com]
> Sent: Monday, April 25, 2011 7:44 AM
> To: Little Scott-B11206; sv-ec@eda.org
> Cc: Fais Yaniv-RM96496; Michael Burns; Mehdi Mohtashemi
> Subject: RE: Updated version of 2506 (covergroup filtering)
>
> Hi Scott,
>
> The major change in this version seems to be the following item:
> -Added a restriction that the cross types are only accessible from
> within the cross scope.
>
> Please consider the following points in this regard.
>
> - Firstly, in this approach, user will have to define the functions
> within cross declaration.
> Now if suppose, the function needs to be modified, it has to be done
> by modifying the cross declaration.
> Typically, if the coverage model is part of an IP, user will be
> reluctant to change the IP.
> What alternative do we suggest to user in such scenarios? Basically,
> your actual goal is to
> provide user flexibility and this approach will probably put some
> kind of restriction.
> I understand that if you declare it within cross scope, you can use
> covergroup argument etc
> in the function, but think about a user who doesn't want to use
> arguments and just rewrites
> a function to create a new coverage space.
>
> - Secondly, as I mentioned in one of my earlier mails, by opting for
> such syntax, we are allowing
> function calls within cross scope. This is something which is
> radical in the sense that so far
> we were allowing only bins/options. Now you bring function
> definition also and make this more
> like a class. That way we should possibly try to make covergroup
> look like a class and not the
> cross. So, have we thought about shifting the definition of function
> to covergroup level?
> In fact, why can't we move even the cross typedefs also to
> covergroup level? I understand that
> it will require naming the cross types differently instead of just
> naming them as CrossValType etc.
> for all crosses. In fact, we can append the cross names with the
> typedefinitions.
> Anyway, for both the cases (function within covergroup, cross), the
> BNF will require changes
> to show function call being allowed in appropriate scope. If we
> stick to your earlier proposal i.e.
> function declaration outside covergroup, we don't need any BNF
> change though.
>
>
> I believe we were planning to explore the function scope with users.
> Did you receive specific f/b regarding such use model which made you
> switch to this one? Please let me know if I am missing something here.
>
> Regds,
> Swapnajit
>
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Little Scott-B11206
> Sent: Wednesday, April 20, 2011 7:16 AM
> To: sv-ec@eda.org
> Cc: Fais Yaniv-RM96496; Michael Burns; Mehdi Mohtashemi
> Subject: [sv-ec] Updated version of 2506 (covergroup filtering)
>
> Hi all:
>
> I have uploaded a revised version of the proposal for mantis 2506.
> The major changes are described below. I don't want to be too
> presumptive, but if it is okay with Mehdi I would like to suggest that
> we discuss this proposal first in the SV-EC meeting on 04-25. I hope
> that will give interested parties enough time to review the proposal
> and arrange their schedules to attend the meeting. Mehdi, are you okay with that?
>
> Thanks,
> Scott
>
> mantis link: http://www.eda.org/svdb/view.php?id=2506
> .docx link:
> http://www.eda.org/svdb/file_download.php?file_id=4928&type=bug
>
> Major changes for v3
> -Removal of <> syntax to enclose set_expression to syntax 9-2 and
> removed from affected examples.
> -Added restriction that identifiers in the with expressions, set
> expressions, and cross functions are limited to constant expressions,
> instance constants (for classes only), or non-ref arguments to the
> covergroup. This is consistent with previous restrictions to
> variables in the open_range_list.
> QUESTION: I don't like repeating the restriction several times. I
> wouldn't mind referencing the restriction, but it seems silly to
> create a subsection for a sentence just because it is used often.
> Does someone else have an idea to enable me to write the restriction
> once and use it many times?
> -Added a restriction in Section 19.5.1.1 that disallows non-pure user-
> defined systfs -Specified with_expression application prior to bin
> distribution as the default behavior -Added distribute_first
> covergroup option to cause bin distribution to happen prior to
> with_expression application -Removed text describing how to access the
> cross types from outside the cross scope.
> -Added a restriction that the cross types are only accessible from
> within the cross scope.
>
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.