PAR issues

Why is the first topic of our meetings never on the agenda?

The PAR for this effort is expiring by end of year. Greg just reviewed

the current PAR: it was accepted in the NesCom meeting in June

1999. Brief review of the balloting process, backing up time

frames, resulted in a goal of starting ballot around april-may, but

that was under an assumption that the PAR expired later in the year.

Current decision is to work all-out with a goal of starting the

balloting process by April 1. If we are concerned about not hitting

this date then we will request an extension.

pg 20 - add'l operators in table 5.

Tony added additional operators in table 5, and additional columns of

usage, for completeness.

First issue raised here was a concern about the presence of 4

different domain operators. Would be nice to reduce the number of

operators to a single operator if possible. This led to:

pg 21 - chainname referencing

...and the presence of 2 operators in this construct at the moment - ::

and ->, along with documentation presence of a single-colon which is

part of p1450.6 operators.

After discussion on whether we should document the ':' operator, which

is not used in this spec but is part of the p1450.6 definitions, it

was agreed to move the paragraphs at the top of page 21 to a

recommended usage context and not part of this spec. Tony provide

paragraphs to Greg, [AI1].

After additional discusion about the need for using a different

operator to identify the 'instance' of a cellname, it was agreed to

change the use of -> to ::, because the application of this operator

is identifiable from the context, and eliminate arrows at this time.

Tony identified the use of an 'instance.cellname' in the diagram for

Case 1. It was recommended that this should be cellname::instance to

follow the scanchain naming conventions (which would be

::chainname::instance), and that the cellname and chainname are still

unambiguously differentiated here because of the leading :: on the

chainname. Tony to change reference, [AI2].

Summary of Table 5 changes:

Remove ':' and '->'. Identify '::' is the primary instance operator.

Also based on discussion started by Tony, add comma to the table [AI3].

pg 24 - AllowAcrossPatterns attribute

New issue and new requirement for clarification. The behavior of

variable scoping was raised. Concept that variables are local and

instantiated on a Pattern basis independent of what domain blocks

declared them. To support accessing the same variable across multiple

contexts, the attribute AllowAcrossPatterns must be present on the

variable declaration.

Other (also undocumented) concept is that variable declarations from

the same domain context are global/shared; for instance, variables

defined in the unnamed Variable block are shared across all Patterns

by default. Local variables are created by defining named Variable

blocks and only Patterns that access those named block have shared

access to the instance of that variable from that domain.

Concern raised by Dan that other standards (.3) using Variables need

to expect similar behaviors, and that the current unworded expectation

leaned toward a more inherently-global model.

This issue was identified outside the Working Group and Tony will

arrange a meeting between Greg, Tony, and the individual, to discuss

appropriate structuring models. [AI4].

pg 31 - Fix{} referencing state or waveform

Review of the additional wording to support identification of a WFC or

a static state via the \e construct. Peter had a concern that this

context was different than the context of the F statement inside a

Pattern/Macro/Procedure. During the discussion it was identified that

the expectation that a Fix requirement is checked on the next executable

statement (the next Vector to execute); there still needs to be

clarification whether the Fix statement itself operates as an

assignment like a Condition, or is just a constraining/checking

statement on the values asserted on those Fixed signals and it is

necessary for some subsequent operation to assert that Fixed value if

it was not already set.

Request to add a sentence here indicating that additional assertions

to the same value as specified in a Fix statement is allowed; it is

not wrong for Patterns to re-assert a Fixed value if they desire (it

is not an error to mention a Fixed signal again, it just has to be

constrained to the specified Fixed value). Tony [AI5] to add sentence.

pg 61 - Construct needs to add 'Call'; Greg agrees.

pg 66 - Question about the need to assign SignalVariables with a '#'

The fundamental issue is the behavior of SignalVariable assignments on

a Call/Macro statement. There are two models that may be used here:

the Integer model (where the value is assigned to that variable when

the assignment statement is seen), or the Signals model (where the

value is treated as a parameter and is deferred assignment until that

reference is assigned a '#' or '%' inside the proc/macro body).

Tony leaned toward the Integer model because SignalVariables are

declared in the Variables block and reduces overhead if the value is

assigned when an assignment statement is seen (irrespective of whether

the assignment is in the parameters of a macro/procedure

call). However with the help of Jason, an example was presented where

multiple values are passed to a SignalVariable, and need to be

consumed sequentially in order for the macro/procedure to operate

correctly. This indicates the need to support parameter-passing using

the Signals model for SignalVariables. Tony will add words around this

requirement to make the need for this clear, [AI6].

fail feedback (briefly)

Jason had a question about the failure data-return from a tester using

these constructs, which was identified to be the contents of the

middle box on page 100. He is concerned about the verbosity level of

this information.

Jason maintains an intention to form a review group on the issue of

fail feedback, [AI7].

Meeting adjourned at 11:45 PST.