Phone Conference P1450.1 Working Doc Subgroup Thurs Feb 28, 10:00 am PST --------------------------------------------- Attendees: ---------- Jim Teisher Tony Taylor Greg Maston Doug Sprague Agenda ------ - Discuss dot0 clarification doc as distributed by Greg, with comments received from Doug Sprague from an internal IBM review and attached at end of these minutes. Issues ------ Greg took AI[1] to put files on web. Clarification to dot-zero review -------------------------------- Cover - This issue exists on hardcopy versions only; PDF does not have cover. Add explicit reference to 'hardcopy only'. Change made. Clause 6.3 - Reserved words. Break Table 2 paragraph into correct Clause reference. Change made. Clause 7, second paragraph --- Intent - allow either brace or semicolon-formatted version of all statements. Some discussion about this. Tony recommended some additional words for this second paragraph to provide justification for this clarification. Change made. clause 10 - wording change from 'STIL format' to 'files that start with a STIL statement' has been made. clause 15.3 - last statement about two attributes that can be 'defined only once'. Greg took AI[2] to send the location of this limitation in the current dot-1 spec to Working Group members. clause 15.5 - changed wording. Recommendation section - request to add wording to this section to indicate that this info is additional and 'not normative'. Done. Greg took [AI3] to compete these changes and redistribute the clarification doc. New Issues ----------- Specification/support for an 'unspecified' state ------------------------------------------------ Doug has an Issue with the current set of events defines. Perspective: during scan operations want to specify a value that doesn't matter, a force-dont-care state. Tony identified that the 'N' event was intended to provide this function; it identifies a "force" and you don't-care (because you don't-know) whether it's up or down. Tony has an additional recommended usage or clarification on unresolved events: These events don't appear at the tester. The 'N' state in particular would be mapped to either a 0 or 1. However, it's not an ERROR if the 'N' state appears/remains late in the flow, because it's really an indication that there's an option to the resolution of this value, whatever's easiest to do at the end. Tony take AI[4] to provide wording for this. Double-quotes in STIL strings ----------------------------- Tony raised the issue that an environment may want to be able to define a string like "abc"def". Presented one mechanism to support this, which would be to define the usage convention: "abc".""."def", where the null-length double-quoted string implies the presence of a single-quote. This was seen to be too subtle, and a following proposal was to define a explicit special string that is inserted with dot-concatentation operations, for example: "abc"."_DOUBLEQUOTE_"."def" This was not fully accepted by the Working Group as an acceptable solution either, and the Working Group decided to continue with the following statement: It is recognized that a deficiency of STIL is incorporating double quotes in strings; it is illegal to have double quotes in STIL. --------------------------------------------------- Next Meeting ------------ in two weeks; Mar 14, 2002. AIs --- [AI1] Greg - owe website updates [AI2] Greg - distribute ref of Termination and DefaultState attrs to WG. [AI3] Greg - Update clarification doc per changes above and redistribute. [AI4] Tony - add wording to indicate intent of 'N' state as 'dont-care' ------------------------------ Clarification Requests to the Dot-zero Clarification Doc from Doug Sprague: Subject: Re: 1450-1999 Clarifications Document Date: Tue, 26 Feb 2002 15:49:56 -0500 From: "Douglas Sprague" To: "Greg Maston" CC: "Douglas E. Sprague" , "Gregg Wilder" , "Jason Doege" , "Jim Teisher" , "Peter Wohl" , "Rohit Kapur" , "Tony Taylor" Greg, Sorry for not getting back with you sooner on this. I've passed the 1450-1999 clarifications document by a few active STIL users here inside IBM and got some feedback on it. Some of them have probably not seen earlier versions of the document so all this is pretty much new to them and I think they raised some good points. Some minor and some not so minor. #1 - Cover: Not sure why this is needed as all our 1450-1999 documents (electronic form...PDF) say "Standard Test Interface"? #2 - Clause 6.3: The last sentence in this clarification should be attributed to Clause 6.4 seeing that Table 2 is in 6.4 and not 6.3 #3 - Clause 7: There is confusion and concern regarding the second part of this clarification. The confusion could probably be cleared up by showing an example of the STIL statement with both formats...maybe. Also, when "statement" is used in this context, is it referring to only top-level statement blocks (like STIL, Signals, SignalGroups, Timings,...) or is it also including simple statements (like ScanIn, Termination, Period,...). If I understand things correctly, it's the latter, and if this is so then there is concern that this will impose significant complexity and modification to existing parsers to allow "{...}" constructs in all places within STIL where today only ";" is allowed. I think this clarification really pushes the envelope of what is a clarification to the spec and what is a modification to the spec. I recall some discussion about this at the meeting where this was decided upon but it seems we are potentially going beyond what was the original intent of the spec with this clarification. I understand the need for this with the new STIL statement syntax that we want but is there a way we can modify just that statement and not burden all statements. Of course if we were to just make this clarification be for the top-level STIL statements (and maybe that is what this clarification is trying to do) then that may be the best solution. And if that is the case, then I believe the STIL itself is the only one that does not have the block syntax and that's easier to swallow. #4 - Clause 10: Some confusing about the phrase "in STIL format" used in this clarification. Following is a suggestion for a less ambiguous sentence...I think. Only STIL files (files beginning with a STIL statement) can be referenced with the Include statement. #5 - Clause 15.3: The last sentence in this clarification seems to impose a new restriction on using Termination and DefaultState for signals and signalgroups. Does this imply that if I have a signal with Termination specified and I have a need to include that signal in a group then the group I include it into cannot have Termination specified? If this is the case, why not allow this and let the group definition for Termination win? #6 - Clause 15.5: In rule 1, the first sentence, as suggestion to change "Resolution occurs when that ..." to "Resolution occurs when a ...". Also, in the second sentence in that rule, a suggestion to change the first instance of "SignalGroups" to actually be singular "SignalGroup". #7 - Recommendations: It's not obvious where these go in the document. Should there be a separate clause or appendix or should these go inline at the associated clauses in the document? For instance, if/when the 1450-1999 were to go for reballot, where would these recommendation go? I guess maybe related to how these recommendations are being handled in 1450.1, then they would be in a separate "Recommended Usage" document. Regards, Doug ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Doug Sprague -- Software Engineer -- TDS Systems -- VLSI Test Eng. Tie Line: 474-9975 Ext Line: (207) 664-0806 dsprague@us.ibm.com