Subject: [sv-bc] unpacked array and structure expression issues
From: Feldman, Yulik (yulik.feldman@intel.com)
Date: Tue Oct 21 2003 - 03:11:03 PDT
Hi,
I've found a number of issues in the "7.12 Unpacked array expression"
and "7.13 Structure expressions" of the SV3.1 LRM. Please check whether
they are real issues.
1. In unpacked array expressions, is it legal to specify more than
one type:value pair for the same type or more than one default:value
pair? If yes, what is the semantics?
2. In structure expressions, is it legal to specify more than one
member:value pair for the same member or more than one default:value
pair? If yes, what is the semantics?
Note that it is said explicitly that it is legal to specify more than
one type:value pair for the same type in structure expressions (in this
case the last value should be used), however, it is not defined what to
do in situations described in the above questions.
3. The first rule for unpacked array matching says (last paragraph
of 7.12):
"For type:value, if the element or sub array type of the unpacked array
exactly matches this type, then each element or sub array shall be set
to the value. The value must be castable to the array element or sub
array type. Otherwise, if the unpacked array is multidimensional, then
there is a recursive descent into each sub array of the array using the
rules in this section and the type and default specifiers".
First, it is not clear whether the "otherwise" in the third sentence
means that the types do not exactly match or that the value is not
castable. I'll assume that it means that the types do not exactly match,
since it makes more sense. The other issue is a question whether the
last sentence refers to unpacked arrays of any kind of arrays or only to
unpacked arrays of unpacked arrays. The unpacked arrays of unpacked
arrays makes more sense since it would be inconsistent to perform a
recursive descent into a packed array using the rules for unpacked
arrays. If this is true, the wording should be changed to something
like: "Otherwise, if the unpacked array is multidimensional and the sub
array type is unpacked, then there is ...". Here is an example of the
above problem:
bit [1:0] a [1:0];
a = { bit:1'b1};
If I do not descend into the packed dimension, the variable 'a' gets the
value '0101', since the 1'b1 becomes zero-extended to '01' twice. If I
do descend into the packed dimension (because the unpacked array "bit
[1:0][1:0]" is "multidimensional"), the variable 'a' gets the value
'1111', four times 1'b1.
4. The BNF for array_member_label in A.8.1 says:
array_member_label ::=
default
| type_identifier
| constant_expresion
According to the text description in "7.12 Unpacked array expressions",
the unpacked array expression can have two kinds of label:value pairs:
type:value and default:value. If this is the case, then what is the
semantics of the "constant_expression":value pair?
5. The BNF for struct_member_label in A.8.1 says:
struct_member_label :=
default
| type_identifier
| variable_identifier
In "7.13 Structure expressions", there is an example that includes the
following line: "initial s2 = { bit[31:0]:1, default:0, string:"" };".
However, I can't see how the type "bit[31:0]" can be parsed using the
rules in BNF. The type_identifier is a simple identifier, which can not
include the range.
6. Note that the label identifier in the member:value and
type:value pairs has different scoping rules than most other expressions
have. This identifier should be looked-up in the scope of the
corresponding unpacked array/struct declaration, chosen according to the
matching rules of unpacked array/structure expression, rather than in
the scope where the structure expression itself is found (according to
my interpretation of the standard). Note that the same type identifier
may resolve to different types in different scopes. The standard does
not seem to define the scoping rules according to which the identifier
should be resolved. Consider the following example:
typedef X t1;
typedef struct {
t1 m1;
} s1;
begin
typedef Y t1;
typedef struct {
s1 m2;
t1 m3;
} s2;
s2 var = { t1:1234 };
end
Should the type identifier t1 be resolved to the type X when it is
matched against the m1 field in the context of struct s1 and be resolved
to the type Y when it is matched against the m3 field in the context of
struct s2? Or should it always be resolved to the type Y since it is the
only type visible from the context of the structure expression?
Thanks,
Yulik Feldman.
This archive was generated by hypermail 2b28 : Tue Oct 21 2003 - 08:51:59 PDT