Arpad, Bob, I have not followed the e-mail thread, but let me put my 2 cents in on how we handle NA. With the exception of IV and VT table, and record that has an NA in the Min or Max field takes on the value of the Typ field. In the case of IV and VT tables there are two cases, one case is when all the Min or Max data is NA, for all rows of an IV or VT table. In that case, all value of the Min and Max columns take on the Typ value. In the case where some rows have NA and some do not, then those rows with NA are ignored for that column. Do these rules make sense for all cases where there is an NA in a Min or Max column? Walter -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad Sent: Monday, July 14, 2014 12:15 PM To: 'IBIS-users' Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns Bob, Thanks for your response, but remember, I am asking this as an EDA vendor. And a big aspect of my question is what the EDA tool is expected to do with such models. The spec is quite vague, and I think it should define a few rules. We can't just throw out all models and abort the simulation if we find NA-s in the min/max corner in any of the keywords for which the spec doesn't say to use the typ value when min/max is not available. But this also applies to the model makers. The spec should have a few rules on what keyword combinations can have NA in the min/max columns. The way the spec goes now, a lot of combinations are allowed which do not make sense or can't be simulated. Thanks, Arpad ================================================================= -----Original Message----- From: Bob Ross [mailto:bob@teraspeed.com] Sent: Friday, July 11, 2014 8:59 PM To: Muranyi, Arpad; 'IBIS-users' Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns Arpad: You have provided a good analysis and scratched the surface of the problem. I do not think IBIS should make it illegal to have some, but not all corner data missing (e.g. the min and max columns for some tables are NA). There are pathological cases where such a models are still accurate and useful. E.g, ideal 50 ohm source resistors for the pullup and pulldown tables to the defined pulldown and pullup reference voltages for all corners with only the typ table is given and the min/max table corners have NA entries. The intent might be to model a fixed 50 ohm impedance for all pullup and pulldown table corners and vary the V-T data.) Or just providing an ideal 50 ohm termination for all corners could be done with just the typical data only, and that can be used with other models with all numerical corner data given. However, the user should be suspicious of and probably reject models for real buffers with NAs in the corners because they are incomplete or contain uncorrelated information that would make corner analysis inaccurate. Bob -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad Sent: Friday, July 11, 2014 10:45 AM To: IBIS-users Subject: [IBIS-Users] A question on how to handle NA in the min/max columns Hello, I would like to discuss the question of how to handle the situations when min/max data is not available in certain IBIS keywords. The IBIS specification has several occurrences of the following statement (with some variations here and there): If minimum and/or maximum values are not available, the reserved word "NA" must be used indicating the typical value by default. (This one can be found on pg. 36 at the end of the 1st paragraph of the Usage Rules on the top of the page). The interesting thing is that this statement does not appear under every single keyword, so my first question is whether this was intentional or sloppiness. For example, pg. 53 where the I-V tables are described, we can read the following: All four columns are required under these keywords. However, data is only required in the typical column. If minimum and/or maximum current values are not available, the reserved word "NA" must be used. "NA" can be used for currents in the typical column, but numeric values MUST be specified for the first and last voltage points on any I-V table. Each I-V table must have at least 2, but not more than 100, rows. This section does not state what the EDA tool should do when min/max data is not available. My guess is that the expectation was that the EDA tool should use the typical data, but this is not stated. The same observation can also be made for the waveform tables on pg. 69, [Composite Current] on pg. 71/72 and the [ISSO ***] keywords on pg. 56. The story gets more interesting when we consider how the I-V tables and the waveform voltages are related to each other by Ohm's law using the R_fixture load resistor value. One might argue that if the min/max data is missing from the waveform tables, the typical waveform data might be "adjusted" (scaled) relatively easily so that they would be in agreement by Ohm's law. One could even do the reverse when the min/max data is available in the waveform tables but are missing in the I-V tables. But things will get more complicated or perhaps impossible with the [ISSO ***] and/or [Composite Current] tables. Imagine a certain waveform which includes typ/min/max, but the [Composite Current] following it has only typ data (or the other way around). So the question I would like to clarify is whether the IBIS specification should define what to do in these cases, or perhaps impose some requirements on how the model maker should provide the data for these various keywords (i.e. require all of them to have or not have min/max data). Note that not all keywords fall into this category. For example, C_comp and its variants are relatively independent from I-V and waveform related keywords, so these would not have to be "matched" with having or not having min/max data. Questions, comments welcome... Thanks, Arpad ========================================================================== == == -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org |or ibis-request@eda-stds.org | |IBIS reflector archives exist under: | | http://www.eda-stds.org/ibis/email_archive/ Recent | http://www.eda-stds.org/ibis/users_archive/ Recent | http://www.eda-stds.org/ibis/email/ E-mail since 1993 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org |or ibis-request@eda-stds.org | |IBIS reflector archives exist under: | | http://www.eda-stds.org/ibis/email_archive/ Recent | http://www.eda-stds.org/ibis/users_archive/ Recent | http://www.eda-stds.org/ibis/email/ E-mail since 1993 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org |or ibis-request@eda-stds.org | |IBIS reflector archives exist under: | | http://www.eda-stds.org/ibis/email_archive/ Recent | http://www.eda-stds.org/ibis/users_archive/ Recent | http://www.eda-stds.org/ibis/email/ E-mail since 1993Received on Mon Jul 14 10:06:45 2014
This archive was generated by hypermail 2.1.8 : Mon Jul 14 2014 - 10:06:59 PDT