Phone Conference P1450.1 Working Doc Subgroup

Thurs, June 3, 2004, 10:00 am PDT

 

Attendees:

Tony Taylor (chair & scribe)
John Cosley
Jose Santiago
Bruce Kaufmann

 

Documents

Agenda

  1. Status

  2. Clause 15 - ScanStructures with cell groups included (in attached pdf)
    - functionality agreed to last meeting; need WG review of the new write-up

  3. Clause 18 - Pattern data (in attached pdf)
    - New Table 10 - backslash operators
    - Question: Is this too restrictive? Should we, for instance allow '\j\WSIGNAME', or '\m\SSIGNAME' ?

  4. Clause 18.3 - events in pattern data (in attached pdf)
    - new table of events

  5. DM16 - How far do we go with allowing \e? (see resolution doc)

  6. DM20 - instances of complex scan cells (see resolution doc)

  7. GR3 - rules for reserved words (see resolution doc)
    - new rule: "The rule in STIL.0 that all keywords be reserved is relaxed in STIL.1. Only keywords for the top level blocks and statements are reserved."
    - means that if you specify STIL 1.0 { Design xxx; } that all dot0 keywords are no longer outlawed
    - why do we even need to reserve the top level keywords for that matter?
    - is there value to keeping Table-1 but labeling it a list of new keywords? ... along with the statement that these keywords are not reserved

  8. DM-22AU - 57, 19.1.(1), , E
    - Path restriction is un-checkable: cf. halting problem


Meeting discussion

 

IEEE meeting clearances

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

 

1. Status

percent completed = 84%
    DONE = 237
    UNCH = 14

percent remaining = 16%
    ASSIGN = 33
    REVIEW = 3
    TBD = 13

2.Clause 15 - ScanStructures with cell groups included

WG is still OK with the syntax as decided last week.

 

John suggests to add a new rule that states - Complete scan chains are identified by the presence of either a ScanIn or a ScanOut statement in the ScanChain block. All other scan chains are either partial chain segments or cell groups that can not accessed directly by a tester.

 

Tony will augment clause 15.5 and then proceed to adjust all the examples to the new syntax.

 

3. Clause 18 - Pattern data; and DM16

WG thought that the new table of backslash operators was a good idea ... however ...

 

Upon further discussion it became clear that the idea of putting the allowed backslash combinations into the table was insufficient. The first idea (from John) was to develop some meta-definitions for things like  - anything that can produce a wfc (either wfc, \W signame, \W sigvar, \W wfcconst); anything that can produce an event, etc. Then indicate which backslash operators can be used with each. The second idea (from Jose) was to develop a bnf definition of what is allowed.

 

Tony agreed to do some more work on this and have a new proposal ready for the next meeting.

 

Examples of the combinations to consider are:

    \r\w, \r\d, \r/h

    \jw, \jW name

    \m\w, \m\W name

 

Jose further questioned whether the table would be better moved to an earlier place in the document (e.g., clause 6) since some of the backslash operators are used in other blocks - i.e., the Pattern -> Equivalent statement uses \m.

 

A related issue was raised as to whether \e-events are sticky - i.e., do they repeat in subsequent cycles. It was agreed that they should repeat until a subsequent \e or wfc. It was also decided that only one event of a given class (drive, compare) be allowed in a vector on a signal. The \ex and \eX should behave identically and serve to terminate any compare activity at T0. A \el, \eh, \et each start window compares at T0 and terminate at the end of the period, with the understanding that they will repeat again in the next cycle if no new behavior is specified.

 

4.DM20 - instances of complex scan cells - This issue was tabled as neither Peter or Greg were present.

 

5. GR3 - rules for reserved words

 

WG agrees with not making new blocks and statements reserved words (as is done in dot0). WG further questioned why even the top level block names need be reserved. Everything is really position dependant. Would like to get the opinion of those not present before deciding.

 

WG also strongly suggests adding this new concept to the dot0 clarifications document and then changing the rule in the dot0 standard in the upcoming revision.

 

6. DM-22AU - Path restriction is uncheckable

The issue being raised is illustrated by the following:

    If (x) Shift { V { SI=#; } }

    If (y) Shift { V { SI=#; } }

The choice of which shift or shifts gets executed is not know until run time. This makes it impossible to do the scan data preparation (i.e., padding) necessary.

 

WG decided to add the rule - If/Else/While are not allowed to control a Shift block.

 

WG discussed the LoopData construct and decided that it is OK. The behavior is that the first LoopData consumes all the data and any subsequent LoopData with the same signals will just get the extended last cycle.

 

7. Annex-O - is approved by WG. Tony to remove old information.


Meeting ended at 11:05.


Next meeting

Thursday, June 17, 2004, 10:00 to 11:30AM, PDT

 

AIs

  1. Greg - Statement of Intent on expression syntax and get NO-voters buy in

  2. Tony - work with Rohit to resolve the timing expression issue described above

  3. Bruce - rework  Annex-N to clarify the use of labels and X statements

  4. Peter - DM-5 "What is the nature of STATE_ELEMENT?"

  5. Tony - Update doc per the above decisions

  6. Greg - Facilitate final decision on reserved words - in dot1 and dot0