Date: Thu Jan 27 2011 - 07:08:17 PST
Hi,
I'll assume the current version of the proposal was posted after Dave's mail, since it answers his question about overlapping between the active_bits and quiet_bits arguments.
Where did the names active_bits and quiet_bits come from? Neither of them seems intuitive to me in the context in question, nor are the names opposites. The example on page 3 calls them "inactive bits". $countbits uses yet another name, "control_bits". Consistency and clarity, please!
In the example on page 3, the colon following "always_comb begin" should be deleted. It is illegal without a block name following.
logic [2:0] acceptable_quiet_bits;
logic [31:0] myvec;
logic design_initialization_done;
...
always_comb begin :
if (!design_initialization_done) begin
acceptable_quiet_bits = 3'b0XZ;
end else begin
acceptable_quiet_bits = 3'b000; // repeated bits OK
end
a1: assert ($bitshot0(myvec,1'b1,acceptable_quiet_bits));
end
The begin-ends in the if-else are redundant and clutter the code.
"$bitshot0" should not be bold.
In the sentence,
"The function $countbits returns an int equal to the number of bits in expression whose values are contained in control_bits."
"expression" should be in Courier font.
Regards,
Shalom
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Rich, Dave
Sent: Thursday, January 27, 2011 11:16 AM
To: ben@systemverilog.us; Seligman, Erik
Cc: sv-ac@eda.org; sv-bc@eda.org
Subject: RE: [sv-ac] New proposal posted for 2476 at http://www.verilog.org/mantis/view.php?id=2476
My comments here, and answers to Ben's questions below.
These functions definitions really belong in section 20 and should be allowed in constraints.
What happens if the active_bits and quiet_bits arguments contain overlapping values?
Because these are system functions, the active_bits and quiet_bits arguments can be any fixed sized integral types. And because of the weak nature of Verilog integral types, the LRM cannot prevent padding. For example $bitshot(<expression>,1,3'b0XZ).is a problem because active_bits has padded 0's. Same issue from control_bits.
An alternative is to define the arguments as a fixed size logic [0:3] and require the user to replicate values as needed. Then $bitshot(<expression>,'1,'b0XZ). becomes $bitshot(<expression>,4'b1111,4'b00XZ).. Other alternatives are to use queues of bits or strings.
You don't need to say "If the function is used in an assertion, then all arguments shall be of types legal in assertions. For example, $onehot0(A) shall not be used in an assertion if A is a dynamic array." because 16.6.1 already prohibits them.
For "The expression argument to the above functions shall be of a bit-stream type . For the purposes of calculating the return value, the argument is treated as a vector of equal size assigned from {>>expression} (see 11.4.14)."
I think the following would be clearer
The type of the expression argument to the above functions shall conform to a bit-stream type (see 6.24.3). The expression is treated as a generic packed type for the evaluation of each function
Not even sure the that last sentence is needed.
Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439
[cid:image001.png@01CBBE43.33DA1E50]<http://www.twitter.com/dave_59>[cid:image002.png@01CBBE43.33DA1E50]<http://go.mentor.com/drich>
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of ben cohen
Sent: Wednesday, January 26, 2011 11:25 PM
To: Seligman, Erik
Cc: sv-ac@eda.org
Subject: Re: [sv-ac] New proposal posted for 2476 at http://www.verilog.org/mantis/view.php?id=2476
Three comments:
1) $bitshot (<expression>,<active_bits>,<quiet_bits>)
Do we want some defaults? For example:
$bitshot (<expression>,[<active_bits=1]>,[<quiet_bits=0>]) ??
[DR] No we don't want default argument values. Defaults should be reserved for infrequently used arguments.
2) $bitshot can be read as "$ bits hot" or as "$ bit shot". Obviously, we mean bits-hot and not bit-shot. Somehow, it struck me as funny. Do we care? Do we want an underscore, such as $bits_hot ??
[DR] The normative text could refer to these as bits-hot function and that would solve the problem
3) In the above example, we have a vector myvec which is allowed to have values 0, X, or Z on inactive bits during some design initialization phase, but afterwards expected to only have 0 for inactive bits.
// Change the "which" to "that"
In the above example, we have a vector myvec that is allowed to have values 0, X, or Z on inactive bits during some design initialization phase, but afterwards expected to only have 0 for inactive bits.
Ben Cohen systemverilog.us<http://systemverilog.us>
On Wed, Jan 26, 2011 at 12:06 PM, Seligman, Erik <erik.seligman@intel.com<mailto:erik.seligman@intel.com>> wrote:
The new version at http://www.verilog.org/mantis/view.php?id=2476 adds a bunch of clarifying examples, and tweaks some phrasings. Please take a look & see if the $bitshot function description seems clearer, or if further changes are needed. I have also emailed sv-bc to see if our current description of the expression arg will work.
Once we have the basic content solid, we can look at Shalom's suggestion to also move all this stuff into chapter 20.
-- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, 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.
