Phone Conference P1450.1 Working Doc Subgroup Thurs Jan 18, 10:00 am PST --------------------------------------------- Attendees: ---------- Tony Taylor Peter Wohl Gregg Wilder Doug Sprague Greg Maston Rohit Kapur Tony opened the meeting with a request to Greg to review the changes he made in this current document, and a proposal to follow-up to that with a set of questions he had identified. Unfortunately, this document (basis for discussion in this meeting) had not been distributed to everyone else until an hour before this meeting. Greg reviewed his changes, summarized in Table 1 under the 1/10/01 entry. Tony then started going through his list of issues - First issue (convention only): reference to WaveformChar should be WaveformCharacter, uniformly in the document. Greg's AI[1] to correct. Questions about the Definitions Section --------------------------------------- Minor discussion about section 3, page 6: Tony asked for a clarification about the intent of putting information in section 3.1 vs. Annex A, etc. Greg indicated that his understanding is that any definition present in section 3.1 becomes a "global IEEE definition" (part of IEEE std 100). Anything that is a definition for this document but not intended an IEEE universal definition, should be present in Annex A. Table 3, Mixed-Operators Expressions and Concerns ------------------------------------------------- Table 3, page 9: Tony raised a concern about putting ALL operators into ONE table, and the implication that this would allow for an expression like: "var = 10ns & signal1;". Greg identified that from his view, a single table, identifying precedence of all operators, was necessary for a complete algebraic definition of these expressions. However, perhaps we should work toward a set of separate operators for different types of expressions - numeric_expr, bitwise_ops. Boolean expressions cross-over this breakdown and they may be the one to cause the need for a single table. Tony made a request for everyone to consider what the best thing to do here was, and in particular to review the Verilog LRM, IEEE 1364, and consider: (a) how should we leverage off of this definition in our effort? (b) how should we represent this capability and minimize confusion in our effort? The Working Group took an AI[2] to look at IEEE Std. 1364 and consider what to do here. Pass and Fail Concepts ---------------------- pg 10, an IMPORTANT comment in the first two expression examples. Tony opened a discussion about the terms "Pass" and "Fail". The issue is that the tester/test environment tends to equate the notion of "passing" with the value 0, and the notion of "failing" with a notion of non-zero, which is DIFFERENT than the C-language notion. Greg identified that the document currently identifies "> 0" as True and "<= 0" as False... the Working Group took AI[3] to consider how to define "pass" and "fail" and make the concept acceptable to the test domain and the C-language orientation. Greg took AI[4] to put "Pass" and "Fail" into Annex A. Doug identified another context of Pass and Fail, in multiple device testing, no failures is an all-zero "pass", one or more failures is none-zero, where the set bits identify the failing device. Variable Block Placement ------------------------ pg 11: Tony raised a concern with Variables needing to being referenced outside the PatternBurst. Primary context of this issue was identified as the need to reference Variables from the Environment block (as part of CTL). After a brief discussion, the Working Group Resolved to put Variables as part of Spec block, instead of inside PatternBurst. Greg took AI[5] to put an initial pass at this concept into the doc and identify disconnects or requirements to support this concept. Rohit/Tony added a request to support the use of variables in the range expression. The Working Group was requested to review this concept and identify concerns about this capability (AI[6]). Rohit identified the purpose of this feature was to support parameterized cores with generic pattern sets that could be configured for a specific value of a specific code instance. During the discussion it was identified that the VALUE of the range would be a single FIXED value and not an expression that needs to be evaluated at "run" time. Therefore this construct could be constrained to allow only ENUM types in the range expression. Greg took AI[7] to consider the impact of defining an extension to the dot0 definition of range expressions, to allow enum-type variables in the range. SignalGroup/Variable Interchangability -------------------------------------- Tony started with a concern about pg 11: examples - The third bulleted example is too brief/incomplete, bcause the two statements presented here are really coming from two different contexts (first statement in the Patterns, second statement is in the Macro definition). This issue was extended by Tony to a general discussion about the example on page 21. The concept on page 21, and part of the goal of CTL is to support a mechanism to replace what was originally a "group" reference, to become a "variable" reference when the core was integrated into a design, and the original group signalrefs were no longer "signalrefs". The Working Group was requested to consider how to support this capability (AI[8]). Cell_ref / ScanChain references concern --------------------------------------- pg 11, section 5.6: Tony/Rohit opened a discussion about the cellref_expr, as identified the cellref_expr contains a reference to internal names. A request was made to expand this namespace to include "chain names" to get/support hierachical references. Minor discussion about what hierarchical means (hierarchical name vs "hierarchical reference"). During the discussion it was identified that the INTENT of the cell_ref namespace is that multiple occurances of the same cell-name across different scan-chains declarations identify the SAME cell (i.e. the cell name namespace is a single namespace, just like the Category namespace). Rohit identified a concern for CTL about the cell_ref namespace and the rules/requirements that identify this namespace. Rohit is comfortable that the "unique names" notion DOES satisfy his requirement/need to be able to reference the same cell across multiple chains. He identified that this capability is necessary and that if the cell_ref construct was ever changed such that cell names became "locally scoped" under an ScanChain declaration, the CTL environment would need some sort of additional referencing mechanism support such as including ScanChain names in this namespace and defining hierarchical refs. Process ------- Tony asked who gets the doc next? Tony could do some pattern and variable stuff, or Peter could do some BIST stuff. Peter identified (as in the last meeting) that he does not want the doc before the end of January. So Greg took AI[9] to continue working the set of changes outlined in this meeting. Tony volunteered to feed bits to add to Greg. BIST structures --------------- Doug has some feedback on BIST structures: - uniform notation in document is necessary: "tap" or "tab". Peter has already corrected this. - some concern raised about BistRegister block, and single BISTClock statement. Peter identified one change already done, to make the BISTClock statement optional. Additional discussion about the scanmasterclock/scanslaveclock definitions in the ScanStructures vs the single BISTClock definition. Peter indicated that the scanclocks, which execute a shift, are functionally different than the BISTClock, which advances the BIST state. Considered removing this statement entirely; only usage is when you write out the entire STIL file, there is a load/unload procedure that may need to pulse a BISTClock, and for that reason may want to need to know what the BISTClock should be. Peter took AI[10] to add to documentation to distinguish this clock from any scan connection. Doug again raised the question: is there no need to support multiple clocks to advance the BIST machine?, and Peter said that the purpose of this is to support a level of functional simulation of the BIST environment, and all BIST environments today work with the assumption of a single BIST clock architecture. - Doug identified a concern that was raised at IBM that there may need an additional structure to support diagnostics at a tester, looking for: how to get the mapping of the LFSR, to a scanchain scancell or PO... BISTStuctures has "connections" statement; Doug has question about whether an explicit mechanism is available to determine an LFSR location has a mapping available to a ScanStructures. Peter feels the constructs are sufficient, but Doug will identify if more explicit information is necessary. Another perspective on this issue, raised by Rohit, is whether the Connections under BISTStructures should be found in a separate Environment block, with the specific purpose as "functional simulation". Could either put these constructs under the BISTStructures, or since the purpose is "external" it could go into the Environment. It was identified that a Different level of connectivity needs to be expressed by CTL constructs, from the BISTStructures construct. This issue has been discussed. Rohit and Tony will generate an example to contrast putting connection type (or functional simulation type) information into the Environment block as part of AI[11]. Tony - concern that the parameters for BIST are incomplete, need Waveforms and Timing and other stuff to actually use this... perhaps need a Macro to support loading the seed, and that the Pattern should call a macro to load a seed and perhaps execute the entire BIST cycle. This discussion followed the Bist example in Peter's current doc, that in the pattern instead of saying "parameters", call a macro with sufficient parameters to implement the BIST setup and operation. How should the reference to a particular BIST register be made from the pattern? Tony added to AI[11] by proposing Rohit and he will add another example to try other ways. Next Meeting ------------ Tony proposed the next meeting for two weeks from now, Feb 1. Same phone connection unless otherwise specified. P1450.2 Meeting --------------- Gregg proposed a dot2 meeting to be held next week at this time slot (to fill the alternating weeks with .2 effort). Adjourned --------- Meeting was adjourned at 11:40 am PST. ---------------------- AI's ---- AI[1] - Greg make sure uniform reference to WaveformCharacter in doc. AI[2] - Working Group to look at IEEE Std. 1364 and consider what to do with Table [3]. AI[3] - Working Group to consider how to define "pass" and "fail" and make the concept acceptable to the test domain and the C-language orientation. AI[4] - Greg to put "Pass" and "Fail" into Annex A. AI[5] - Greg to move Variables from PatternBurst to Spec. AI[6] - Working Group review concept of 'enums' in the range expression. AI[7] - Greg consider how to define the 'enum' extension to ranges. AI[8] - Working Group to consider signalgroup/variable interchangeability, consequences and requirements. AI[9] - Greg continues as owner of the current doc. AI[10] - Peter to add to documentation to distinguish the BistClock from any scan or other "clock" references. AI[11] - Tony and Rohit to generate some "alternate construction" examples for concerns with the BistStructures definitions.