STIL Working Group P1450.x meeting Chandler AZ, Hosted by Microchip Feb 21 - 22 2000 The STIL Working Group thanks Microchip for supporting this effort, by hosting this meeting, printing up documents, and providing ammenities during the long hours of tedious discussion. Meeting called to order at 9:10 am by Tony Taylor, with a round of introductions by all participants. Participants ------------ Tony Taylor - Synopsys. Makes heavy use of STIL internally. Dave Dowding - Fluence. Makes trouble. Working with Toshiba to support a set of STIL tools. Had partnership w/Microchip Frank Peyton - Consultant in semiconductor test industry, Gregg Wilder - TI ASIC. working to replace TDL with STIL, slow going. Greg Maston - started with Moto, now with Fluence Peter Wohl - started with ATTI, now with Synopsys. STIL key part of the tool. Doug Sprague - IBM. defining a flow to move STIL data to tests; pushing Advantest and Teradyne; converting internal tools to support this flow at the moment. Gerd Bleher - Agilent. Klaus-Dieter Hilliges - Agilent. Emile van Rooyen - Microchip. Vineet Pancholi - Intel. started with Microchip, now with Intel. interested in next-gen scan-based burnin Ajay Khoche - Agilent Kim Smith - Microchip. doing translator to move STIL onto testers; strong simulation-oriented STIL-oriented frontend system. Ernie Wahl - Lucent. keeping tabs on STIL; interest in Auto Program Gen Bernard Heilbler - SZ testsysteme. R&D for new tools for test systems. test systems are mixed-signals, so interested in extensions ----- Working Documents for this Meeting ---------------------------------- The following documents were made available in paper copy for this meeting. The Minutes will refer to these documents as identified below: doc1: "Working Document for STIL Meeting - P1450.1, Chandler, Feb 2000", dated 2/12/00, Tony Taylor, on the P1450.1 website as "Cumulative Proposal for Feb 00 meeting". doc2: "P1450.2 - DC Levels", dated 1/5/00, Gregg Wilder, on the P1450.2 website as "syntax proposal (latest)". doc3: this is a collection of emails generated by Kim Smith (conditional proposal), Klaus-Dieter (independent patterns), and Doug Sprague (STIL Spec Issues). doc4: Handout of slide presentation from Klaus-Dieter to talk to the independent pattern data (distributed by Klaus-Dieter). Agenda ------ The Agenda discussion opened with a listing of specific items based on the Working Document set, to address in this meeting. A discussion about the handling of P1450.2 as a separate break-out session started as part of the agenda definition. A request was made to Gregg to define a candidate agenda, to determine whether the .2 gets a separate break-out or not. The following agenda items were defined. As pertinant, the specific dotted effort is identified as ".0" (1450.0), ".1" (P1450.1), and ".2" (P1450.2): - doc issues - how to organize efforts into supplements and extensions. (greg; 15 min) - .0: dougs issues (doug; 30 min) - .1: section 2.3 and fix statement - patset and patlist (tony) - .1: independent pats (klaus) - .1: conditional execution (kim; 30 min) - .1: BIST & scan (peter) [doc1 sections 2.7,2.8,2.9] (15,15,15) - .2: gregg to develop parallel .2 agenda - future plans - how to make progress; finish plans on .1 stuff (30 min) - restart .4/.5 after .2 closure - .3: mailing request (if Chris Nelson shows up) - next meeting - other dot extensions (10 min) - .1: doc1 section 1.4 (peter; 5 min) - .1: doc1 section 1.7 (kim; 5 min) - .1: doc1 section 2.1 (kim; 15 min) Gregg's .2 agenda ----------------- - .2: overview of new doc (1 hr) - .2: dc table - discuss in detail (1 hr) - .2: power seq section - in detail (1 hr) - .2: level switching in cycle (30 min) - .2: topics deferred to .4 and .5 efforts (30 min) - .2: format for the proposal (1 hr) - .2: tutorial or examples? ---- The Agenda as outlined was accepted by concensus, with the definition that after preliminary common discussions, the Working Group would partition into P1450.1 and P1450.2 efforts and work in parallel for most of the meeting time. Motion to accept the minutes of the last meeting; all approved. A proposal was made to handle the first two issues ( doc and .0 clarifications) as a single Working Group, and then to break out into two subgroups. Clarification ------------- A request was made to list the STIL extensions (dot-name) by perspective, to make sure we are all talking to the same definitions: .0 - current 1450-1999 spec .1 - design .2 - levels .3 - tester targetting .4 - flow .5 - test methods doc1 contains two sets of definitions for signal constraints, sections 2.9 and 2.10. The question was raised as to which was pertinent, and the resolution is that section 2.10 is out; section 2.9 is the current proposal. Doc Issues ---------- Discussed partitioning of document between supplement to .0 and .1 effort. Tony and Greg to discuss with the IEEE and Gordon how to support this effort, and how to structure a ballot so that the supplement and the extension are tied to one ballot process, because accepting one and not the other will not work. Doug's Issues ------------- Issue #1: --------- Doug talked through the issue with the array construct. Peter agrees and disagrees; the multiple declaration of the "same name" is a problem. Lively discussion on this issue; identified the biggest concern here is the potential confusion for identify the "same name" to be both an array and a scalar. Tony presented three options to address the issue: a - 1. nothing b - 2. signame root cannot be reused. 3.a declare an "automatic group" of a unbracketed reference; i.e. "a" is defined automatically as = "a"[10..5] 3.b signame root CAN'T be both a scalar and an array; i.e. if "a"[15..0] then cannot have "a". c - 4. recommendation that the user avoid defining both an array and a scalar signal with the same rootname. Further discussion on the difference between quoted and unquoted names as well. The question raised was: is "A" the same as A (unquoted)? The anser is provided in section 6.8 of the 1450-1999 spec: User-defined names may be declared either unquoted or enclosed in double quotes. Once declared, all references to that name shall use the same convention to reference that name; for instance, the name "Xyz" is always referenced as "Xyz" (with quotes present). A motion was made to chose between "do nothing" (option a), or to "do something" (option b or c). The vote was 6 for "do nothing", 7 for "do something". A motion was made to consider implementing option c (defining a recommendation as part of a recommended usage document). The vote on recommendation was 10 for option c, 2 for option b. Therefore the working group voted to define a recommendation that users not declare the same name as a scalar and an array. Issue #2: --------- There was a discussion about define-before-use, and whether that perspective covered this issue. There was general agreement that the spec should make a clear statement about no implied ordering for statements except for specific sections. A motion was made to add a clarifying statement to section 5.1.1, using Doug's identified words or something similar. Unamimous agreement with the proposal to add a clarifying statement to section 5.1.1. [ai1-gregm] Issue #3: --------- There was a discussion about 1024-character restrctions in the language, indicating that obviously there is a need for a clarifying position. A motion was made to use Doug's words or something similar, to section 6.15, to clarify this issue. Unamimous agreement with the proposal to add a clarifying statement. [ai2-gregm] Issue #4: --------- There was much discussion here about what is the "right" thing to do to minimize confusion. Several potential resolution options to the multiple-declaration-of-the-same-name problem were discussed: - name refs cannot be on both sides of the '=' - define an order to the evaluation - single definition only. The discussion continued through lunch on this topic. After lunch, in order to make forward progress, Doug's Issue #4 was tabled to be discussed between Emile, Doug, and Greg, and to send notification of the resolution around to the STIL Working Group. The group partitioned into two groups after tabling Issue #4. Tony, Frank, Kim, Ajay, Emile, Klaus, Gerd, Doug, Peter and Greg went with the 1450.1 group. Dave, Gregg, Vineet, Ernie and Bernard went with the P1450.2 group. P1450.1 Effort -------------- The following minutes were taken for the P1450.1 subgroup effort. Conditional Execution (kim's email found in doc3) ------------------------------------------------ Overview of Var statement and simple manipulations. Current context has defined variables inside a Pattern; discussion about communicating between two (parallel) patterns, and whether the Variable construct should be used to communicate between processes. For instance, should Variables be used to send info to other instruments or get info from other instruments, or should Pseudo Signals be used for this purpose? Tony feels that 'conditional statements' seem to fit with the notion of controlling instruments; Kim senses that this notion may be better applied by using special Signals. Discussed using variables to assign values to signals (not part of current proposal). Discussed the potential for using Variables as a communication mechanism between Patterns and other STIL blocks. Kim identified a concern about moving variables out of scope of Pattern; desire is to keep the Variables inside the Patterns and not create another STIL block called "Variables". Greg raised a concern with pattern-variable construct and concern about the limitations of that construct. Is just a "fail indicator" sufficient? what about vector count, failing signal, etc. Peter identified that the fail notion is related to the X statement (section 3.1 of doc1). Tony discussed that that particular locations (after the V statement) is "valuable real estate", and has been proposed for several constructs before, but never defined (yet). Is this the right application? The conditional constructs proposed by Kim were accepted as a starting point for discussing the issues above, and subsequent discussions on this topic tabled for further developement by Kim and Tony. [ai3-kims,tonyt] During the next break, Tony and Peter provided the following edits to doc1: pg 2 of doc1 has extraneous '=' on SignalGroups WFCMap ex. WFCMap from_wfc is not a "star" option - should be one or two WFCs only. pg 6 of doc1 - section 1.10 - WFCMap example should not have braces and equal in WFCMap. pg 27 of doc1 - section 3.1 - remove last sentence of the "Loop" def. pg 10 of doc1: example in section 2.4 "Signals" in PatternBurst should be "SignalGroups" and comment changed. [ai4-tonyt] Independent Patterns (Klaus-Dieter) -------------------- Overhead handout (doc4) discussed. Perspective of CTL also presented by Tony, and contrast of a "module-based" test vs. a "core-based" (where a "module" has direct access to the outside world, and a "core" may be integrated and accessable only through a test "harness"). Reviewed the Dallas STIL meeting comments on this issue, which had an issue with multiple named Signals block, but the notion of a higher-level test to instantiate parallel independent tests was agreed to. In that meeting (and this meeting), the option to support multiple named Signal blocks was raised; the P1500 group uses a mechanism similar, renaming the Signals block of core modules to allow maintaining that information. Concurance in the Working Group with Klaus' proposal (example 3 in doc4, using the "Test" block to define "ParallelExec"s). The notion of defining an environment around PatternExecs (to prevent the requirement of merging Timing blocks somehow) was seen to be a necessary part of this solution. Non-independent Pattern (Tony) ----------------------- Tony provided the following definitions for the "non-independent pattern merging". Constructs presented in section 2.3 of doc1. PatList: list of patterns defined with a required order (sequence of referencing) PatSet: list of patterns, but no required order based on sequence. ParallelPatList: list of patterns, ALL to execute in parallel. Tony presented the notion of supporting these constructs in one PatBurst: PatBurst { PatList { } ParallelPatList {} PatList {} } This would require that the PatternBurst allow multiple instances of these statements (today only one PatList statement is allowed). This would allow the definition of sequential behavior to be defined in one patburst. Some discussion followed on how to "align" or "resynchronize" across Patterns when multiple blocks are present. Tony identified the following rules for handling alignment conditions: 1. last vector = BreakPoint {} statement - use that breakpoint to fill the gap a. with one vector: repeat that vector b. with multiple vectors: repeat that set of vectors c. with no vector: hold final static state 2. no breakpoint specified: - first vector of next pattern must align precisely in timing to that last vector 3. new statement in PatBurst: Extend (patname)*; -- puts an implicit "BreakPoint;" statement into the referenced pattern (without requiring the Pattern be edited), to extend the final state of that pattern. This allows a pattern set without a BreakPoint, to have an "effective BreakPoint" added. It also allows the fractional period. 4. new statement in PatBurst: Wait (patname)*; -- e.g. ParallelPatList ( A,B,C} Wait C; // if know that C is the long pole 5. new statement in PatBurst: Fixed sigexpr (defaultstate); -- "excludes" a set of pins from a patternset; holds them at a constant state value (not a waveform). 6. Kim's request: repeat a complete patternset in a PatBurst. "Repeat all" "Repeat Last"; Kim identified that his intent here is to be able to do all in the PatBurst extensions that you could do in the pattern itself. This allows arbitrarily defined patterns (straight line) to be used without modification. Tony generated a diagram to represent the "tiling" process with some representative Pattern relationships. That diagram is captured as: http://grouper.ieee.org/groups/1450/dot1/min_0008_multipat_diagram.gif Two styles of adding these "control statements" into the PatternBurst were considered, as distinct statements or as "attributes" of a Pattern inside that block: - Burst { ParallelPatList{A B C} Repeat A; Extend A B; Wait C; PatList {D E F} } -or- - Burst { ParallelPatList{A { Repeat; Extend; }B {Extend;} C{Wait;}} PatList {D {Fixed sigs1=\eUUDUDU;} E F} } Tony says we should not try to approve of this right now. Kim likes the concepts here. It's 3:45 pm. Peter and Greg are refining the constructs above. Frank is concerned about ambiguous repeats. In fact, Frank's issue was presented as the following concern: Question/issue: How do you stop A while it's repeating???? The current discussion was tabled for Tony to take another airplane flight. Another documentation edit: --------------------------- doc1,section 1.4: add a statement to the effect that if a WFC in a \m does not have a map defined in a WFCMap, then use that character. Peter's issues : 2.7 BIST structures ------------------------------------- This section is "new" in that Peter updated the whole section, but the only changes here are with the Connections and Parameters statements. Connection here refers to BIST register bits by number, to either ConnectTo or ConnectFrom. Tony raised a concern that CTL has a Connection block as well, to connect cores into a SoC. But the BistStructures uses the BIST register "number" as one end of the connection, whereas the CTL Connection needs to connect between two complete environments, and does not have this "simplifying connection" option. The following diagram (or aspects of it) was generated to discuss the relationship of the CTL Connection to the BIST Connection, and to look at how to leverage these two. The basic diagram for this discussion is found at: http://grouper.ieee.org/groups/1450/dot1/min_0008_connection_question.gif After some discussion between Tony and Peter, and the Connections diagram, there seems to be a different context of use here, for the BISTStructures connection (which refers to internal device data), and the CTL Connections (which refers to core-IO-to-device-IO data). Tony tabled the discussion to try to understand the Connection of different environments. [ai5-tonyt,peterw] The Parameters block contains information that may be specified per BIST, with an option to specify an instance of a BistRegister with different Parameters. Greg made a motion to add the Parameter block to the second form of the BistRegister statement (the form used to reference BistRegisters in the Pattern), to make the statement uniform with the first occurance of those statements. The vote was 9 in favor with no opposed. End of the First Day -------------------- the .2 group reappeared, and discussion of the next day ensued. Dave proposed that we start tomorrow talking about the basic flow of each document, and then the .2 group will go off and complete their effort. Motion to go home, for those local. For those staying over, dinner. Seconded, and approved by consensus. ---- Tues Feb 21, 2000 Agenda for Whole Group ---------------------- 1. Discuss documentation plans and ownership 2. split into two groups 3. discuss next meeting Agenda for P1450.1 subgroup: ---------------------------- . scan . 2.7, 2.9 . sig and group resolution/continue discussion (dougs forth issue) . .2 report . 1.7 issue . 2.1 issue Documentation Plans and Ownership --------------------------------- Clarifications to 1450-1999 --------------------------- Doug's issues need to be refined to a set of clarifications on 1450-1999. Greg will generate the addendum/clarification document, and then follow-up with the IEEE to determine the process to provide that information as part of this document. [ai6-gregm] Supplement Document to dot0 --------------------------- Greg will own this document. [ai7-gregm] - follows format for 1450 std - additional syntax "extensions" to fit into the current document at the appropriate locations - additional examples in body of statements [tony will provide as necessary] - A subsequent discussion identified the extension for multibit constructs, for dot2. Greg is thinking that this may need a separate supplement to allow this issue to be balloted with the P1450.2 effort. Extension dot1 -------------- Tony will own this document. 'tutorial' in front contains 'views': - simulation view [kim] - atpg view [peter] - fail log view [tony maintain current one] - scan example [peter] - bist example [peter] Extension dot2 -------------- Gregg will own this document. tutorial section elaborates on a "virtual tester"; structure the same way. The P1450.2 Working Group will refine the ownership of sections of this document. CTL doc ------- Tony is responsible for coordinating this document - tutorial example here using macro parameters in STIL syntax Greg is to find out if Peter can reuse his VTS paper, especially the diagrams, as part of a standards document (moving info from a paper into a standard). [ai8-gregm] 2.8 Scan -------- Peter introduced the 2.8 topic (doc1), which detailed why scan needs to be extended; basically that the scan structure needs to be completed to support more flexible scan designs. Greg is concerned that the Peter's syntax doesn't follow STIL constructs (a block is contained in a semicolon statement), and proposed the following change: ScanCells { !; a1; a2; a3 { } a4; !; } This change was accepted by the Working Group. Discussion about the "When master_observe;" reference in the scancell, which appears in this example as a forward-ref (and probably always is, with the assumption that the scanstructures need to be defined before the procedures). Confusion about the interaction of this construct with the pattern data. Discussion indicated that the EFFECT of the master_observe execution affects the behavior of the FOLLOWING shift. As a result of the discusion, a proposal was defined to use the ScanStructures statement in the procedure to indicate the "mode" or "behavior" of the scanchain, to be in effect until changed with a subsequent scanstructures statement. Proposal was refined to add to the ScanStructurs statement in the patterns section, a reference to the mode of the scanchain, as follows: ScanStructures G1 { Parameters { ScanMode S;}} and the ScanCells statement also changed to reflect representing this information. As a side-note: Greg strongly recommends quoting all signal names. 2.9 Signal constraints ---------------------- As stated earlier: section 2.9 replaces 2.10. Proposal to change WFCMap to two structures: WFCMap a x; WFCMap bc y; -or- WFCMap {a x; bc y;} This allows the braced construct to be defined in the syntax as a logical extension of defining "multiple statements". This proposal was accepted by consensus. Greg raised a concern about Peter's first example on pg 20 of doc1. The V{} statement references a[0] and b[8], problem here in that the Equiv statement defined 'a' and 'b' names and these should not be "equivalent" references. Discussion on this topic, and the application of the "equivalence" context, ensued. The following change to the example was proposed: Pattern epat { E a[15..0] \m b; V {a[0]=0; } //b_low[0]=1; V {b=H; } //a[15..0]=L; } The above example was agreed to by Peter, but the ability to STILL assign: V {b[0]=L; } //a[0]=L; too! was defined by Peter as critical as well. After more discussion, the context of the Equivalent statement was better understood. An equivalence is defined to applied to the signal level. Equivalences are not applied at the group name; when a signal is referenced in an assignment, the equivalence assigned to that signal is applied. Once defined, an Equivalence is valid through the rest of the pattern, and cannot be removed. The following example was generated: Signals { a; b; c; } SignalGroups { X='a+b'; Y='a+c'; Z='a+b+c'; M='a+b'; } Pattern { E X Y; // ok E X Z; // error - bit-corrospondence problem E X \m Y; // error because of the first declaration E Y \m M; // error because of the first declaration } Doug4 ----- Tony requested a revisit of Doug's issue #4 of yesterday, to see if there was any additional review that could be done for that question. Doug identified that in brief conversations between the three people identified to discuss this issue, that the general consensus is leaning toward a solution that supports an "order definition" to resolve changes to a name already defined. The following general concept is proposed: 1. Resolution occurs when the group is defined. 2. Resolution starts with the containing domain, the global groups, and then the Signals. 3. Resolution is Order-dependent in the SignalGroup Resolution across named signalgroups is not allowed; resolution in a group can only depend on Signals and global groups, and previous definitions in that group. All current rules still exist, to wit: a. Cannot change the definition of a signal, in the global signalgroups. The Working Group (both P1450.1 and P1450.2) then went to Lunch 12:10 - 1:50. Next Meeting Discussion ----------------------- Next meeting will be around VTS. Some discussion about beginning or end of VTS; current anticipated time is the end of VTS - end of Thurs/Friday/Saturday May 4/5/6. Peter will try the hotels directly, Tony will try VTS/TTTC to see what rooms we can get there. [ai9-tonyt] Kim's 1.7 issue --------------- Concern here that the UserKeyword in a local context will not allow overriding of any defined keywords UNLESS we allow userkeywords to override STIL keywords that are not in that context. A motion was made and agreed by consensus, that local UserKeywords can override STIL keywords that are not used according to the standard in that context. Kim's 2.1 issue --------------- Concern here is that the Inherit construct may not have been completely recorded. Discussion about the InheritEnvironment statement, and it's meaning. As a side-note during this conversation, it was identified that the Working doc (doc1) needs to be updated to remove all SignalMap references, and if applicable change references to NameMap. It was determined that the InheritEnvironment statement would inherit both SignalGroups and NameMaps blocks, if present in the block being inherited. Peter generated the following example to clarify: Environment ENV { SignalGroups G1; NameMaps { .... } } Environment ENV3 { NameMaps { } } Environment ENV2 { SignalGroups G2; InheritEnvironment ENV; //"inherits" (add the statements to // define) the SignalGroups G2 & // the NameMaps in ENV NameMaps { InheritNameMaps ENV3; //"inherits" (add the statements to // define) the NameMaps info in ENV3. } } Some more edits to doc1 were identified: pg 7 section 1.10 doc 1 last WFCMap example remove equals in two examples. replace all occurances of NameMapInherit with InheritNameMap in doc1. Goal of the Inherits concept in STIL is that Inherited environments will always use local data first, to override global data as appropriate. Version Statement/Versioning Issue (not on agenda) ---------------------------------- Tony asked about the STIL version statement and how we support versioning. Started to define mechanisms to support versioning of extensions, or whether one rev is appropriate. Tony requested that the format of the STIL statement change from STIL 1.0 to STIL 2000;, and to define a statement for each extension such as: STIL1 2000; STIL2 2000; etc. This issue was tabled for additional proposals. Levels Synopsis (P1450.1 efforts) --------------- The P1450.2 subgroup presented a summary of their effort. Very little change was made to the doc2 document. Added: Remove the DCTable block, and define the DCLevels and DCSequence as two blocks. Split the levels and the sequence into two separate blocks and not in one container; keep DCLevels and add a DCSequence ref in the patternexec, and allow optional multiple references of each. Question about having a default sequence defined, or a mechanism to indicate a default sequence. Even though DCSequences are defined here, they may not be referenced until the Test flow is described. Added a Force and Init statement to the DCTables; some discussion about how this interacts with WaveformTable and DefaultState constructs. If no sequence is specified, the order of sigref blocks in the DCLevels is used as the "default sequence". Some discussion about supporting a notion of "levelsets" much like "timingsets". There's a notion about being able to select levels from inside timing today, using a numeric index after the drive or compare state. There are four special names defined in the DCSequence: initialsetup, end_of_program,(beginning/end of test), powerraise, powerlower (used between tests). Contents are defined by the user; names have special context, to be applied as necessary at the beginning or end of test and to change levels between tests. The environemnt also supports user-defined DCSequence block names as well. It was again identified that the level select mechanism in the Waveform needs to be placed in a .0 supplement. 1450.2 responsibilities ------------------------ Gregg owns the reference [ai10-greggw] Dave owns the tutorial [ai11-daved] Ernie owns the definition of the virtual tester for tutorial section [ai12-erniew] Bernard and Vineet will generate tutorial examples [ai13-bernard,vineet] Greg made a motion to adjourn the meeting, Dave seconded, approved by consensus. Meeting was adjourned at 3:05 pm. Summary of Action Items ----------------------- ai1-gregm - add a clarifying statement to section 5.1.1 ai2-gregm - clarify section 6.15, 1024 char restrictions ai3-kims,tonyt - conditional constructs ai4-tonyt - fix example in section 2.4 ai5-tonyt,peterw - connection to BIST structures ai6-gregm - determine the process for addendum/clarification document ai7-gregm - generate the dot0 addendum ai8-gregm - can Peter reuse his VTS paper? ai9-tonyt - meeting room at VTS ai10-greggw - Gregg owns the reference sec of 1450.2 ai11-daved - Dave owns the tutorial for 1450.2 ai12-erniew - Ernie owns the virtual tester definition for 1450.2 ai13-bernard,vineet - tutorial examples for 1450.2 Respectfully submitted, Greg Maston