Brad,
what about if I have:
typedef logic [3:0] [3:0][1:0] T;
logic [31:0] k = T'{default:1'b1};
Is this equivalent to the multiple concatenation :
logic [31:0] k = {16 {2'd1} };
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad
Pierce
Sent: Monday, January 24, 2005 3:32 PM
To: sv-bc@eda.org
Subject: Re: [sv-bc] Question about of section 7.13 of 1800-D3
That second sentence, arguably, is redundant, and just there for emphasis.
You cannot construct a simple bit-vector type with an aggregate constructor,
but only with a concat. For convenience, one is allowed to omit the
parentheses when casting a concat to a simple bit-vector type, but it is
still just the cast of a concat.
Therefore, if the lvalue is of a simple bit vector type, there would be no
sensible type context to infer for an aggregate constructor, so it would not
make sense to omit the explicit type prefix. For example, this is illegal
-- int i = {default:1'b1}; because this is also illegal int i = int'{default:1'b1} The following aggregate constructor is legal logic [3:0] [7:0] j = {default:1'b1}; and yields the same as logic [3:0] [7:0] j; initial begin for (int i = 0; i < 4; i++) j[i] = 1'b1; end Other equivalent ways to write it would be logic [3:0] [7:0] j = '{4'{1'b1}}; or logic [3:0] [7:0] j = '{$size(j)'{1'b1}}; or logic [3:0] [7:0] j = '{1'b1, 1'b1, 1'b1, 1'b1}; or with a concat logic [3:0] [7:0] j = {8'd1, 8'd1, 8'd1, 8'd1}; Now consider the following example typedef logic [3:0] [7:0] T; logic [31:0] k = T'{default:1'b1}; Here we are first constructing something that is not a simple bit-vector type, then implicitly casting it to a simple bit-vector type with the assignment. An equivalent way to write this would be logic [31:0] k = {8'd1, 8'd1, 8'd1, 8'd1}; -- Brad -----Original Message----- From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Francoise Martinolle Sent: Monday, January 24, 2005 11:10 AM To: sv-bc@eda.org Subject: [sv-bc] Question about of section 7.13 of 1800-D3 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? 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. 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}; // use of replication in array constructors for packed array assignment mdv2 = {3{2'b1}}; equivalent to {2'b1, 2'b1, 2'b1} ? // 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 or mdv1 = {3'b000, 3'b111, 3'bxxx} which is a concatenation and assigns 3'bxxx to mdv1.Received on Tue Jan 25 20:43:14 2005
This archive was generated by hypermail 2.1.8 : Tue Jan 25 2005 - 20:43:19 PST