But that does not make 251 a duplicate of 2506.
SV-EC can decide that it does not want to implement the request in 251 and close the issue on that basis, but not as a duplicate of 2506.
I change my vote from "Abstain" to "Oppose".
Shalom
> -----Original Message-----
> From: Havlicek John-R8AAAU [mailto:r8aaau@freescale.com]
> Sent: Wednesday, September 22, 2010 9:33 PM
> To: Bresticker, Shalom; Rich, Dave; neil.korpusik@oracle.com; sv-
> champions@eda.org
> Cc: Havlicek John-R8AAAU
> Subject: RE: [sv-champions] Email vote - Ending September 22nd mantis
> 251
>
> Hmm ... I can't make any specific sense of what is being suggested in
> 251.
>
> One of the restrictions in defining cross bins is that they are limited
> to tuples of bins from the component coverpoints being crossed. One
> does not have full flexibility at the level of the cross to ignore or
> redefine the bin structure that comes from the coverpoints.
>
> The proposal for 2506 respects this approach and extends it.
>
> I can't really tell what the reporter of 251 wants. Nevertheless, I
> agree with Dave that the general area of concern is covered or, at
> least, overlaps significantly with 2506, and I would hope that the
> reporter of 251 would participate in resolution of 2506 and/or 2953.
>
> J.H.
>
> -----Original Message-----
> From: owner-sv-champions@eda.org [mailto:owner-sv-champions@eda.org] On
> Behalf Of Bresticker, Shalom
> Sent: Wednesday, September 22, 2010 1:05 AM
> To: Rich, Dave; neil.korpusik@oracle.com; sv-champions@eda.org
> Subject: RE: [sv-champions] Email vote - Ending September 22nd mantis
> 251
>
> The description of 251 says,
>
> "For cross coverage, the syntax in table 20-4 does not allow multiple
> bins to be created for user defined bins, i.e. using the [] notation
> with the binsof construct. So the only way to track the crosses
> separately is through automatically created bins. Was there any
> specific
> reason for not allowing that. The syntax should be enhanced to allow
> multiple bins being created for user defined bins. The example in
> Section 20.5.1 should also be suitably enhanced."
>
> That looks to me exactly like a "suggested direction".
>
> Shalom
>
> > -----Original Message-----
> > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > Sent: Wednesday, September 22, 2010 7:54 AM
> > To: Bresticker, Shalom; neil.korpusik@oracle.com; sv-
> champions@eda.org
> > Subject: RE: [sv-champions] Email vote - Ending September 22nd mantis
> > 251
> >
> > 251 is more of a dissatisfaction of the current semantics of crosses
> > without a suggested direction. If nothing else, mantis 2506 has a
> > loose proposal that should alleviate the concerns raised by 251.
> >
> > > -----Original Message-----
> > > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > > Sent: Monday, September 20, 2010 7:35 AM
> > > To: Rich, Dave; neil.korpusik@oracle.com; sv-champions@eda.org
> > > Subject: RE: [sv-champions] Email vote - Ending September 22nd
> > >
> > > Dave,
> > > How does the proposal of Mantis 2506 address Mantis 251?
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Sep 27 04:27:43 2010
This archive was generated by hypermail 2.1.8 : Mon Sep 27 2010 - 04:27:44 PDT