Subject: RE: FW: [sv-bc] unpacked array and structure expression issues
From: Feldman, Yulik (yulik.feldman@intel.com)
Date: Wed Nov 05 2003 - 09:36:15 PST
Hi Greg,
Obviously, I agree with you. What is left, then, is:
1. Specify in the standard that the value expressions of default:value
and type:value pairs are self-determined.
2. Decide whether the value expressions of member:value pairs should be
self-determined as well. Probably not, since there is no issue with
multiple contexts with this kind of a label:value pair.
--Yulik.
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
Sent: Wednesday, November 05, 2003 7:09 PM
To: Feldman, Yulik
Cc: sv-bc@eda.org
Subject: Re: FW: [sv-bc] unpacked array and structure expression issues
Yulik,
Your counterexample is a syntax error.
In "default:{...}", the {}s are ALWAYS to be
understood as verilog concatenation.
Since there is no unique datatype necessarily
associated with the default label, there is
no basis for ever reading them as an aggregate
subexpression.
Doing otherwise would mean that the same text
(for the value expression) would be re-parsed
and re-type-balanced for each implicit assignment
to which it might apply.
In discussing this we might consider default:a+b
and try to determine the bit width of the adder
circuitry. There are three possible choices -
1) self-determined expression width,
2) MAX over a,b, and all the fields and elements
to which the default: clause applies.
3) MAX over a,b, and each one of the fields and
elements to which the default clause applies
(yielding several distinct adders in some cases).
Of the three, I think "self-determined" is the only
sensible answer. This is consistent with the concept
that source text has a single meaning. While
editing it, equals can substitute for equals...
Greg Jaxon
P.S. This is another example where the ambiguity
between concatenation and aggregate expressions
has bitten an informed reader. In my personal
opinion it would have been better to use []s
as the delimiter for aggregate expressions just
so its designers could play in a different sand box
from Verilog concateanation.
Yulik Feldman wrote:
> 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 - 09:39:17 PST