This section of the document represents the minutes of the 3/10/2015 meeting ---------------------------------------------------------------------------- Attendees: Ric Dokken, Scott Franzen, Carey Garrenton, Greg Maston, Jim O'Reilly, Ernie Wahl Line and clause numbers if any are with regard to STIL.4 syntax document D01 dated March 10, 2015. ACTION ITEMS: 1. Ernie: tar & gzip Mar 10 version of P1450.4_D01.doc, and place into directory parallel to PDF file location 2. Jim: create level one heading subdocs 3. Ric: put syntax document into Subversion 4. Jim: Send to Ernie source materials used to create SignalMap figures. CONSENSUS NO on: Clause 13.3 Spec/Category Variables: include recommendations regarding, for within a Spec: Specifying different variables in different categories? Specifying different variable definition sequence in different categories? This section of the document was distributed by Ernie on 3/4/2015, prior to the 3/10/2015 meeting. -------------------------------------------------------------------------------------------------- Attendees: Ric Dokken, Scott Franzen, Carey Garrenton, Greg Maston, Jim O'Reilly, Ernie Wahl Old line and clause numbers if any are with regard to STIL.4 syntax document D00 dated November 3, 2014. New line and clause numbers if any are with regard to STIL.4 syntax document D01. Row numbers and "New Chapter Headings" (column C) if any are with regard to file "STIL4_ReworkMap2015_02_03_EW.xls", tab "STIL4_ReworkMap_v11 (02-03-15)" ================================================================================ Sub-documents: Level 1 or Level 1 and 2 ? EJW suggestions (TOP-DOWN): MOVE New Chapter Heading "Global Functions" to BEFORE New Chapter Heading "Timing and WaveformTable syntax" (Extension to STIL.0 clause 6.14 6.14 Signal expressions (sigref_expr), Table 5 ?) MOVE New Chapter Heading "Device to Tester Interface" to BEFORE New Chapter Heading "SignalMap" MOVE New Chapter Heading "Device" to AFTER New Chapter Heading "Device to Tester Interface" MOVE New Chapter Heading "Test Program" to AFTER New Chapter Heading "Device to Tester Interface" MOVE New Chapter Heading "BinMap" to AFTER New Chapter Heading "Test Program" MOVE New Chapter Heading "FlowVariables" to AFTER New Chapter Heading "Test Program" ================================================================================ NOTE: undo , ref mtg2014_10_07.txt Last PDF with spec variable units spec: P1450.4_D00_2014_10_06.pdf, lines 3188 (table 5), 5780 (capitalize on restoration to "Units"), employ empty string instead of None 5797 return empty string instead of None for consistency with lines 3444, 3634 (Table 11), and 5765 * Units rationale is to unequivocably specify/communicate intent: - Communication between STIL.0 and STIL.4 is between STIL.0 spec-vars and STIL.4 vars . Min,Typ,Max fields are read-only in STIL.4 . Meas field is read/write in STIL.4 - STIL.4 vars are strongly typed - STIL.4 vars supports None - STIL.0 spec-vars are extended to support None . any unspecified spec-var field is initialized to None . any spec-var field that has units/no-units, constrained all others fields those units/no-units - STIL.0 spec-var used only for its Meas field requires initialization syntax extension to STIL.0: . Sentinel value None constrains spec-var to the equivalent of STIL.4 Real . Sentinel value NoneA constrains spec-var to the equivalent of STIL.4 Amperes ================================================================================ REMINDER: STIL.2 has DCSequence Connect/Disconnect instructions To do before suspension of red-text leaf-node discussions: *Line 5634: include recommendations regarding, for within a Spec: - Specifying different variables in different categories? - Specifying different variable definition sequences in different categories? Line 4923, 4951: consider Enum (quantifyable and extensible) for App (application) Line 4060, Table 13: convert(string) Line 3355, Table 6: VecRange Line 3186, Table 5: constraint Type () Line 2823: var_assignment_stmt Line 1215, 3130, Table 1: add TestExec Not directly syntax or semantics related: Line 5072: "win" description ================================================================================ See footnote on function max in table regarding relational-operator/SpecVariable action item (near line 4054) -------------------------------------------------------------------------------- Line 5059: review StdFunctional parameter win description after Ric's data capture proposal. Underpinning assumptions: - PAR, section 5.4 Purpose: STIL is the standard for the interchange of digital test data from the test generation environment (where a great deal of design information is used to generate device tests) to the test and manufacturing environment.....The flow and binning constructs in this extension allow developing a test program description in a common language; this common description can either be used as input to a test program generator which translates the description into the native language of specific IC ATE systems, or can be run directly on IC ATE systems that use 1450.4 as their native language. - STIL.0, section 1. Overview, paragraph 2: this is what we're extending. My hope: we're creating a single language, a subset of which can run on a tester. My fear: we're creating two parallel languages, one designed to run on a tester and the other as an information conduit for ATPRG and translators. So far it affects: . Line 2085: TestProgram syntax . Line 2890: Test instantiation syntax . Line 3231: SigGroup parameter - STIL.4 supports in-use tester capabilities (10 to 20 years back). -------------------------------------------------------------------------------- failMemArm/failMemArray issues: - function (expression context only) or Action? - on Bypass "failMemArray() == psig" may pick up a previous signature and accidentally pass - Entertain Ric's suggestion that it ought to be a test but include in phase I, e.g., StdMemCapture() functional test w fail mem capture and compare - used for memory bist & repair flow - used to test A/D converter on digital tester, req's mid-band - ask for example where X is used, i.e., why is signal in sigref_expr when it is not being used in comparison? - use string datatype -------------------------------------------------------------------------------- NOTE C++: - does not allow keywords as identifiers, e.g., while, case, etc - does allow function names to be used as identifiers, e.g., printf, etc Disallow Test Instantiation in global top-level namespace: each TestProgram has its own copy of FlowVariables, Bins, Specs (any type the test program can write to), e.g.: - if a test is instantiated at top-level and a reference is passed, it is not clear which copy it should be a reference to. - is a global instantiation automatically a means of communication between test-programs executing in parallel (defeats SiteSharePer control) -------------------------------------------------------------------------------- Jim's email Sun 8/10/2014 11:56 AM: 1. A function call IS an action, in my opinion - therefore, should be allowed. * See Syntax Document Update Mon 7/21/2014 8:21 AM * should statements abs, max, min, pow, also be allowed? 2. See my email on 8/4/2014 (subject: Re: [STDS-1450.4:] Test Instantiation Constraint Rationale) on this. In short, if Device block is used, tests must be instantiated within the TestProgram block, and multiple TestPrograms can be included in the input stream. If the Device block is not used, only a single TestProgram is allowed in any one input stream, and Tests can be instantiated either inside or outside the TestProgram block. * Don't create a sub-language if you can avoid it 3.a. Not sure what is being proposed or discussed here - aren't actions already part of the reserved words list? If not, what actions are NOT currently in the reserved words list? Please elaborate. * Look at the reserved words list 3.b: Actions should not be required to use parentheses - use only as necessary to disambiguate compound expressions (as in C or C++ or pretty much any other computer language). * if action are functions with a void return value, C tells apart by parentheses 4. Why is this even an issue? The precedent has been set in dot1 (no duplication of variable names of different types allowed in the same context) - we should simply follow it and extend to our expanded range of variable types. * this is about the interaction SigGroup (Unnamed block), Spec, and String names (Unnamed block) see Table 6—STIL name spaces, PDF pg 74 ================================================================================ ECID - Electronic Chip ID (http://grouper.ieee.org/groups/1149/1/ECID_Electronic_Chip_ID.html) The ECID register is unique per die and may include Wafer X-Y locations, lot information, wafer number, binning information for temperature and speed grade and any other information deemed appropriate for traceability. -------------------------------------------------------------------------------- Ref Annex "D.1 Parsing and Loading": provisions must be made for each TestProgram to get its own copy of Category/Spec-variable Meas fields. * Each TestProgram must have its own Meas field for each Spec variable. * Each Category/Spec-variable expression containing a reference to a Spec-variable for whom the Meas field is selected may evaluate to a different value for each TestProgram * Bins may be set differently per TestProgram Semi Standard hardware/software interfaces see file c:/Users/Ernie/Documents/Test/Standards/Standards.txt -------------------------------------------------------------------------------- Event sequence: STDF initialized before the initialization call is made: Const Integer x_coord = getSTDF("PRR.X_COORD"); Standard: forces initialization sequence: STDF before variable init Recommended: STDF before variable init optional -------------------------------------------------------------------------------- Decision to move Standard variables to annex was made under misconception: 1. Translation 2. Special purpose variables would require special treatment at run-time 3. These are not under the PAR: they are under a. "Common interfaces between the test flow environment and test program components". b. "Order of execution of test program components". c. "Binning or categorization of tested ICs". -------------------------------------------------------------------------------- * Don't allow initialization to function call at LOAD or require None return BTW: errno is part of the ANSI C standard ================================================================================ # FROM PREVIOUS SESSION: # # * Discussion about elements not specific to flow, but which impacts it. # - For instance, test Program variables vs. variables shared by program and pattern (i.e., initialization sequence) # - how much of this belongs in the dot4 language, i.e. should be standardized, and how much of it is just uses of the dot4 language # * Action Items: # - All: Resolve remaining red items # - All: Review TOC - identify items believed to be in or out of scope # - All: For items in scope, review individual sections, state whether level of detail is not enough, about right, too much. # - Add annex(es) for recommended, but not mandated, information or usages. ---------------- Q. WHY DO WE NEED SPEC_BLOCK_NAME AT ALL ? A. SPEC_BLOCK_NAME narrows the search. To not have it as a hierarchical delineator is a programming language aberration that serves no purpose. Try to factor out repetition of identical syntax ref ChannelMap & SignalMap, e.g., channel statements to keep slight difference from creeping in. ================================================================================ Ric Dokken: * how many each Chip, Package, ChannelMap, Signals, SignalGroups, TestProgram blocks are expected at the top level ? Device 0, Chip 0, Package 0, SignalMap 1+, Signals 1 unnamed, SignalGroups 0+, TestProgram 1 * loadboard/test-software interaction - does loadboard EPROM reader load: TestProgram, ChannelMap, Package, Signals, SignalGroups ? - does TestProgram check read EPROM to check for compatibility ? ================================================================================ PatternExec related rules from STIL.0/2 1 = block name is required at definition 2 = block name is optional at definition U = PatternExec uses unnamed global block if not named T = STIL.0 PatternExec may be used for timing only when PatternBurst is absent S = Spec need not be specified if PatternExec was created under STIL.0 rules (the norm) N = If name is absent, then top-level unnamed object is used References inside PatternExec block: 1 Category CATEGORY_NAME 1T PatternBurst PAT_BURST_NAME 1 Selector SELECTOR_NAME 2N DCLevels (DC_LEVELS_NAME) 2N DCSets (DC_SETS_NAME) 2S Spec SPEC_BLOCK_NAME 2U Timing TIMING_NAME -------------------------------------------------------------------------------- * Standard PatternExec to StdFunctional mapping: 1 PatternExec patexec { 2 Spec spec_tim1; 3 Category cat_tim1; 4 Selector sel_tim1; 5 Timing tim; 6 7 Spec spec_lev1; 8 Category cat_lev1; 9 Selector sel_lev1; 10 DCLevels lev; 11 DCSets dcsets; 12 13 PatternBurst burst; 14 } * Category: see section 6.11.2.6 Spec/Category Variables, line 5103 * STIL.0 Pattern data for scalable devices: does "sigref_expr = vec_data;" allow for more vec_data than the number of signals in sigref_expr ? Ref STIL.0 21.1 Cyclized data, pg 100 (PDF 108): quote "The vec_data shall always define at least an individual WaveformChar for each SIGNAL-NAME in sigref_expr." Desired specification: if there are more WaveformChars than SIGNAL-NAMEs, discard the excess ================================================================================ STIL.0 pg 66, NOTE 1: NOTE 1—The Spec block defines spec variables in STIL. All spec variables are defined under categories in this block. Categories are used to reference sets of spec variables, and it is the Category block name that is important when referencing variables. The Spec block name is not significant. -------------------------------------------------------------------------------- STIL.0 section 6.16, pg 66, Table 6: Any Spec variable or Spec category defined in any Spec block is global, irrespective of the presence of an explicit domain name on the Spec block. -------------------------------------------------------------------------------- STIL.0 section 6.16, pg 67: 2nd item in dash list: It is an error to refer to a name defined in two different (domain named) blocks, even if both definitions for the name are the same. 4th item in dash list: For spec variables, it is an error to redefine a previously defined category for a spec variable. -------------------------------------------------------------------------------- STIL.0 section 16, pg 80: If the Timing block references spec variables that contain multiple values (i.e., Min, Typ, or Max values), the variables shall be specified in an unambiguous manner, either by resolving which value to apply via a Selector block, or qualifying the variable name in the reference (for example, ‘var.Min’). -------------------------------------------------------------------------------- STIL.0 section 16.1, pg 81: Category CATEGORY_NAME: Selection of a category, which defines the values of spec variable to be used for this pattern execution. -------------------------------------------------------------------------------- STIL.0 section 19, pg 94, last paragraph: Any given variable-category value shall be defined only once. ================================================================================