Subject: RE: STIL.3 - Review of Test Resource Constraint - Standard To: "Tony Taylor" Hi Tony, I didn't get through this all, but here's my comments from where I am now. A general comment... I've very impressed by what you've accomplished here. I recall thinking at a STIL meeting (at TI? 4 or 5 years ago?) that this concept of standardizing tester targetting and resource checks was (I think the cliche I used was) "a bridge too far". Although I haven't read the entire draft and I've understood only a portion of what I've read, I'm impressed by the depth and breadth of what you have here. Page 9 – lines 79-81 (for example): Consider the following alternative for expressing the timing constraints: Drop the “Min” and “Max”, and change the expression from a timing value to a Boolean. The Boolean expression could then be considered an assertion – if it evaluates True, then all is ok. If it evaluates false, then there is a violation. For example, the lines 79-81 would become: D { ‘@2>@1+10ns’; } U/D { ‘(@3>@2+10ns) && (@2<@1+32ns’; } D { ‘(@4>@3+10ns) && (@4<@2+25ns)’; } I think your syntax (as in the document) is slightly easier to read then what I have above, but I think the above “assertion” approach can more gracefully deal with the following situations: – When I want >= instead of > – When an edge has constraints to multiple other edges (such as if @4 must be >@3+10ns and also >@2+20ns) – When an edge must match up exactly with the timing of another edge in another WFC (we have this in one of our testers – where the same timing generator can be used in an input cycle and an output cycle – therefore the timing in the different WFCs must match exactly). Clause 16 - page 31. FormatSelect - a couple of points here. First there are two separate blocks with the keyword FormatSelect. There is a description labeled (5) on page 33 - apparently only for the first block. This seems confusing to me. I think maybe the description on page 33 should acknowledge that there are two block variations and introduce the differences between the two blocks (Or maybe that's what the 3rd sentence - beginning with "If" attempts to do - but I didn't follow it). The other point is a typo (I think). There is an open parenthesis before the FormatSelect statement, but there isn't a matching closing parethesis. Ditto for the 2nd MaxShapes statement. I have a comment from one of our engineers who is concerned whether the WaveformCharacteristics stuff in clause 16 is sufficiently expressive to represent some of the testers he is familiar with (including ours). Here's my attempt to convey the specifics in our case: We have a tester that has a single time-set - shared between the In and Out cycles. It has 2 timing generators per pin. Each timing generator can be used in either an In format, an Out format or both. If used in both, it must of course have the same value in both cycles. The tester can switch between In and Out on a cycle by cycle basis (i.e. can't drive and compare in the same cycle). His conclusion is that the syntax wouldn't allow that to be represented. As I write this, I'm not sure I agree; here's my attempt: SignalCharacteristics Data Scan In Out { InOut OnCycleBoundary; }; WaveformCharacteristics xyz { FormatSelect InOut { MaxTimeSets 1; MaxTimingGenerators 2; }; }; WaveformDescriptions { // some way of verifying that the timing for the drive and compare are compatible // perhaps such as comment #2 above. }; Am I right? 10 - page 23. Pragma is defined to be a STIL block - which I think means it can only appear at the root level (i.e. not inside any other block). I don't have a specific example justifying this, but it seems to me allowing it to be like a STIL.0 Ann (that can occur at a statement level - not just a block level) might be more appropriate - so tester (etc.) specific information could be inserted with a higher degree of precision. Also, this seems to make sense to me from the perspectives that a) a Pragma kind-of looks like an Ann (with those {* *} delimiters) and b) a Pragam kind-of acts like an Ann (since parsers must be able to skip over them, and people can put whatever they want to in them. Certainly someone could improvise an statement-level Pragma by just using an Ann - with some specific keyword inside - and coding their reader to look for that keyword. 12.1 (pg 26) - (3) It seems to me if you have a Category that you also need a Selector. Since you don't allow specification of a Selector, I think that means only the .Typ value is used. I don't see anything that says that. I can imagine someone putting their limits into the .Min and .Max (since their limits are minimums and maximums). Clause 17- (3) at the bottom of page 36 (etc.) I'm not sure I understand this. Should it say "Specify the number of data values ..."? How is this intended to be used? Does something add up all the resources used in a PatternBurst and determine if the resources (as defined in WaveformCharacteristics) is exceeded? (I think so, for all 4 usage models). If so then I probably have an issue with the NumberTimeSets. A previous line of testers that I've worked on went through great pains to find redundencies across different (apparent) time-set usages in the pattern. If it found that timeset A and timeset B could actually be collapsed into a single timeset, it would do so - giving the user a larger apparent number of timesets. (two timesets could be collapsed into one for example, if they used different timing generators - such as if timeset A only used timing generator #1 and timeset be only used timing generate #2). What I think I'm seeing is that the ATE companies are doing more to manage the tester resources (such as timesets) in flexible/efficient/non-obvious ways that go toward undercutting the ability of STIL.3 to represent a testers abilities to handle a PatternBurst (i.e. the resource utiliziation can't be determined without detailed understanding of the optimizing resource allocation algorithms in the ATE's operating system). integer_expr - throughout. integer_expr seems similar to time_expr in STIL.0 - but is never defined as such. A couple of picky points to consider here: - we're not too far off from having testers that might support more than 2G vectors (at least considering "IEEE time" - as measured in years). That enters the range where you can't represent the value as a "signed int" in C/C++ (on most 32 bit machines). And 4G might not be too far beyond that, which you can't even do on a 32 bit integer. STIL.0 (page 60) says an integer is a 32-bit twos complement number (i.e. up to 2^32-1). Is that applicable to your integer_expr? Is it sufficient? - According to SI - and STIL.0, 2G is not a valid value - since G (giga) prefix must be followed by a unit. And if 2G were to be a legal value, would it mean 2billion or 2^31? Different people give different answers. I think STIL.3 should take a position on this to avoid future troubles - I'd suggest reminding that values such as 2G, 2M, 2k are not legal. - I can't find a place where these following issues might be applicable, so they are probably moot. But I'll raise it anyways and let you decide. Is '100ns/50ns' and integer_expr? Is '(100ns/3)*6'? The issue in the first is that units cancel to produce a unit-less value. The issue in both is that you can produce an integer from floating point - and the issue with the 2nd is that intermediate values might need to be floating point. An issue in the 2nd is that some rounding is necessary to produce the right answer. (is 1.0 the same as 0.9999999999999999999999999999999999)? 12.1 (pg 25) (b) - "An integer value of '-1' means ...". This seems like a good idea overall, but is defined here to be appliable only to this block. This implies I can't do this in other places. For example, in 16.1, I might want "MaxShapes '-1'" to indicate there is no limit to the number of waveform shapes. But I think the draft now prohibits me from doing this. In general I think the spec's attitude is that "unspecified"="unlimited" - i.e. if a value for a constraint is not specified, then there is no limit. But sometimes (at least with me) "unspecified"="I dunno". But usually, "I dunno" != "unlimited". So I think there is value in being able to explicitly specify "unlimited". 18.1 (pg 41) (19) PatternVariables - I don't understand this on two levels. First, from sentence structure, I can parse this as either a) whether variables or expressions are supported for Macros and Procs, or b) whether variables are supported for Macros, or for Procs or for expressions. I think some elaboration might be helpful. Also, I can't figure out what it means that variables are or are not supported for Macros or Procs. Everything below is just typos (etc.): spell checker the the - appears several times in the document 1st sentence of last paragraph of page 3: Remove “addition” or change to “additional” Item 4 on page 4: This paragraph says “then the loader is expected to do an optimal job of assigning resources”. What does “optimal” mean here? Does it imply to a user that the loader must perform some optimization? I think the answer is “no”. How about “then the loader performs the task of assigning resources”. 3.1 (pg 5): TRC is used throughout the document. Should be defined here. 4 (pg 5) 1st paragraph: Remove the hyphen in ver-batim 4 (pg 5) 2nd paragraph: Says “All clauses in this document are normative.” But they aren’t. 5 explicitly isn’t. 1 (Overview) should probably be considered informative as well. Suggest changing the word “All” to “Unless otherwise noted, all”. 4.1 (pg 6) last paragraph: The double quotes were dropped from around “it is an error” and “it may be ambiguous”. Also the word “shall”. Also, in 1450.3 it is not a ‘dashed’ list (it is a lettered list – in 1450.0 it is a ‘dashed’ list). 5.2 1st paragraph: Too much “might”. 6 (pg 18): Unbalanced double-quote in the header for clause 6. 6 (pg 16): Extra comma before NumbertimeSets. 7 (pg 19): Wording doesn't make sense to me. Should this be something like: “A TRC block that contains a PatternReport…” 7.1 (pg 20): Missing "a" - Add an "a" before separate. 7.3 (pg 21): First sentence. Should you use pattern-burst as a proper noun? I think you mena PatternBurst as defined in STIL-1999 here. Probably ditto for Pattern. 7.3 (pg 21): 2nd sentence - the word "that" confuses me when I read this. 9.1 (pg 23): "and integer" 12.1 (pg 26) - (3)Should STIL.1 be STIL.0? 10 (pg 23) - 4th sentence - single/plural mismatch between "contents" and "is". -DVO-