minutes-2002-06-21

Agenda:

1. The following is a list of pages in the new doc that have questions needing discussion:

11 - Need wg review/approval of the above change. Note that params can only be ints ... not reals, time, voltage, etc. Makes for some awkwardness, but avoids the 4.9999 type of problems.

11 - Need to think about how Spec-vars can be used in combination with IntegerParam. Need an example of usage.

24 - new subclause needs review/approval of WG. Need to resolve whether lower level block replace or merge with upper level blocks. JohnC sites CTL as a case where stmts are merged. In most cases, named objects are merged (signals, scan-cells, procs, macros, etc.).

30 - Need wg review/approval - added Variable reference to the TRC block. Also, note the usage of <|>.

36 - Need wg review/approval of change to DCLimits. See code example below. Uses boolean expr, like in TimeLimits stmt.

38 - Are parens reqd around the boolean expr? To differentiate from the list of identifiers? What about a stmt like: DCLimits VIL XYZ < @@; vs DCLimits VIL (XYZ < @@);

38 - Need wg review/approval of the use of <|> to represent optional stmts.

41 - Second integer_expr has been removed from the following stmt. Don’t think it is required, and don’t rember why we put it there.

59 - Need to review this annex. Need to decide if examples should all be changed to use the new Assert stmt in a Vars block, or do we also have examples that use spec-vars?

2. I think it's time to put together the ballot list and notify IEEE. I expect to complete my work in the document in the next two weeks. How much more time do we need for wg review? For work with ATE companies on TRC creation?

Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.

1. New statements - Assert, IntegerParam, IntegerConfig

- The code example in 5.2 incorrectly shows MIN_PERIOD as an int, and expects it to be a real

- Need to work out how real value constants can be accommodated. Can we use spec-vars?

- Need to updated this example, and also annex B

2. Scoping rules

- The scoping rules, as currently written are confusing

- WG prefers to see stmts from higher level blocks merged with lower level blocks

- Here is the vote on the three alternatives:

    1. replace by block - TT

    2. merge & report error upon conflict - DG, GM, DF (and probably JC)

    3. merge & local overrides - JS

- The merging paradigm is to be consistent with dot6. Tony has agreed to review all the dots and prepare a summary of scoping usage across all of STIL (probably will make into an App Note)

- The merging paradigm is TBD, but basically will say that statements in higher level blocks and lower level blocks co-exist as though created in a single block. All rules as defined in a single block must be adhered to. Any violations will result in a error. An example of an error - high level block calls for WaveformAttributes, and low level block calls for WaveformDescriptions (Note: only one or the other is allowed)

3. DCLevels

- WG agreed with the two main changes: a) multiple identifiers, b) boolean expression (like for TimeLimits)

- WG decided that parens are required around the boolean expression to delimit from the list if identifiers (as is done in pattern-data and timing-data.

- WG discussed the need for separate limit definitions when multiple ref levels are specified - i.e., in support of the U1, U2, etc. WG decided not to address it at this time. Which means that all the mult levels must meet the same set of limits. If we decide to support it later, then it will require extending the identifiers - VIL1, VIL2, etc.

- Jose asked about user defined checks that are not covered in the defined syntax. An example would be if one want to specify that VIH always be greater that VIL. We need to think more about this. One possibility, of course, is UserDefined, but that's ... duuh ... non-standard. Another possibility is the new Assert and use of constant params.

4. Use of < ... | ... > at top level

WG approved of the changes to the top level block to more accurately show the allowed syntax between semicolon terminated statements and the block statements.

5. Proofing the document

WG agreed that we need to do a thorough proofing of the document before it goes to ballot. The plan is for Tony to finish making changes to D12 by the next meeting - May 11. We would then use May and June to thoroughly review the document. The following agreed to proof the document:

- Greg Maston

- Jose Santiago

6. Ballot process

- Tony will prepare the ballot submittal forms for IEEE with the plan to submit the first draft on July 1, 2006.

Meeting adjourned 11:15 Pacific time