Filetype Excel XLS | Posted on 05 Jul 2022 | 3 years ago
Authentication
digital resources
169x Filetype XLS File size 0.12 MB Source: grouper.ieee.org
Sheet 1: comments
| Name | Category | Page | Subclause | Line | Comment | File | Must Be Satisfied | Proposed Change | Resolution Status | Resolution Detail (last updated - Nov 11, 2006) | Other1 | Other2 | Other3 |
| LEY, ADAM W | Editorial | 20 | 6 | 1 | The first line in sub-clause 6 includes the text "STIL0", which is not defined. | No | Replace with "STIL.0". | DONE | oct 1 - changed | ||||
| LEY, ADAM W | Editorial | 1 | All | 1 | Please note that my comment concerning use of "TRC LANGUAGE" in the header applies to all pages notwithstanding the fact that the comment entry cites page 1. | No | Change header on all pages. | DONE | oct 1 - changed see also next item | ||||
| LEY, ADAM W | Editorial | 1 | All | 1 | The use of "TRC LANGUAGE" in the page header doesn't seem appropriate. I believe that the usual convention is to spell out the full name of the document across facing pages starting from page 2. | No | For the draft, use "DRAFT STANDARD FOR EXTENSIONS TO STANDARD TEST INTERFACE LANGUAGE (STIL) (IEEE STD 1450) FOR TESTER TARGET SPECIFICATION". | DONE | oct 1 - changed. However, I could not get all the suggested words into the header. The IEEE editor may want to alter it again after it is approved by the ballotters | ||||
| LEY, ADAM W | General | 1 | front matter | 2 | In the document title, given in D14 as "P1450.3 - Standard for Extensions to Standard Test Interface Languge (STIL) (IEEE Std. 1450-1999) for Tester Target Specification", it seems improper to cite the STIL.0 standard by year of issue since the latest version should apply. | No | Omit the year of issue for STIL.0 from the title such that the new title reads "P1450.3 - Standard for Extensions to Standard Test Interface Languge (STIL) (IEEE Std 1450) for Tester Target Specification". | DONE | oct 1 - The date identifier - "1999" has been removed from the title. Note: This, however, conflicts with the requirement to be consistent with the title in the PAR. IEEE will have final contol over the title after ballot approval. | ||||
| SANTIAGO, JOSE M | Technical | 65 | 898 | In Annex D.1, the 'Module' statement is missing the module name per the syntax. | No | Add module name after 'Module' | DONE | oct 1 - added module name | |||||
| SANTIAGO, JOSE M | Technical | 64 | 882 | The 'PatternAttributes' statement uses 'MaxVectors', which is old syntax. | No | Change it to 'Max Vectors' per syntax | DONE | oct 1 - changed to "Max Locations". Did search/replace over whole doc. Removed MaxVectors from keyword list - Table 3. | |||||
| SANTIAGO, JOSE M | Technical | 63 | In the Annex D.2, the first paragraph states "&The PatternAttributes block is used to define the MaxVectors &" | No | Since 'MaxVectors' is not valid syntax, change to "&define the maximum number of vectors &" | DONE | oct 1 - changed | ||||||
| SANTIAGO, JOSE M | Technical | 59 | 763 | In Annex B.1, the 'Module' statement is missing the module name per the syntax. The same is true for line 766. | No | Add module name after 'Module' | DONE | oct 1 - changed | |||||
| SANTIAGO, JOSE M | Technical | 50 | 17.2 | 691 | The 'PatternAttributes' statement uses 'MaxVectors', which is old syntax. | No | Change it to 'Max Vectors' per syntax | DONE | oct 1 - changed | ||||
| SANTIAGO, JOSE M | Technical | 50 | 17.2 | Should the 'LoopMatch' parameter be 'Loop' based on syntax | No | Correct syntax or example | DONE | oct 2 - item 11, 13 are related changed to MatchLoop. Note: There is already a block for general "Loop" attributes. |
|||||
| SANTIAGO, JOSE M | Technical | 47 | 17.1 | 12 | In the syntax for PatternAttributes, the 'MultiBitData' statement has the + sign and 'No' selected as default. | No | Remove the + sign from the syntax, since the description does not have it and it is inconsistent. | DONE | oct 2 - removed parens and + sign. | ||||
| SANTIAGO, JOSE M | Technical | 47 | 17.1 | Should the 'Loop' parameter be 'LoopMatch' based on example | No | Correct syntax or example | DONE | oct 2 - item 11, 13 are related. See item ll for comment |
|||||
| SANTIAGO, JOSE M | Technical | 47 | 17.1 | There is no descriptions for any of the "instruction_enum" list of parameters | No | Add detailed descriptions | DONE | oct 2 - added description for the enum list | |||||
| SANTIAGO, JOSE M | Editorial | 45 | 16.1 | In the definition for syntax line number 1, the default option is not underlined. | No | Underline 'Rule' since it is a default attribute for 1. | DONE | oct 2 - changed | |||||
| SANTIAGO, JOSE M | Editorial | 43 | 15.1 | In the definition for syntax line number 11, the default option is not underlined. | No | Underline 'Dynamic' since it is a default attribute for 11. | DONE | oct 2 - changed | |||||
| SANTIAGO, JOSE M | Editorial | 42 | 15.1 | In the definition for syntax line number 6 through 10, the default option is not underlined. | No | Underline 'Dynamic' since it is a default attribute for 6 through 10. | DONE | oct 2 - changed | |||||
| SANTIAGO, JOSE M | Technical | 36 | 13.1 | 7 | Why do we need two statements called 'NumberDCLevels' in this block? | No | These statements should be combined | DONE | oct 2 - changed | ||||
| SANTIAGO, JOSE M | Editorial | 34 | 12.1 | In last paragraph, " (a) Synchronous: Signals&" | No | Underline 'Synchronous' since it is a default attribute | DONE | oct 2 - changed | |||||
| SANTIAGO, JOSE M | Technical | 34 | 12.1 | In the definition for syntax line number (5) InOut, both 'InOnly' and 'OutOnly' are not described | No | Add descriptions for 'InOnly' and 'OutOnly'. | DONE | oct 2 - changed - Also added keywork "Static" to the syntax. - Also removed the note which applied to syntax that has been removed - "Note that whereas the In/Out specification on the top level SignalAttributes block specifies the basic ability to either drive or compare, this statement specifies when the in/out switching may occur." |
|||||
| SANTIAGO, JOSE M | Technical | 33 | 12.1 | 4 | In the syntax for SignalAttributes, the 'InOut' statement does not have 'Static' listed as an option but it is defined in page 34. | No | Add 'Static' to the list of options. | DONE | oct 2 - changed | ||||
| SANTIAGO, JOSE M | Technical | 33 | 12.1 | 4 | In the syntax for SignalAttributes, the 'InOut' statement does not have a default selected from the group | No | Suggest to make "WithinCycle" the default | DONE | oct 2 - changed as suggested | ||||
| SANTIAGO, JOSE M | Technical | 32 | 11.2 | 538 | The 'PatternAttributes' statement uses 'MaxVectors', which is old syntax. | No | Change it to 'Max Vectors' per syntax | DONE | oct 2 - changed | ||||
| SANTIAGO, JOSE M | Editorial | 29 | 11 | In last paragraph, " Constraints: This&" | No | Underline 'Constraints' since it is a default attribute | DONE | oct 2 - changed | |||||
| SANTIAGO, JOSE M | Technical | 29 | 11 | 10 | Should the MODULE_NAME be in parenthesis to make it optional | No | Consider making the MODULE_NAME optional | DONE | oct 2 - The module name has been made optional | ||||
| SANTIAGO, JOSE M | General | 27 | 10.1 | In last paragraph, fix sentence "&tags may may be used &" | No | Change to "&tags may be used&" | DONE | oct 2 - changed | |||||
| SANTIAGO, JOSE M | Editorial | 15 | 5.3 | In the description for Note 8, The following sentences "The CompareStrobe & states." is invalid since the 'DriveState' statement are not used in example. | No | Remove sentences | DONE | oct 4 - other questions are raised by this ex: - p41; DriveEvents L H L/H 2 1; are the single event defs reqd? same for CompareEvents. - p41; the 1st integer expr is optional with a default of 1; for both DriveEvents and Compare/Events. - compare states should be h/l/x for window - CompareStrobe and CompareState stmts removed; now part of the referenced WaveformAttributes - Note: now Annex F |
|||||
| SANTIAGO, JOSE M | Editorial | 15 | 5.3 | In the description for Note 6, The following sentence "The DriveState & states." is invalid since the 'DriveState' statement is not used in example. | No | Remove sentence | DONE | oct 4 - stmt removed; now defined in the referenced WaveformAttributes stmt. | |||||
| SANTIAGO, JOSE M | Technical | 15 | 5.3 | 214 | The 'Module' statement is missing the module name per the syntax | No | Add module name after 'Module' | DONE | oct 4 - changed; see also item 25 | ||||
| SANTIAGO, JOSE M | Technical | 14 | 5.3 | 186 | The first entry 'In' preceeding 'RTO_FORMAT' does not match the syntax | No | Need to remove the 'In' word. | DONE | oct 4 - changed | ||||
| SANTIAGO, JOSE M | Technical | 13 | 5.2 | 134 | The 'PatternAttributes' statement uses 'MaxVectors', which is old syntax. | No | Change it to 'Max Vectors' per syntax | DONE | oct 4 - changed | ||||
| SANTIAGO, JOSE M | Technical | 11 | 5.2 | 79 | The first entry 'In' preceeding 'INTVC' does not match the syntax. Same is true for lines 87, 93, 100, 108, 116, and 123 in pages 11-13. | No | Need to remove all invalid words | DONE | oct 4 - changed | ||||
| SANTIAGO, JOSE M | Technical | 10 | 5.2 | 73 | Multiple attributes used with 'FormatSelect', only one must be selected | No | Change from 'In Out' to 'InOut' or &? | DONE | oct 9 - changed | ||||
| SANTIAGO, JOSE M | Technical | 9 | 5.1 | 37 | The 'PatternAttributes' statement uses 'MaxVectors', which is old syntax. | No | Change it to 'Max Vectors' per syntax | DONE | oct 9 - changed to Max Locations | ||||
| SANTIAGO, JOSE M | Technical | 9 | 5.1 | 33 | The 'PatternAttributes' statement uses 'MaxVectors', which is old syntax. | No | Change it to 'Max Vectors' per syntax | DONE | oct 9 - changed to Max Locations | ||||
| SANTIAGO, JOSE M | Technical | 9 | 5.1 | 21 | The 'CompareEvents' statement uses 'Edge', which is invalid syntax | No | Remove 'Edge' from example. | DONE | oct 9 - changed | ||||
| SANTIAGO, JOSE M | Technical | 8 | 4.3 | In line starting with "Clause 17.2. "MAP_STRINGS" syntax and 17.3, &" | No | Change '17.2' and '17.3' to '18.2' and '18.3' respectively | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | Technical | 8 | 4.3 | In line starting with "Clause 17. Environment block &" | No | Change '17' to '18' | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | Technical | 8 | 4.3 | In line starting with "Clause 10. Variable block &" | No | Change '10' to '9' | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | Technical | 8 | 4.3 | In line starting with "Clause 8. STIL statement &" | No | Change '8' to '7' | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | Technical | 8 | 4.3 | In line starting with "Clause 6. Expresions constructs &" | No | Change '6' to '5' | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | Editorial | 8 | 4.2 | In last listing, "(e) In the tutorial (clause 5), bold numbers&" | No | Replace 'bold' with 'circled'. | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | Editorial | 7 | 4.1 | In last paragraph, "&as identified in the list above (Clause 4). | No | Remove (Clause 4). This is unclear. | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | General | 6 | 2 | In 'IEEE Project.P1450.6' | No | Change 'Project' to 'Std.' | DONE | oct 9 - changed | |||||
| SANTIAGO, JOSE M | General | 6 | 2 | In 'IEEE Project.P1450.1' | No | Change 'Project' to 'Std.' | DONE | oct 9 - changed | |||||
| TAYLOR, TONY | General | Comments have been submitted for reviewers as follows: JC = John Cosley HK = Hirofumi Kamitokusari GR = Gordon Robinson |
No | NO-CHG | No change required | ||||||||
| TAYLOR, TONY | Technical | GR: Section 10.1 on Resouce ids states that "the resouce id within the angle bracket is a format as required by the tester loader. The following are all allowed formats for resource id tags." Igonoring the picky distinction between "resource id" and "resource id tag" I could take this as implying either 1. Anything is allowed (as required by the tester loader, but undefines here) 2. Whatever is allowed must be one of the following forms. |
No | DONE | oct 9 - changed | ||||||||
| TAYLOR, TONY | Technical | GR: I believe that the section (5.4.3) that states that using InheritWaveformTable is an implicit mechanism for resouce assignment could be considered to be changing the existing 1450 meaning. |
No | DONE | sep 29 - This clause does not change any syntax or interpretation as defined in dot0. It is only an example of the application of existing syntax. As proposed by IEEE editors, and to aviod this kind of mis-interpretation, all of the examples in the tutorial section (clause 5) have been moved to the Annex. | ||||||||
| TAYLOR, TONY | Technical | GR: I still hate all of the "global and named block merge rules", particularly when they get below "genuine top-level" blocks. |
No | DONE | sep 29 - similar issues = 49-GR, 77-JC, 118-GM, 119-GM, 137-GM, 138-GM. The following changes have been made: 1) remove subclause 7.5; the following changes are to make scoping explicit 2) disallow multiple PatternAttr, SignalAttr statements 3) allow multiple names on a PatternAttr statement to allow "OR"ing 4) add Inherit statements to provide "AND"ing 5) for consistence the Inherit statement is added to clauses 12 .. 17. |
||||||||
| TAYLOR, TONY | Editorial | GR: There are some obvious "loosely specified parts" such as where the whole of "Mastering Regular Expressions" syntax is included by reference. This contains some extremely powerful and difficult to implement features. (Anyone thought what this implies for STIL lexing? And how are options such as embedded whitespace in regexes being handled? 'Nuff said). |
No | DONE | oct 17 - a new annex has been created that provides a reference to documentation on regular expressions and also reference to the GNU library that can be built in to a STIL reader to implement regular expressions. |
||||||||
| TAYLOR, TONY | Editorial | GR: I've abstained on this one, because although I dislike the document, I can't easily identify specifics that I could state in a no vote comment, and I ended up feeling, "if that's what the active crew want, good luck to them implementing it fully." |
No | NO-CHG | No change required | ||||||||
| TAYLOR, TONY | Editorial | HK: (13) Underline to show default (page 29) The underline to show default is given in syntax, but there is the case that underline is given and is not given in the explanation of statement after syntax, For example: page 29 : Constraints, page 34 : Synchronous, page 42 : Dynamic (6 place) It is better to unify the description. |
No | DONE | oct 9 - changed | ||||||||
| TAYLOR, TONY | Editorial | HK: (12)STIL0 (page 20) STIL.0 is correct. |
No | DONE | oct 9 - changed | ||||||||
| TAYLOR, TONY | Editorial | HK: (11) The description of (flow3), (flow4) (page 15) In other page( page 8,9 etc,), it is described as flow(1). so it is better to use the same description. |
No | DONE | oct 9 - uniformly changed to reference as "flow #"; no parens used. | ||||||||
| TAYLOR, TONY | Editorial | HK: (10) "per pin tester" and "shared tester" The distinction of "per pin tester" and "shared tester" is necessary. |
No | DONE | oct 9 - added "shared resource architecture" to Annex A; also added reference in "per pin architecture in Annex A. | ||||||||
| TAYLOR, TONY | Editorial | HK: (9)The sample description in Subclause 5.2 (page 11) The syntax for WaveformDescriptions block states "WFNAME", and the syntax does not allow describing "In". But the sample description in the Tutorial (page 11) use "In". If sample is not correct, please correct. |
No | DONE | oct 10 - example corrected | ||||||||
| TAYLOR, TONY | Editorial | HK: (8-2) Macro statement must have one of the option values. It is not allowed to describe Macro statement as "Macro;", but it is explained that its default value is "WithParameters". The same thing can be said for ProcedureCalls statement. Is this syntax correct? If syntax is not correct, please correct. |
No | DONE | oct 10 - The general rule is that if a statement is omitted then that condition is not checked. In this case if there is no Macro statement, then all manner of macros with parameters are allowed. Hence the default, if no statement, is "WithParameters". The same thing applies to ProcedureCalls. The explanation has been expanded to clarify this point. | ||||||||
| TAYLOR, TONY | Editorial | HK: (8)The Macro and ProceduresCalls in PatternAttributes (pages 49-50) (8-1) In case "No" is selected for Macro and ProcedureCalls statements defined in PatternAttributes block, and if either Macro or Call is defined for InstructionAttributes statement in the same PatternAttributes block, the interpretation of the test patterns for Macro and Call becomes unclear, whether they are to be supported or not. Also, if "Yes" or "WithParameters" is selected, and if Macro or Call is not defined by the InstructionAttributes statement, its interpretation also becomes unclear. The specification should have additional explanation for such cases. |
No | DONE | oct 10 - see item 57 | ||||||||
| TAYLOR, TONY | Technical | HK: (7)The clock pins and scan pins (page 33) The constraints for number of clock pins and scan pins is necessary. For example, the constraint that limits the waveform types available and availability of bi-directional pins. |
No | DONE | oct 10 - The technique for defining the number of pins allowed with a given set of attributes is to define separate SignalAttributes blocks and use the MaxSignals statement in each block to define the limits. A SignalAttributes statement within a Module block may now contain multiple names. The Inherit statement has been added to allow for common attributes to be identified in a common block. Related items - 59-HK, 74-JC |
||||||||
| TAYLOR, TONY | Technical | HK: (6)The limit of test cycle for multiclock (page 39) The minimum cycle constraint for cycles making one clock in the multiclock waveform is necessary. |
No | NO-CHG | oct 10 - No change to the syntax is required. There are two ways of constraining the number of multi-clocks. The DriveEvents statement can specify the number of edges allowed. Or a multi-clock can be defined using sub-waveforms; in which case the ReplicateSubWaveforms defines the constraint. | ||||||||
| TAYLOR, TONY | Technical | HK: (5)The instruction memory (page 47) The specification to define the constraint of instruction memory is necessary. |
No | DONE | oct 10 - The technique for constraining instruction memory is to define a PatternAttributes block for each type of pattern generation instrument in a system. Each instrument should have its own set of constraints. The Module block can select which of the PatternAttributes blocks are allowed. The PatternAttributes statement has been changed to allow reference to multiple names. |
||||||||
| TAYLOR, TONY | Technical | HK: (4)The units (prefixes) that can be used by testers (page 39) The constraints of units (prefixes) that can be used by testers is necessary. For example some testers have the constraint that the time can be specified in "ns" but not in "ps". Not only time(second) but also constrain of Ampere, Ohm, Volt are necessary. |
No | DONE | oct 28 - added new statemement to define allowed units - TRC -> Units | ||||||||
| TAYLOR, TONY | Technical | HK: (3)The number of nests and pattern steps in Procedure (page 48) The statement to define constraints of number of nests and maximum steps is necessary to ProcedureCalls block in PatternAttributes block. |
No | NO-CHG | oct 10 - No change required. The technique to limit nesting is to use the InstructionAttributes statement. This allows the MaxNest to be specified for each type of statement - Macro, Call, Loop, etc. | ||||||||
| TAYLOR, TONY | Technical | HK: (2)The waveforms on-the-fly (page 39) The specification to define whether user can use the waveforms on-the-fly as the tester constraint is necessary. Because some testers cannot be used by tester's constraint, And some testers have constraints on the types of waveforms available after switching. Therefore, the specification to define the combination of the waveform type is also necessary. |
No | NO-CHG | oct 28 - No change required. This capability is provided by the stmt: MaxShapes, MaxTimeSets, etc. These statements allow to define either Dynamic (i.e., on-the-fly) or Static. Also allow to specify the number of waveforms allowed. |
||||||||
| TAYLOR, TONY | Technical | HK: (1)The minimum edge cycle in a multiple cycle (page 46) The specification to describe the constraint of the intervals of the drive edges (including the case of strobe edges) between the previous Vector pattern and next Vector pattern is necesary. |
No | DONE | oct 10 - Enhance description - Added definition of allowed time expr syntax in WaveformDescriptions -> Shape with references to the dot0 and dot1 allowed syntax. Added an example of a two cycle waveform - The WaveformAttributes -> MinEdgeReTrigger allows to specify the timing constraint on drive and compare edges from one vector to the next. |
||||||||
| TAYLOR, TONY | Editorial | JC: Annex B 2nd paragraph: discussion here refers to using Spec-Var and Spec-Cat for handling Fluid specs. Then the examples use ParamConstant, ConfigConstant and Assert to handle it. | No | DONE | oct 10 - The intro paragraphs to Annex B have been re-worded. | ||||||||
| TAYLOR, TONY | Editorial | JC: 18.1 p.52, (4) regular_expr, should have brief definition here or in Appendix. | No | DONE | oct 10 - see item 50 | ||||||||
| TAYLOR, TONY | Technical | JC: 17.1 p.48: Don't agree with the following defaults: (6) (b) MaxIteration = 1 (should be no limit) (c) MaxLength = 1 (should be no limit) (d) MaxNest = 1 (should be no limit - also typo here 'MaxNext') p.49 (7) should be (6)(i) then all numbers after decrease by 1 (12) Ths -> This |
No | DONE | oct 10 - Changes made as sugggested. 1) Note: Having no limit is consistent with the general rule in clause 11 which states that if a statement is omitted, then no checking is done - hence these parameters become unlimited. 2) typo and clause numbering corrected |
||||||||
| TAYLOR, TONY | Technical | JC: 17.1 p.47: instruction_enum, should it also include Vector in instruction list? | No | NO-CHG | oct 10 - Upon further investigation by the commenter it was decided that no change is required. |
||||||||
| TAYLOR, TONY | Editorial | JC: 13.1 p.36, (5): have many acronyms, should we give more of a definition here as to exactly what they mean? some are obvious, but others not. | No | NO-CHG | oct 10 - No change required. All the DCResource acronyms are defined in dot2. Dot2 is referenced in both clause 13.1 and in clause 2. | ||||||||
| TAYLOR, TONY | Editorial | JC: 11.2 p.31, line 526: should only have 1 } | No | DONE | oct 10 - changed | ||||||||
| TAYLOR, TONY | Editorial | JC: 11.1 p.31, (18): spelling DCResourceAttributes | No | DONE | oct 10 - changed | ||||||||
| TAYLOR, TONY | Editorial | JC: 11.1 p.30, (14), 4th line: is -> if | No | DONE | oct 10 - changed | ||||||||
| TAYLOR, TONY | Technical | JC: 11.1 p.29, line (15): SignalAttributes should not have * - per later description can only have 1. Actually I like the idea of having multiple, perhaps change (15) on page 30? | No | DONE | oct 10 - Related items - 59-HK, 74-JC |
||||||||
| TAYLOR, TONY | Editorial | JC: 11. p.28, (c): 'SignalAttributes Data Clock { }' is a syntax error | No | DONE | oct 10 - see 49-GR. |
||||||||
| TAYLOR, TONY | Editorial | JC: 11. p.28, 2nd paragraph, last sentence: does not make sense, also should reference specific section of document. | No | DONE | oct 10 - changed | ||||||||
| TAYLOR, TONY | Technical | JC: 7.5 (e): The rules for application/merging of block names are not consistent with other STIL rules. Using 2 block names should be OK and they get merged, but no conflicts allowed. For example, you can have multiple InheritWaveformTable statements (timing gets merged) as long as they do not have conflicting information, so why not be able to have multiple named PatternAttributes blocks be merged in the same way? | No | DONE | sep 29 - similar issues: 49-GR, 77-JC, 118-GM, 119-GM, 137-GM, 138-GM | ||||||||
| TAYLOR, TONY | Editorial | JC: 6.1 P.20: shouldn't this list also include Assert, ConfigConstant & ParamConstant? | No | DONE | oct 10 - changed | ||||||||
| TAYLOR, TONY | Editorial | JC: 5.4.1 p.16, line 233: L3-x should be quoted | No | DONE | oct 10 - changed Note: double quotes have been added for consistency. However they are not required by this standard since they are within the Pragma. |
||||||||
| TAYLOR, TONY | Editorial | JC: 5.2 page11-13: Figures are confusing without any explanation of what @@ and @ or t>10 mean. | No | DONE | oct 10 - changed Note: The definition of this syntax is in dot1, so a reference to dot1 has been added to the beginning of this Annex. |
||||||||
| TAYLOR, TONY | Editorial | JC: 2nd sentence: 'These numbers are ... ' | No | DONE | oct 10 - changed | ||||||||
| TAYLOR, TONY | Editorial | JC: 3.1 (same as above) | No | DONE | oct 10 - changed | ||||||||
| TAYLOR, TONY | Editorial | JC: 2.0 References: shouldn't we use 1450.1-2005 now? | No | DONE | oct 10 - changed | ||||||||
| WILDER, GREGG | Editorial | 66 | Shape: This term refers to the wave shape the is created | No | This term refers to the wave shape that is created | DONE | oct 17 - changed | ||||||
| WILDER, GREGG | Editorial | 51 | 18 | Table 3 | No | Add Length from 18.1 | DONE | oct 17 - changed Note: Moved table 3 to clause 6. |
|||||
| WILDER, GREGG | Editorial | 49 | 10 | Max: This statement specifies the minimum number of vectors (or the minimum | No | This statement specifies the maximum number of vectors (or the maximum | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 49 | 8 | Macro: This statement pecifies | No | This statement specifies | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 47 | 17 | Table 3 | No | Add Base, MinAfter, MinBefore, Infinite, Modulus, Macro, Max, VectorCompression from 17.1 | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Technical | 46 | 9 | NumberTimeSets | No | This definition doesn't seem right to me. From Annex E, it looks like this should be something about indirect memory. Or at least it should be different from the definition of NumberShapes. | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 45 | 6 | NumberPeriods: complex shapes the encompass | No | Complex shapes that encompass | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 45 | 16 | Table 3 | No | Add NumberSignals from 16.1 | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 43 | 19 | MinDrivePulse: Specify the minimum allowe | No | Specify the minimum allowed | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 40 | 15 | Table 3 | No | Add MinCompareToDriveOn, MinDriveOffToCompare from 15.1 | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 39 | 6 | TimeLimits: by the period generatoor | No | By the period generator | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 36 | 13 | Table 3 | No | Add PerPinConfiguration, DifferentialConfiguration, NumberTesterChannels, DCLimits, NumberLevels, NumberDCLevels from 13.1 | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 34 | 12 | Numbered comments don't match syntax | No | For example, FanOut is 3 in syntax, 4 in comments | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 32 | 11 | Table 3 | No | Add AllowedScanPadWaveforms, InOut, DCResourceAttributes, UndrivenInOut from 12.1 | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 30 | 9 | MultipleSites: If this statement is omitted, the only | No | If this statement is omitted, then only | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 30 | 8 | MultipleDevices: If this statement is omitted, the only | No | If this statement is omitted, then only | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 30 | 5 | See clause B | No | See Annex B | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 29 | 3 | STILExtensions | No | Define extensions: eg, Design is for 1450.1, etc | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 29 | 11 | In the case were multiple blocks | No | In the case where multiple blocks | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 26 | 9 | 2 | See clause B | No | See Annex B | DONE | oct 17 - changed | ||||
| WILDER, GREGG | Editorial | 22 | 7 | 14 | A TRC file that is to be used for the constraining | No | A TRC file that is to be used for constraining | DONE | oct 17 - changed | ||||
| WILDER, GREGG | Editorial | 15 | 5 | There are two pragmas contained in this example. | No | Add (refer to Clause 19 of 1450.1 for definition of pragma) | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 8 | 4 | 16 | (see Clause C) | No | (see Annex C) | DONE | oct 17 - changed | ||||
| WILDER, GREGG | Editorial | 8 | 4 | 7 | (see Clause B) | No | (see Annex B) | DONE | oct 17 - changed | ||||
| WILDER, GREGG | Editorial | 6 | 2 | IEEE Project P1450.6 | No | IEEE Std. 1450.6-2005 | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 6 | 2 | IEEE Project P1450.1 | No | IEEE Std. 1450.1-2005 for Semiconductor Design Environments | DONE | oct 17 - changed | |||||
| WILDER, GREGG | Editorial | 6 | 1 | The variations in archetecture makes if | No | Change archetecture to architecture; if to it | DONE | oct 17 - changed | |||||
| MASTON, GREGORY | Editorial | 73 | last word first paragraph is misspelled | No | helpful has 1 ell | DONE | oct 17 - changed | ||||||
| MASTON, GREGORY | General | I have a concern about how to identify or classify Signals into SignalAttributes blocks; does one take each Signal and identify ALL the SignalAttributes blocks that it passes, and then start taking sets of Signals that pass each block and running checks given this number of signals? This strategy is not deterministnc, and is likely to end up with implementations of TRC behavior that do not behave the same way. Which at the root says the spec is incomplete because of the potential to interpret the same STIL data against the same TRC in different ways. | No | Augment the spec to identify how to "match" a STIL file into a set of TRC constructs. | DONE | oct 30 - minor syntax enhancement It is recognized that when a TRC is used for the purpose of contraining a flow that there may be multiple solutions that are difficult to resolve. Unfortunately, it is the nature of most ATE systems to have multiple resources that are capable of addressing a particular need - signals, pattern memories, etc. Either the user must create a simple sub-set of the TRC or else it is the application's responsibility to resolve the resource usage issues. Added additional, optional fields to the Variables -> ConfigConstant statement with ALT_CONFIG_NAME(s) |
|||||||
| MASTON, GREGORY | Editorial | 56 | "ESSM" : is this trade-marked? | No | Check we are not treading on something. Google has some great hits here: Emergency Ship Salvage Material, Evolved Sea Sparrow Missile, and the European Society for Sexual Medicine. | DONE | oct 4 - removed the acronym and used the full term wherever it is needed - "Event Sequence Store Memory" | ||||||
| MASTON, GREGORY | Editorial | 56 | "on-the-fly" definition says "see also "static", but "static" carries the opposite meaning | No | Change "see also" to "contrast with". Likewise on the definition of "static" | DONE | oct 20 - changed. Also made same chage to the definition of "static". | ||||||
| MASTON, GREGORY | Technical | 50 | 17.1 | bullet (16) NumVecPerShift: is this the unrolled number of vectors (dependent on the data passed into the Shift), or the number of V statements contained in the Shift block? Note that a STIL to WGL translator is constrained to 1 Vector in the Shift block to map to the WGL scan statement. | No | Clarify definition: both quantities may be important. | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 50 | 17.1 | bullet (10) Max < Loc | Vec > says the statement identifies the minimum number of vectors. | No | Either change the statement to Min < Vec | Loc > or change the explanation&. | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Editorial | 47 | 16.1 | bullet (8) says "comples" | No | change to "complex" | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | Is the PatternAttributes the only block that allows multiple references to named blocks and merges unnamed blocks? All other blocks (PeriodAttributes, SignalAttributes, and WaveformAttributes) appear to only allow a single reference which replaces the unnamed block - as least according to the description on pg 31. In this case, clause 7.5 should be made clear that it affects only the PatternAttributes block, and it should be identified that this block scoping does not apply to these other blocks. Or the other blocks need to have similar scoping support as to the PatternAttributes. | No | A uniform scoping rule across all blocks needs to be established. Different rules for each type of block is not a good definition. | DONE | sep 29 - similar issues: 49-GR, 77-JC, 118-GM, 119-GM, 137-GM, 138-GM | |||||||
| MASTON, GREGORY | Technical | 31 | 11.1 | bullet (13) says "there may be multiple global". I am confused by the context of "multiple global" here; this statement references named blocks and the pertinence of global (unnamed) blocks is questionable for interpreting this statement. | No | remove the reference to "multiple global", or if necessary to indicate potential of global blocks then add a separate sentence "Global (unnamed) blocks may also be present and included based on the handling presented in clause 7.5". | DONE | sep 29 - similar issues: 49-GR, 77-JC, 118-GM, 119-GM, 137-GM, 138-GM | |||||
| MASTON, GREGORY | Technical | 29 | 11 | bullet (c) and (d) reference "Data" and "Clock" constructs that I think were removed from this spec | No | Change examples to something current | DONE | oct 20 - bullet c, d are removed. Or-ing is now explicite in the statements that allow it. And-ing is done by use of Inherit. | |||||
| MASTON, GREGORY | Technical | 29 | 11 | bullet (d) says "any of the conditions may be met". Does this mean that in the example that follows, that if the conditions on SignalAttributes Data are met, but not the attributes on SignalAttributes Clock, that the test passes? | No | It is not an OR, but rather a logical combination of the checks for EACH block that needs to be performed. This statement needs to be reworded | DONE | oct 20 - see item 120 | |||||
| MASTON, GREGORY | Editorial | 29 | 11 | bullet (b), "for all intent and purpose" is wordy | No | remove "that for all intent and purpose" | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Editorial | 29 | 11 | bullet (a), the Note is confusing because it doesn't identify what it pertains to. | No | Try: "(Note: optional statements are identified by parenthesis under the syntax definitions.)" | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Editorial | 29 | 11 | last sentence second paragraph I think cites the wrong reference | No | Change last sentence to "See clause 7.5 for information about block sharing&" | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 29 | 11 | last sentence first paragraph identifies a key piece of processing functionality that requires elaboration/clarification. The term "to choose" is too weak here. | No | Replace the last sentence with: "When a TRC file contains multiple TRC blocks, the application processing that file may process all blocks present or specify which blocks to apply, depending on the application." | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 29 | 10.1 | end of section, options (b) and (c): why not just use the definition of a STIL username as defined in dot0? | No | replace (b) and (c) with: (b) STIL user-defined name (STIL.0 clause 6.8). | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 27 | 9.1 | last word on (2) and (3) is "engr unit". This term is not defined | No | Either define "engr unit" or change wording to something like "constant expression", might need to reference dot1 here for completeness. | DONE | oct 20 - changed - reference made to dot1, clause 5.7 and 5.9 | |||||
| MASTON, GREGORY | Technical | 27 | 9.1 | third sentence on Assert - "the application is expected to report an error". This is actually a REQUIREMENT of this standard, not an expectation. | No | Change "the application shall report this failure to satisfy this statement". Remove the next sentence starting with "If the result is TRUE" -- we don't care and should not constrain an application from returning information about non-violated asserts if it so chooses. | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Editorial | 27 | 9.1 | first sentence on Assert - "result - TRUE". The "-" makes this look like "not TRUE" | No | Remove the dash, change wording. Lets start the whole sentence over again. "The Assert statement contains a boolean expression that is expected to be TRUE in order for the rules checking to pass successfully." | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Editorial | 27 | 9.1 | first sentence on Assert - "that when executed is expected" is wordy. | No | Remove "when executed", redundant. | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Editorial | 27 | 9 | last paragraph "Assert statement is a tool that allows for the" is wordy and vague. | No | Try "the Assert statement (defined below) allows for the &" | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Editorial | 27 | 9 | paragraph at top of page&. Another reference to the infamous clause B | No | Change clause B to something appropriate.. Is this supposed to be Annex B??? There are multiple occurrences of this situation. | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 26 | 9 | definition of "fluid constraints" as "defines sets of things may be varied or adjusted" is not really accurate. Variables, by definition, are variable, and fit in this definition. But the notion of fluidity is that there is a SET AMOUNT of some resource that may be shared or allocated between multiple uses. It's fluid because there is a set amount and you can't overshare that amount (the amount is not expandable or compressible ... like a fluid...) | No | Reword the definition of fluid constraints. Try" fluid constraints are used in this standard to define how a set amount of a resource may be allocated or shared between multiple uses of that resource. Each use may require different amounts of that resource, and there is an identified limit to the amount of that resource available." | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 26 | 8 | EXT_NAME in point (2) is not present in the syntax | No | Eliminate the term "ext_name" here and change to be TRC, change wording in (2) appropriately. | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 26 | 8 | Definition of EXT_VERSION needs to change to be "2006" and parenthetical sentence removed | No | Change EXT_VERSION to be 2006 and eliminate parenthetical sentence | DONE | oct 20 - changed | |||||
| MASTON, GREGORY | Technical | 25 | 7.5 | Example (e) is not a rule and will cause usage problems | No | Eliminate the "choice" here - if both named blocks are referenced, then why are they not merged together and both used? | DONE | oct 20 - this subclause (7.5) has been removed | |||||
| MASTON, GREGORY | Technical | 25 | 7.5 | Example (a) indicates that in the named TRC block, both SignalAttribute blocks from the unnamed TRC block are applied.. However example (b) indicates that if there are additional named SignalAttribute blocks in the named TRC block, these blocks are merged to the unnamed blocks on a conditional basis. This is inconsistent. | No | If rule (a) is applied uniformly, all blocks whether named or unnamed from an unnamed TRC block will be applied to all other named TRC blocks and merged across all blocks of the same type uniformly and not based on names. The alternate solution is to merge only unnamed blocks from the unnamed TRC section uniformly, and require a mechanism to reference named blocks form the unnamed TRC block if those attributes are also to be merged. | DONE | sep 29 - similar issues: 49-GR, 77-JC, 118-GM, 119-GM, 137-GM, 138-GM | |||||
| MASTON, GREGORY | Technical | 24 | 7.5 | first paragraph, second sentence "It may contain global (unnamed) blocks". The plural "blocks" implies to me that there may be multiple of the same type of unnamed block, which I do not believe is supported. | No | Clarify reference - "It may contain an unnamed instance of a block used to define global information." | DONE | sep 29 - similar issues: 49-GR, 77-JC, 118-GM, 119-GM, 137-GM, 138-GM | |||||
| MASTON, GREGORY | General | several references are made to IEEE Std 1450-1450-1999, or 1450-1999, *and* to the defined reference STIL.0 | No | Replace all occurrences of 1450-1999 and other forms with "STIL.0" | DONE | oct 20 - changed | |||||||
| MASTON, GREGORY | Editorial | 22 | 7 | Table 3 identifies new terms "Constraint", "Report", Target" and "Load", which appear to map to the prior references of Flow (1) - (4). In the footnote section it would be nice to correlate these new terms with the prior flows, or identify how they do not match. | No | Add info to the terminology footnotes on table 3, to relate back to the flows, and/or rename the flows using these terms in the earlier part of the document, for consistent referencing. | DONE | oct 28 - Table 3 is just a list of keywords used throughout dot3. - References have been added in Annex A, glossary - constraint, tester targeting, usage model. - Note that Table 3 has moved to clause 6 and is now Table 2 |
|||||
| MASTON, GREGORY | Editorial | 14 | 5.3 | first paragraph, last word is redundant | No | Try: "...Annex E of IEEE Std. 1450-1999." (remove "standard") | DONE | oct 28 - changed | |||||
| MASTON, GREGORY | Technical | 11 | 5.2 | STIL code fragment contains "STIL 1.0 { Design 2005; TRC D12; }" TRC D12 is incorrect | No | Change all occurrences of "TRC D12" (or any other draft reference) to TRC 2006; | NO-CHG | oct 28 - this is a variable that will be changed to the "official" wording when the final editing is done after ballot. Note the the same variable also appears on page 1 (immediately after the title) and on the top of every page. - BTW, it is D14 in the ballot draft. Are you reviewing an earlier draft? |
|||||
| MASTON, GREGORY | Editorial | 10 | 5.1 | Note3 says "If according"& (twice) | No | Try "If applied according"& | DONE | oct 28 - changed | |||||
| MASTON, GREGORY | Editorial | 10 | 5.1 | Note2 says "output compare can be Compare& | No | Try: Supported Output measure operations are identified to be Compare& | DONE | oct 28 - changed | |||||
| MASTON, GREGORY | Editorial | 10 | 5.1 | Note1 contains the phrase "calls out", which is somewhat idiomatic | No | replace all occurrences of "calls out" with "identifies" | DONE | oct 28 - changed | |||||
| MASTON, GREGORY | Editorial | 9 | 5.1 | Remove quotes around "simple" in the clause title | No | same | DONE | oct 28 - changed | |||||
| MASTON, GREGORY | General | All STIL fragments contain a source comment that needs to be modified for the final version of the doc | No | Revise the Source annotation to indicate IEEE Std 1450.3, no draft number, and remove the date. | NO-CHG | oct 28 - see item 142 | |||||||
| MASTON, GREGORY | Editorial | 9 | 5 | The first paragraph introduces the different flow, and different effects on STIL files. But it doesn't identify WHY this is being stated here. | No | Add another paragraph here, and identify of the following clauses what flows are being supported. Try: Clause 5.1 and 5.2 represent standalone TRC files usable for flows (3) and (4), clause 5.3 presents a pattern report generated for flows (2) and (4), and clause 5.4 represents test resource identification per flows (2) and (4). | DONE | oct 28 - changed - The turorial has now been moved to the Annex and each has an intro that defines the purpose and references the flow in fig 1. |
|||||
| MASTON, GREGORY | Editorial | 9 | 5 | First paragraph, sentence starts "The (2) and (4)&" is confusing | No | Try: "Flows (2) and (4) result in data resident in the corresponding STIL file while flows (1) and (3) identify usage models that rely on separate STIL files to contain the TRC information." | DONE | oct 28 - see item 148 | |||||
| MASTON, GREGORY | Editorial | 9 | 4.3 | First and third bullets reference "clause B", 5th bullet references "clause C". Clauses are numbered; what is the reference here? | No | Correct clause references | DONE | oct 28 - changed | |||||
| MASTON, GREGORY | Technical | 7 | 1.3 | The reference to the 80/20 rule - the interpretation of this rule "this standard provides 80% of the TRC info by defining 20% of the rules" is not standard. Normally 80/20 refers to a total of 100% of something - that the amount of effort it takes to define 80% of the issues is equivalent to the amount of effort necessary to define the remaining 20%. | No | I think what is being stated here is that this standard is intended to address 80% of the issues involved with TRC operations, because the effort to address the remaining 20% is too complex and would make the standard unwieldy to apply in general. | DONE | oct 28 - changed wording as proposed | |||||
| MASTON, GREGORY | Editorial | 5 | 1 | First 2 sentences in overview are stilted | No | Try: The STIL Environment supports transferring tester independent test programs to a specific ATE system. While native STIL data is tester independent, the actual process of mapping the test program onto tester resources may be critical, and it is important to be able to completely and unambiguously specify how the STIL programs and patterns are mapped onto the tester resources. | DONE | oct 28 - changed wording as proposed | |||||
| MASTON, GREGORY | General | 2 | "code used for edits to this doc" and table 1 need to be removed | No | remove these two | DONE | oct 28 - changed - Note I think you may have been reviewing an earlier draft. It is gone in D14. | ||||||
| SAYOGO, BARTIEN | General | The title should be revised: IEEE Std for Standard Test Interfase Language (STIL) - Part 3: Tester Target Specification. In 3.1 Definitions: The text should be revised: STIL.3 Refers to IEEE Std. 1450.3 (i.e this standard). The extention of the STIL base standard is commonly referred to as "dot 3": Tester target specification. (Note: For STIL.1, STIL.2 etc. the title should follow as above). |
No | DONE | oct 28 - - The title has been changed per instruction from IEEE editors - changes made to the definitions in 3.1 |
||||||||
| MICEK, TOM | General | In review Tom Micek Freescale |
No | NO-CHG |
| INSTRUCTIONS: Use this form to enter your comments. When complete, save the file on your hard drive and upload the file into the comment submission area. Category - This field is optional but if you leave blank, the system will automatically populate with General. If you enter Technical or Editorial, spell out completely or the upload will be invalidated. Page/Sub-clause/Line Number - These fields are optional. Any data entered must be integers only. No alpha characters or symbols -- doing so will result in an error and the upload will be invalidated. If you wish to reference multiple pages, provide the details in the comment field. Comment/Proposed Change - These fields are required. Enter your comment and proposed change in these fields, respectively. Use plain text characters only. If you use any characters entered with "Crtl" or "Alt" keys; or if you use symbols of any kind, if will result in an error and the upload will be invalidated. Must be Satisfied? - This field is required. Enter Yes or No and spell out completely or the upload will be invalidated. If you have already voted Negative (Disapprove), the data will be associated with your Negative (Disapprove) vote. This categorization is used to differentiate those comments submitted as part of your Negative (Disapprove) vote from other comments that you may wish to submit. Only those comments that have a "Yes" in the "Must be Satisfied" box will be considered as part of your negative vote. If you have already voted Affirmative (Approve), the Must Be Satisfied data will not be used by the system. If you have not yet voted, the data will be stored by the system until you submit a vote. |
||||||||
| Category | Page | Sub-clause | Line # | Comment | Resolution Status | Resolution Detail (last updated - oct 28, 2006) | ||
| Technical | 46 | 16. TRC – WaveformDescription 16.1 TRC – WaveformDescription –syntax (10) Shape |
29 | 1. Problem that the specification to define the minimum edge cycle in a multiple cycle is missed • Problem and Request For input and output waveforms, the D14 specification allows to describe the constraints of the edge intervals for the waveforms defined by Waveforms (the sample description showed in Subclause 5.2 in p.10); however, for the waveform used to run a Vector pattern, the specification to describe the constraint of the intervals of the drive edges (including the case of strobe edges) between the previous Vector pattern and next Vector pattern is not found. It should be added in the specification. |
DONE | oct 28 - see ballot comment #65 | ||
| Technical | 39 | 15. TRC – WaveformAttributes 15.1 TRC – WaveformAttibutes –syntax |
2. Problem of missing the specification to define whether user can use waveforms on-the-fly by the tester constraints • Problem and Request The specification to define whether user can use the waveforms on-the-fly as the tester constraint is necessary. When verifying whether the test pattern can be used in STIL by a tester or not, in case that a waveform is executed on-the-fly in a pattern, sometimes it cannot be used because of the tester’s constraint, the statement to indicate whether a tester has such constraint should be added. Also, if a tester allows using waveforms on-the-fly, some testers have constraints on the types of waveforms available after switching. Therefore, the specification to define the combination of the waveform type should also be added. |
NO-CHG | oct 28 - No change required. See ballot comment #64 |
|||
| Technical | 48 | 17. TRC – PatternAttributes 17.1 TRC – PatternAttributes –syntax (6) LoopAttributes |
3. Problem of missing specification to define constraints of number of nests and pattern steps in Procedure • Problem and Request PatternAttributes block has a specification to describe the constraints of number of Loop block nests and pattern steps, but there is no statement to define the constraints of number of Procedure block nests and pattern steps. Testers have constraints for running patterns of Procedure block; therefore, at least a statement to define constraints of number of nests and maximum steps is required, and should be added to the specification. |
NO-CHG | oct 28 - No change required. To specify the max nest for a procedure: InstructionAttributes Call { LoopAttributes { MaxLength 100; MaxNest 5; } } |
|||
| Technical | 39 | 15. TRC – WaveformAttributes 15.1 TRC – WaveformAttibutes –syntax |
4. Problem of missing the specification to define the constraints of units (prefixes) that can be used by testers • Problem and Request Some testers have constraints for prefix of unit time that can be used. That is the constraint that the time can be specified in “ns” but not in “ps”. For example, it can be specified as in 0.1ns, but not as in 100ps. Even if some testers have constraints to refrain from using ps time unit, it shall meet the constraint if the test pattern converts the ps notation to ns notation in the Timing description and fulfills the time range supported by the tester. Therefore, if a specification to define the prefix of the unit time to be used is provided, it will identify clearly whether the testers with constraints need to convert the time value in advance in order to handle the STIL. It should be added to the specification. |
DONE | oct 28 - added new statemement to define allowed units - TRC -> Units - see item 62 of main comments |
|||
| Technical | 47 | 17. TRC – PatternAttributes 17.1 TRC – PatternAttributes –syntax |
5. Problem of missing specification to define the constraint of instruction memory • Problem and Request There is the specification for defining the number of maximum steps (which can be specified by MaxVectors statement in PatternAttributes block) and the maximum value of scan memory (which can be specified by MaxScanMemory statement in SignalAttributes block); however, there is no statement to define the maximum value for the instruction memory. I suppose this definition is critical for the tester constraint. Therefore, it should be added to the specification. |
NO-CHG | oct 30 - No change required If the ATE has a separate "instruction memory" then a separate PatternAttributes block should be defined for that memory. See TRC -> Module -> PatternAttributes and SignalAttributes -> PatternAttributes for references to multiple blocks. |
|||
| Technical | 39 | 15. TRC – WaveformAttributes 15.1 TRC – WaveformAttibutes –syntax |
6. The specification to define the limit of test cycle for multiclock is missing • Problem and Request The testers can use multiclock as the waveform type. When using the multiclock waveform, its cycles making one clock must require the minimum cycle constraint, but there is no specification to define it. As for the method of timing definition using multiclock waveform in Waveforms blocks, it can check each minimum cycle constraint for multiclock waveform because it can determine the quantities of cycles making a multiclock by the NumberShapes statement in the WaveformDescription block. However, the specification is not provided for the case not using SubWaveform block but multiclock waveform is defined in Waveforms block. It should be added. |
DONE | oct 30 - Changed - Changed ReplicateSubWaveforms to SubwaverormIteration - Added SubwaveformDuration - If multiclock is done with a regular waveform definition, then see the added examples of time-expr rules in WaveformDescriptions -> Shape |
|||
| Technical | 33 | 12. TRC – SignalAttributes 12.1 TRC – SignalAttibutes –syntax |
7. The specification to define the constraints defining number of clock pins is missing • Problem and Request Some testers have constraints for number of clock pins to be used. There should be the specification not only for the constraints of clock pins but also for scan pins (for example, the constraint that limits the waveform types available and availability of bi-directional pins). In D10 specification, it could define each pin type (such as clock and scan) in the SignalAttributes block; however, it is deleted from the syntax in D14, and there is no way to describe it now. Also, it says “selected from the following list:” in the section describing (3) SignalAttributes statement on page 33, but the list is missed from the specification. Please make sure that the pin type description that was available in D10 is still available. Also, the specification for pin type designation is necessary. |
DONE | oct 30 - Several changes made to address this issue. See following in the ballot comment: 49-GR, 77-JC, 118-GM, 119-GM, 137-GM, 138-GM | |||
| Technical | 49-55 | 17. TRC – PatternAttributes 17.1 TRC – PatternAttibutes –syntax (8) Macro, (18) ProcedureCalls |
8. Discrepancy between Macro and ProceduresCalls in PatternAttributes • Problem 1 and Request In case “No” is selected for Macro and ProcedureCalls statements defined in PatternAttributes block, and if either Macro or Call is defined for InstructionAttributes statement in the same PatternAttributes block, the interpretation of the test patterns for Macro and Call becomes unclear, whether they are to be supported or not. Also, if “Yes” or “WithParameters” is selected, and if Macro or Call is not defined by the InstructionAttributes statement, its interpretation also becomes unclear. The specification should have additional explanation for such cases. • Problem 2 and Request Macro and ProcedureCall statements have the default value, “WithParameters” among the options, but it is not allowed to describe Macro statement as “Macro;”, so, it must have one of the values, and therefore the default value never occurs to be applied; however, it is explained that its default value is “WithParameters”. The same thing can be said for ProcedureCalls statement. It is not allowed to describe as “ProcedureCalls;”. The problem is, according to the descriptions in this specification, it can be interpreted as “Macro WithParameters;” when Macro statement is not described. It should specify more clearly whether it is a misdescription of the syntax, or the default value does not exist, or it should be handled as the interpretation described in the previous lines. |
DONE | oct 30 - Changed - Moved the WithParameters statements inside the InstructionAttributes block - therefore, only one way to enable a Macro or Proc. - The default values apply when the statement is omitted. Actually, this becomes "no checking" and therefor macro/proc with parameters would be allowed. |
|||
| Editorial | 11 | 5. TRC orientation and capabilities tutorial 5.2 TRC used to define waveforms and timing |
9. The problem of the sample description in Subclause 5.2 that is not described in accordance with the syntax 79: In INTVC { // two cycle double pulse 80: Shape { 81: U/D/P; 82: (@@>=@1+10ns) D; 83: (@@>=@2+10ns && @@<@1+32ns) U/D; 84: (@@>=@3+10ns && @@<@2+25ns) D; 85: } 86: } • Problem and Request In the sample description of the STIL above, it says “In INTVC” in line 79; however, the syntax for WaveformDescriptions block states “WFNAME”, and the syntax does not allow describing “In”. I suppose the sample description in the Tutorial is wrong, but I request to modify the sample description in order to make clear that the syntax is correct. waveform_descriptions_block = WaveformDescriptions (WAV_DESC_NAME) (< Rule | Explicit >) { (1) WFNAME { (2) ( NumberData integer_expr ; ) (3) ( NumberIO integer_expr ; ) (4) ( NumberMask integer_expr ; ) (5) ( NumberPeriods integer_expr;) (6) ( NumberShapes integer_expr ; ) (7) ( NumberSignals integer_expr;) (8) ( NumberTimeSets integer_expr ; ) (9) Shape { (10) ( (TRC_LABEL:) ( time_expr ) < EVENT | EVENT_LIST> ;)* } // end Shape })* // end WFNAME } // end WaveformDescriptions |
DONE | oct 30 - Changed The example has been corrected to agree with the syntax definitions. Note that this example is now in annex E. |
|||
| Technical | 36 | 13.TRC - DCResourceAttributes 13.1 TRC - DCResourceAttributes - Syntax |
10. Problem of missing the specification to define constraints for DCSequence • Problem and Request Describing DCSequence is allowed by IEEE Std 145 0 .2-2002. However, the corresponding IEEE1450.3 TRC descriptions do not exist. I think it is necessary to have the specification to describe constraints for the descriptions already allowed to describe clearly by STIL. |
DONE | nov 3 - changes made to DCSequence block - 1. PerPinAttributes - changed from a statement to a block which defines the rules for like pin types 2. DCSequenceAttributes - a new block type added to define the allowed sequencing of each pin type 3. Shape - a new block type to define the actions and timing allowed for each pin type. |
|||
| Technical | 36 | 13.TRC - DCResourceAttributes 13.1 TRC - DCResourceAttributes - Syntax |
11. Problem of missing the specification to defile resolution and accuracy for DCResource • Problem and Request The descriptions to define constraints for resolution and accuracy for Timing are specified. However, the descriptions to define resolution and accuracy for VForce and IForce of DCResource (Supply, PMU, etc) are not specified. I think it is necessary to have specification for set of constraints for DCLevels as well as those for Timing. |
DONE | nov 3 - see previous item for details | |||
| General | - | - | 12. Question regarding the specification to define constraints with cnosiderations for tester hardware specification • Problem and Request I assume that the basic items of the constraints for the hardware specification that can be commonly interpreted on general testers can be described as the tester constraints by IEEE1450.3. However, I also assume that all of the tester specific hardware specification for each of the tester makers can not be fully described as the tester constraints. Considering these assumptions, I can not understand very well how much IEEE1450.3 is supposed to define the constraints that are closely associated with the tester hardware specification (such as the measurement range of voltage, ALPG patterns, DFM memories, method of pin multiplex test, etc). As for a simple example, D14 has the syntax regarding to DFM, but there is no syntax for measurement range (e.g., 80mA Range, 800mA Range, etc) How much do you assume the standardized STIL should cover to express the tester specific specification? Or, do you assume that the "STIL to test program" conversion makers would describe the expressions or syntax that are not presented in the specification on thieir own by using PragmaBlocks and so on? Please let me know your basic idea if it is possible. |
NO-CHG | nov 3 - no change to doc 1. See subclause 1.3 for a general statement as to the completeness of this set of tester rules. 2. There certainly will be resources in a tester for VMeas, Imeas, Tmeas, etc. The decision by earlier working groups (dot1, dot2) has been that the measurement process should be defined by means of a test-method (see dot4). When such test-methods are defined, they also need to define the hardware resources and the TRC checks to be done on those resources. |
|||
| General | - | - | 13. Question regarding the tester resource mapping considering the tester hardware specification • Problem and Request It is almost the same contents as of #12 above, however, it is a question from the view point of the tester resource mapping required when converting from STIL to test programs. As for the hardware specification that can be commonly interpretted as for general testers, I assume that the basic items such as Timing and DCResource can be converted from the descriptions in IEEE1450.0/1/2/3 into test programs. However, I also assume that it is difficult to describe for the conversion considering all of the hardware specification for each tester maker as in the STIL common language. Considering these assumptions, I can not understand very well how much IEEE1450.3 or 4 or 5 is supposed to define the constraints that are closely associated with the tester hardware specification (such as the measurement range of voltage, ALPG patterns, DFM memories, method of pin multiplex test, etc). Do you assume that the "STIL to test program" conversion makers would describe the expressions or syntax that are not presented in the specification on thieir own by using PragmaBlocks and so on? There is no concrete example of conversion to be referenced in the specification. I would like you to provide a concrete example of STIL to test program conversion and the principle ideas if it is possible. |
NO-CHG | nov 3 - see previous item for details | |||
no reviews yet
Please Login to review.
