Phone Conference P1450.1 Working Doc Subgroup Thurs May 24, 10:00 am PST --------------------------------------------- Attendees: ---------- Doug Sprague Greg Maston Peter Wohl Tony Taylor Agenda ------ Agreed to by consensus: 1) Doug's BreakPoint email, enclosed at end of these minutes. 2) Review of p1450.1 doc. Documents discussed: -------------------- [1] Doug's email on the BreakPoint { AfterUnMerge; } [2] p1450.1 proposal, dated May 22, 2001, distributed by Greg. Doug's BreakPoint issue ----------------------- Doug, Greg and Peter discussed Doug's BreakPoint proposal (Tony joined late due to conflicting meeting). Concern was raised about both the subtitlies of the un-merging operation AND the need for the originator of the STIL patterns to provide this data anyway. Peter talked through an alternate proposal that allows the BreakPoint to be presented even in a merged-data from the pattern perspective. Greg volunteered AI[1] to provide an example of the concept for consideration, to allow a level of support of this issue without additional language constructs. P1450.1 Spec ------------ Some minor points were discussed in the last p1450.1 spec: Tony asked about support for "integer_expressions". Greg replied that currently, most expression types are lumped in the spec under the single type "logical_expr" or "wfc_expr". Discussed options for additional expression types, if needed. They should have a section in clause 5 and a definition in Annex A if they are generally occuring constructs. Doug raised a concern in section 5.5, about the C-style user errors around the use of "=" and "==", and errors such as "If 'a=5' {}". Group responded that this problem already exists in the current spec, and it's not easy to correct IF we are following C-style notation (which we are using if we are using Verilog meaning of operators). Peter raised a concern with the ScanStructures Inherit construct. When cells get inherited, the state-element names need to be prefixed with the inst_name as well. Greg took AI[2] to correct this. In this section it was also identified that the "pat_expr" needs to be modified to "logical_expr" - Greg AI[3]. During this discussion, a question was raised: Can the "pat_expr" (soon to be "logical_expr") contains cellrefs? Currently the "logical_expr" does not define cellref_exprs in it, so currently they are not allowed here. There is motivation to allow them (and possibly the state-element names as well) in these expressions, AND if this change is made then we need to consider how these expressions need to be changed to support the inherit process as well. THIS IS AN OPEN QUESTION AT THIS POINT. Open Issues ----------- Doug wants review of the parameter passing not-quite-clarifying statement for next meeting (or next meeting he attends). Original proposal is pasted at the bottom of these minutes for review. Doug has identified a context where a particular STIL generator is missing signal states at start of procedure. The issue was briefly discussed as needing to provide an initial "C" statement as the first statement of the procedures. Next Steps ---------- After the minor additions to the document identified in the AI's, Greg will turn the document over to Tony, particularly for review of expression notation. The group decided to have another meeting NEXT THURSDAY, May 31, to do a bit more thorough walk-through of all the issues in the doc. Doug indicated lack of availability for this week but the remaining 3 thought it would be good to have this time.... well, maybe Greg was just vociferous about the opportunity... Meeting was adjourned at 11:30 PST. AIs ---------- AI[1] Greg - do example of BreakPoints using alternate-procedure-bodies AI[2] Greg - add note in state-element references to identify name change in Inherit contexts in ScanStructures. AI[3] Greg - change pat_expr to logical_expr in ScanStructures. AI[4] Greg - find parameter clarification email and attach here for next week review. --------------------------------------------------------- --------- Doug's BreakPoint { AfterUnmerge; } Proposal -- Subject: New Issue -- Breakpoint Statement for Merged Scan Patterns Date: Thu, 24 May 2001 07:25:26 -0400 From: "Douglas Sprague" To: "Greg Maston" , "Tony Taylor" , "Peter Wohl" , "Gregg Wilder" Folks, As a result of some recent emails related to usage of the STIL BreakPoint statement, we have identified a problem with using the BreakPoint statement with merged scan patterns. To explain the problem, let me first describe how BreakPoint would be used for unmerged scan patterns. Consider the example below: Procedures { scan { C { si=\r2 0; so=\r2 X; | Shift { V { si=#; so=#; clk=P; } } } ... Pattern unmerged { ... Call scan { si1=001001; si2=1011; } // load V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { so1=LHLLXXX; so2=XXLHL; } // unload BreakPoint; Call scan { si1=001001; si2=1011; } // load V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { so1=LHLLXXX; so2=XXLHL; } // unload BreakPoint; Call scan { si1=001001; si2=1011; } // load V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { so1=LHLLXXX; so2=XXLHL; } // unload BreakPoint; ... } As you can see above, for scan-based patterns, the breakpoint statement would typically be placed within the patterns between the load and the unload operations. As the spec indicates, the breakpoint statement defines a location in the pattern where the devices is in a stable state. The patterns could be stopped before the breakpoint, and then restarted after the breakpoint, without affecting the test. Greg, as a side note, related to our discussions on having the Breakpoint statements inline with the patterns or buried down in the scan (load) procedure. I think for unmerged patterns, we need to keep it outside the actual procedure/macro because of section 5.5.1 in the 1450.0 spec which indicates one of the conditions required to perform merging would be that we need to reference the "same" procedure/macro by the Call or Macro statements for the load and unload operations. If we buried the breakpoint statement down in the procedure/macro for the load operation then we would have to have a different procedure/macro defined for the unload which would not have a breakpoint statement. Ok...back to the problem. So if we were to merge the pattern above then they would look something like the following: Pattern merged { ... Call scan { si1=001001; si2=1011; } // load V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } BreakPoint; Call scan { si1=001001; si2=1011; // load so1=LHLLXXX; so2=XXLHL; } // unload V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } BreakPoint; Call scan { si1=001001; si2=1011; // load so1=LHLLXXX; so2=XXLHL; } // unload V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } BreakPoint; Call scan { so1=LHLLXXX; so2=XXLHL; } // unload ... } Now the problem comes in with the breakpoint statement in used in these merged scan patterns. The breakpoint statement in this context is not accurate as we cannot break the patterns at these point and stop the test and then start up the test after the breakpoint. Doing so would cause failure of the device for the unload data at the beginning of the patterns after the breakpoint. The breakpoint statement in this context is not totally incorrect seeing that if we were to unmerge the data at breakpoint where we wish to split the patterns then all should be OK. So what I'd like to propose is something of the following flavor be added to the spec to address this issue. This is an important issue for IBM as we do this type of merging and unmerging of scan patterns all the time and in different places based on tester resources as well as the application in which the patterns are applied. I would propose a new statement/keyword could be used for the block form of the breakpoint statement in clause 22.9. I'd suggest a keyword of "AfterUnmerge" could be specified as the first statement (and possibly the only statement) within the block of a breakpoint statement. Breakpoint statements with this keyword would indicate that we are at a breakpoint in the patterns but only after the patterns at this point are unmerged. So an example of what this would look like: BreakPoint { AfterUnmerge; } And the new statement syntax would be: (LABEL:) BreakPoint; (LABEL:) BreakPoint { (AfterUnmerge;) (PATTERN-STATEMENTS)* } I think that if we provide this new facility for specifying this special type of breakpoint which requires unmerging then we need to define the how to unmerge the patterns at the given breakpoint. Here's my first pass at the unmerging process: When a BreakPoint is encountered with the AfterUnmerge statement, then the patterns must be unmerged at that point to create a break in the patterns that keeps the product in a stable state for the subsequent patterns following the BreakPoint statement. Below defines a systematic approach for unmerging the patterns in this scenerio: 1 - The burst of patterns prior to the BreakPoint should be stable and usable asis. 2 - The new burst of patterns to result from breaking the patterns at this BreakPoint statement must be preconditioned by first re-processing all patterns starting just after the last previous BreakPoint statement up to the current BreakPoint statement. 3 - As part of the re-processing all the patterns for this preconditioning (from the previous BreakPoint statement to the current one), all compare or expect events (see clause 18.2) other than CompareUnknown must be suppressed. 4 - Now that new burst of patterns has the proper preconditioning patterns, all patterns following the current BreakPoint are now output asis. This does not necessarily have to be put into the 1450.1 spec but we do need to look at including this somewhere in the new mods to the spec. Maybe in dot3 as Greg has suggested. Just wanted to pass this by the dot1 group and get their take on if/where/how we should include the new facility to handle breakpoints in merged scan patterns. I'm open to any suggestions or other ways to solve this problem I can talk to this more at the meeting later today.. Thanks, Doug ---------------------- Doug Sprague Email: dsprague@us.ibm.com Phone: 207.664.0806 (T/L: 474-9975) --------------------------------------------------------- --- Greg's Attempted Clarification Statement on Parameter Passing Subject: Re: Question #2 for this week -- A possible small glitch in the 1450.0 spec? Date: Fri, 27 Apr 2001 09:40:17 -0600 From: Greg Maston Organization: Synopsys, Inc. To: Douglas Sprague CC: Gregg Wilder , Peter Wohl , Tony Taylor alright Doug, I slept on this question because my brain hurt too... not that I'm in any better place to think about this now... I too find this section very complicated. I pushed for an absolute-name-relationship for parameters but that concept was voted down as too restrictive. Unfortunately, those people who voted it down then didn't define the relaxed-mapping constructs sufficently so I take the blame for most of the words in here... and my brain still hurts... so here goes, we'll see how far we get... My understanding of the parameter resolution process is: (1) all same-name parameters are resolved first. (2) all remaining parameters are matched based on signal-expansion. This is stated in the first bullet on page 113... or at least that was the INTENT of that first bullet... So the INTENT of the statement you are questioning below, is the situation that after doing (1), there are still more-than-one reference to a signal with a % or #, but the only remaining arguments in the call do not name-match this reference. At this point, it is not possible to determine which argument in the call (again, assuming more-than-one argument contains this signal) should be used to resolve which parameter --- unless, of course, we add more rules like "the order of declaration of the arguments resolves the remaining parameters"... which is (a) a terrible rule and (b) just further complicates the mess that exists... To make sure that users did not assume some sort of resolution for multiple-signal-references-without-name-resolution, we defined this bullet. You are correct that there is a problem if we took away the second vector in the example below this bullet, and then called that procedure with too many arguments, none of which name-matched the parameter and multiple of which contained reference to that signal. But that is not the problem that this bullet is addressing; this bullet is addressing ambiguous resolution of multiple references in the body, not too-many-arguments-in-the call. We cannot delineate all the error situations that may occur here, but we can add more bullets if necessary. It is currently not an error to pass more arguments into the call than are needed to resolve the body, and in fact this was seen (when this issue was raised at one of the Working Groups) to be a good thing, and is even stated in the first bullet after this example. But, it should be an error if the same parameter is passed multiple times, too --- ie, fill_ { sig1=100; sig1=100 }; ...(and no, I don't care whether the WFCs are the same or not, really...) I think the core of the issue is that in order to do un-name-matched-resolution, the set of signals in the remaining parameters of the body must be unique (ie, only one reference to a signal) and the set of signals in the remaining arguments of the call must be unique (ie, only one reference to a signal ..uh... that is in the first list [I don't care if a signal is referenced multiple times here if it's not a parameter]). The bullet you reference specifies the first condition. But we do not have a bullet or reference for the second condition, which is the one you are asking about. So here's a potential addition to that bullet (add is the second sentence of this text...): It is an error if the same signal is referenced by multiple sigref_exprs in the invocation of a Procedure or Macro, and multiple references to that signal in the body of a Procedure or Macro rely on component-name-matching. Component-name-matching requires a unique reference to a signal in the body of a Procedure or Macro, and a corresponding unique reference of that signal in the arguments passed in the invocation of that Procedure or Macro (after explicit name arguments have been resolved). Note that this is not an issue if the parameters are resolved by explicit name matching. An example of the error situation is: ... So what's everyone think? should I add this sentence here under the clarifications? (which is probably a different question: does it really clarify?) Douglas Sprague wrote: > > First, of all. Thanks Greg for clearing me up on the last question. As a result I'm re-working our > STIL code for processing Macros/Procedures. > > In the process, I ran across this and just wanted to note it as I think it's a problem with the spec. > As small problem but a problem just the same. > > In clause 24.5 and in the section "Data substitution using the # and % WaveformChars has the following rules:" > > The third hashed bullet says: > > --- It is an error if the same signal is referenced by multiple sigref_exprs in the invocation of a Procedure > or Macro, and MULTIPLE REFERENCES to that signal in the body of a Procedure or Macro RELY on > component-name-matching. Note that this is not an issue if the parameters are resolved by explicit > name matching. .... > > Anyways, the MULTIPLE REFERENCES in all caps above is what I'm questioning. Shouldn't this be > something like A REFERENCE TO as well as RELY should go to RELIES. To me, it seems that if even > a single component-name-matching reference to a signal exists in the body for which there are multiple invocation > references then that's a problem. I guess only a problem if the multiple instances define different WFC > values to be applied. > > For instance, in the example that follows, wouldn't it still be a problem if we took out the second > vector in the proc/macro body and just had "V {sg1=%; }"? We would have conflicting values > of 0 and 1 to be applied to si1. > > It's a subtle thing I know but I figured I raise it now that I happened to be looking at this section in detail > again seeing that I will forget about it in another few weeks. Then again, maybe I'm missing something > here in which case I'm sure you guys will set me straight. > > Your thoughts? > > P.S. Does anyone else's brain hurt when trying to "fully" understand clause 24.5? > It really puts a strain on mine! To say nothing about writing code that will correctly > implement it to a T. > > ---------------------- > Doug Sprague > Email: dsprague@us.ibm.com > Phone: 207.664.0806 (T/L: 474-9975) -- -------------------------------------------------------- Greg Maston (303)748-2584 Fax:(303)321-3549 Synopsys, Inc. 1335 Dexter Street Denver,CO 80220-2456