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

Hi Swapnajit:

I would expect that in most scenarios a parameter would likely suffice to modify the covergroup. In cases where that isn't possible the function within the cross could call an appropriate virtual function.

The BNF changes are in the most recent proposal.

Thanks,
Scott

> -----Original Message-----
> From: Swapnajit Chakraborti [mailto:swapnaj@cadence.com]
> Sent: Tuesday, April 26, 2011 8:14 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,
>
> 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.