RE: [sv-bc] FYI: New proposal for 2476 posted

Hi,

why separate args rather than a bitvector? To limit the max number of selectors? Can they be logic variables?

Thanks,
ed

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Seligman, Erik
> Sent: Tuesday, January 18, 2011 10:26 AM
> To: Gordon Vreugdenhil; Brad Pierce
> Cc: sv-bc; sv-ac@eda.org
> Subject: [sv-ac] RE: [sv-bc] FYI: New proposal for 2476 posted
>
> Rereading the draft, I like this suggestion a lot.
>
> SV-ACers: any objections to this change?
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Tuesday, January 18, 2011 7:03 AM
> To: Brad Pierce
> Cc: sv-bc; sv-ac@eda.org
> Subject: Re: [sv-bc] FYI: New proposal for 2476 posted
>
> Thanks for forwarding this Brad.
>
> AC members -- wouldn't it be cleaner to have all the new count..
> routines be subsumed by a single "countvals" routine that takes
> a vector and a series of 1 to 4 scalars and counts all the occurrences
> of those values?
>
> Ex.
> $countones(expr) is $countvals(expr, 1'b1);
> $count1XZ(expr) is $countvals(expr, 1'b1, 1'bx, 1'bz);
> $countX(expr) is $countvals(expr, 1'bx);
>
> That way one could parameterize the behavior more easily in user code,
> particularly if one said that "redundant" bits were only counted once;
> i.e. $countvals(expr, 1'b1) == $countvals(expr, 1'b1, 1'b1)
>
> Gord
>
> On 1/17/2011 4:06 PM, Brad Pierce wrote:
> >
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Seligman, Erik
> > Sent: Monday, January 17, 2011 3:01 PM
> > To: Korchemny, Dmitry; Kulshrestha, Manisha; Bresticker, Shalom;
> Tapan Kapoor; sv-ac@eda.org
> > Subject: [sv-ac] New proposal for 2476 posted
> >
> > Hi guys-- I've posted a new version of 2476 at
> http://www.verilog.org/mantis/view.php?id=2476 . It attempts to also
> cover 1559, 3036, and 3037, incorporating Dmitry's recent suggestions.
> Please take a look& send comments if you can.
> >
> > Also, tomorrow we should be sure to discuss 2938 and 2804 (items I
> owned that were bounced back by champions) now that I'm back from
> vacation.
> >
> > Thanks!
> >
> > -----Original Message-----
> > From: Korchemny, Dmitry
> > Sent: Tuesday, January 04, 2011 4:15 AM
> > To: Kulshrestha, Manisha; Seligman, Erik; Bresticker, Shalom; Tapan
> Kapoor; sv-ac@eda.org
> > Subject: RE: arguments for system functions: fixes to 2476? (or 1559.
> 3036)
> >
> > Hi all,
> >
> > I wrote two proposal sketches on this subject. They are not complete
> proposals yet, but show how the definitions may be extended to
> arbitrary data types, including dynamic ones.
> >
> > Thanks,
> > Dmitry
> >
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Kulshrestha, Manisha
> > Sent: Tuesday, January 04, 2011 2:03 PM
> > To: Seligman, Erik; Bresticker, Shalom; Tapan Kapoor; sv-ac@eda.org
> > Subject: [sv-ac] RE: arguments for system functions: fixes to 2476?
> (or 1559. 3036)
> >
> > Hi,
> >
> > I think $isunknown should also work on bit streams as this function
> also
> > checks each bit.
> >
> > Manisha
> >
> > -----Original Message-----
> > From: Seligman, Erik [mailto:erik.seligman@intel.com]
> > Sent: Saturday, December 18, 2010 3:49 AM
> > To: Bresticker, Shalom; Kulshrestha, Manisha; Tapan Kapoor;
> > sv-ac@eda.org
> > Subject: RE: arguments for system functions: fixes to 2476? (or 1559.
> > 3036)
> >
> > Oops, it looks like we need to add the argument types for $onehot,
> > $onehot0, $isunknown and $countones to 2476. Or move this issue to
> > other proposals& modify the problem statement for 2476.
> >
> > Are these the types we should specify?:
> >
> > $onehot (<expression>)
> > $onehot0 (<expression>)
> > $countones ( expression)
> > expression = any bit-stream type (6.24.3)
> > $isunknown (<expression>)
> > expression = any legal SV expression (or do we have to limit this
> one
> > to bit streams too?)
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Bresticker, Shalom
> > Sent: Wednesday, November 17, 2010 11:00 PM
> > To: Kulshrestha, Manisha; Tapan Kapoor; sv-ac@eda.org
> > Cc: sv-bc@eda.org
> > Subject: [sv-ac] RE: arguments for system functions
> >
> > Hi,
> >
> > Mantis 1559 is "To which types can $countones be applied?". That
> issue
> > is still open.
> >
> > Mantis 2476 is " Need clarification about system functions $onehot,
> > etc", and the description is
> > "A clarification is needed what can the argument type of system
> > functions $onehot, $onehot0, $isunknown and $countones be and where
> > these functions may be used - in assertions only or everywhere in
> > expressions."
> > However, I don't see that the approval proposal to 2476 addresses the
> > argument type issue.
> >
> > Mantis 3036 is "Explicitly allow unpacked data types for arguments of
> > assertion system functions".
> >
> > If 2476 will not address this issue, then no current Mantis addresses
> > it, I think, and probably 1559 should be expanded to cover the other
> > similar functions as well.
> >
> > Regards,
> > Shalom
> >
> >> -----Original Message-----
> >> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> >> Kulshrestha, Manisha
> >> Sent: Thursday, November 18, 2010 8:53 AM
> >> To: Tapan Kapoor; sv-ac@eda.org
> >> Subject: [sv-ac] RE: arguments for system functions
> >>
> >> Hi Tapan,
> >>
> >> It is not clear from the description if $onehot0 etc. have to follow
> >> the
> >> same restrictions on the expression as in expressions in assertions.
> >> Since these functions can be used outside of assertions, it is
> better
> >> to
> >> describe what kind of arguments can be passed to them.
> >>
> >> Manisha
> >>
> >> -----Original Message-----
> >> From: Tapan Kapoor [mailto:tkapoor@cadence.com]
> >> Sent: Thursday, November 18, 2010 12:19 PM
> >> To: Kulshrestha, Manisha; sv-ac@eda.org
> >> Subject: RE: arguments for system functions
> >>
> >> Hi Manisha,
> >>
> >> The argument to these function is "expression", which is also an
> >> argument to immediate assertions (16.3), deferred assertions (16.4)
> > and
> >> sampled value functions like $rose, $fell (deal with LSB of
> > expression)
> >> in section 16.9.3. These are also potential candidates if any
> >> definition
> >> change is to be considered.
> >>
> >> Section 16.6 does provide some sort of definition (which more of set
> > of
> >> restrictions) for the expression that can appear in sequence and
> >> property expressions. I tend to agree that this definition is not
> good
> >> enough for all the constructs (discussed in clause 16).
> >>
> >>
> >> Warm regards,
> >>
> >> Tapan
> >>
> >> "You must be the change you want to see in the world" : Mahatma
> Gandhi
> >>
> >>
> >>> -----Original Message-----
> >>> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> >>> Kulshrestha, Manisha
> >>> Sent: Thursday, November 18, 2010 11:21 AM
> >>> To: sv-ac@eda.org
> >>> Subject: [sv-ac] arguments for system functions
> >>>
> >>> Hi,
> >>>
> >>> Currently LRM does not define what type of expressions can be used
> in
> >>> system functions $onehot, $onehot0 etc. (these functions are
> defined
> >> in
> >>> 16.12.). Since the expression passed to these function should be
> >>> converted to a bit vector before doing any analysis on it, is it OK
> > to
> >>> restrict the expression to be an integral type (6.11.1) ? Or
> probably
> >>> that was the intension initially but never got documented.
> >>>
> >>> Comments ?
> >>>
> >>> Thanks.
> >>> Manisha
> >>>
> >>> --
> >>> 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.
> >>
> > ---------------------------------------------------------------------
> > 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.
> >
> >
>
> --
> --------------------------------------------------------------------
> 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.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.