Phone Conference P1450.1 Working Doc Subgroup Thurs June 7, 10:00 am PDT --------------------------------------------- Attendees: ---------- Greg Maston Peter Wohl Tony Taylor Jason Doege Agenda ------ Agreed to by consensus: 1) Review selective-BreakPoint-generation notions 2) Review red-text issues in p1450.1 from Greg, to eliminate if agreed. Documents discussed: -------------------- [1] p1450.1 proposal, dated May 22, 2001, distributed by Greg. [2] selective-BreakPoint emails (attached at end) selective-BreakPoint-generation ------------------------------- Following up on a train of emails discussing how to specify BreakPoints in an environment where scan data "has been merged" at generation time, Greg proposed the selection of a BreakPoint-or-merge set of statements based on dynamic evaluation of an If condition (email enclosed at the end of these minutes). Subsequent emails from Doug extended the notion to use a "system variable", which Greg proposed to define as a function instead (to provide a clear evaluation mechanism for the value of that variable/function). Doug took AI[1] to write-up a paragraph on the definition of this function. The discussion continued on this topic, because the current If construct (without an Else) is suboptimal for identifying when two sets of statements are independently selected (the "If (a){} If (!a) {}" environment vs. "If (a){} Else{}"). Doug made a motion to add an Else clause, seconded by Greg and agreed to by consensus. Tony took AI[2] to define the Else construct. Discussion continued down this path to consider an ElseIf clause and a Case construct. These notions were not supported by this Working Group. P1450.1 Discussions ------------------- This round of discussions centered around "red text" fields highlighted by Greg, which indicate requested changes (generally eliminations) that Greg was not comfortable doing without review by the Working Group. pg 10: question about the Period construct, which appears to have been removed but this bullet was left behind. Agreed to remove bullet. pg 10, table 3: Greg raised an issue that Table 3 had been inserted in this document in response to defining/supporting general Verilog operators, but that it's difficult to justify all these operators, particularly as highlighted by Peter, the bit-wise and reduction operators. Discussed whether STIL has the need for both of these. Reviewed the history of why these constructs were all defined here, which is related to CTL needs for operators. Tony took AI[3] to talk to Rohit about how much of this table is necessary from a CTL perspective. Tony will add a footnote/reference to the Verilog standard (IEEE 1364) to minimize our need to redefine these constructs. Doug asked for examples of the operator usages to identify why they are here (for the ones we determine we want to have remain). Tony raised a potentially missing operator here; the test constraints effort often sees the need for exponentiation, which is NOT defined at this time. No motion made on this issue; it was identified that the shift operators can support representation of powers of 2. Next red-text item is the last bullet on pg 10. Greg is extremely concerned that expression processing cannot justify or determine the accuracy of the different units, particularly without incorporating electrical rules (e=ir). Tony is concerned that if we don't do this we need to make a statement about it... so the decision was made to add a paragraph in this section (but not as a bulleted item) to identify this. Tony asked if different operators would apply to different expression types and whether table 3 should identify these. He will look at how to represent this (and what makes sense). section 11.5 - agreed to eliminate the struck-out sentence. Peter identified that the syntax in the BistStructures has been changed: integer_list instead of conn_num_expr; Tony identified that this change has been made in his updated copy. Other Issues ------------ The next meeting is the regularly-scheduled Thursday meeting two weeks (June 21). Meeting was adjourned at 11:08 PDT AIs ---------- AI[1] Doug - define NeedBreakPoint() function (or whatever it gets called) AI[2] Tony - add Else construct to current spec AI[3] Tony (to Rohit) - review table 3 operators to determine if all are required to be supported particularly by CTL. ====================================================== == Greg's Email on the Alternate AfterUnMerge Proposal ====================================================== Subject: optionally building BreakPointed Pattern Sets (alternate concept to AfterUnmerge) Date: Thu, 24 May 2001 17:34:51 -0600 From: Greg Maston Organization: Synopsys, Inc. To: Tony Taylor , "Douglas E. Sprague" , Peter Wohl , Gregg Wilder , "Greg Maston @home" Alternate proposal to replace the BreakPoint AfterUnmerge syntax using current constructs (well, the second example used p1450.1 extensions too): Peter's concept (if I understood it right, otherwise this is another idea), is to define an environment where the pattern data remains in the same format (ie, "merged" meaning the scanout and scanin data is provided in a single Procedure call), BUT to control the body of the Procedure to support BreakPoints. To use Doug's previous example context: ------------------- Procedures merged { scan { C { si=\r2 0; so=\r2 X; } Shift { V { si=#; so=#; clk=P; } } // unload-load in one Shift } } Procedures unmerged { scan { C { si=\r2 0; so=\r2 X; } Shift { V { so=#; clk=P; } } // unload in first Shift BreakPoint; Shift { V { si=#; clk=P; } } // load in second Shift } } Pattern single_call { ... Call scan { si1=001001; si2=1011; } // load V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { si1=001001; si2=1011; // load so1=LHLLXXX; so2=XXLHL; } // unload V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { si1=001001; si2=1011; // load so1=LHLLXXX; so2=XXLHL; } // unload V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { so1=LHLLXXX; so2=XXLHL; } // unload ... } -------------- Now, the selection of the Procedures for this structure would be through the PatternBurst: PatternBurst unmerged { Procedures unmerged; PatList { single_call; } } PatternBurst merged { Procedures merged; PatList { single_call; } } -------------- with this structure, some external process (ie the patternexec) can choose to build a pattern set that contains BreakPoints or not. Now, one issue with this is the current STIL spec specifies the merging process across procedure calls, and with this structure the merging process has to be done across Shift blocks, but it's not difficult to determine if two Shift blocks are mergable or not. -------------- Alternately we could use some p1450.1 Variables to control the selection of unmerged procedure constructs, for instance... I'm making this up as I go... SignalGroups pat_vars { patterncount Integer { InitialValue 0; } } Pattern single_call { ... Call scan { si1=001001; si2=1011; '++patterncount'; } // load V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { si1=001001; si2=1011; // load so1=LHLLXXX; so2=XXLHL; '++patterncount'; } // unload V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { si1=001001; si2=1011; // load so1=LHLLXXX; so2=XXLHL; '++patterncount'; } // unload V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; } Call scan { so1=LHLLXXX; so2=XXLHL; '++patterncount'; } // unload ... } Procedures { scan { C { si=\r2 0; so=\r2 X; } If 'patterncount%8 == 0' { // unmerge every 8th scan operation Shift { V { so=#; clk=P; } } // unload in first Shift BreakPoint; Shift { V { si=#; clk=P; } } // load in second Shift } If 'patterncount%8 != 0' { // otherwse merge scanin and scanout Shift { V { si=#; so=#; clk=P; } } // unload-load in one Shift } } } -- -------------------------------------------------------- Greg Maston (303)748-2584 Fax:(303)321-3549 Synopsys, Inc. 1335 Dexter Street Denver,CO 80220-2456 ====================================================== == Doug's Email Response on this Concept ====================================================== Subject: Re: optionally building BreakPointed Pattern Sets (alternate concept to AfterUnmerge) Date: Wed, 6 Jun 2001 15:16:17 -0400 From: "Douglas Sprague" To: "Greg Maston" CC: "Douglas E. Sprague" , "Greg Maston @home" , "Gregg Wilder" , "Peter Wohl" , "Tony Taylor" Greg, Finally getting around to responding to your proposal. Sorry for the delay. Your 1450.1-based solution is the one I'm interested in. I want to be able to do merged or unmerged on the fly, not globally for a given patternexec. Although providing for merged/unmerged based on the procedures loaded is a neat idea and would be useful. I agree in concept with the approach you outline for the 1450.1 solution but have a couple of issues with it: 1) Instead of using a local "patterncount" variable in the "If" statement I would like to see us agree upon some predefined STIL system variable (maybe defined in the 1450.1 spec) which we could key off for this particular situation. I guess the point I'm trying to make is that we need a way of unmerging any kind of STIL files we get from any STIL producer. The only way I know of accomplishing that is to put something in the spec such that this approach of having both the merged as well as unmerged versions of the scan operations is clearly identified and always done the same way. This will make it easy for all STIL consumers to be able to break patterns where they need to. I'd suggest something like: Procedures { scan { C { si=\r2 0; so=\r2 X; } If '!MergedScanOperations' { // unmerge whenever the STIL reader // deems it necessary. Shift { V { so=#; clk=P; } } // unload in first Shift BreakPoint; Shift { V { si=#; clk=P; } } // load in second Shift } If 'MergedScanOperations' { // otherwse merge scanin and scanout Shift { V { si=#; so=#; clk=P; } } // unload-load in one Shift } } } So, in this example, we would define in the spec a STIL system variable called "MergedScanOperations" (call it what you want) which I guess we would also define some default for it. This variable could be modified during the STIL->ATE translation process whenever it is determined that there is a need to break the pattern (due to: tester resource limitations, size manageability, ...) and at that point turn temporarily set this variable to 'false' (or 0) such that the subsequent processing of the next scan operation would get unmerged. Just an idea to hopefully provide more structure to this particular situation. I don't mind doing this some other way but what ever way we come up with I'd like to be structured such that all STIL readers can implement in a very simple way. I definitely agree with Peter's direction on this to put the unmerging burden on the STIL producer by encoding it into the macro/procedures. 2) Another issue is that the 1450.0 spec indicates in section 24.5 in the next to last line item: --- A particular sigref_expr shall appear only once in a Shift block. Consecutive shift blocks require unique sigref_exprs for each Shift block. I believe your example violates this part of the spec. I know it's really not an issue with the way you have this coded and why this restriction is in the spec to begin with so I'm not sure how you get around this one. Can we remove that restriction in the 1450.0 spec as part of the 1450.1 spec? Does the presence of the "If" construct cause other problems like this with the 1450.0 spec??? On a separate note, it was brought up to me that there is a contradiction in the 1450.0 spec related to the section I just pointed out above and in section 24.4 where it states: "Only one Shift statement is defined in a scan-oriented block. This was raised in the context of some discussions on how to represent STIL "non-parallel" scan operations such as implementing JTAG (1149.1) scan operations (into the TDI pin) followed by a scan operation into other product scan pins (which were setup by the previous JTAG scan) all within a single procedure. This should be doable (I believe) and still abide by the restriction specified above in 24.5 but the statement in 24.4 causes problems and I believe would require separate procedure/macros to implement this. I'd appreciate anyone's take on this. Regards, Doug