RE: [sv-bc] Question about of section 7.13 of 1800-D3

From: Francoise Martinolle <fm@cadence.com>
Date: Tue Jan 25 2005 - 20:31:51 PST

 
Greg,

Thanks for the explanation. Your new text is wordy but a lot more clear.
Can we get this new text in the LRM?

Francoise
    '

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
Sent: Monday, January 24, 2005 3:31 PM
To: Francoise Martinolle
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Question about of section 7.13 of 1800-D3

Francoise Martinolle wrote:
> I am a little bit confused about some of the new text for array
> constructors in section 7.13 which states:
>
> "
>
> When the braces include an index, type, or default key, the braces
> shall not be interpreted as a concatenation, but as an array
> constructor, for both packed and unpacked array types. When an array
> constructor is assigned to a left-hand value that is of a simple bit
> vector type, an explicit type prefix shall be used.
>
> "
> I think that this means that we can use array constructors for packed
> or unpacked arrays but I don't understand the effect of the last
> sentence of this paragraph.
> Why would this only apply to a single bit vector type and not to a
> multi dimensional packed vector?

I agree that this sentence is defective. Recall here that "array
construction"
and "concatenation" are two different semantic actions that can share the
same syntax. Rather than run away from this ambiguity, some designers have
been trying to shoehorn both feet into one boot. I think what they meant
here was to require an explicit type prefix wherever construction semantics
are desired, but concatenation syntax would be legal. At the risk of being
mistaken for someone who advocates this ambiguity, here is a possible
rewrite of the whole paragraph in which I try to set the idea straight.

"When an assignment-like context imposes a packed array type on curly braces
  there is some ambiguity about whether their contents are to be interpreted
  as a self-determined concatenation of bits, or as context-determined
elements
  of an array. When the braces enclose a list of index, type, or default
keys,
  they have no interpretation as a concatenation, and so are treated as an
array
  constructor. When they embrace an ordinary list of expressions, or a
multiple
  concatenation, then they continue to be regarded as concatenation. As in
Verilog
  2001, such expressions are self-determined and do not inherit any type
information
  from the assignment-like context. Although packed array construction does
not
  happen by default, it can be forced by using an explicit type-prefix. When
the
  left curly brace has a type prefix and introduces a list of expressions,
or a
  multiple concatenation, it is a constructor even if the type identifies a
packed
  array. In this case, the expressions are assigned element-wise to the
bits or
  to the subarrays along the first dimension of a packed multidimensional
array."

I apologize for the wordiness, hopefully this level of redundancy will
prevent mistakes in the use or implementation of this troublesome language
feature.

> What about if the vector data object does not have a explicit data
> type (look at mdv1 declaration in the examples below)?
> Perhaps the intent of this last sentence is to determine if curly
> braces in the absence of an index, type or default key mean a
> concatenation of an array constructor. But it is not always possible
> to have an explicit type prefix if the data type of the object is
> implicitly declared with ranges. In that case the curly brace will
> always be interpreted as concatenation.
> Additionally this rule should also apply to multi dimensional packed
> arrays and not just simple vectors.

I agree. But note that since the constructed type is "packed", the
assignment can proceed even when the constructed type isn't precisely the
same one which declared the receiving object. So any equivalent packed
array typedef ought to do the job...

> ex: I think that all the following assignments are legal and none
> require a explicit type prefix
>
> logic [1:0] [2:0] mdv2; // 2 dimensional packed vector
>
> logic [2:0] mdv1; // simple bit vector
>
> // use of index or default keys
> mdv2 = {2:2'b1, 1:2'b0, default: 2'bx};

Yes, this is going to be an array constructor. But No, you've written a
statement with an out-of-bounds index and implicit 0-extension of
each element. I think the "first" index here is [1:0]. Your example
would be correct had you declared logic [2:0] [1:0] mdv2;

>
> // use of replication in array constructors for packed array
> assignment
>
> mdv2 = {3{2'b1}}; equivalent to {2'b1, 2'b1, 2'b1} ?

No, this would not be an array constructor. It is just plain old
concatenate.

>
> // use of array constructor for a simple packed vector
>
> mdv1 = {default: 1'b0}; equivalent to {1'b0, 1'b0, 1b0} ?
> A more interesting example for mdv1 would be:
> mdv1 = {default: 3'b000}; which is equivalent to {3'b000, 3'b000,
> 3'b000} which assigns the value 3'b000 to mdv1

Right, but only because 3'b000 is truncated to 1'b0 when it is assigned to
the corresponding array element of mdv1.

>
> or
>
> mdv1 = {3'b000, 3'b111, 3'bxxx} which is a concatenation and assigns
> 3'bxxx to mdv1.

Right again, the most significant bits are truncated, and this is Verilog
concat.

I think we mostly know what to expect from this syntax now.
It strains my personal limits for syntax ambiguity, but I'm pretty
conservative. Heck, the world just loves Perl, and I doubt more than a
handful of Perl users can correctly parse some of the monstrosities that are
legal in that language... so this will probably survive the test of time.

Greg Jaxon
Received on Tue Jan 25 20:31:57 2005

This archive was generated by hypermail 2.1.8 : Tue Jan 25 2005 - 20:32:10 PST