Subject: FW: [sv-bc] unpacked array and structure expression issues
From: Feldman, Yulik (yulik.feldman@intel.com)
Date: Wed Nov 05 2003 - 00:01:50 PST
Hi,
Here are two additional issues with unpacked array and structure
expressions.
6. This one is related to the issue 5 in my previous mail, appended
below. In V2K standard section 4.5.1 "Rules for expression types" it is
stated that "Expression type depends only on the operands. It does not
depend on the LHS (if any)". However, please note how the type of the
value expression in the label:value pairs of unpacked array and
structure expressions apparently depends on the expressions that are not
operands of the value expression.
7. This is one takes the issue 6 one step further. Not only the type of
the value expressions in the label:value pairs can not be resolved
according to its operands only, there are cases when its type can not be
resolved at all. Consider the following SV code:
struct {
struct {
logic [2:1] a;
} s1;
struct {
logic [4:3] a;
} s2;
} s3;
s3 = { default : { a : 1 } };
The type of the expressions "{ a : 1}", "a", "1" should be both "logic
[2:1]" and "logic [4:3]" simultaneously. Moreover, the identifier "a"
should be resolved to two different "a"s. This, in turn, makes it
impossible to continue resolution of the expression "1" (in case it is
more complex), since different "clones" of this expression should be
resolved in different contexts. Such semantics is beyond the concepts
that existed before the introduction of unpacked array / structure
expressions. Note that this happens as a result of the complex semantics
of the "default" expression that makes it possible for the "value"
expression to be resolved in several places with different contexts. If
the "value" expression is another unpacked array / structure expression,
it couldn't be resolved. The same issue exists with type:value pairs.
There is no problem with member:value pairs, since they are always bound
to a single struct member. The standard doesn't specify whether having a
complex unpacked array / structure expression as a value expression of a
label:value pair is legal or not, implying that it is legal. The
standard shows an example with a structure expression being the value
expression of a member:value pair, but not the value expression of a
default:value or type:value pair.
For a compiler, one way to resolve this issue is to explicitly "unwind"
the unpacked array / structure expression during elaboration to
semantically equivalent "simple" expressions, the thing that could cause
capacity and performance issues. The other way is to change the language
to prevent such situations (for example, by defining that the type of
the second operands of default:value and type:value pairs is not
dependant on the context).
I would appreciate if you could discuss these issues and the issues in
the previous mail and put them into the issue list, if they are indeed
issues.
Thanks,
Yulik.
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Feldman, Yulik
Sent: Tuesday, October 21, 2003 12:11 PM
To: sv-bc@eda.org
Subject: [sv-bc] unpacked array and structure expression issues
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 : Wed Nov 05 2003 - 00:06:17 PST