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

But our latest version is very similar to this proposal.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik
Sent: Tuesday, January 18, 2011 17:26
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.
---------------------------------------------------------------------
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.