Phone Conference P1450.1 Working Doc Subgroup
Thurs Jan 30, 10:00 am PST
Attendees:
Greg Maston (chair & scribe)
Jim Teisher
Daniel Fan
Peter Wohl
Dave Dowding
Documents
Agenda
Meeting discussion
table 5: Reviewed the changes to table 5 (actually more around
p19). Changes were accepted by this Working Group.
clause 6.10: Reviewed current definitions for scancells, and
scanchain-referencing constructs. Constructs were accepted by this
Working Group.
clause 10: variables usage. The attached pdf var-examples.pdf served
as the focus for this discussion. This example contains operations to
observe the behavior of two primary issues:
(a) variable scoping
(b) variables as macro/proc parameters and parameter-passing behavior
Both of these topics are new topics. They have been identified as
lacking definition in the current spec and need to be resolved.
(a) Variable Scoping
--------------------
The current proposal identifies the following model for scoping
behavior:
- (assumed) standard naming resolution; variables in named blocks
override definitions in the global block.
- every variable used in a Pattern, irrespective of where it was
defined (whether in a named Variables block or in the unnamed block)
is by default instantiated uniquely in every Pattern block that
contains that variable. Since each variable is uniquely instantiated
for each Pattern, there is no communication of variable information
between Patterns. Variables will be initialized to the Default value
(if specified) at the start of a Pattern execution. These variables
are considered "local" because a unique copy is maintained in each
Pattern.
- the attribute 'AllowAcrossPatterns' defines a Variable that has
characteristics of a "global" variable: only one copy of that variable
exists and all references to that variable from any Pattern refer to
the same variable. This variable does communicate across patterns
because all patterns see the same value of that variable.
- conflict resolution of the same variable name with different
attributes is not specified at the moment; do the local attributes
win?
One goal of these constructs is to support fairly direct integration
of Patterns from multiple sources (where some sources use
communicating variables and others do not). Integration of multiple
variables blocks can be accomplished by merging unnamed blocks as long
as the variable definitions in all unnamed blocks are consistent, and
maintaining individual named blocks or in some cases uniquifying these
names as necessary.
....
In discussion in the Working Group, another model was proposed for
variable scoping that purposefully binds the scoping with the STIL
name resolution process. This proposal would modify the existing
example (to support current behavior in that example) From:
10: Variables {
11: Integer INT; // used for integer pattern data
12: SignalVariable SV; // used for wfc pattern data
13: Integer FLAG {
14: AllowAcrossPatterns;
15: InitialValue 1;
16: }
17: }
To:
Variables {
Integer FLAG { InitialValue 1; }
}
Variables local {
Integer INT;
SignalVariable SV;
}
where the scoping is defined as:
- (assumed) standard naming resolution; variables in named blocks
override definitions in the global block.
- All variables declared in the unnamed block are by definition
"global" variables. A single instance of these variables is defined
for an entire test program. These variables can communicate across
Patterns.
- All variables declared in a named block are by definition "local"
variables. Each Pattern will have a unique instance of this variable
and these variables do not communicate across patterns.
- When a variable in a named Variables block has the same name as a
variable in the unnamed block, by definition that variable for any
pattern that uses that named Variables block is now local.
Binding the scoping to the naming resolution process also facilitates
integration of patterns from multiple sources. Furthermore,
'localization' of a variable from a named Variables block is automatic
and does not conflict with a global declaration that may have come
from a separate source. Also by maintaining all global variables in a
single unnamed block, the potential for conflicts or ambiguities of
whether a particular variable is a local or global variable based on
the presence or absence of an attribute, is eliminated.
Another identified benefit of this model is elimination of a separate
attribute, which complicates the merging process when two blocks (in
particular, unnamed blocks) are brought together and they both contain
the same variable but different attributes.
Working Group proposed that an example be generated along the lines of
the current example, that identifies the constructs to support this
model. Greg (or Tony), AI[1].
Jim asked about where these issues came from, and whether we were
considering all the consequences of the new proposal. Greg identified
that these issues were currently being raised at Synopsys and that we
would be discussing this alternate proposal. However, the dot-6,
dot-3, and dot-4 specs also have functionality dependent on
Variables and it was expected that these three groups would also
eventually become involved in the discussion.
(b) Variables as Macro/Proc Parameters
--------------------------------------
The other construct present in this example is the explicit
differentiation of assignment operations between normal (executed)
statements, and macro/parameter calls with arguments. Normally,
variables will take on the assigned value when the assignment occurs,
for example:
38: C { INT=5; SV=1111; } // direct param assignment
But when the assignment occurs in the argument list of a macro or
procedure call, then the assignment is deferred in the same way that
signal assignments are deferred; a '#' or '%' assignment must be
present in the body of the procedure or macro, to consume this new
value.
As Greg talked through this example, and indicated in particular that
the value of '6' to variable INT in macro M1 was deferred, he
presented an additional statement as the first statement in the body
of macro M1:
21: If 'INT==6' { Goto end_of_M1; } // False: INT has the value 5 in the first call
Peter recommended adding this statement to the example, AI[2].
Greg, fearing that he would forget the details of the discussions
above if he didn't get to typing the minutes, recommended to end this
Working Group session rather than continue to the next agenda
item. The remaining agenda items remain for the next meeting.
additional detail to resolve
----------------------------
1. local variables receive the initialvalue at the start of a
Pattern. When do 'global' variables get initialized? at the start of a
burst (which start in a hierarchy of bursts)? at the start of an exec?
2. statement processing. Are the statements:
2.1: V { SV=#; GR1='SV'; }
2.2: V { GR1='SV'; SV=#; }
(where SV is a signalvariable and GR1 is a signalgroup)
the same? Currently, dot1 places no order requirements on processing
statements in a Vector, which means an application can process the
statements in the opposite order and result with the same answer
(barring illegal behavior like assigning the same signal two different
WFCs). However this is not true for the statements above, unless an
evaluation precedence is defined that places integer-variable
assignment above signal-assignment (which only goes so far since you
can have multiple integer-assignments in one statement).
The unambiguous construct here would be:
2.3: C { SV=#; } V { GR1='SV'; }
It is bad form to have a variable on both the left and right hand
sides of an assignment in "one statement"; should it be illegal, or do
we identify that the result is ambiguous, or do we define in dot-1
that these statements are evaluation-sensitive and shall be evaluated
in a specific sequence? is the sequence order dependent or precedence
defined?
Meeting adjourned at 10:53 PST.
Next meeting
next phone meeting Feb. 13.
AIs