Phone Conference P1450.1 Working Doc Subgroup Thurs Aug 16, 10:00 am PDT --------------------------------------------- Attendees: ---------- Peter Wohl Tony Taylor Greg Maston Jason Doege Agenda ------ Agreed to by consensus: 1) Review Tony's latest p1450.1 [1] Documents discussed: -------------------- [1] p1450.1 proposal draft 0.97, July 31, distributed by Tony. Opening Concerns ---------------- Peter asked about complex scancell issues, and whether the identified issues were completed. Greg indicated that he remembered two issues: one with the Annex example missing some inversions (which have been corrected) and the second issue being a clarification that the scancell entity is a single bit. The clarification doesn't go here but goes up with the scancell definition, and to Greg's recollection this has not been done yet. P1450.1 Discussions (doc [1]) ----------------------------- The document review attempted to proceed linearly, by changed section, but jumped around in several places to provide additional background on the proposed changes. Reviewed 5.7 - integer_expr. New constructs defined by Tony. Group approved these additions, including the expanded integer representations. Reviewed 5.10 - engineering units. Discussion about potential overlapping of units - conflict of a magnitude-character with an engineering-type-character, and an integer-value (with a magnitude-character) with an "engineering-value" (with both a magnitude and a type). The current engineering-types do not conflict with the magnitude-characters, and there should not be a problem distinguishing engineering-terms from integer-terms (no does a distinction need to be made). Reviewed 7.1 - Tony added statements for UserKeywords, UserFunctions, UserParameters, potentially to identify the presence of these sections later in the STIL file. Before discussing these statements, Tony moved us forward to 17.1 (Environment block syntax) to discuss the User field in the Type statement of the FileReference block. Section 17.1 - filetype and fileformat field definitions. Tony indicated that these field definitions are coming from CTL (dot6), and that since the statement is defined here it would be nice to identify the fields here as well. Peter identified a concern that the CTL constructs are more constrained than the general Design constructs, and that these fields, while appropriate to CTL, are not sufficient for the general dot0 context. Greg identified that User option in this statement is yet another way to define User-extensions, specific for a statement, with no value added over existing User behaviors, and with the same problems that an additional statement has: as soon as a User field is placed here, all automation that involves this statement is moot. So why not make the user define a statement with this value instead? Greg and Peter voted to remove these definitions. Back to 7.1 - Peter asked what happens if the block identified UserKeywords and there were no UserKeywords statement here (and vice versa) - what happens? It does not change the behavior of the parser (which still needs to handle this constructs whether or not they were identified), and just complicates the error-handling behavior, with no ultimate user advantage except to make the user correct the statement in the version block. These statements were removed since there was not any useful additional behaviors identified for them. Section 9 - The addition in this section for this release was the "reverse-mapping" behavior, starting with multi-WFCs on the right-hand-side of the WFCMap statement. In order to explain this construct, Tony moved use to Annex I, which is brand-new and presents the usage of these construct. Tony raised a concern about the implied order of the mapped data (first WFCMap position = comparelow, etc). He had three points (some alternatives and some additions) on this concept: 1. Use the order of waveform declaration in a grouped waveform statement to define the Substitute WFCs (removing the WFCMap addition entirely). Greg identified that he does not want to bind waveform constructs to 'S' interpretation; users will need to assemble waveforms from anywhere, and waveforms should not be constrained to common timing (which is an assumption when waveforms are grouped) in order to be used for substitution. 2. put the WFCMap data into the waveform statement that contains the 's', for instance by using a bracketed block in the wave-event statement that has the 's'. Peter identified that the reverse-mapping operation is Signals-oriented and not WFT-based, and is concerned that binding the reverse-mapping at the WFT level is the wrong place. 3. what about a mapping value for 'CompareValid'? Greg identified that there is no mechanism present to distinguish a CompareHi or Low return from a CompareValid, and therefore the only mechanism to return a CompareValid would be in a context where the mapping states were explicitly identified (so the compare-lo and compare-hi values could be undefined and only the CompareValid defined). But in the current definition, the system would return hi or low and not a "valid". No changes were made to the existing proposal after these discussions. Jason asked why define a CompareSubstitute - how is it different than using a Compare to a known value, and returning failures? Peter identified several differences: 1. not requiring a failure semantic to be defined that supports returning this information (allowing existing undefined failure semantics to continue to be employed), 2. 'S' operates as a placeholder/location for where to do the check (allowing the existing failure mechanism to identify other problems in the test), 3. Substitute returns detected value information (1-of-4), which is more information than the typical failure returns (which is "not-the-specified-value") [again, not impacting existing undefined failure mechanism]. Tony identified the WGL Substitute context and WGL characters 'Q' and 'S' - WGL 'S' applies to the input data, and 'Q' is used for output. Peter noted that the WGL notion of "substitute" was not at all related to this construct, being the mechanism WGL uses to identify and associate a 1-or-0 state from the Vector data (STIL uses WFCs for this purpose), and that we should avoid walking any closer to the WGL concept than already happens because we each use the term "substitute" differently. Covered Section 12 - new section on WaveformTables, to define the CompareSubstitute operator previously discussed. New section was accepted without changes. Covered Annex I - accepted at this time with no changes. Covered changes to Annex M - new example M.3 (identified in the last meeting as L.3). Jason was confused by the _1 reference in the last scanchain of this example. So was Rohit Kapur when he reviewed this example. Greg will modify this example to use different names (ie "A" and "B"), hopefully to help identify where these names came from. New Items --------- Doug's issue - Doug provided some information to define a new UserFunction, to be used to control scan-pattern-partitioning during test load operations. Tony indicated that a variable could serve this purpose as well. Greg related that this scenario was previously discussed, and that a key perspective to this behavior was that the partitioning operation was actually occuring dynamically - while the pattern was being read, the partitions were being established by calling this function. Tony will discuss his perspective with Doug. Next document delivery is scheduled for Aug 28, to occur before a conflict that Peter, Greg and Tony all have (next point). Tony, Greg, and Peter all have a conflict on the next regularly-scheduled meeting date of Aug 30. However, in the interest of final prep and approval of this doc for internal review, Tony proposed that the next meeting be scheduled for Friday Aug 31, 2001, same time. Peter will not be available to participate then, however his comments will be carried into the meeting given the next doc delivery date. Tony will confirm if Doug is available for this time. Meeting was adjourned at 11:19 PDT AIs ---------- miscellanious changes as identified above.