Re: [sv-bc] integer bit bounds

Calling packed_dimensions a "range specifier" sounds like a holdover
from 1364.  But the phrase you quote does not appear verbatim in that
document (top of 4.3 is the closest match).  Judging from the context,
I think the author may have been saying "even without explicitly
declaring any dimensions" there's an actual [31:0] dimension accessible
using the array query functions.

This author gets an M for "misleading", especially since
(I believe, while others disagree that:) the dimension
being defined is not always numbered "1"!

Here's another attempt at rewording:
"Variables or elements declared to have a fixed-size integer type
(*integer*, *shortint*,  *longint*, OR *byte*, call this /N/),
 have (for the purpose of array query and type matching) the
 predefined dimension [$bits( /N/ )-1:0]."

I'll leave it to the committee to judge whether this subverts
their intent.

Greg Jaxon

Bresticker, Shalom wrote:
> What's the bit about "without a range specifier"?
> 
> Shalom 
> 
>>> For a fixed-size integer type (*integer*, *shortint*,*longint*, and 
>>> *byte*), dimension 1 is predefined. For an integer/ N/ declared 
>>> without a range specifier, its bounds are assumed to be 
>>> [$bits(N)-1:0].
>>>
>>> I understand the first sentence.
>>> I don't understand what case the second sentence is referring to.
>>> Can someone clarify?
>> The first sentence promises a definition which the second 
>> sentence is trying to deliver.  It should probably /not/ 
>> focus on  "integer N" - which makes it sound like a mere 
>> example, instead the two sentences should be joined to say
>>
>> "For a fixed-size integer type ( *integer*, *shortint*, 
>> *longint*, OR *byte*, call this /N/ ), dimension 1 is 
>> predefined to be [$bits( /N/ )-1:0]."


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.