STIL Working Group May 4-5 2000 Montreal, Canada, in association with VTS ------------------------------------------ The Working Group thanks Synopsys for supporting this meeting. Meeting called to order at 9:00 am by Tony Taylor, with a round of introductions by all participants. Attendees: --------- Tony Taylor, Synopsys Ernie Wahl, Lucent Sebastian Prassi, SZ Paul Reuter, Mentor (morning of first day only) Doug Sprague, IBM Peter Wohl, Synopsys Greg Maston, Fluence Rohit Kapur, Synopsys (occassionally) Discussion about what will push STIL forward in the industry started during introductions. Rohit identified the need to do marketing to push the STIL standard forward. Working Documents for this meeting: ---------------------------------- [1] May 00 Syntax [2] Gregg's DC levels doc was referenced but not reviewed at this meeting. Agenda: ------ As identified in the proposed agenda for this meeting, document [1] identifies the issues to discuss at this meeting. Additional construct proposals (not in document [1]) were identified and added to the agenda below. Tony identified some particular sections of [1] for review. The proposed agenda, with a resolution of each proposal after discussion, is presented below. Action Items and Typos in the review doc are listed at the end of these minutes. - tentative balloting plan - 1.17 - FileReference. Added this. - 1.18 - MacroList. Dropped this. - 1.13 - Conditionals and Var. Identified motivations but not closure. - LockStep (new concept). Identified motivations but not closure. - 1.15 - BIST structures. Dropped this. - CTL discussion (Rohit). Overview and motivation for requirements. - 1.11.1 - Tiling. Accepted proposed new syntax. - 1.16 - ScanStructures. Accepted as discussed (new syntax proposed) - "P"-behaviors discussion. Tabled for further discussion. - Conditional statements modification. Approved. - Variable block structure (reprise). Tabled for additional consideration. - Variable typing (reprise). Accepted "Usage" statement. - review tentative plan for balloting, doc generation, next meeting. - Versioning - STIL 1.0; dot versions, other versions. - Review doc structure, identify weak points, areas where need more examples - attend P1149.4 meeting, 10:30 Fri. The agenda was accepted by consensus. 1450.2 discussion ----------------- Tony opened a discussion about focusing any effort on DC levels at this meeting. Identified Gregg's doc [2], no one here has had much chance to review. This group did not feel enabled to do work here. Tentative plan for balloting: ----------------------------- Current proposal for the balloting process is to present a P1450.1 document and a P1450.0 supplement as a single ballot. Greg presented a concern that balloting a supplement to P1450.0 might put this entire effort at risk. While it would be nice to keep additions to specific syntax constructs, defined with those constructs in the .0 document, the ability to affect more than the scope of the .1 proposal might make accepting these changes as part of the .0 document difficult. Greg proposed that all constructs of the current proposal be presented in a single .1 document, even though it would make identifying the complete set of STIL constructs a bit more difficult. The Working Group accepted the motivation to define all constructs in a single document. There was more discussion over the concern about .1 failing and P1500 passing. Rohit identified that the P1500 group has a contingency (to rely on STIL UserKeywords if the P1450.1 ballot fails), but that contingency needs to be mobilized if necessary, and therefore P1500 needs to have a notion of status on this effort before they start balloting. Section 1.17, FileReference: --------------------------- This is a new proposal coming from the P1500 side. It is a statement inside the Environment block. changes: add VHDL format to pattern_file_format, filetype needs to have user_defined, also layout file formats GDSII, add DTIF to faultlist. changes: remove Word, RTF, and Frame. No, deleted tool-specific formats but RTF is tool-independent so it's still there. changes: add PostScript to the list. Peter asked for clarification for the purpose. Tony elaborated that this was to assist in linking this data to other file references in the "environment" of this data. For instance, if the patterns are in STIL then they would be Included, but if the patterns were in WGL or some tester-specific format, this mechanism would be used to reference that data. Basic definition/scope/perspective of CTL was defined: Everything needed for integration of the design is part of CTL. If STIL is the mechanism to transport that information, then this information needs to rely on being referenced from the STIL. Should this be part of the CTL environment, or part of the general STIL stuff. The WG agreed to add this construct, but proposed to change the syntax from a single statement to a block statement. Peter proposed the following syntax: (FileReference "filename" { (FileType type;) (FileFormat format;) (Version "ver";) })* (FileReference "filename";)* As part of the definition, the Working Group agreed to enumerate the format and type fields, but not tie the two enums together (not relate the options of the "format" to the options of the "type"). Ernie identified a request to identify a "pathtype" as well, or should we use URL definition. Decision to remove filepath, and change filename to be a URL format. Greg will look to see what issues we have either adding a definition of URL or referencing an external ...standard [AI1-gregm]. The filepath statement inside the FileReference: (FilePath "path";) was removed, and path aspects put back to the filename. Rohit identified a side-concern with the Working Group drop-and-add philosophy. This particular item is identified to be a P1500-issue, and if we change this item we need to identify to P1500 that we changing this. Peter made a motion, seconded by Tony, to approve the whole shebang as written above (that IS the wording of the motion), with the set of types associated with the filetype and fileformat as identified in document [1] with "changes" above. Unanimously approved by the Working Group. MacroList proposal: ------------------ Purpose to identify what macros are actually used. From a CTL perspective, need to know what macros are needed to be modified. This proposal has been modified by the P1500 WG, to require that macros used by test programs be appropriately partitioned by MacroDef blocks so only used macros are present in MacroDef blocks as necessary; they will mandate that macros be so organized. P1500 moved away from this requirement, so it has been struck from this document. Conditionals and Variables (1.13) -------------------------------- Last Working Group proposal put the Var declaration into the pattern. Problem identified with this is two-fold: 1. Would like to KNOW when variables will be declared. 2. Have circumstances where variables need to go cross-patterns. Proposal to add to Spec: Spec { Category { Name { PatternVariable { Base wfclist; Alignment ; Length integer; } }}} Pattern p { V { grp = 'var1'; } var1 = FF; //"variable assignment" statement } The "Typ" value of a PatternVariable is used to specify a default or initial value. If "Base" is not specified, then is the "default type" of a "variable" integer? Do we need a general variable, and a boolean, and a counting type? How does the "type" of the min/typ/max expression affect this variable? Should the expression "type" be identified - time, volts, unitless? Peter: what is the scope of a variable? Does the variable retain it's value between sequential patterns? Proposal is yes. Desire is to make this a mechanism to communicate between patterns. Greg raised concerns about this discussion from the minutes of the last meeting, and identified the discussion of the last meeting to use variables inside Patterns only, and pseudo-signals as inter-pattern or inter-facility communication. Rohit identified that the purpose of this extension is general "simulation-control", and identified the counter-concern that extending the concept of "pseudo-signals" to get tied up in pattern communication is too far afield for the purpose of Signals, and because Signal blocks are unary in the STIL environment, too restrictive to support variable representation. This was summed up with the statement: Pseudo signals are an extensible aspect, and if we're defining communication between patterns or between the test program, we need a specific construct to support that process. Proposal is to use variables to support that. Diagram 1, was generated. This can be found at: http://grouper.ieee.org/groups/1450/dot1/min_0018_diagram1.gif Discussed diagram 1, perspective that the analog device could be "started" from a variable or a pseudo-signal. Concern that setting a variable happens outside of the context of a pattern, outside of real-time. Statement was made that a variable is used when there is not real-time involved, if real-time (precise time) is needed then MUST use pseudo-signals. This current proposal (having Variables and Pseudo-signals inside the standard) will need a recommended usage document. Need to identify when to use pseudo-signals and variables. If need timing within a vector, then need to use signals. if don't need timing, DON'T USE PSEUDO SIGNALS. CTL requirements: need a mechanism from outside the patterns to control the pattern execution. This is a TIMING-FREE requirement. Want to specify GLOBAL CONTROL of pattern. Also need a CONTAINER that isolates that data to support separate cores. Identified that we don't have a local solution yet; have a global solution. May need another mechanism to support scoping or to identify collision. For instance, if there are two instances of the core, and variables controlling behavior of the design, need two instances of that variable (one per pattern set). Putting Variables into the Spec construct places them into the pattern context at the PatternExec level (as part of the Selector process). Need to move the construct from the Exec to the Burst level (allows specification at the individual Pattern level as well). As a result of this consideration, a NEW proposal was defined to create a new container Variables to allow new scoping level of this construct. Tony would like to add a Variable declaration inside the PatternBurst as one technique to support instantiation. Peter is concerned about doing things at both levels - if do it at the PatternBurst, do we need it in the Spec (which places it at the Exec)... consideration is to move the construct to the burst and not modify the spec (not put it into the Spec block) because it's too late. Peter requested the construct to be defined at the PatternBurst level, and to raise the discussion of this issue for the next meeting. Lockstep -------- Rohit presented diagram 2. This can be found at: http://grouper.ieee.org/groups/1450/dot1/min_0018_diagram2.gif Peter presented the current need/capablity to pull the last shift bit out of the Shift and place it in a subsequent Vector: load_unload C1 { V { a=0; } Shift {} V { a=1; scout=#; } <------ PULLING LAST BIT HERE. } load_unload C2 { V { ...} Shift {} V {} <------ not pulling a shift bit here. } Parallel LockStep { P1 P2; } After some discussion, a potential transform to support this issue was seen. But the concern remains, that "LockStep" is being defined external to the application context, and that the flexibility of the constructs that may see a "LockStep" requirement may cause problems without identifying internal requirements or structures to support "LockStep". The following question was raised: isn't this a set of requirements on the transformer/integrator? The response was: the pattern loader needs this information because the data coming from the two macros needs to be "tied together". There was another concern raised that the entire set of patterns may need to be checked before the validity of a "LockStep" statement could be validated. This concept was tabled for additional review at this point. BIST: ---- The original purpose of the BIST construct was to have sufficient description of BIST to allow/support "fast simulation". Described the LFSR structures, ignore the connection to the design. Started with LFSR concepts, expanded to support notion of cellular automata (CA) styles of BIST. A concern was raised several meetings ago, that there may be additional design constructs that need to be included as part of the description. Extended the connection environment to support XORs in the logic cloud between the BIST and the design. Then added the Parameters section, to further support describing the BIST stuff. But the description is still incomplete. BIST concept is much less well defined, not as rigorous in requirements. So start all over again. Proposal is to put "special structural constructs" block into STIL, for instance, Behavioral Elements { LFSR {} } Rohit considers that the block "Behavioral Elements" or "Structural Environment" is critical in STIL even without much description or body, as an "extendable environment" to support design description. Looking for an extendability construct in STIL to describe at some level, the interaction of the design with the test program. Need in P1500 is to support EXTEST mode, to check the logic around the core. Paul elaborated that the thing here is that some signals are key to this manipulation, and this manipulation is based on macros that specify how to manipulation this. The question is: do we need to know/have the reference to some other design construct. Rohit wants a structural reference with "labels" to structural stuff, and have a notion of how patterns may interact with this info. Concern that ConnectIn in the P1500 Envrironment needs to be able to relate to this information. Decision at this time is to leave the BIST section out, and have particular advocates (Peter) work toward a comfortable and necessary set of definitions. [AI3-peterw] Peter took the action item to continue thinking about BIST constructs. CTL intro: --------- Goal of CTL is to provide standard interface between the core provider and the system integrator. Cores come in as black boxes. Need to provide access to the core to use the core test data (INTEST). Also need to provide access to the logic around the core (EXTEST). May have a QUIET mode as well, etc. Test data comes in, in two pieces: Data, and Protocols. The goal of CTL is to never touch the test data, but manipulate the Protocols (which are of much smaller volume). CTL puts constraints on the style of STIL to support this capability, for instance, all data one example of a requirement: breaking apart vectors to remap .... another issue NOT addressed with current constructs: F vector - not complete solution because doesn't hold across patterns, and doesn't relate back to modes of the core...more below Panel discussion about parameterized cores. Issue or concern in the market about need to support this capability. Special CTL constructs end up in the Environment block: Environment { CTL { // attributes about signals // internal signals/groups description } CTL mode1 { // give meaning to the pattern data, // for instance to setup the IDDQ-stable mode } } One mode can inherit another mode. Another can succeed a mode (or be a child or however you think about it). Relationships are defined by block constructs inside a CTL, and include the blocks: CoreInstance, Internal, External, ScanInternal, PatternInfo. Internal is what you know for sure. External is "suggestions and guidelines" for how to interface to those references. ScanInternal is used when a core has an internal scanchain, and establishes the internal scan to the core IOs. Fixed: for CTL, need to put Fixed construct in the patternburst, to make sure that signals that are setup in a leading pattern, remain or hold the same value for subsequent patterns (where those subsequent patterns don't affect those signals). Tiling 1.11.1: ------------- Presented the constructs Fixed Wait Extend, as part of the PatternBurst info. Discussion about the two types of Fixed statements, this Fixed and the Fixed inside the Patterns. Inside Patterns, Fixed is a WFC reference; inside the PatternBurst the Fixed is a state value. Concern about the interaction or restrictions between these two constructs - can a Fixed in a Pattern assert a waveform that is equivalent to the state specified by the Fixed at the PatternBurst (answer from group is yes). Issue raised that there is also a notion about being "fixed" as asserted from a Levels point. This scenario OVERRIDES any data that might be present on that signal, while the Fixed construct here does not allow data to be present that is incompatible with this fixed value. The 'Extend' concept: behavior depends on last statement in pattern being extended. If a BreakPoint is present, then repeat that Break set as necessary until the first non-integral vector, i.e., it holds the last level/state value. Might need another recommended usage doc to indicate that not all parallel patterns should have an 'extend' defined; there should be one pattern that dictates the length of these patterns. There is a basic asumption here, that everything is contiguous. If one pattern set is running a funny frequency, and when done kicks another pattern set (perhaps on different signals) at a different frequency, it needs to kick that pattern off AT THAT PRECISE TIME (unless a Wait is present). Discussed the strategy to support "extending" a pattern when used in a parallel context with another pattern. The goal is to not modify the original pattern (such as add a breakpoint at the end of that pattern set when it did not originally have one). If Pattern A does not have a BreakPoint at the end, but needs a keep-alive clock, then user must define another PatternBurst (or PatList) that contains Pattern A + a new Pattern "I", and Pattern "I" is a single BreakPoint block with one vector and the keep-alive clock,and referenced from the ParallelPatList. based on example in syntax doc [1], page 14, 1.11.2: ParallelPatList { Pat A; Pat B; Pat C;} PatList { Pat I; } Extend { Pat I: Pat B; } Wait { Pat C; } ParallelPatList MUST have no signal overlap to run in parallel. That means that you CANNOT have a signal in common, even a Fixed signal. Wait and Extend can appear at the PatBurst level only. Peter made a motion to accept these concepts as discussed and seconded by Greg. Unanimously accepted. ScanStructures, 1.16: -------------------- Extended definition of scancells. Proposal to replace the Parameters block as defined here, with the new Variables block in the PatternBurst that has been proposed. PatternBurst { Variable scanmode; } example pg 25: ScanStructures { G1 { ... // Parameters {} is now gone. CellOut Slave { 'scanmode != 1 && scanmode != 0'; } CellOut Master ! { 'scanmode == 1'; } CellIn ! Master Shadow { 'scanmode != 0'; } a3 { if 'scanmode > 0' CellIn Shadow ! Master; if 'scanmode == 2' CellOut Slave; if 'scanmode == 1' CellOut Master !; } The values of scanmode (this is Peter's cheat sheet): when = 0 - serial mode, = 1 - shift mode, = 2 - parallel mode skewed_load { 'scanmode = 0'; ... } load_unload { scanstructs G1; Shift {} 'scanmode = 2'; } master_observe { 'scanmode = 1'; scanstructs G1; V {} } Pattern scan { 'scanmode = 2'; Call load_unload{} //scanmode stil 2 Call skewed_load {} //sets scanmode to 0 V {} //scanmode still 0 Call master_observe{}// Call load_unload{}; 2 scenarios to use this info: fast simulation, and diagnosis. Fast sim is the Shift statement. Master_observe only hits clock in a vector. Controling this variable this way allows the accelerated constructs to interprete the V{} statement as well as the Shift, and accelerate both of these statements. Peter identified the concept of a "level" of Variables support here: level 0: no scan structures (and therefore no acceleration) level 1: traditional scan structures description. STIL with no control options has sufficient information for this context and muxed-input-style scan test logic, to accelerate this environment. level 2: full robust support, using variables to identify acceleratable and non-acceleratable situations. Greg considered defining an enum type so he doesn't need Peter's cheat sheet to follow the previous example. Identified a need to "type" variables, because all of the variable manipulations in the example above, are not intended to be supported on the tester, but are used solely for "simulation acceleration" support. The following statement was defined to address this: PatternVariable | SimulationVariable; patternvariable - variable needed to properly execute a pattern simulationvariable - used only for simulation usage. Motion made to accept Peter's constructs as discussed. All votes in favor with Ernie abstaining, and Rohit who just walked in didn't vote. Stopped for the first day for dinner @ 6 pm. Started the next day at 9:17 am, with a topic raised by Ernie. "P" limitations: --------------- Next day, resumed at 9:17 am with a discussion about P-modes. Ernie opened the discussion with a concern that the behavior of the driver-on "P" is a fixed behavior, but he may want/need an environment where that behavior is different. Discussed the notion of a "little p", (new state proposal), where the "little p" follows a set of rules. This proposal was made to be consistant with the current standard. One set of proposed rules are: P rules (last drive rules), N rules, last compare rules. Ernie is considering a construct that perhaps allows the "state" of the P to be specified as a separate value, which would allow this value to be set separately (based on an external set of heuristics), and then applied with the P event. Greg was asked to generate a document of WGL "pmodes", and distribute this document for consideration by the Working Group [AI6 - gregm]. A brief discussion of whether this was a Design issue was started. While there are impacts to event interpretation with this construct, this issue may be more closely aligned with tester constraints. This issue was tabled for further consideration. Conditional statements structure: -------------------------------- Tony identified an issue with the constructs: If ( expr ) {} expr; Proposal to use single-quotes to differentiate the expressions, to be consistent with expressions in STIL: If 'expr' {} 'expr'; This prevents ambiguity potential with leading keywords as well. This change was agreed to by consensus. Variable block structures: ------------------------- Tony presented the concept of separating the Simulation Vars from the Pattern Vars by named blocks: PatternBurst B { Sim Vars { a } Pattern Vars { b } } Peter raised the question about whether the same variable name could appear in both the Sim and Pattern spaces. Greg said since Variables appear in the same space (inside Patterns) and are used in the same statements (conditionals and expression statements), that they are not differentiatable, so they naturally share a common namespace. Peter proposed rather than typing the variables as "patternvariable" or "simulationvariable", perhaps have a "non-ate-variable" type. Current proposal based on this discussion is to to define the ONE attribute: SimulationUseOnly; SimulationUseOnly variables cannot appear in contexts that control pattern flow or signal assignment. Doug mentioned that perhaps this should be structured as: Usage SimulationUseOnly; to allow future extensions to the Usage context. This was approved by consensus. Next Meeting: ------------ Tentatively discussed next meeting around the first week of August. Doug identified that he will be on vacation at that time someplace in Maine, so the Working Group accepted his proposal to have the meeting someplace in Maine. Doug took an Action Item to look into someplace at Bar Harbor.[AI4-dougs] Discussed the way to order the information for P1450.1. Tony proposed defining an Annex of all statements in STIL as part of this document, Greg speculated this might belong as something that goes between ALL docs (and would remain on the website as a master index of all STIL statements and where they are defined). 1149.4 meeting: -------------- The Working Group took a Break from 10:30 - 12:00 to attend the 1149.4 Working Group. They had invited us to present on STIL and to discuss possible avenues of synergy between our efforts. Versioning: ---------- Discussion about revision/versioning options. Reviewed current version statement: STIL 1.0; Considered that the next round of balloting might change this statement to: STIL 2002; Proposed the syntax: Extension Design 2001; Extension CTL 2001; Extension DCLevels 2001; Need to describe the intent of the Extension keyword, and the intent that the keywords defined for the specific types of extensions imply. Discussed positioning of this statement. Extension statement MUST occur before the first occurance of a keyword that is specific to that version, and (for language consistency) *should* appear at the top of a file containing those constructs. Changed the proposal (and forced the statement to occur up front) to be: STIL 1.0 { Extension Design 2001; } This discussion identified the additional points: Clarification to allow STIL statements to be either ; or {}. This clarification is necessary to allow the STIL 1.0; statement to become STIL 1.0 {} (without reballoting the current standard). [AI5-gregm] - Greg to do this. Clarification needed that the STIL statement must be the first statement of each file, including Included files. [AI5-gregm] - Greg to do this. Clarification that only STIL files can be included. [AI5-gregm] - Greg to do this. Working Group Voting Requirements: --------------------------------- Tony would like to consider defining some rules to establish voting privilege in the Working Group, for instance to require attendance at a minimum of 2 Working Group meetings in the past two years. The purpose of this is to facilitate progression of the P1450.1 proposal to the IEEE without getting the effort suddenly sidelined by new participants as we start the effort to actually construct the proposal document. TimeLine: -------- May < meeting : issues mostly resolved June July < milestone : agree to document structure Aug < meeting : sections mostly complete Sept < milestone : doc available for review on web Oct < meeting : final document review Nov Dec < milestone : ballot decision on proposal doc. Structure of the P1450.1 document: --------------------------------- A first-pass repartitioning of the P1450.1 review document was made, to define the order and structure of the document for balloting. The results are below: Leading section numbers on these lines are the section numbers of the current document [1] under review. All tutorial numbers (T1-T7) are new, although material for these sections may be present in the current document. TUTORIAL: -------- T1: --- parameters, vector expressions T2: --- \m T3: --- \j T4: --- F and E T5: --- conditional T5.1 -- tiling T5.2 -- lockstep T6: --- scanstructures examples T7: 2.0 1450.1 - Simulator Cross-Reference / Fail Data Feedback (Brady & Tom Munns)- 26 2.2 Fail Data Feedback in STIL- 29 2.3 Simulator Cross-Reference / Fail Data Feedback Example: 30 2.4 Simulator: Internal Perspective - 31 First section: ------------- KEYWORDS/main: 1.8 Local Keywords (as decided at Dec99 meeting) ENVIRONMENT/main: 1.10 Environment Statement (as decided at Dec99 meeting) FILEREFERENCE/main: 1.17 FileReference Statement (proposed by CTL working group) STIL/main: - Extension statement Second section: -------------- PATTERNBURST: 1.11 PatternSet & ParallelPatList (As discussed at Feb00 meeting) 1.14 Conditional Execution of Patterns in a PatternBurst (As discussed at Feb00 meeting) -- break into two sections: a general 'conditions' and as applied to PatternBurst - new VARIABLE statement - LockStep Third section: ------------- PATTERN section: 1.1 Parameter Passing to Macros (as decided at Dec99 meeting) 1.2 Vector Data Expressions (as decided at Dec99 meeting) 1.13 Conditional Execution of Pattern Statements (As discussed at Feb00 meeting) --- reference to 'conditional' section of Burst 1.3 Vector Data Mapping using \m. (as decided at Feb00 meeting) 1.4 Vector Data Mapping using \j. (as decided at Feb00 meeting) 1.9 Specifying Event Data in a Pattern (as decided at the Dec99 meeting) 1.5 Signal Constraints using Fixed & Equiv. (as decided at Feb00 meeting) 1.6 ScanStructures statement in a Pattern Block (as decided at Dec99 meeting) 2.1 Syntax: The Cross-Reference (X) statement Forth section: ------------- SCANSTRUCTURES: 1.7 Indexed List of ScanCells (approved at Feb99 meeting) 1.16 Scan Structures (Updated by Peter Wohl from Feb 00 meeting) DROPPED SECTIONS: ---------------- 1.12 Independent Parallel Patterns (as decided at Dec99 meeting) --- make it a clarification/recommendation [AI5] 1.15 BIST Structures (Updated by Peter Wohl from Feb 00 meeting) --- removed 1.18 MacroList & ProcedureList (proposed by CTL working group) --- removed Assignments: ----------- The following individuals accepted the following sections to generate a "ballot-ready" section for: Peter took: scanstructures, \m \j F and E (1.6, 1.3, 1.4, 1.5, 1.16, 1.7) [AI7-peterw] Greg took: the main stuff (1.8, 1.10, 1.17) [AI8-gregm] Tony took: patternburst and conditionals,lockstep (1.1.,1.2,1.13,1.11,1.14) [AI9-tonyt] Doug took: fail feedback (2.0) [AI10-dougs] Adjourment: ---------- The meeting was adjourned at 12:30 pm Friday. Action Items: ------------ [AI1-gregm]: Greg to look up URL references. [AI2-all]: Group to review and consider the Variable scoping issue. [AI3-peterw]: Peter to consider BIST constructs. Anyone else with an interest in this area shall participate in this effort. [AI4-dougs]: Doug to look into locations in Bar Harbor. [AI5-gregm]: Greg to add the three Clarifications to the Clarification doc. [AI6-gregm]: Greg to ship "pmode" concept to WG. [AI7-peterw]: Peter document assignments [AI8-gregm]: Greg document assignments [AI9-tonyt]: Tony document assignments [AI10-dougs]: Doug document assignments Typos in the review document: ---------------------------- Page 6 move [15:0] up a line in example (should be associated with variable decl). Page 25 section 1.17 first line needs "with". Page 1, additional curly brace to close macrodefs section 1.2, and rest of example re-indented. Section 1.8, page 9: second paragraph, "not" should be "now" in "NOW allowed to appear..." Page 10, section 1.10, example at bottom of page needs to replace closing parenthesis with closing squiggly brace. ----- Respectfully submitted, Greg Maston