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?