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 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] 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)andsampled value functions like $rose, $fell (deal with LSB ofexpression)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 setofrestrictions) 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 definedin16.12.). Since the expression passed to these function should be converted to a bit vector before doing any analysis on it, is it OKtorestrict 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"
This archive was generated by hypermail 2.1.8 : Mon Jan 24 2011 - 08:12:21 PST