Arpad, The AMI language, and explicitly the format Corner were originally designed to avoid the confusion in IBIS of the meaning of "most". Values of tap coefficients, strength, CTLE settings are clearly independent of process corner. The AMI language makes this perfectly clear to the model maker and the EDA tool. To me "align implicitly to slow and fast corners" means that the model maker expects the EDA Tool to use <slow value> for slow/weak process corners and <fast value> for fast/strong corners. I do not think it is necessary, but it might make it clearer by adding a sentence like: "The model maker expects the EDA Tool to use <typ value> for nominal conditions, <slow value> for slow/weak process corners and <fast value> for fast/strong corners." Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, June 14, 2011 8:50 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft Walter, The AMI section of the current 5.0 spec says: | Note that in the context of Algorithmic Model for type 'Corner', <slow | value> and <fast value> align implicitly to slow and fast corners, and | <slow value> does not have to be less than <fast value>. What does "align implicitly to slow and fast corners" mean exactly? Slow and fast corners where? If I remember correctly, we established verbally in this discussion that this refers to the corner setting of the EDA tool, selecting a certain corner for the analog IBIS [Model]. Whatever corner the user selects in whatever GUI the EDA tool has for the legacy analog IBIS model is the corner that we are trying to use for selecting the corresponding AMI parameters value from a parameter of Format Corner. But what are the slow and fast corners in the legacy IBIS [Model]'s terminology? Well, most min data corresponds to slow and most max data corresponds to fast, according to: "For most [Model] keyword data, the "min" column describes slow, weak performance, and the "max" column describes the fast, strong performance." But C_comp is not part of that, according to what the bottom of pg. 174 says: | The "min" and "max" columns for all remaining keywords and subparameters | will contain the smallest and largest magnitude values. This applies to the | [Model] subparameter C_comp as well ... | | C_comp is considered an independent variable. So based on all this, please explain to me what is the exact meaning of "align implicitly to slow and fast corners" in our current spec. Based on reading the spec I have no idea. Thanks, Arpad ========================================================= From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Tuesday, June 14, 2011 6:54 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft Arpad, These words are for AMI parameters of format Corner. What does that have to do with C_comp? Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, June 14, 2011 7:51 PM To: IBIS-ATM Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft What is "slow and fast corner" for the C_comp values according to the IBIS specification? The reason we need to fix IBIS here is because the AMI parameters Format Corner are associated with the "slow and fast corners" of IBIS. If we don't know what they mean, we can't make that association. Thanks, Arpad ===================================================== From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Tuesday, June 14, 2011 6:46 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft Arpad, What is not clear about the following words? | Note that in the context of Algorithmic Model for type 'Corner', <slow | value> and <fast value> align implicitly to slow and fast corners, and | <slow value> does not have to be less than <fast value>. I agree that IBIS [Model] parameters are not clear, but we are not going to solve that here. We are charted to fix AMI not fix IBIS. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, June 14, 2011 7:33 PM To: IBIS-ATM Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft Forgot to finish my thought: And since AMI parameters Format Corner supposed to be associated with the IBIS corner problem, it seems that we need to solve the IBIS corner problem also, or define an independent classification for that from the AMI portion of the spec. Arpad ======================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, June 14, 2011 6:30 PM To: IBIS-ATM Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft Walter, This BIRD draft is dealing with AMI parameters Format Corner (which is not in your list below). That's what is not clear for me in the spec. Arpad ============================================================== From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Tuesday, June 14, 2011 6:26 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft Arpad, Please note that it is for "most [Model] keyword data". This is the IBIS problem. We are talking about AMI Parameters. For AMI Parameters we already say "For type 'Range' and 'Increment', <min value>, <max value> does not imply slow and fast corners". What is not clear about this? Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, June 14, 2011 7:15 PM To: IBIS-ATM Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft Walter, I totally disagree with you. "Why do we need to add anything else?" Exactly because of the word "most" on pg. 174: "For most [Model] keyword data, the "min" column describes slow, weak performance, and the "max" column describes the fast, strong performance." Note that towards the bottom of pg. 174 the spec says: | The "min" and "max" columns for all remaining keywords and subparameters | will contain the smallest and largest magnitude values. This applies to the | [Model] subparameter C_comp as well ... | | C_comp is considered an independent variable. This is the reason I disagree with you. C_comp is a pretty important part of the analog model and its corner conditions. If we don't know what its min/max values mean in terms of slow/fast, how are you going to make an association between the AMI slow/fast corners and the analog models' slow/fast corners? Sincerely, Arpad ========================================================================== From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Tuesday, June 14, 2011 5:56 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft Arpad, This is the current wording in 5.0: | | Note that in the context of Algorithmic Model for type 'Corner', <slow | value> and <fast value> align implicitly to slow and fast corners, and | <slow value> does not have to be less than <fast value>. For type 'Range' | and 'Increment', <min value>, <max value> does not imply slow and fast | corners. Why do we need to add anything else? I think the above words are clear and Unambiguous. These words mean that the "Model Maker expects the EDA tool to use <typ value> for typical performance, <slow value> for slow weak performance, and <fast value> for fast, strong performance". AMI models do not suffer the consequences of the word "most" in the following Sentence in the IBIS 5.0 specification on page 174: For most [Model] keyword data, the "min" column describes slow, weak performance, and the "max" column describes the fast, strong performance. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, June 14, 2011 6:29 PM To: IBIS-ATM Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft Hello, Since our discussion in the ATM teleconference today did not reach a conclusion on what the text should say, I would like to continue with this topic in email, so that we could hopefully find a solution by next Tuesday. Here is the debated text for your convenience: | Note that for Format Corner AMI parameters, the selection of one of the | three possible values (<typ value>, <slow value>, <fast value>) is done | by the EDA tool based on its internal IBIS [Model] corner setting. | Since the IBIS specification does not define how exactly an EDA tool | should pick from the various types of min. and max. data in the .ibs | file to achieve slow and fast simulation results, the exact method of | how <typ value>, <slow value> and <fast value> from Format Corner AMI | parameters should be associated with the EDA tool's corner setting | cannot be defined here. However, it is recommended that the typ., min., | max. (or similar) IBIS [Model] corner settings should be associated with | the <typ value>, <slow value>, <fast value> in Format Corner AMI | parameters, respectively. For AMI parameters <slow value> does not have | to be less than <fast value>. For type 'Range' and 'Increment', <min | value>, <max value> does not imply slow and fast corners. Summary: 1) The main motivation for this BIRD was to state in the spec that the Format Corner parameter gets its control input from the EDA tool automatically and a GUI for user selection is not necessary for these types of variables. 2) Another goal was to define that the AMI corner and the analog model's corner settings are linked together Problem: In IBIS we (deliberately) left C_comp independent from the I-V and V-t curves, because we thought that its variations were not related to silicon. As a result, EDA vendors implemented their own methods for how the user combines the C_comp with the I-V and V-t curves. Some vendors have five corners (typ/min/max/slow/fast), other vendors may have different user options. Question: How do we associate the AMI slow/fast corners with the IBIS analog model's min/max corners? Options: 1) Leave it open in the spec and let the EDA tool vendor do what they think works best with their products. - the problem is that if EDA tools have different associations the results will be different, or the model files might have to be edited "tailored" manually for each tool 2) Introduce another subparameter for C_comp to define the meaning of its min/max corners - this would also solve some issues in legacy IBIS 3) Define in the AMI portions of the specification that for [Model]s which have [Algorithmic Model] keywords, the min/max corners of C_comp have a specific meaning (slow/fast), which doesn't apply to legacy IBIS modeling This BIRD draft does #1, but we really don't seem to like it. Bob already started a C_comp BIRD draft, and it seems that we like the ideas Bob wrote down, but we were wondering about the syntax approach Bob proposed. This would go with option #2 pretty well, but may take a little more time to finish Bob's BIRD draft. Option #3 is fairly inconsistent, and as a consequence I think it will confuse a lot of model makers and users, and therefore it is error prone. But this may be the simplest and fastest solution to have something well defined. I personally think that #2 would be the most robust solution because it would solve the IBIS problem as well as the AMI problem. It is not challenging from a technical perspective, so I would think that we should be able to finish Bob's BIRD draft in a short time. I would simply add a new subparameter to the spec under or above C_comp to specify the meaning of its columns: C_comp_corner typ slow fast C_comp 7.0pF 5.0pF 9.0pF where slow/fast can be in either order, while the numerical entries for the 2nd and 3rd columns will have to be in increasing order (to go with the old rule: min < max). Once we have this, the AMI Corner association would solve itself by using this new subparameter. The C_comp_corner subparameter would be required when {Algorithmic Model] exists in [Model], but optional in all other cases. I am open for comments and suggestions. Thanks, Arpad ======================================================================