minutes of the STIL meeting Dec 9-10 1999 at TI Dallas Tx in attendance: -------------- Gregg Wilder Ernie Wahl Francisco Hernandez Bernard Heibler Kim Smith Nathan Biggs Greg Maston Tony Taylor Doug Sprague Peter Wohl Opening Remarks --------------- The Working Group wants to thank Francisco Hernandez and Gregg Wilder, and TI, for hosting us at this meeting. Ernie raised a complaint from Don Denburg. The Working Group has never had a celebratory meeting after the release of 1450. The Working Group unhappily acknowledges that they are all workaholics. Tony passed around a copy of the minutes taken discussion at the last meeting at ITC. The minutes were accepted by default. A request was made for these minutes to be complete. Greg agreed - accepted - to take these minutes. Agenda ------ Tony led the discussion on agenda with an overview of the current dot efforts. Tony presented the syntax doc he had distributed prior to the meeting as proposal for review for dot 1 efforts. Gregg assembled a dot2 document for review. Copies were distributed for those in need. Dot3 has little effort; An action item from awhile ago, to generate letters to ATE companies, requesting participation, hasn't happened yet. Kim raised the issue that purchasers don't have much lever to force STIL and limiting expansion of STIL; Ernie disagreed that this was suppressing the expansion of STIL because of internal tools, Tony stated that design tools will push STIL forward. Dot4 has a lot of work behind it, but little in review form. Ernie stated some testers are very capable and others are problematic, esp. in flow, and having a consistent level of representation is critical in this area. Dot5 requires foundation work from .4. Dot6 (analog) - needs groundwork on flow and test methods to get support here. Bernard feels that wave representation is straightforward, but the actual measurement capability is still VERY tester dependent. Before finalizing the agenda, the group took a break. Over break the group had a lively discussion about CTL and where STIL fits, in order to define the orientation of some of the syntax requests on the .1 list. Agenda: ------- - All syntax issues of Tony's document were sorted for .1 issues; table below - attack in the following order: 1.8,1.5 (scangroup ref) 1.7, 2.1, 2.2 1.3,1.4,2.9,2.10,1.10 1.8, 2.5, 2.6, 1.9 2.3, 2.4 1.1, 1.2, 1.3 2.7, 2.8 fail feedback levels flow - goal to spend max 1 hour per line above. Working Discussion: ------------------- 1.7 : localkeywords - Initial proposal is to define the statement "LocalKeywords" or "LocalUserKeywords". Statement can appear only once in a block. Definitions can not conflict with any keyword scoped to that block, and statement must occur before any occurrence (use) of one of those keywords. Discussion: three contexts of keywords in STIL: (1) STIL global keywords (2)UserKeywords [globally defined], and (3) localkeywords. Motion was made in regards to allowing localkeywords to override STIL keywords that are NOT part of a scope. Motion was made that localkeywords should NOT be allowed to override ANY STIL keyword, whether inside the current scope or not. Agreed to unanimously. Justification: need to push users to make extensions part of the standard, not allow localkeywords to override that STIL usage even if in a different context. Motion was made to allow multiple localkeywords statement. Amend: make localkeywords follow the same semantics as UserKeywords with local scope. Justification: problem with including information, don't know what's in that block; also for consistency with UserKeyword structure. Motion passed unanimously. Motion was made to modify the concept of 'localkeywords', to use the same 'UserKeywords' statement, with the extension that this statement is now allowed to appear inside STIL blocks. When inside blocks the list of definitions is scoped to be defined in that block only. Motion passed unanimously. A usage recommendation was stated at this point, that users of STIL should be recommended to NOT USE 'global' userkeyords, but always define keywords inside their usage context. This allows for the highest level of 'syntax' checking by minimizing the scope of application of a UserKeyword. -- Discussion on 1.5: Peter identified the need to add a ScanStructures statement to the statements in the pattern block, to operate as the current ScanChain statement operates but referencing a set of scanchains rather than each one individually. Justification: this statement allows referencing of complete scan "group", which reduces the number of statements needed to reference multiple scan chains. Motion was made and carried with 2 abstentions, 8 in favor. - At this point, the group took another break. -- Discussion on issues 2,1,2.2 - Kim raised the perspective that this whole block should just be UserKeywords. Tony discussed CTL extensions. Discussed the impact of UserKeyword for the whole environment; need support of 'Include' and 'Ann' statements inside those blocks. Motion by Ernie to support the CTL and Design constructs as UserKeywords. Discussion about whether anything needs to be defined INSIDE these specific blocks. SignalMap location needs to be determined, as to under the block or up a level --- Nathan's proposal: Environment (name) { SignalGroups name; SignalMap { ’a+b’ { Verilog "a/b"; VHDL "A[0..1]"; } } } Another recommended usage was stated here. It is recommended that all users put names on all Env blocks, and not rely on an unnamed Environment block. This recommendation may be extended across all blocks that support named and a single unnamed instance; to avoid confusion, difficulty in interpretation, and to minimize issues when collecting data from multiple sources into one test program, all blocks should be named. Naming conventions and semantics on Environment blocks follows the semantics of the SignalGroups block (unnamed Environment blocks can always be accessed; named blocks when referenced (i.e. in a PatternExec) will override any global definitions). A discussion ensued on what is understood inside the UDK -- issue being that Ann structure needs to be interpreted inside a UDK, otherwise that block will not be properly parsed if it contains Anns. The issue was opened up to include comment syntax and Includes. A motion was made at this point and seconded, to extend the definition of the contents of a User Defined Block, to support the interpretation of Ann, Include, // , and /* */. Motion was voted and approved unanimously at 12:15 pm. Another motion was made and seconded, to use UserKeywords inside the Environment block to support the creation of tool-specific blocks inside the Environment block. This motion was made specifically against the previous assumption that undefined blocks could be defined inside the Environment block and operate as if they were implicitly declared as UserKeywords. Motion passed unanimously. A motion was made to accept the Environment block, make SignalMaps part of Environment block level, and define the two forms of the sig-expr statement inside the map block. After discussion, a friendly amendment was made to this motion to define the Environment block syntax as: Environment (name) { (SignalGroups name;) (SignalMaps { (sig-expr "map string";)* (sig-expr { (userid "map string";) })* }) }) This motion was seconded and passed unanimously. The group broke for lunch at 12:40 and returned at 1:30. A motion was made to support referencing of Environment information. The motion was stated to allow named and one optional unnamed Environment. The unnamed Environment is global, and the data contained in the unnamed block merges with a named Environment data when a named block is referenced from a PatternExec. Motion was amended to replace "the data contained in the unnamed..." with "allows a single reference to a named Environment block; if no Environment block is referenced, then defaults to use the global (unnamed) Environment block if one is defined". A discussion on this motion resulted in an attempt to understand how information contained in two (named) Environment blocks might be collected, via either an Inherit mechanism or by allowing MULTIPLE references to that information. The discussion identified the two scenarios below: Env TesterA { SignalMaps { r0 "channel1"; } } Env SimB { SignalMaps { r0 "top.u1.r0"; } } scenario (1) scenario (2) --------------- -------------- Env Test { or PatternExec { Inherit TesterA; Env TesterA; Inherit SimB; Env SimA; } } After this discussion, the Working Group came to the conclusion that since the Environment is a block that references STIL into "something else", that "something else" is not identified to be part of STIL (in fact, is typically identified to be very much outside of the STIL context), and therefore no objects in STIL (such as the PatternExec) should be referencing the Environment today. Therefore the previous motion, to define referencing for this information, was tabled. ---- However the group continued the issue of how Environment information might be incrementally defined and collected together via some form of Inherit or Merge function. Several methods for collecting information were identified as candidate operations: (1) all information in an inherited block is added into a referencing block, where ALL the information from each block is maintained (with the perspective that there is no "common information" but each set of information is unique (i.e. identified or tagged by block name), (2) information from an inherited block is added into a referencing block, but "common information" in the inheriting block replaces information defined in the inherited block (basic Waveform model), and (3) "common information" is an error (basic SignalGroups model). A motion was made to define an Inherit operation to support inheriting of SignalMap data. A discussion followed about whether the there was a need to inherit the SignalGroups information as well as the SignalMaps. The discussion extended the inherit context to potentially include a general "Inherit" statement to allow inheriting of all the components of an Environment including the UserKeyword blocks. The motion was defined to extend the Environment block to include the syntax: Environment (name) { (SignalGroups name;) (InheritEnvironment name;)* (SignalMaps { (InheritSignalMaps name;)* (sig-expr "map string;)* (sig-expr { (userid "map string";) })* }) }) During discussion, another user recommendation was made: in the Environment block, it is recommended that the user define few UserKeywords, and collect associated information into these few UserKeyword blocks (i.e. "Design" or "CTL" blocks). That is, the user should define a limited number of Environment "contexts", and collect data associated with a context into one of these blocks, rather than defining a lot of separate blocks with little data (i.e. a single statement) in each. Another use recommendation was identified: that the information in all User Defined Blocks needs to follow STIL constructs, including Anns and comment structure. (this recommendation was made to emphasize the earlier motion in regards to this issue). It was defined that the InheritEnvironment statement understands processing the SignalMaps block only; UserKeywords are ignored for inherit... SignalGroups are not inheritable. And the InheritSignalMaps statement (inside Signalmaps) processes SignalMaps only. The sig-expr statement inside the SignalMaps supports a "global" and a "userid"-tagged option on the "map string". It was defined that one global map (non-"userid"-tagged) may be defined, and that the last definition (the one local to the current context) wins. For named userids, the same replace construct is enforced (last declaration of a userid wins). A sticky point on the InheritEnvironment statement was discussed, in regards to supporting Inherits of all statements in the Environment block, including SignalGroup statements and inherit operations on User-defined blocks in the Environment. The previous decision to not support inheriting of SignalGroup information was changed, to inherit the SignalGroups statements as well. Much discussion occurred about whether the InheritEnvironment capability should be defined to be extensible, to support inheriting of user-defined blocks. --------- A motion was made and seconded to add the InheritSignalmaps statement, and to resolve named-map strings and global maps as locally as possible, and to add the InheritEnvironment statement and define that SignalGroups information across the inherit environment are merged. The vote was 6 in favor with 1 opposed. ------- 1.3,1.4... A motion was made and seconded to accept point 1.3 as stated, with a friendly amendment to remove any commas in there. The vote was 5 in favor with the rest abstaining. A motion was made and seconded to accept single-quoted expressions on the right-hand side of an assignment statement in a vector statement, to allow the assignment of parameters by 'bit'. The vote was 1 abstain, 8 in favor. More discussion followed. A concern was raised in the example text, that passing parameters "through" SignalGroup references, to have them resolve into different SignalGroups in the macro, would make it very difficult to identify when incorrect WFCs were referenced. Therefore the concept was defined that macro call parameters still need to have WFCs defined in a WFT, to allow checks to be performed against each macro invocation without needing to perform a complete resolution of that application of that data in the macro. 1.4: Multiple parameters: The construct of passing more than one piece of information on a macro parameter (e.g. m2 { ABUS { x y; }}), and using multiple indexes was in that macro to pick out which parameters to use, was TABLED. The Working Group wishes to recommend avoiding using multiple data constructs for SOC test programs at this time. The justification for removing this capability was that the equivalent function can be accomplished with multiple macros, each with a single parameter. The syntax in section 1.4 was defined to change as follows: 1. remove the multiple [][] constructs. 2. place single quotes around each element. 3. get rid of the dot. The group then focused on addressing the capability to support inversion. Peter identified the need to define all elements of inversion. need to define input-Z and input-X. A complete table would also contain: z>n t>x n>n x>x Greg identified the problem with this mechanism, which is to ultimately declare waveforms on the fly, as the current stated mechanism here was doing event-based inversion of waveform data. This is not good. To address this problem, the group moved over to issue 2.10, which defines specific relationships of WFCs using a \m and a "Map" block. This construct supports the capability to define inverted waveforms as well as other relationships. The name "Map" was changed to "WFCMap". A motion was made and seconded to add \m to the vector escape sequences and WFCMap in the SignalGroup and Signals block. The vote was unanimously in favor. 2.9: Was moved and seconded to approve as written. Vote was 8 approve one abstain. Section 1.10: This is a new issue raised by Peter. The focus of the issue is: how does WFC-replacement occur? Is it meaningful to have multiple WFCs against the same signal in one vector, e.g., V { b = 0; b = x; } Peter presented the need to support "two data" on bidis: force meas 0,1,Z,N X Z L,H,T ---- 0 L 1 H ---- 0 H,T 1 H,T After some discussion, the Working Group defined a solution where: (a) the normal behavior of a WFC-assignment to a signal is to replace the last-assigned WFC value. (b) this behavior may be OVERRIDDEN on a per-vector bases, through the use of a "join" escape sequence. The "join" allows both WFCs to be evaluated, using the WFCMap, to resolve or specify a single new WFC that is the desired effect of these two WFCs. For instance, take the case where two SignalGroups have a common element in them (signal 'b'): _pi = '...+b'; _po = '...+b'; A procedure may "join" these two groups in a vector: proc { cs { V { _pi=#; _po= \j #; }}} Signal 'b' needs to be resolved based on the combinations of WFCs that may be seen by these two groups. It might have a WFCMap declaration like: WFCMap { 0x = 0; 1x = 1; ...} This mechanism provides for the explicit resolution of "joined" data without creating new combinations of waveforms on-the-fly (previously mentioned as an issue above). "Joining" requires the WFCMap to define two WFCs to equate to a single new resolved WFC. The WFCMap never requires more than two WFCs as the example below presents: V { b = 0; b = \j A; b = \j c; b = d; } | | | join A and 0; get n | | join c and n; get m | missing join; discard all that previous stuff... It was defined that if a join does not have a combination specified, then use the last WFC. --------- 1.8: braced block on timing constructs. The proposed syntax: 0 {'0ns' U { Foo Yu }} The alternate syntax: 0 {'0ns' U; Foo Yu; } The problem with the alternate syntax is that it assumes time order; that 'foo' is tied to the last event time. The proposed syntax would make explicit the binding of the userblock "Foo". This was tabled as the alternate solution sufficiently addresses the current requirements --------- 1.9: The issue presented here is the need to provide "explicit" table events in a Vector, with no association with time. The proposed syntax was to add the escape character '\e' to indicate a set of untimed table events: (1) V { x = \e U; } An alternate proposal, extending the '@time' construct was considered, where the time value would be left off: (2) V { @ { x = U; } The discussion included extending the notion of resolved-waveforms to allow mapping of "untimed waveforms": (3) V { x = u; } WFT {{{ x { u { U; }}}}} The last point was determined to not solve the problem as it still required WFC-mapping to discover that an untimed waveform was referenced. The '@' option was seen to be unpleasant. But first, a motion was made and seconded to add ! onto the compare events table as 'unspecified'. The was accepted unanimously. The "!" compare event is to indicate that the state of the signal is unknown, and it is also unknown whether it is an input or output. It performs a similar role to the "?" input event. A motion was made and seconded on (1), to add the \e escape to vector statements. The vote was 3 abstain, 6 in favor. The meeting adjourned for the day at 6:30 pm. -------- Thurs. Dec 10 Started with a discussion on documentation. Debating the structure of the documents - a supplement to 1450.0, and the dots. Greg took an action item to discuss this issue with GordonR. Tony took the action item to update the dot1 document with additional text, some of which is in earlier documents. Deferred additional discussions on example generation to 11:30. -- Discussion on 2.5 - Everyone present was comfortable with at least the If and While statement. But a long discussion ensued about the "expression". Concerns were raised about using these constructs in ATE programs, and being able to interpret "intent" of the expression statement, so it can be executed in an ATE environment. A long discussion ensued about the impact of the expression, what needs to be defined to support transportation of this construct, what types of data might need to be defined (boolean, integer, float, simulation states,...), etc. Tony identified 4 environments as potential contexts for application of this capability: 1. verilog and simulator in general communication 2. pattern - pattern sync 3. instr conrol 4. ate instr mapping 5. variable to signal map There was some discussion on the mechanics of this proposal; implicit declaration of signals/pseudo sigs/env map; or implicit decl of meas spec values; how assign to meas spec values; what 'types' are necessary (simulation states, integers, floats...), etc. This proposal was tabled, to work on expression evaluation/constructs/typing/etc. Kim took an Action Item to look at the simulator capabilities necessary in the expression. Greg took an Action Item to look at the expression constructs ---- Discussion on 2.6 - ParallelPatList: Much discussion about what happens between two patterns that run at different frequencies and whether the patterns "must tile" or not (ie does patA below need a Break loop at the end that generates enough cycles to fill the gap; and what happens if that gap does not fill "integrally"?) +------+ +-------+ | patA | | patB | | | | | +------+ | | +-------+ +-----------------+ | patC | +-----------------+ Discussed the notion of an assertion statement in the PatBurst "must tile": PatBurst { MustTile; ParallelPatList { A B } PatList { C } } 3 conditions to support/identify at the end of a parallel pattern run: - hold (last static state of pins), break, tile. Tony took an Action Item to summarize this and present the requirement. PatternSet: PatBurst { ParallelPatList {A B} PatList {C} PatternSet{D E F} PatList{G}} | patC | +-----------------+ +--------+ | patF | +--------+ +--------+ | patE | +--------+ +--------+ | patD | +--------+ +--------+ | patG | +--------+ PatternSet allows you to reorder the sequence of patterns {F,E,D}. Pattern C must come before; Pattern G must come at end... Identified that the PatternSet should NOT be used to do implicit parallel patterns, even if the set of signals between patterns are non-overlapping. To do this, need to define two bursts that contain PatternSets, and reference them in a higher level with a ParallelPatList. Motion to approve PatternSet and ParallelPatList constructs was made, seconded, and approved unanimously. Right before the bathroom break. Discussion on 2.4: parallel independent patterns. Proposal defines a construct with two Signals blocks; the Working Group had much discussion about the implications of having multiple Signals blocks. There is strong concern that the need to identify separate Signals blocks has major impact on the way that STIL "could be" used, and that this capability would require much support and identification of why the user should NOT do this. STIL is intended to be a device test. The view of a single device is central to the constructs. If two independent devices are being tested, then the data should be presented as two separate STIL blocks. However, STIL supports the strong separation of data at the PatternExec, and does NOT define how multiple PatternExecs should interact. This allows the ability to separate independent tests with no sense of combination. The Working Group came to resolution to ask for more information from the submitter of this proposal. The submitter needs to justify this construct. Can you really power-up half of the device without the other half? Do you never run open/shorts across all pins of the device? If there is any test that runs the complete device, the separation of signals will not allow that to be done. The fundamental issue that was raised by Klaus-Dieter, can be solved in the P1450.5 by defining a test as follows: Test xxx { PatternExec exec1; PatternExec exec2; } This issue was tabled pending more feedback from the submitter. -- Discussion 1.2: Proposal to drop the "Macro" and "Call" and allow just the macro name. Discussed the name space issue; if a macro or procedure does not have a unique label, there is increased name space collision with all the statement constructs, and both the macro and procedure name spaces. Lots of discussion about the notion of allowing a "V" to be redefined as a macro (and the implication in the definition of "V" requiring the use of "Vector"...) Motion made and seconded to drop this option; passed unanimously. -- Discussion 2.7: BIST structures. Only additional comment from LogicVision was to add an XOR cloud between the LSFR and the design connections. Connection statement needs to look like a scan cell list, with decimal_integer. Peter discussed some extensions that are missing. 1.6: indexed list of scan cells was discussed here as well. A proposal was made to extend the SignalMaps construct of yesterday, to support mapping of "names" wherever they may be found. NameMaps { ScanStructures g1 { ScanChain c1 { A[0] "top/dev/i1"; A[1] ... } } Signals { sig1 "top/mysig"; } SignalGroups a { } Variables { var "anotherone"; } NameMapsInherit ....; UserFunctions { loadBist "Advantest_startit"; } } Motion was made by Nathan and seconded to replace the SignalMaps with NameMaps and to remove the SignalGroups reference above as it is no longer needed (explicit resolution of groups provided in the namemap). This was accepted unanimously. A brief discussion of Action Items then followed: Kim took an AI to look at conditional execution, specifically operands, mechanism, etc. to support expression definition/function. Nathan took an AI to generate examples on all the accepted syntax that has his name on it; conditionals, environment, namemaps construct. Peter took an AI to update syntax and provide examples on constructs with his name on it. -- The next meeting is tentatively scheduled for early March, tentatively in Chandler. After some further discussion, the meeting is proposed for February 21/22 in Chandler. However Peter took an AI to look into a March meeting in Vermont or Montreal, and Greg took an AI to look in Colorado as well. -- Discussion 2.8 - ScanStructures - Discussion about the additional definition of scan element data. Problem identified is that one bit of scan data may not map exclusively to a single scan "cell", and furthermore the definition of a "cell" is ambiguous. To support simulation interfaces, may need to represent additional aspects of this data. After some discussion, a decision was made to not define the proposed constructs as additional info at the ScanStructures level, and to work the issue in regards to the ScanCells statement. One level of cell representation is to map the additional 'inputs' and different 'outputs' of particular cells. Conceptually this could be represented by bracketed notation to indicate multiple locations where the same data needs to be applied, for instance: ScanCell A B C [ D E ] F; Other information that may be necessary is additional Slave/Master references: "cell" xx { In D1 D2; out D3; SlaveIn D4; SlaveOut D5; }. Peter will rework this issue in context of the name mapping. -- DC Levels --------- Opened the discussion on DC Levels. Issues identified to address: . choose which alternative to use . identify the intent of each construct. For instance, slew rate - is this an "intended" value or a "required" value? . review each statement type Overview on original proposal: add statement to PatternExec to call DCTable. DCTable had three sections: Supplies, DCLevels, and PowerSequence. Issues on this proposal: 1. before testmethods and flow; what integration is necessary with those aspects?, 2. should the PowerSequence be a separate block by itself?, 3. how do we specify time sequence of power events? (original proposal specified sequence but not time), 5. should we predefine named sequences, can the user provide more sequences - need one to initialize (apply) and one to remove (remove), need other sequences as well - incrementing power, etc., 5. how do you specify different sequences from different points in the flow (i.e. moving from one Vdd to another...)... Gregg's 2cd proposal: One PowerSequence block in the DCTable, but multiple named sequences inside; for each sig-expr assign a sequence number to define the execution order... discussed the impact of using 'sequence numbers' vs. declaration order to define the sequence order. Ernie's 2cd proposal: Attempts to address the exact time sequence - each 'block' is defined to occur after the previous block completed. Dave's 2cd proposal: Attempts to integrate the PowerSequence into the DCTable directly, without a separate block, or to provide a block with a sequence number. Dave and Tony's proposal after ITC: 1. DCTable callout in the PatternExec, including sequence refs in the callout, which includes a representation of previous-next relationships that are defined external to flow (removing the need to define power-sequencing operation as part of the flow model, but allowing it to be specified...) Discussion about how the sequence "should" be applied - when a test exits from one of several ports, and goes to the next test node, the power sequence needs to be applied; how much of this process is specified, how much is defined by 'implication' moving from one table to another... Proposal to rely on a 'poweron' sequence when using a DCTable and starting/entering a test, default 'transition' tables "up", "down" when moving from one DCTable to another, and a final 'poweroff' sequence when exiting. Situations where one table has pins at a higher level, other pins at a lower level, would require explicit sequence definition. Sequence order, when moving between "tests" or "PatternExecs", is a flow issue and cannot be 'used' until a mechanism to move between tests is defined, which is part of the flow. Proposal to define a "DCDefinition" block that contains multiple tables and named sequences. Sequence order cannot be applied until tests are sequenced which are part of flow. The test sequence order issue is pushed into group 4. Tony's diagram: DCDefinition { DCTable { } DCSequences { } } +-------+ | flow | +-------+ | +-------+ | test | | node |-may contain explicit sequence ref +-------+ | +-----------+ | test type | +-----------+ | | | +------------+ +-------------+ +-------------+ Timing ref DCTable ref Burst ref +------------+ +-------------+ +-------------+ Motion to use the 'time stamp' method of specifying sequences (Ernie's proposal). Need to generate some more examples and determine if this structure looks like STIL. Slew Rate question ------------------ Add to the list of options in the DCTable, a Slew Rate value. Specify a VIHSlew and VILSlew; maybe a single value option too? Slew value should be respected, that is, programmed by the tester. Discussion about interpretation - does this value mean that if the tester can't do this, this test can't be used? Or is this value a "min recommendation" or a "max recommendation"? After much discussion, the interpretation of this data was established to be the same as all other values specified here - if this value is stated, then it should be followed. If it's not followed, then the same risk happens as for all other disagreements with specified values... The motion to add a VIHSlew and VILSlew was made, seconded, and unanimously accepted. A discussion about the V/IMeasure statements as part of the DC information then followed. While these statements are part of the proposal, they really have implications on how/when these measurements are performed, which indicate "to be addressed by Test Methods"... these were meant to be implicit test operations, measuring voltage and current on the applied pins, and speculation is that this information should be part of the test. Gregg took an Action Item to identify another section in this document to indicate all power level issues that have been proposed to be moved to another effort. Two such areas are: power sequencing (moving under flow), and VMeasure statements (moving under Test Methods). Meeting adjourned at 3:50 pm.