Subject: Re: [sv-bc] array and structure expressions ambiguities
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Nov 11 2003 - 13:46:06 PST
See my response.
At 04:00 PM 11/7/2003 -0800, Dave Rich wrote:
>Françoise,
>
>You sort of answered several of your own questions. As you quoted, the
>spec says the only time {} is interpreted as an aggregate is when it is on
>the RHS of an explicit assignment statement. All other uses require a
>cast. (i.e. lvalues, ports)
>
>bit unpackedbits [7:0] = {1'b0, 1'b1, {2{y}}, 1, 1, 1, 1}; //illegal
>
>The statememt above is illegal because {2{y}} because it is a
>self-determined expression, thus it must be a interpreted as a
>concatination. That means there are only seven elements for the
>initialization of an unpacked array of 8 elements.
Agreed. I proposed to have a new syntax without the outer curly braces
n{exp} and to interpret it as the initializer of n elements of the unpacked
array with the expression "expr".
Currently you allow the replication to be used an an initialized of an
entire array (there is an example in this section 7.11 and 7.13)
bit unpackedbits [7:0] = {8{1'b1}};
and I think it should be generalized to allow a replication to fill an
arbitrary number of array elements. In order to differentiate it from a
concatenation (which would be applied to a single element) I propose to
drop the outer braces.
Ex:
bit unpackedbits [7:0] = {1'b0, 1'b1, 2{y}, 1, 1, 1, 1};
would be equivalent to:
bit unpackedbits [7:0] = {1'b0, 1'b1, y, y, 1, 1, 1, 1};
>Regarding the general issue of replication, I think the issue of
>bitstream casting and queues will solve you issue by creating a
>dynimically sized unpacked array type.
I don't understand. I am just trying to initialize an array in a convenient
way using replication
expressions.
>bit [7:0] packedbits = {8{1}}; // illegal
>
>The statement above is illegal becasue the expression on the LHS is a
>packed object, so the {8{1} is interpreted as concat, and 1 is not a sized
>number.
Agreed.
>Dave
>
>
>Francoise Martinolle wrote:
>
>>I have a few questions regarding section 7.11, 7.13, 7.14
>>
>>1) Replication/multiple concatenation usage:
>>
>>In section 7.13 (unpacked array expressions) it is said that the multiple
>>concatenation can be used for unpacked array expressions as well.
>>An example is given which initializes a who array.
>>
>>bit unpackedbits [1,0] = {2 {y}};
>>It is said that it is equivalent to :
>>bit unpackedbits [1,0] = {y,y};
>>
>>Is it also legal to use the multiple concatenation to partially
>>initialize the array:
>>bit unpackedbits [7:0] = {1'b0, 1'b1, {2{y}}, 1, 1, 1, 1};
>>
>>A multiple concatenation in Verilog 2001 includes the outer curly braces.
>>I think that there is an ambiguity when interpreting the multiple
>>concatenation for elements of unpacked arrays when one of the element is
>>a vector.
>>Is the multiple concatenation result assigned to A vector element or is
>>the multiple concatenation distributed over several elements of the array?
>>
>>Consider for example an array of 8 ints:
>>
>>int unpackedbits [7:0] = { 1, 2, 3, {4{y}}, 4 };
>>
>>Is this legal and equivalent to
>>unpackedbits = { 1, 2, 3, y, y, y, y, 4 };
>>
>>Or would that be equivalent to
>>unpackedbits = { 1, 2, 3, { y, y, y, y} , 4 };
>>
>>which would presumably be treated differently. In the first equivalent
>>form, the entire array is initialized, while in the second equivalent
>>form, the array initializer has a size error.
>>
>>I think it is a good idea to allow the replication operator to initialize
>>an unpacked array however it seems that we should have a different syntax
>>to differentiate the assignment to one element of the array from the
>>distribution of the assignment to multiple elements of the array. Note
>>that it is not possible to cast the multiple concatenation to indicate
>>that it is to be distributed over 4 elements of the array, no such type
>>exists. Only the type array of 8 integers has been defined.
>>
>>Section 7.13 also states that systemVerilog determines the context of the
>>braces by looking at the left hand side of an assignment. If the left
>>hand side is an unpacked array, the braces represent an unpacked array
>>literal or expression. Outside the context of an assignment on the right
>>hand side, an explicit cast must be used with the braces to distinguish
>>it from a concatenation.
>>
>>Does this rule applies to any other set of curly braces found inside the
>>array?
>>Note that it is not always possible to cast an inner set of curly braces.
>>example:
>>typedef [2:0] arraytype [3:1];
>>
>>arraytype myvar;
>>
>>outiside the context of an assignment to myvar, how is
>> { {2{3'b000} , 1} interpreted?
>>The rule says that you have to type cast it:
>>arraytype' { {2{3'b000} , 1}
>>
>>How do you type cast {2{3'b000}} ?
>>
>>If we had:
>> arraytype' { {2{3'b000} , 1, 3'b111}
>>would the multiple concatenation be applied to the first element of the
>>array, 1 to the second element and 3'b111 to the third element?
>>
>>I think we should have a different syntax to indicate that the element of
>>the replication are being distributed over the elements of the array.
>>However we should still allow a multiple
>>concatenation to also be assigned to 1 element of an array.
>>I propose that for the first interpretation, we remove the outer braces
>>of the replication and that for the second interpretation we use the
>>regular syntax of a multiple concatenation which has the outer braces.
>>
>>Therefore:
>>
>> arraytype' { {2{3'b000} , 1, 3'b111}
>>the first element {2{3'b000}} would be a regular vector concatenation and
>>be applie dto the first element of the array. That would be equivalent
>>to { {3'b000, 3'b000} , 1, 3'b111}
>>
>>
>>arraytype' { 2{3'b000}, 1, 3'b111}
>>would be interpreted as a assignment of 3'b000 for the first 2 elements
>>of the array.
>>that would be equivalent to {3'b000, 3'b000, 1, 3'b111}
>>
>>2) type casting
>>If the left hande is an XMR, is the type cast necessary for the right
>>hand side array or structure initialization?
>>What about the case of passing an array initializer to a non local
>>function or task?
>>I believe that in these two cases the type cast should be required.
>>The type name should be the prefix of array initializer, the size should
>>be the prefix of a vector concatenation.
>>top.v = {1'b1, {2{3'b000}, 1'b1}
>>
>>But how do you type cast if top.v does not a type name?
>>Assume that v is declared in module top as:
>>[2:0] v [3:0];
>>
>>what is the type cast for the array initializer?
>>top.v = {1'b1, {2{3'b000}, 1'b1}
>>
>>I guess that you should create a local type definition equivalent to the
>>type definition of v in module top.
>>
>>Note that if you use the default case, you would need to have a type cast
>>to be able to determine how big is this array literal if you have an oomr
>>on the left hand side.
>>
>>top.v = {1'b1, {2{3'b000}, default : 1'b1}
>>
>>I would like to propose that the type cast be required in the cases of :
>> assigment (if the left hand side is an oomr)
>> port association
>> argument to a non local task/function
>>
>>3) packed structures
>>Do you allow positional association for *packed* structures? Or is it
>>only named and type associations?
>>If positional association is used for a struct. I believe that it needs
>>to be type cast in order to distinguish it from a regular vector
>>concatenation since a packed struct is just like a vector.
>>
>>typedef struct {
>> int x;
>> int y;
>>} st;
>>
>>The following has an ambiguous interpretation:
>>st s1 = {1'b0, 1'b1};
>>In order to disambiguate use cast:
>>st s1 = st'{1'b0, 1'b1} ; equivalent to {x:1'b0, y:1'b1}
>>
>>st s1 = {1'b0, 1'b1} is equivalent to 2 bits 2'b01 assigned to the 64 bit
>>vector st.
>>
>>Also in that case you can assign unsized values to each element of the
>>struct:
>>st s1 = st' {1, 2};
>>
>>In summary:
>> I would like to have:
>> 1. a different syntax for replication of values over the elements of
>> an unpacked array: remove outer braces.
>>
>> 2. require an explicit cast to distinguish vector concatenation from
>> array and structure expression in the case of an oomr assignment, non
>> local task and functions, port connections and for packed structs.
>>
>> 3. The name syntax shoud be consistent with the rest of name
>> associations in verilog
>>x: 1 should instead be .x(1)
>>
>>Let me know the resolution of these issues.
>>
>>Apart from these issues, I have the following question:
>>do we allow aggregate expressions as lvalues? (left hand side of
>>assignments, port connections)?
>>
>>{y,x,z} = {1'b1, 1'b0, 1'b1};
>
>--
>--
>David.Rich@Synopsys.com
>Technical Marketing Consultant
>http://www.SystemVerilog.org
>tele: 650-584-4026
>cell: 510-589-2625
>
>
>
This archive was generated by hypermail 2b28 : Tue Nov 11 2003 - 13:54:07 PST