Walter: Comments to your questions are in your e-mail. Bob From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz Sent: Monday, June 20, 2011 6:34 AM To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM' Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft; Questions on section 9 Arpad, In section 9 of IBIS has the following setnences: | The required "typ" column for all data represents typical operating | conditions. For most [Model] keyword data, the "min" column describes slow, | weak performance, and the "max" column describes the fast, strong | performance. It is permissible to use slow, weak components or models to | derive the data for the "min" column, and to use fast, strong components or | models to derive the data in the "max" columns under the corresponding | voltage and temperature derating conditions for these columns. It is also | permissible to use typical components or models derated by voltage and | temperature and optionally apply proprietary "X%" and "Y%" factors described | later for further derating. This methodology has the nice feature that the | data can be derived either from semiconductor vendor proprietary models, or | typical component measurement over temperature/voltage. | The voltage keywords that control the voltage conditions are [Voltage | Range], [Pulldown Reference], [Pullup Reference], [GND Clamp Reference], and | [POWER Clamp Reference]. The entries in the "min" columns contain the | smallest magnitude voltages, and the entries in the "max" columns contain | the largest magnitude voltages. | | The optional [Temperature Range] keyword will contain the temperature which | causes or amplifies the slow, weak conditions in the "min" column and the | temperature which causes or amplifies the fast, strong conditions in the | "max" column. Therefore, the "min" column for [Temperature Range] will | contain the lowest value for bipolar models (TTL and ECL) and the highest | value for CMOS models. Default values described later are assumed if | temperature is not specified. | | 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 even if the correlation to the voltage, | temperature, and process variations are known because information about such | correlation is not available in all cases. | | C_comp is considered an independent variable. This is because C_comp | includes bonding pad capacitance, which does not necessarily track | fabrication process variations. The conservative approach to using IBIS | data will associate large C_comp values with slow, weak models, and the | small C_comp values with fast, strong models. Question #1: Re | For most [Model] keyword data, the "min" column describes slow, | weak performance, and the "max" column describes the fast, strong | performance. Does "most" mean "All [Model] keyword data, with the exception of the specific parameters mentioned in this section, min values should be used for slow/weak components and max values should be used for fast/weak components." Or "Most [Model] keyword data, with the exception of the specific parameters mentioned in this section, min values should be used for slow/weak components and max values should be used for fast/weak components." "Most" can mean both cases. C_comp currently is a significant exception for the first statement (there may be one or two other minor ones). For the second case, a terminator based on [Rpower] and [Rgnd], or [Rac], [Cac] could be extracted according to PVT (process, temperature, voltage) and be positioned such that the values creating the fastest responses are in the min column. Similarly the series element extractions according to PVT may have the opposite effects including whether it is configured as in series with the signal or as a shunt to the signal. Also it is possible for voltage or temperature compensated devices to have entries correctly positioned according to PVT, but their compensated effects and values cause the min entries to perform the fastest. So in the second case, there are device-specific, circuit-specific or even extraction-specific situations where the typ, min, max entries are not always the typ, slow, fast entries. Question #2: Re | The entries in the "min" columns contain the | smallest magnitude voltages, and the entries in the "max" columns contain | the largest magnitude voltages. Which of the following is correct? [Pulldown Reference] 0 -.02 .01 Or [Pulldown Reference] 0 .01 -.02 Good catch on ambiguity and incompleteness of the verbage for "0" volts. The [Pulldown Reference] 0 .01 -.02 would be the correct entry. The intent is to set up the rails to create the minimum voltage drop across the device (with respect to both the [Pullup Reference] and [Pulldown Reference] for all of the min entries, and max voltage across the device for the max entries. I also agree that C_comp requires a BIRD so that a [Model] can have define values of C_comp for components that have a fast C_comp that has a smaller magnitude that a slow C_comp. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Sunday, June 19, 2011 12:08 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft Walter, Regarding: "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." I would like you to show me where in the spec this is made clear with page numbers, etc. As far as I understand, this is not clear at all which is the very reason that we are working on this BIRD draft. Also, regarding the first sentence of the above quote, my reading of the spec and from all the conversations that took place on this topic gives me the opposite impression. This sentence on pg. 141: | Note that in the context of Algorithmic Model for type 'Corner', <slow | value> and <fast value> align implicitly to slow and fast corners. seems to be trying to do exactly the opposite, to "align" certain AMI settings with the process corner of the analog IBIS model. Aside from that, your suggested text: "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." unfortunately doesn't solve our problem, because "slow/weak process corners" and "for fast/strong corners" are not defined in the IBIS specification for analog models. I can hear you responding with pg. 174 to this, but please remember the word "most" in the 2nd sentence of the 2nd paragraph and the next to the last paragraph on the bottom of that page, which is the reason for the problem. While we may know what slow and fast is for the I-V and V-t curves, we do not know what those are for C_comp. I am still on the opinion that the only way we can solve this would be with another BIRD that introduces a subparameter or keyword for C_comp to allow the model maker to give fast/slow meaning to the min/max C_comp values. Once we did this, the fast and slow conditions for the analog model would be known and the issue with Format Corner would resolve itself almost automatically. So I would recommend that we look at Bob's C_comp BIRD, or add another subparameter immediately before or after C_comp to allow the model maker to "label" its min/max columns with "fast" and "slow" as they see fit, something like this: C_comp_corner typ slow fast C_comp 7.0pF 5.0pF 9.0pF We could make this additional subparameter required ONLY when the [Algorithmic Model] keyword is present, and optional for all other cases. This would keep existing models working but would allow us to move forward with the Format Corner AMI model parameters unambiguously. Thanks, Arpad ================================================================ From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Tuesday, June 14, 2011 10:11 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft 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 ======================================================================