[sv-ac] RE: arguments for system functions: fixes to 2476? (or 1559. 3036)

Dmitry-- based on the description of bit stream type casting in 6.24.3, isn't your recursive description in 3036 unnecessary? I think we can replace it with something like "For the purposes of calculating the return value, all bits in the argument are treated as a single packed bit vector, following the conversion rules in 6.24.3."

Here's what you had:
-------------------
If the argument expression of the above functions has an unpacked aggregated data type then the functions are defined recursively as follows:
- $coutones (expression) returns the sum of $countones results applied to all expression elements.
- $onehot (<expression>) returns true if for only one element of the expression $onehot returns true, and $countones for all other elements returns 0.
- $onehot0 (<expression>) returns true if for at most only one element of the expression $onehot0 returns true, and $countones for all other elements returns 0.
- $isunknown (<expression>) returns true if $isunknown returns true for some element of the expression

-----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.

-- 
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.