Phone Conference P1450.1 Working Doc Subgroup Thurs Feb 1, 10:00 am PST --------------------------------------------- Attendees: ---------- Tony Taylor Peter Wohl Doug Sprague Greg Maston Agenda ------ Proposed by Tony and agreed to by consensus: - review Greg's changes - new business -- BIST structures -- cellnames and namemaps - next step Documents discussed: -------------------- [1]Greg's latest (it was late, too) P1450.1 doc v9.2, pdf [2]Cover letter to this document, attached below these minutes. [3]Greg's email on Variable Usage, attached below these minutes. Greg's changes: --------------- WFCMap move - ------------- Discussed move of WFCMap from PatternBurst back to Signals/Groups, a change that was not previously discussed. Tony raised a concern about the capability or potential need to change mapping between Bursts, Greg indicated that since construct was defined as an attribute, it could be changed by defining a new SignalGroup with different WFCMaps and referencing the necessary group in the Burst... that is, a mechanism DOES exist to change this mapping if that is necessary. This was agreed to unanimously by the members present. Variables and Enumerations as separate blocks --------------------------------------------- Discussed the issue of moving the Variables and Enumerations. Original proposal was to place these in the Spec block, but the current document (at Greg's motivation) made these new top-level blocks. Greg discussed his concern about placing these into the Spec. Tony presented the notion that the Spec block, schematically, looks like: Spec { Variable {} Category {} } And that an Enum block can fit easily here, and these new Variables could fit into the current Variables block as additional types. Greg indicated that if you do this, the resulting structure side-steps the Category construct, which uh...destroys...(Greg's word) the current access mechanism for all data contained in here (which is dependent on Category), and furthermore makes the access dependent on the Spec block (at least for the enums if not the variables) -- which is an unused container in the current .0 spec, and makes the access to enums inconsistant with the access to variables AND FINALLY placing this under the Spec makes the resolution process dependent on the PatternExec and probably not the place to identify variables (with additional justification discussed below). The WG tabled this discussion for this meeting. AI[1] to all members to review and consider alternatives. Greg took AI[2] to complete removal of the Variables and Enums from the PatternBurst, as the members agree with the need to remove this construct from this block. Enum values in SignalGroups --------------------------- Greg talked through point(3) in the cover-email, and the resolution problem. Tony identified that option (3.1) seems sufficient, Doug feels that minimizing resolution overhead is critical, and (3.1) is the minimal impact. Greg took AI[3] to continue specing this option to look for other problems. Greg identified that referencing Enums from the SignalGroups either requires Enums to be a separate block or part of SignalGroups; it would be difficult to resolve these references if under the Spec block. Variables/Signals interchangeability issue ------------------------------------------ Greg discussed his additional doc[3] about his current perspective on variable/signal(group) interchangeability. The result was for the WG to continue considering this concept. Again, this capability implies that Variables and SignalGroups are constructs in parallel, and should follow similar resolution paths (driving toward an option to put Variables either into the SignalGroups or in parallel to them). Peter's BIST discussions ------------------------ Questions from Doug identified need to match "functional cells" of BIST register with the "scan cells" of ScanStructures. Need to know that "cell1" in ScanStructures is the same as "bit5" in BIST structure. Peter defined a proposal to add new field in BistStructures that has a scan cell list, correspondence to ScanStructures is by cell name. Peter took this AI[4]. Greg took an AI[6] to add some references in added tables for BistStructures top-level block. Tony's cellname references -------------------------- In the Environment NameMaps block, ScanStructures { ScanChain { scancell }} levels are not necessary because we've identified that each scancell name must be a unique reference (meaning that if the same scancell occurs across multiple chains then those cells are meant to be the same...). Therefore a proposal was extended to replace these levels with a single ScanCell block. Unanimously agreed, Greg took AI[5] to implement this. Next ---- 1. Greg to continue his cleanup and integration of changes as identified in AI's below. 2. Greg to send document to Peter for his integration of BistStructures and other work. 3. Next meeting on 15th. hold to schedule even though Greg will be in Mnt. View. ---------------------- AI's ---- AI[1] WG - review and consider Variables and Enums placement. AI[2] Greg - complete removal of Vars and Enums from PBursts. AI[3] Greg - implement enum-in-array-refs with constraints (3.1). AI[4] Peter - add cross-reference statement for BistStructures. AI[5] Greg - remove ScanStruct levels in Env. and add ScanCells. AI[6] Greg - add BistStructures reference in tables in prep for Peter. -----------------Doc[2]: Greg's Cover Email---------------- Subject: Re: STIL - phone call Thursday OR: so what has Greg done anyway? Date: Wed, 31 Jan 2001 22:11:37 -0700 From: "Greg Maston" Reply-To: gmaston@qwest.net Organization: Synopsys, Inc. To: "Tony Taylor" , gmaston@synopsys.com, gwilder@dal.asp.ti.com, dsprague@btv.ibm.com, peterwohl@adelphia.net, "Rohit Kapur" Dear Members of the P1450.1 Review Committee, sorry this update is coming at you so late, but there have been a series of issues that I've attempted to respond to, both from the last meeting and subsequent discoveries with individuals involved in this process. If frame would be better than pdf, just ask... Formalism: I noticed a tendancy in some parts of this document to refer to some undefined quantity called "tester". I started to change occurences of "tester" to "ATE", and added that acronym to our usage list. But this needs contemplation as to the uniform reference we need to use in this spec. Also we need to carefully consider when we use this term, since by some interpretation of the definition of the scope of this effort we are outside of ATE usage.... Be aware that the red strikethrough text will be removed in the next iteration of this document (pending agreement by reviewers). Here's the high points of what to look for in this doc (and a starting point for discussions) You can look at the last table History entry for a summary of these changes as well... 1 - WFCMap definition placement. In the previous spec this had also been placed in the PatternBurst. However, current use of this construct indicates that it really needs to be handled as an additional signal/signalgroup attribute. Therefore I've moved this construct (back) under the Signals and SignalGroups blocks. Note this was done in discussion with Peter Wohl, who was the last one tagged with changing this construct. This change forced the creation of two new sections in this document, to represent changes to the Signals and SignalGroups. 2 - Variables and Enums definition placement: in the last meeting, we identified a problem with scoping Variables under the PatternBurst as defined in the last spec. Problem was access to these definitions outside the pattern space, CTL identified the need/desire to do this. Proposal was to move these two sections into the Spec block. The Spec block has some interesting problems -- one being that the "Spec" level is really unused in the STIL evaluation process, it's really the sub-level Category that gets used. But there's more: the Spec block allows definitions inside to be organized EITHER by Category or Variable -- that is, there's already a Variable block in here, with different semantics on the Variables (min/typ/max definitions). I don't think it's a good idea to trounce into this section with a different type of Variable, in fact, I think we need to steer clear of this section and allow multi-valued Spec Variables to be distinct from the Variables we're adding in this spec(ification). Therefore, in this new proposal, I've boldly declared two new global blocks, to support Variables and Enumerations. Now, Kim Smith indicated that this was EXACTLY what he did not want to have, but there are more issues here that may drive the NEED to declare these blocks this way. Anyway we need to review and consider the placement of these blocks as new global blocks or not. Also I've placed the Reference to these blocks into the PatternBurst, but I'm unsure whether this should happen in the Burst or the Exec. Since these variables are used only in Patterns and PatternBursts, I think this is the right place... but we need to review that decision. However, now, at least these variables are externally visible to other blocks, in particular, the Environment block (and CTL concerns). 3 - Enum application in SignalGroups... one point discussed at the last meeting was to support the use of Enums in the SignalGroups array declarations, for instance "TOP_BUS[TOP_BUSHIGH..0]". I think this is straightforward to support BUT I've got a concern about how we resolve this reference. Today, the SignalGroups blocks can be completely resolved when they are read -- all signalgroup information is resolved based on current Signals and the global SignalGroups (if present). This proposal adds a dependency on the Enums information, and here's my concern: how do we maintain the independent resolution process for SignalGroups? There are a couple of answers, so I'll throw them out to the audience (maybe you can come up with more, too): 3.1 - SignalGroups can only use Enums declared in the global Enum block, which must be defined before a SignalGroups block that uses any of these definitions. Straightforward but too restrictive? 3.2 - Add an Enum block-reference statement to the SignalGroups, to allow independent resolution of Enum values to those found in named Enum blocks. Consistent with STIL resolution mechanisms, but confusing because the Enum values used in a Pattern may be different from the Enums used in a SignalGroup... 3.3 - Defer evaluation of SignalGroups until used inside a PatternBurst, and resolve the values dependent on the Enums used in the PatternBurst. This resolves the confusion with 3.2, BUT this means that not only can SignalGroups NOT be resolved when read, but that the VALUE of the SignalGroups may be different in different PatternBursts. I don't like this...(I don't like this at all...) Personally, IF we decide to support this capability, then I like 3.2, unless we can commit and hold to 3.1 as sufficient support for this capability. 3.2 maintains current SignalGroup resolution constructs with Enum resolution flexibility consistent with the STIL resolution environment. The fact that values may be different is consistent with this same issue between Timing and Patterns (because Timing references SignalGroups, and PatternBursts reference SignalGroups, the SignalGroups used between these two contexts may be different today). BUT I MUST ASK: do we need to add this level of complication to the STIL resolution environment? OR can we get away with 3.1? I have NOT added sections to support this construct until we determine whether we can enforce a resolution strategy.... 4 - Variables use. I made this a separate email. I've not changed the document for this proposal, although if you read table 4 carefully some of the issues are in there already (woops) - but i wanted to get feedback from the Working Group before i went too far. 5 - expressions and table 3 operator constructs... I've NOT implemented changes here yet (basic issue is partitioning some of the functions up in logic_expr into additional types -- pending result of the Variables discussion above...) 6 - I added another section "Top-level statements and required ordering", to identify the requirements and ordering dependencies on Variables, Enumerations, and Environment blocks (and any other top-level block we add to the spec...) Good Luck. -- -----------------Doc[3]: Greg's Variable Email---------------- Subject: Variables Considerations Date: Wed, 31 Jan 2001 22:37:22 -0700 From: "Greg Maston" Reply-To: gmaston@qwest.net Organization: Synopsys, Inc. To: "Tony Taylor" , " Douglas E. Sprague" , " Gregg Wilder" , " Greg Maston @home" , " Rohit Kapur" , " Peter Wohl" One of the topics raised in our last phone discussion involved the notion of being able to interchange variable usage with signalgroup usage; the motivation for this capability is the ability to maintain the same name references, when macros and procedures are re-written to support an instance of a core (in particular when the original macro/procedure was defined based on that "core" being the DUT). The key issue here is the ability to maintain parameter names in the macro call, inside the pattern, but then to use the parameter arguments in the re-written macro body in a different fashion. Here's my current thought on this topic (and of course a proposal): (1) To allow variables and signalgroups to be interchanged freely, a variable reference may appear wherever a signal/group reference may appear. - first impact of this capability: variables (possibly just variables of type WFC) become part of the signal/group namespace. A similar set of name-restriction rules would apply, to wit: -- it is an error for a variable name, present in a flow, to have the same name as a signal or signalgroup also present in this flow. With this rule, it is possible to always unambiguously identify 'a' in the statement(s): "V { a = 0100101; }". It was mentioned that we could adopt a priority-resolution process, for example a variable of name 'a' would take precedence over a signalgroup of name 'a' in the same space. I would chose NOT to do this because: (a) it's inconsistant with most other STIL resolution processes (that forbid use of the same name inside a common name-space), and (b) 50% of the time we would resolve a definition the wrong way, and the user would not be informed that the resolution was not what was expected - by making it an error, the user is forced to an explicit, consistant use of names, and required to correct duplicate usages. Also, the replacement of a signalgroup name with a variable name in the CTL context should not be a problem, since the original signalgroup declaration (defined when the core was a DUT), references a bunch of signals that are no longer top-level signal names anyway... in other words, that original core-as-DUT signalgroup may still be present in the STIL file but it can't be referenced in this new environment because the signal definitions are not the same... - second impact of this capability: Because current signal assignment expects WFCs only on the RHS (right-hand-side) of an expression, and because it's not possible to disambiguate variable names from WFC strings (take my current working example: is 'a' a variable or a hex value?), I think it is REQUIRED that assignment of a variable to a signal must be presented as an expression. This could EITHER be done as: V { sig1 = 'a'; } OR V { 'sig1 = a'; } but personally I like the quotes just on the RHS only better, because making the entire thing quoted still leaves the potential for 'a' to be misinterpreted as a variable or a hex value in that complete expression... NOW, what I've accomplished with the namespace restriction, is the elimination of the Eval statement, because you can always use a Condition statement in place of the Eval. ALSO, this will support the DIRECT REPLACEMENT of signalgroups with variable references. -------------- Next point to consider: one identified feature/requirement of this capability, is the ability to do "bit selects" of the new variable, in the re-written macro or procedure body. We've constrained the use of [] to be allowed only on variables that were declared with []. Therefore, my motivation is to not allow direct bit-selects of a variable unless that variable was defined with []. Also, we might need some "width" information on variables that were not declared with [] to support this capability. Here goes the proposal on how to support this: Variables { a { Type WFC; Width 10; } //original signalgroup 'a' contained 10 signals a[0..9] { Type WFC; Width 10; } //bracketed version for bit-select support } ---original def---- SignalGroups { a = 'sig1+sig2+sig3...' } MacroDefs { a { V { a = #; } } } ---new defs---- MacroDefs { a { C { a[0..9] = 'a' }; //assign original parameter to bit-select signals V { newsig1 = 'a[0]'; newsig2 = 'a[3]'; } V { ...etc... } } } Patterns a { Macro a { a=0100000111; } } ------ This allows the original parameter in the macro call in the patterns to remain just the same, but causes an additional assignment to a "bit-selectable" variable in the re-written macro body. It also necessitates the declaration of a variable that matches the original parameter name and an additional variable that is declared with a range construct (that I've not added to the spec yet, but is doable...) ... I don't know... I'm still playing around with this concept... ... but we won't get this far on this next phone call anyway... --