Hi Ray:
Based on these responses would you prefer to see this options removed?
Thanks,
Scott
> -----Original Message-----
> From: Michael Burns [mailto:michael.burns@oracle.com]
> Sent: Monday, May 09, 2011 1:45 PM
> To: Little Scott-B11206
> Cc: Ryan, Ray; sv-ec@eda.org
> Subject: Re: A couple items about 2506 (Non-trivial coverage space
> shapes)
>
>
> Yeah, I don't care about either of these at all. The intention was just
> to give the user some performance knobs to turn for when things seem to
> be taking a long time, but I don't see that this needs to be
> standardized in SystemVerilog. However, if this sort of thing stays in
> the proposal, it could be useful at the instance level - the difficulty
> of forming the coverage space could depend on constructor arguments
> provided at instantiation.
>
> --Mike
>
> On 5/9/2011 11:28 AM, Little Scott-B11206 wrote:
> > Hi Ray:
> >
> > 1) I can go either way on this option. You are correct that the
> effort_limit will vary from processor to processor. My expectation is
> that this is more of a debug feature. It would be employed to quickly
> identify which covergroup is taking a long time to build the coverage
> space. Given this use case I don't see the need for it to be applied
> at the instance level. Mike, can you shed any light on the motivations
> here?
> >
> > 2) I agree that this feels very much like a vendor option. I am fine
> to remove it from the proposal.
> >
> > Thanks,
> > Scott
> >
> >> -----Original Message-----
> >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> >> Ryan, Ray
> >> Sent: Monday, May 09, 2011 12:43 PM
> >> To: sv-ec@eda.org
> >> Subject: [sv-ec] A couple items about 2506 (Non-trivial coverage
> space
> >> shapes)
> >>
> >> 1) At the end of the proposal there is the addition of
> "effort_limit"
> >> to table 19-1 (Instance Specific Coverage options).
> >> My general impression is that this is more of a vendor option.
> However,
> >> if it is specified in the LRM the limit should specify an effort
> number
> >> (rather than "number of CPU seconds) where the interpretation of the
> >> number is vendor specific. The tie to "CPU seconds" is problematic,
> >> (still will vary between vendors, but now will vary depending CPU to
> >> CPU). Does this need to be specified for each covergroup instance?
> >>
> >> 2) There is also an addition of "study" to table 19-3 -- Coverage
> group
> >> type (static) options. This feels even more like a vendor option
> >> (optimization).
> >>
> >>
> >> Ray Ryan
> >>
> >>
> >> --
> >> 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.Received on Mon May 9 13:02:21 2011
This archive was generated by hypermail 2.1.8 : Mon May 09 2011 - 13:02:23 PDT