Date: Thu Jan 27 2011 - 01:16:11 PST
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
<http://www.twitter.com/dave_59> <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
On Wed, Jan 26, 2011 at 12:06 PM, Seligman, Erik <
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, and is believed to be clean.
