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

I was not expecting the "scalars" to be constant -- any expression is fine.
Off the top of my head, I'd probably go with multiple expressions
and then just pick off the low-order bit in terms of the semantics
(so that integer 1, 0 work in a natural manner), but I don't have a strong
opinion on that vs a vector.

Gord.

On 1/18/2011 7:31 AM, Eduard Cerny wrote:
> 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.
>>

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