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

Hi Adam,

We are considering to drop $bitshot and to keep $countbits only.

Regards,
Dmitry

From: Adam Krolnik [mailto:adam.krolnik@verisilicon.com]
Sent: Thursday, January 27, 2011 17:20
To: Seligman, Erik
Cc: Korchemny, Dmitry; Gordon Vreugdenhil; Brad Pierce; sv-bc; sv-ac@eda.org
Subject: Re: [sv-bc] FYI: New proposal for 2476 posted

Hello all;

I see the proposal has changed from vectorhot to bitshot.

Would you consider an alternative name to bitshot since you are generalizing the active value and the inactive
values? Something more general, without 'hot' ?
   bitactive ?
   isactive ?
   oneactive ?
   onebit ?

Lastly, is there really a large use for such a function over something that counts selected bits ?
E.g.

   $countbits(sigs, bits_to_count) == 1
   $bitshot(sigs, bits_to_count, bits_not)

  Thanks.

   Adam

Seligman, Erik wrote:

Ah, I see, you modified 3036 and 3037 again, rather than modifying 2476. Is there a reason why we shouldn't merge the proposals? Since they touch the same part of text, and 2476 needs to take 3037 into account when modifying a syntax box, I think the combined 2476 proposal is probably best to avoid editor confusion.

Also, is there a similar change we could make with the onehot functions? Perhaps something like

$vectorhot(expression,<bit>,<0_bits_ok>,<unknown_ok>);

...returning TRUE iff at (most 1 / precisely 1, depending on 0_bits_ok) bits of the vector equal <bit>, reject_on (if unknown_ok == 0) any bit X or Z.

-----Original Message-----

From: Korchemny, Dmitry

Sent: Tuesday, January 18, 2011 7:50 AM

To: Seligman, Erik; Gordon Vreugdenhil; Brad Pierce

Cc: sv-bc; sv-ac@eda.org<mailto:sv-ac@eda.org>

Subject: 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> [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<mailto: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> [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<mailto: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> [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<mailto: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<mailto: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> [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<mailto: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<mailto: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> [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<mailto:sv-ac@eda.org>

Cc: sv-bc@eda.org<mailto: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> [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<mailto: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<mailto: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> [mailto:owner-sv-ac@eda.org] On Behalf Of

Kulshrestha, Manisha

Sent: Thursday, November 18, 2010 11:21 AM

To: sv-ac@eda.org<mailto: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.
--
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design", "Creating Assertion-Based IP"
---------------------------------------------------------------------
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.