[sv-ec] 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.