RE: [sv-ec] Outstanding covergroup filtering (2506) questions

Hi Scott,

Thanks for the clarification.
Regarding scope, I am fine with what is described in the proposal i.e. declare it
outside covergroup scope. Some justification for this preference are:
- covergroup syntax remains more less similar with coverpoints/cross/bins etc.
- Declaring a function explicitly within covergroup basically makes
  it look so much like a class with member functions and possibly that is not our
  target at this point.
- If we start declaring this function within covergroup, users may ask why
  then we are not allowing declaration of "new" or for that matter "sample"
  override also inside covergroup.

In my opinion, if we go with ignore/illegal approach, sticking to distributing first will
ensure consistency. If we see that "with expression" requires the reverse, we may think
of providing an option so that it can be controlled by user.

Regds,
Swapnajit

-----Original Message-----
From: Little Scott-B11206 [mailto:B11206@freescale.com]
Sent: Saturday, April 16, 2011 1:48 AM
To: Swapnajit Chakraborti; Gordon Vreugdenhil
Cc: sv-ec@eda.org; Fais Yaniv-RM96496
Subject: RE: [sv-ec] Outstanding covergroup filtering (2506) questions

Hi Swapnajit:

I agree that the simulator can't defer the calculation of the coverage space until post-simulation in all cases. I don't believe that the LRM needs to say any more than is currently in the proposal. The purpose of these statements in the proposal is to ensure that tools are allowed to be clever and efficient not to provide a sketch of how they do that.

What is your preference regarding the scope? It isn't clear to me from your statements.

Can you elaborate on why you would prefer to distribute then apply the with expression? I don't have a problem with adding an option to change the time of filtering. How do others feel about this?

Thanks,
Scott

