Phone Conference P1450

Meeting discussion

pg 24 - Variables -

Greg recapped last weeks discussions. Tony voiced a concern about this

behavior, in that variables local to a pattern need to propagate

'down', probably to the pattern reference, in an integration flow that

adds additional patterns into a PatternBurst. This can be a

maintenance issue for pattern development. Also there's an issue that

variables are instantiated at the 'use' level rather than as part of

the block itself, which makes the instantiation process less clear.

At this point, due to some other interruptions, a process change

request was made to Tony: add the stil website password into the

meeting announcements, so phone numbers and passwords are all in one

place; [AI1] to Tony.

The Working Group accepted to remove the AllowAcrossPatterns attribute

in favor of this proposal to support variable scoping in conjunction

with Variable block naming and referencing scopes. [AI2] to Tony to

remove AllowAcrossPatterns and to add words in support of

scoping-by-block-references.

issue 2 from last weeks minutes -

As part of covering Variables issues, Issue 2 at the end of last

meeting's minutes was discussed. In that issue, Greg raised a concern

about assigning values to variables and signalvariables mixed with

signal references to those variables, in the same Vector or Condition

statement. The issue is that currently there is no stated evaluation

order on statements in the V{} or C{}, nor does evaluation order

affect the expression EXCEPT in this situation where variables are

both l-val and r-val (on the left side of an assignment, and on the

right side of an assignment) in the same set of statements.

The Working Group agreed to make it an error to use variable

references in multiple assignment statements, where there are separate

left-hand and right-hand applications of that variable, in a single

Vector or Condition, or any other context where order of evaluation

has not been defined. [AI3] to Tony to add this restriction.

The unambigious solution to this problem is to always put the

assignments in separate Condition statements.

BUT NOTE (Greg added this while typing the minutes): it is not an

error to have the same variable on both sides in a SINGLE statement,

for example:

C { 'var = var+1'; }

Signals and WFCs comparisions - pg 69

Question is: can we compare a signal against a WFC? Currently the

definition of boolean expression would tend to lean toward

interpreting that this was not allowed, and Greg indicated that that

was his original motivation in order to limit the needed definitions

of "what was equal". Greg identified several issues here:

(a) WFC references can look like alot of different things, and are

easily mis-parsed to be integer values, STIL keywords, or other things

of the wrong type. This is an issue today in the pattern area, but due

to limitations of where things can appear it can be addressed. Moving

WFC-lists into the expression arena opens a can of parse worms.

(b) are we comparing against WFCs, or comparing against the waveform

functionality defined by a WFC? For example, if WFC "1" and "2"

define identical waveforms, and a signal is currently assigned WFC

"1", is 'sig == 2' True or False?

do we compare in these contexts?

It was also identified that any scenario that needs to compare WFCs,

can do an equivalent operation by maintaining a parallel variable

value and performing the comparison against that value. The

disadvantage of this solution is that it requires redundant constructs

to be maintained for the purpose of comparison.

After some additional discussion, with no definitive resolution, the

proposal was made for all members of the Working Group to go out and

generate applications to demonstrate the need for this

capability. [AI4] to all.

Hex data - pg 72 -

The example on this page featured an assignment of 'FF' to an integer

variable. The Working Group agreed that this was permissable but only

with the addition of a \h to identify the following value to be

hexadecimal. Tony took [AI5] to add the capability to support \h in

integer variable assignments.

Scan chain chaining - pg 73 -

The current example features two Shift blocks in the macro definitions

of each of the cores after integration into a bigger design, to

consume the scan-bits of the other core as appropriate. Problem with

this example is that the behavior of a Shift block with no argument

values is not really defined.

Several alternate proposals were made, in particular, using a Loop

construct with either a constant or variable (data-dependent) number

of loops; problem with data-dependency here is that the data is

actually coming from a parallel pattern context and isn't part of the

data present in this pattern context. Another proposal was the use of

the BreakPoint to facilitate maintaining synchronization (which Greg

identified still needs semantic definition in the LockStep section to

be used this way).

After some discussion, a proposal was made to augment the semantics of

a Shift in the context of parallel-patterns in lockstep, to support no

arguments in that Shift as having the semantic interpretation that the

Shift is dictated by data being present on some other Shift data in

parallel to this.

Both the Loop-count proposal and the Shift-semantic proposal seem

to have merit. The group agreed to ponder these alternatives and make

a decision at the next meeting.

Pragma movement proposal

Tony presented the issue of moving the Pragma block from .3 into .1,

in order to support a mechanism to define UserFunction bodies, as

shown in the Agenda above. The current requirement satisified by

moving the Pragma to this spec is to provide a mechanism to define

UserFunctions. The current requirements in .3 for Pragma capability is

unchanged, and since .3 references .1 it would have the Pragma

definitions available.

General concern was raised about the potential for over-use of a

Pragma block, and a proposal to have a strongly-worded recommendation

that users limit occurance of these blocks was made. There was

tentative acceptance by the Working Group of supporting the Pragma

block here pending the addition of this definition into the working

draft by Tony for review next time; [AI6] to Tony.