Phone Conference P1450.1 Working Doc Subgroup Thurs May 31, 10:00 am PDT --------------------------------------------- Attendees: ---------- Greg Maston Peter Wohl Tony Taylor Rohit Kapur This was an off-week meeting from the regularly scheduled every-other-week meetings. The purpose of this meeting is to assure progress on spec issues and to discuss any immediate doc concerns, with the goal of having an updated spec for the next regular meeting. Agenda ------ Agreed to by consensus: 1) Identify current issues with spec and edit directions 2) Discuss InheritScanStructures concept (particularly in CTL context) Documents discussed: -------------------- [1] p1450.1 proposal, dated May 22, 2001, distributed by Greg. [2] ScanStructures emails from Tony and Greg (enclosed below) P1450.1 Discussions ------------------- Tony opened the issues with discussion about "expression" terminology. The current doc uses the term "logical_expr" but not uniformly - "pat_expr" may still be found in the doc, and Tony used additional terms (notably "integer_expr") in other docs (CTL). Greg identified that there are other "restricted expression" contexts, notably boolean expression contexts (If and While statements), and whether these should be separately typed constructs (ie, "bool_expr") or whether the words in the definition where these expressions are used was sufficient. Tony identified that the "cellref_expr" needs to be made more clear as well; currently the reference in section 5.4 indicates expression context as defined for sig_exprs and this is not correct because "+" and "-" are not used for cellrefs. Tony took AI[1] to do a pass on "_expr" terminology, for this document and to get any CTL terminology consistent as well. A discussion (related to the boolean issue) ensued about the terms Pass/Fail. These terms have an opposite sense to True/False (Fail=1=True), but the concept really applies to the TestResult() construct which has been removed from this document. As a result of this discussion: Tony took AI[2] to remove Pass/Fail from this document. Greg tool AI[3] to put TestResult() into the recommended-usage document, as well as defining Pass/Fail here in assoication with this construct. Tony took AI[4] to add line-numbers references to all syntax blocks, as is currently done in the PatternBurst section, to faciliate referencing constructs in these blocks. Greg identified that there are also some empty annexes to hold additional examples that had been postulated, that need to either be added or the annex removed. Tony will review his empty annexes; Rohit was also identified as having his name on one too (to his surprise). InheritScanStructures --------------------- There had been previous email discussion about the ScanChain namespace and it's potential interaction with ScanCells. The emails are enclosed below. The result of this discussion is to leave the namespace constructs as currently defined (using instance references) and not add scanchain names into the scancell space. Tony took AI[5] to change the instance names in the example on page 26 from "core" to "module" or something, to eliminate potential confusion of this construct with CTL definitions. Rohit identified a conflict of the InheritScanStructures "instance" construct with the current CTL CoreInstance constructs, in that the current CTL constructs put the "instance name" in the block's domain name field and allow multiple names on the domain name block to support multiple instances. This allows the hierarchical name reference from other blocks to follow a dotted-domain-name construct. The current InheritScanStructures deviates from this strategy because it requires an instance-name to be defined and follows a dotted-instance-name construct (which is a new naming notation). Greg identified that the use of multiple domain names as instance-specific names was a significant deviation from the original single-domain-name construct, and that by placing lists of instance names at this level would cause editing third-party information every time a core was imported from an external source and instantiated in a design. The current proposal avoids these issues because the instance data is defined under the new design's block (that has to be created anyway), and allows direct reuse of data without changing that data (assuming unique naming constructs). The discussion diverged at this point into CTL-specific issues, which will be followed up in the CTL working group. The CTL changes to be addressed are to: 1) modify the CoreInstance syntax to conform with the ScanStructures syntax described above; 2) allow ScanStructures, BistStructures, Pattern blocks to be included in the CoreInstance block; 3) include in the CoreInstance section of the CTL document how to use the Include and IfNeed statements for blocks that are not always needed to be parsed but are needed to be included; 4) in CTL applications, the core-instance name should be used instead of an inherit-instance name for referencing things like hierarchical scan chains (i.e., xxx.yyy format). Other Issues ------------ Greg mentioned that he had email contact from Gregg Wilder, in which Greg recommended a path to close the P1450.2 review and move the document toward IEEE balloting, but had not had follow-up from Gregg and requested Tony to touch base with Gregg for closure. The next meeting is the regularly-scheduled Thursday meeting next week (June 7). Meeting was adjourned at 11:58 PDT. AIs ---------- AI[1] Tony - do a pass on "_expr" terminology. AI[2] Tony - remove Pass/Fail from this document. AI[3] Greg - put TestResult() and Pass/Fail into the recommended-usage document. AI[4] Tony - add line-numbers references to all syntax blocks AI[5] Tony - change instance names in the example on page 26 from "core" ----------------------------------------------------- Tony's Email on ScanChain-referencing/InheritScanStructures ----------------------------------------------------- Subject: hierarchical scan structures Date: Wed, 30 May 2001 17:20:15 -0700 From: "Tony Taylor" To: gmaston@synopsys.com CC: rkapur@synopsys.com, peterwohl@adelphia.net Greg, I discussed the hierarchical scan solution with Rohit after our phone call today. We are both convinced that the solution that you propose will work and does address the needs of reconfigurable scan chains. I then re-read the 1450-1999 document on ScanStructures. I really don't see that there would be a conflict if we added scan chain names to the cell name domain. The standard does not explicitely say that this cannot be done. If the user wants to reference groups of scan cells along with individual cells, I think that it is logical the the both exist in the same name space, just as signal group name exist with signal names. I put together an example in both styles for your consideration. Peter, I'm copying you on this also to get your opinion. =============================================================== Example using InheritScanStructures: ScanStructures PARTS { ScanChain CH1 { ScanCells A B C; } ScanChain CH2 { ScanCells D E F; } ScanChain CH3 { ScanCells G H I; } } ScanStructures WHOLE { InheritScanStructures PARTS { Instance P; } ScanChain CH123 { ScanCells P.CH1 P.CH2 P.CH3; } ScanChain CH12 { ScanCells P.CH1 P.CH2; } ScanChain CH23 { ScanCells P.CH2 P.CH3; } } =============================================================== Example using merged name space: ScanStructures ALL { ScanChain CH1 { ScanCells A B C; } ScanChain CH2 { ScanCells D E F; } ScanChain CH3 { ScanCells G H I; } ScanChain CH123 { ScanCells CH1 CH2 CH3; } ScanChain CH12 { ScanCells CH1 CH2; } ScanChain CH23 { ScanCells CH2 CH3; } } =============================================================== ----------------------------------------------------- Greg's Email Reply on ScanChain-referencing/InheritScanStructures ----------------------------------------------------- Subject: Re: hierarchical scan structures Date: Wed, 30 May 2001 18:58:18 -0600 From: "Greg Maston" Organization:Synopsys, Inc. To: "Tony Taylor" CC: gmaston@synopsys.COM, rkapur@synopsys.COM, peterwohl@adelphia.net References:1 table 6, pg 66, row 3, identifies the constraints on scanstructures and scanchain names: ScanStructures Scan names and scanchain names - A single ScanStructures block is optionally named. Multiple ScanStructures blocks shall be uniquely named. ScanChain names shall be unique inside a ScanStructures block. Now, by defining that scanchain names are unique inside scanstructures (and not stating something like "across all scanstructures"), indicates that the names do not have to be unique across all scanstructures. They "may" be, BUT THEY DO NOT HAVE TO BE. The problem is that if these names are not required to be unique across ALL scanchains, then it is ambigous if one of these names appear in other contexts (and is meant to refer to some non-unique scanchain someplace else). ...What is missing in this table (which has been pointed out by Doug Sprague) is a definition of the scancell namespace in this table. this should have been here as well... ...so... if you want to reference scanchain names in other contexts (ie, mixed in with other names like scancells), and you want those references to be unambiguous, (1) you need to specify that these names may be found in those other contexts. (2) you need to indicate that these names are unique across all names in those other contexts. (3) and by inference, these names have to be unique across themselves. It's the last point that requires a change to what is currently specified in table 6. If you really want to do this, you change a stated requirement in p1450.0, to a more-restrictive requirement (because to be unambiguous, scanchain names need to be unique not only across all scanchains but also across all scancell names... and that is not in the document today). This change means that a p1450.0-compliant program is not necessarily p1450.1-compliant because of this extra condition. We've been trying NOT to cause these types of situations.