> -----Original Message-----
> From: Swapnajit Chakraborti [mailto:swapnaj@cadence.com]
> Sent: Friday, April 08, 2011 6:19 AM
> To: Gordon Vreugdenhil; Little Scott-B11206
> Cc: sv-ec@eda.org; Fais Yaniv-RM96496
> Subject: RE: [sv-ec] Outstanding covergroup filtering (2506) questions
>
> Hi Scott, Gord,
>
> I agree that in case the expression uses covergroup argument and/or
> any other variable references, the closure can only be created during
> covergroup construction. But what is not clear to me is how simulator
> can defer it's knowledge on coverage space till post simulation. I am
> assuming that some post simulation tool will evaluate the coverage
> space based on the closure set passed to it by the simulator and as it
> is happenning post simulation the coverage space will not be known
> during simulation. If that is the case, there will be various issues,
> illegal bin warning cannot be generated, ignore cannot be done
> correctly and even sampling cannot happen. Please let me know if I am
> missing something here.
>
> If you agree with the above statement, then I see two ways of solving
> this problem. One way is to do a dummy simulation run just to create
> the closure sets, pass the closure set data to the non simulation
> tool, obtain the coverage space from it (much faster than simulator)
> and then start a new simulation with this coverage space data.
>
> The other option may be to pass the closure set to a non simulation
> tool immediately (will not wait till end of simulation) and this tool
> will compute the coverage space faster than the simulator and return
> the coverage space to simulator for it's use. This will avoid the
> dummy simulation run as stated in earlier option. I am not sure if
> these points were discussed or not and hence trying to clarify them.
> Please let me know your comments in this regard.
>
> The proposal doesn't discuss how this handshaking between simulator
> and non-simulator tool will happen, how the closure set will be passed etc.
> Do you foresee a need to capture that aspect also as part of this
> proposal? Or this will be left totally tool dependent and remain as
> vendor's USP?
>
> Regarding scope of declaration of the function to generate queue
> elements, the ideal place would have been the cross scope because the
> typedefs (CrossQueueType etc) are available within cross scope. That
> way it would be the innermost scope and everything starting from class
> variables, covergroup arguments, cross types all would have been
> available to this function and there would have been no need to use
> scope operator to access anything. But declaring it within cross scope
> looks a bit cumbersome to me because this is going to be an explicit
> declaration and not like implicit typedefs. Have we thought about next
> higher logical scope which is covergroup scope? If it is declared
> within covergroup scope that also looks ok because this ensures some
> kind of logical encapsulation and ensures access to everything that
> this function may need (of course for typedefs it will need the scope
> operator). Keeping the function declaration outside covergroup scope
> is possibly best approach as it calls for least change in current syntax.
>
> Regarding order of distribution and filtering of fixed size bins, I am
> in favor of distributing the values first and then applying the with
> expression filter. We may want to provide a new covergroup option for
> this as well which can be controlled by the user.
>
> Regds,
> Swapnajit
>
>
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Tuesday, March 29, 2011 7:43 PM
> To: Little Scott-B11206
> Cc: sv-ec@eda.org; Fais Yaniv-RM96496
> Subject: Re: [sv-ec] Outstanding covergroup filtering (2506) questions
>
> That's correct; but that is true even for the other situations where
> the function relies on covergroup constructor values or instantiation
> parameters from an enclosing scope. Any non-local reference would
> require at least an elaboration (for parameter values) or simulation
> (for covergroup formals) in order to collect referenced values.
>
> So unless you have a completely pure function (not referencing
> anything outside the function at all), a totally separate tool would
> still have to know some additional information.
>
> Gord.
>
> On 3/29/2011 7:08 AM, Little Scott-B11206 wrote:
> > Hi Gord:
> >
> > Thanks for the clarification. I agree that the variable references
> wouldn't be live. They would be sampled at covergroup creation.
> >
> > My intention was to indicate that this behavior would be a departure
> from what is doable today. With current covergroups another tool
> (e.g., a coverage management tool) can determine the coverage space
> given the covergroup definition. If constructs like item 3 are used
> in a covergroup I believe that a simulator or simulator-type
> evaluation would be required to even calculate the coverage space. Is
> that correct?
> >
> > Thanks,
> > Scott
> >
> >> -----Original Message-----
> >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> >> Gordon Vreugdenhil
> >> Sent: Tuesday, March 29, 2011 8:52 AM
> >> To: Little Scott-B11206
> >> Cc: sv-ec@eda.org; Fais Yaniv-RM96496
> >> Subject: Re: [sv-ec] Outstanding covergroup filtering (2506)
> >> questions
> >>
> >> Scott, one clarification -- in (3) you suggest that a simulator
> would
> >> be required to calculate the with expressions at sim time for
> >> variable references. I don't think that is required. The
> >> simulator would certainly need to capture the values of all
> >> referenced variables at the time of covergroup construction and
> >> associate the fixed set of values as the "closure"
> >> (see http://en.wikipedia.org/wiki/Closure_%28computer_science%29)
> >> of the function along with the covergroup.
> >>
> >> I didn't hear anyone suggest that variable references should be
> "live"
> >> in the sense that changes after covergroup construction would
> >> impact the function behavior.
> >>
> >> So as long as the simulator captured the values, the actual
> filtering
> >> could still be done late if one wanted to do so.
> >>
> >> Gord.
> >>
> >>
> >> On 3/28/2011 8:00 PM, Little Scott-B11206 wrote:
> >>> Hi all:
> >>>
> >>> Medhi asked me to summarize the primary outstanding issues in the
> >> covergroup filtering proposal (2506). I will ask the Freescale
> >> user community for their opinion on these issues. I hope that
> >> others
> will
> >> do the same and discuss the results on the reflector. I will be
> >> traveling and only be able to catch the end of the meeting on April
> >> 11th. Hopefully we can resolve most of these issues over the
> >> reflector.
> >>> 1. Use model for with expressions. My understanding is that the
> >> expected use model for the with expression is to reduce/shape the
> >> coverage space like is done with ignore bins but using more
> >> powerful methods than are allowed by the current ignore bins
> >> syntax. If this is the case, does this imply that the solution
> >> should be an enhancement to the ignore bins syntax and not
> >> something as general
> as
> >> with expressions? Are there additional use models envisioned by
> >> the user community that benefit from the power provided by with
> expressions?
> >>> A note on current capabilities:
> >>> ignore/illegal bins: these must be explicitly specified which is
> >> tedious for large coverage spaces (ignore_bins are often generated
> >> via scripts for large spaces). Ignore bins are removed after bin
> >> distribution. See pg. 496 in P1800-2009 for an example.
> >>
> >>> iff: this does not affect the shape of the coverage space. It can
> >> affect when coverage is collected.
> >>> intersect: allows reduction of cross bins that contain values in a
> >> given open range expression. This gives some power but again it is
> >> very limiting for complex coverage shaping. See pg. 501 in P1800-
> 2009
> >> for an example.
> >>> ||,&&: allows a reduction of cross bins by oring or anding
> >> combinations of the bins involved in the cross. See pg. 501 in
> >> P1800-
> >> 2009 for an example. Again, this is not terribly powerful.
> >>> 2. Based on the use model for a constructive/generative approach
> >>> does
> >> it make sense to apply the expression and then do bin distribution
> or
> >> do bin distribution and then apply the filtering? In the first
> >> case a change of the expression will likely result in very
> >> different bin assignments. In the second approach there may be
> >> empty bins. How would these artifacts complicate the coverage merging process?
> >> Current covergroup constructs may exhibit these merging issues, but
> >> we don't want to needlessly exacerbate the problem.
> >>> 3. The proposal adds syntax to use a function to generate a queue
> of
> >> elements that define the cross bins. The question is what will
> users
> >> want to access in these functions? There are three levels of items
> >> that may be accessed 1. compile time constants (parameters, etc.) 2.
> >> const variable/arguments 3. general variable references (these
> >> would be "sampled" at the instantiation of the covergroup). Which
> >> level
> of
> >> "purity" do users desire in these functions? It should be noted
> that
> >> as we proceed up the list the opportunity for tools to pre/post
> >> calculate the coverage space is diminished. In fact, if the users
> >> desire item 3 it would require a simulator to calculate coverage
> >> spaces of this type.
> >>> Thanks,
> >>> Scott
> >>>
> >>>
> >> --
> >> --------------------------------------------------------------------
> >> Gordon Vreugdenhil 503-685-0808
> >> Model Technology (Mentor Graphics) gordonv@model.com
> >>
> >>
> >> --
> >> This message has been scanned for viruses and dangerous content by
> >> MailScanner, and is believed to be clean.
> >>
> >
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>
>
> --
> 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.