From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #238 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Monday, July 14 2014 Volume 01 : Number 238 ---------------------------------------------------------------------- Date: Mon, 14 Jul 2014 13:06:37 -0400 (EDT) From: Walter Katz Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns 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 1993 ------------------------------ Date: Mon, 14 Jul 2014 19:30:06 +0000 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns Walter, Thanks for your reply, but I wasn't talking about rows... I was talking about the case when the entire column is NA for min/max. Imagine a case when the I-V tables have all three corners filled, but the waveform tables have only the typ column filled. This is legal according to the spec. What is the EDA tool supposed to do? We can synthesize the min/max waveform tables so that the end points are calculated from the min/max I-V curve / load line intersection and then scale the typical waveform according to those calculated end points. This would set the amplitude correctly for the synthesized waveform tables. But what about the time scale? If the [Ramp] has min/max data, we could look at the slope in the min/max [Ramp] and scale the time axis of the synthesized waveform table according to that. Now we have a reasonable synthesized min/max waveform data. But what if the [ISSO ***] or [Composite Current] tables are missing min/max columns? Such synthesis may be more and more difficult or impossible, yet the specification allows any combination for missing or existing min/max columns. Shouldn't the spec spell out some rules on not allowing that to happen? Thanks, Arpad ====================================================================== - -----Original Message----- From: Walter Katz [mailto:wkatz@sisoft.com] Sent: Monday, July 14, 2014 12:07 PM To: Muranyi, Arpad; IBIS-users Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns 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 1993 ------------------------------ Date: Wed, 11 Jun 2014 09:35:44 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] full differential buffer IBIS modeling ---clarification This is a multipart message in MIME format. - ------=_NextPart_000_01CA_01CF8558.85A2F7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let=92s take an LVDS buffer as an example. Most LVDS buffers are designed = to work into a 100 Ohm differential load and the Vcm of most LVDS buffers is 1.2V but there are exceptions to this value. So the equivalent load seen by each side of the differential driver is 50 Ohms to 1.2V. When setting up the loads on the buffer typically the R_fixture is 50 Ohms and the V_fixture is 1.2V. Rref, Vref and Vmeas would be 50 Ohms, 1.2V and 1.2V respectfully. =20 With a LVDS buffer you cannot load it with a 50 Ohm resistor to ground, you have biased the driver way outside its normal operating range. You will not get the correct characteristics. ECL will have entirely different loads, the 50 Ohm resistor is connected to Vcc =96 2V so the Vref and V_fixture wi= ll be different for each corner. CML works with 50 Ohm resistors to Vdd, etc. These are all differential drivers but the loads are different. You need to look at the datasheet for the part to figure out the correct loading conditions. Very few, but there are some, differential drivers will function properly with a 50 Ohm load to ground.=20=20 =20 Regards, =20 Tom Dagostino =20 Teraspeed Labs 9999 SW Wilshire St. Suite 102 Portland, OR 97225 USA =20 971-279-5325 Office 971-279-5326 FAX 503-430-1065 Cell =20 tom@teraspeed.com=20 www.teraspeed.com =20=20 =20 Teraspeed Consulting Group LLC 16 Stormy Brook Road=20 Falmouth, ME 04105 401-284-1827 =20 From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Saravanan Ganesh Sent: Tuesday, June 10, 2014 11:39 PM To: Lynne Green; ibis-users@eda.org Subject: RE: [IBIS-Users] full differential buffer IBIS modeling - ---clarification =20 Hi Using =BD of R_diff to ground and simulating the V-T char dos not settle the outputs at required levels. actually according to the termination as shown in attachment the rl =3D50o= hm connected from each differential output to common cap and cap is connected to Vcm_rx w .r.t gnd. How to divide this in to half? And get ibis model correct? What values to be used in the Rfixture , vfixture, Rref ,Vref, Vmeas ,etc in .s2i file=20 Regards Saravanan.G =20 =20 From: Lynne Green [mailto:lgreen22@mindspring.com]=20 Sent: Friday, May 09, 2014 10:39 PM To: Saravanan Ganesh; ibis-users@eda.org Subject: Re: [IBIS-Users] full differential buffer IBIS modeling - ---clarification =20 Dear Saravanan, A differential buffer in IBIS 3.2 requires two buffer models, one for each output. To use s2ibis3: - -Use the SAME load to ground for EACH output.=20=20 - - Do not use a differential resistor between the two outputs. Use 1/2 of R_diff to ground. - - Run s2ibis3 once, using the inverting output pin, and create BUFFER1. Run it again for the non-inverting output pin, and create BUFFER2. Note that no other changes are made between the two runs. - - In the models, be sure to label the output type to indicate BUFFER1 is inverting and BUFFER2 is non-inverting.=20=20 For simulation, assign BUFFER1 to the inverting pin and BUFFER2 to the non-inverting pin. Under [Diff Pin], list the buffers with ZERO time offset (the time offset is captured in the V-t tables). At least one simulation, with R=3DRload, should be used to test the model before releasing it for us= e, another with a different R is recommended.. Hope this helps. PS: if you plan do this often, you can modify the s2ibis3 source to capture both outputs in just one run of s3ibis3. Not sure why no-one has shared their modification with the IBIS Open Forum. Cheers, Lynne Green retired On 5/9/2014 8:20 AM, Lance Wang wrote: Saravanan, The first, s2ibis3 can be used for simple single-end buffer only. It might not be satisfied for differential buffers. =20 The second, R_load in s2i is the same as R_fixture in the IBIS file.=20 =20 The third, full/true differential pair buffer IBIS extraction will not be handled by s2ibis3 correctly. Another word, you will never be able to get correct IBIS models thru s2ibis3 for your full differential buffers. =20 Hope this helps. =20 Lance Wang IO Methodology Inc. 978-266-8981 =20 SimDE MODEL, the best IBIS modeling tool in the market. http://www.iometh.com =20 =20 =20 =20 =20 From: Saravanan Ganesh Date: Friday, May 9, 2014 at 9:55 AM To: "ibis-users@eda.org" Subject: [IBIS-Users] full differential buffer IBIS modeling - ---clarification =20 Hi=20 I want to brief on the R_load I am using =20 I am creating IBIS model (Version 3.2) of a full differential buffer . I have also connected the termination shown in =93diffbuff_termination.png= =94 in differential buffer schematic.=20 =20 Even though I have connected the required termination in schematic itself , the .s2i file need R_load value to be supplied. Therefore I have used a High value resistor (R_load=3D100G ohm) in .s2i fil= e. =20 Hyperlinx =93Check file for IBIS spec conformance=94 gives following erro= r =85 =20 ERROR: Model OUTPUT_DIF: The [Rising Waveform]=20 with [R_fixture]=3D1e+011 Ohms and [V_fixture_max]=3D0.22V has MAX column DC endpoints of 0.08V and 0.31v, but an equivalent load applied to the model's I-V tables yields different voltages ( 0.08V and 0.35V), a difference of 0.01% and 16.09%, respectively.=20 =20 What could be wrong? What can I do to get rid of these errors and warnings? =20 Please mail me if any more clarification required ,Waiting for your replies. Thanks and regards Saravanan.G =20 =20 From: Saravanan Ganesh=20 Sent: Thursday, May 08, 2014 8:04 PM To: 'ibis-users@eda.org ' Subject: full differential buffer IBIS modeling =20 Hi=20 I am creating IBIS model (Version 3.2) of a full differential buffer . I have also connected the termination shown in =93diffbuff_termination.png= =94 in differential buffer schematic. Therefore I took R_load =3D 100G ohm in .s2i file, so that only load in schematic are effective. Hyperlinx =93Check file for IBIS spec conformance=94 gives following erro= r =85 =20 ERROR: Model OUTPUT_DIF: The [Rising Waveform]=20 with [R_fixture]=3D1e+011 Ohms and [V_fixture_max]=3D0.22V has MAX column DC endpoints of 0.08V and 0.31v, but an equivalent load applied to the model's I-V tables yields different voltages ( 0.08V and 0.35V), a difference of 0.01% and 16.09%, respectively.=20 =20 What could be wrong? What can I do to get rid of these errors and warnings? =20 Thanks and regards Saravanan.G - --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner, and is=20 believed to be clean.=20 - --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner, and is=20 believed to be clean.=20 =20 - --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner, and is=20 believed to be clean.=20 - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------=_NextPart_000_01CA_01CF8558.85A2F7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Let’s take an LVDS buffer as an example= .=A0 Most LVDS buffers are designed to work into a 100 Ohm differential loa= d and the Vcm of most LVDS buffers is 1.2V but there are exceptions to this= value.=A0 So the equivalent load seen by each side of the differential dri= ver is 50 Ohms to 1.2V.=A0 When setting up the loads on the buffer typicall= y the R_fixture is 50 Ohms and the V_fixture is 1.2V.=A0 Rref, Vref and Vme= as would be 50 Ohms, 1.2V and 1.2V respectfully.=A0

<= p class=3DMsoNormal> <= /p>

With a LVDS buffer yo= u cannot load it with a 50 Ohm resistor to ground, you have biased the driv= er way outside its normal operating range.=A0 You will not get the correct = characteristics.=A0 =A0=A0ECL will have entirely different loads, the 50 Oh= m resistor is connected to Vcc – 2V so the Vref and V_fixture will be= different for each corner.=A0 CML works with 50 Ohm resistors to Vdd, etc.= =A0 These are all differential drivers but the loads are different. You nee= d to look at the datasheet for the part to figure out the correct loading c= onditions.=A0 Very few, but there are some, differential drivers will funct= ion properly with a 50 Ohm load to ground.=A0

 

Regards,<= /p>

 

Tom Dagostin= o

<= o:p> 

Teraspeed Labs

9999 SW Wilshire St.

Suite 102

Portland, OR 97225

USA

 <= /span>

971-279-5325= =A0 Office

971-279-5326=A0=A0 FAX

503-430-1065=A0 Cell

 

<= p class=3DMsoNormal>tom@teraspeed.com

www.t= eraspeed.com

 

Teraspeed Consulting Group LLC

16 Stormy Brook Road

Falmouth,= ME 04105

401-284-1827

 

From: owner-ibis-users@eda.org= [mailto:owner-ibis-users@eda.org] On Behalf Of Saravanan Ganesh
= Sent: Tuesday, June 10, 2014 11:39 PM
To: Lynne Green; ibi= s-users@eda.org
Subject: RE: [IBIS-Users] full differential buffe= r IBIS modeling ---clarification

 

Hi

Using =BD of R_diff to ground and simulating the V-T char dos not= settle the outputs at required levels.

actually according to the termination = as shown  in attachment the rl =3D50ohm connected from each differenti= al output  to common cap and cap is connected to Vcm_rx w .r.t  g= nd.

How to divide this in to half? And get ibis model correct?

What values  = to be used in the Rfixture , vfixture,  Rref ,Vref, Vmeas ,etc in .s2i= file

Regards

Saravanan.G

 

 

From: Lynne Green [mailto:lgreen22@mindspring.com]
= Sent: Friday, May 09, 2014 10:39 PM
To: Saravanan Ganesh; ibis-users@eda.org
Subject: Re: [IBIS-Users] full differential buffer IBIS modeling ---clarification<= /span>

 

=

Dear Saravanan,

A differential buffer in I= BIS 3.2 requires two buffer models, one for each output.

To use s2ib= is3:
-Use the SAME load to ground for EACH output. 
- Do not us= e a differential resistor between the two outputs.  Use 1/2 of R_diff = to ground.
- Run s2ibis3 once, using the inverting output pin, and creat= e BUFFER1.  Run it again for the non-inverting output pin, and create = BUFFER2.  Note that no other changes are made between the two runs.- In the models, be sure to label the output type to indicate BUFFER1 is i= nverting and BUFFER2 is non-inverting. 

For simulation, assign= BUFFER1 to the inverting pin and BUFFER2 to the non-inverting pin.  U= nder [Diff Pin], list the buffers with ZERO time offset (the time offset is= captured in the V-t tables).  At least one simulation, with R=3DRload= , should be used to test the model before releasing it for use, another wit= h a different R is recommended..

Hope this helps.

PS: if you = plan do this often, you can modify the s2ibis3 source to capture both outpu= ts in just one run of s3ibis3.  Not sure why no-one has shared their m= odification with the IBIS Open Forum.

Cheers,
Lynne Green
reti= red


On 5/9/2014 8:20 AM, Lance Wang wrote:

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>
Saravanan,

The first, s2ibis3 can be used for simple single-end buffer only. It might= not be satisfied for differential buffers.

 

The sec= ond, R_load in s2i is the same as R_fixture in the IBIS file. 

 

The third, full/true differential pair buffer IBIS extract= ion will not be handled by s2ibis3 correctly. Another word, you will never = be able to get correct IBIS models thru s2ibis3 for your full differential = buffers.

 

Hope this helps.

=

 

Lance Wang

IO Methodology= Inc.

978-266-8981=

 

=

SimDE MODEL, the best IBIS modeling tool in= the market.

 

 <= o:p>

 

 

 

From: Sar= avanan Ganesh <Saravanan.= Ganesh@onsemi.com>
Date: Friday, May 9, 2014 at 9:55 AMTo: "ibis-users@eda.org<= /a>" <ibis-users@eda.org&= gt;
Subject: [IBIS-Users] full differential buffer IBIS modeling = - ---clarification

 

Hi

I want to &n= bsp;brief on the R_load  I am using

 

I am creating  IBIS = model (Version 3.2) of a full differential buffer .

I have also  connected the termination shown in “di= ffbuff_termination.png” in differential buffer schematic. =

 

Even though I ha= ve connected the required termination in schematic itself , the .s2i file n= eed R_load value to be supplied.

= Therefore I have used a High value resistor (= R_load=3D100G ohm) in .s2i file.

=  

Hyperlinx “Check file for I= BIS spec conformance”  gives following  error …<= /o:p>

 

ERR= OR: Model OUTPUT_DIF: The [Rising Waveform]

      with [R_fixture]=3D1e+011 Ohms and= [V_fixture_max]=3D0.22V

  &nb= sp;   has MAX column DC endpoints of  0.08V and  0.31v,= but

      an e= quivalent load applied to the model's I-V tables yields

      different voltages ( 0.08V a= nd  0.35V),

    = ;  a difference of  0.01% and 16.09%, respectively.

 

What could be wrong? What = can I do to get rid of these errors and warnings?

 

Plea= se mail me if any more clarification required ,Waiting for your replies.

Thanks and regards

Saravanan.G

<= p class=3DMsoNormal> <= /p>

 

From: Saravanan Ganesh
Sent:= Thursday, May 08, 2014 8:04 PM
To: 'ibis-users@eda.org'
Subject: full differenti= al buffer IBIS modeling

 

Hi

I am creating  IBIS model (Version 3.2) of a full differentia= l buffer .

I have also  connected t= he termination shown in “diffbuff_termination.png” in different= ial buffer schematic. Therefore  I took R_load =3D 100G ohm in .s2i fi= le, so that only load in schematic are effective.

Hyperlinx “Check file for IBIS spec conformance” = ; gives following  error …

&n= bsp;

ERROR: Model OUTPUT_DIF: The [Risin= g Waveform]

    &nb= sp; with [R_fixture]=3D1e+011 Ohms and [V_fixture_max]=3D0.22V

      has MAX column D= C endpoints of  0.08V and  0.31v, but

      an equivalent load applied to the mo= del's I-V tables yields

  &nbs= p;   different voltages ( 0.08V and  0.35V),

<= p class=3DMsoNormal>      a difference of  0.= 01% and 16.09%, respectively.

<= span style=3D'font-size:9.5pt;font-family:"Arial","sans-serif";color:#33333= 3'> 

What could be wrong? What can I do to get rid of these err= ors and warnings?

 

Thanks and regards

Saravanan.= G


--
This message ha= s been scanned for viruses and
dangerous content by MailScanner, and is
believed to be cle= an.


-- =
This message has been scanned for viruses and
dangerous content by = MailScanner, and is believed to be clean.

=  


--
Th= is message has been scanned for viruses and
dangerous content by MailScanner, and is
belie= ved to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------=_NextPart_000_01CA_01CF8558.85A2F7E0-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Mon, 9 Jun 2014 16:42:29 +0000 From: "Mirmak, Michael" Subject: [IBIS-Users] Presentations from the IBIS Summit at DAC 2014 now available! - --_000_942B8AE05D9831409A64517FFA4C46015E487008fmsmsx120amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The presentations from Thursday's IBIS Summit at DAC 2014 are now available= free through the URL below: http://www.eda.org/ibis/summits/jun14/ Thanks to our co-sponsor, the EDA Consortium, for making the event possible= , and to our presenters and attendees for their support! Michael Mirmak Chair, IBIS Open Forum http://www.eda.org/ibis/ - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E487008fmsmsx120amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The presentations from Thursday's IBIS Summit at DAC= 2014 are now available free through the URL below:

 

        &nbs= p;       http://www.eda.org/ibis/summits/jun14/

 

Thanks to our co-sponsor, the EDA Consortium, for ma= king the event possible, and to our presenters and attendees for their supp= ort!

 

Michael Mirmak=

Chair, IBIS Open Forum

http://www.eda.org/ibis/


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E487008fmsmsx120amrcor_-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Wed, 18 Jun 2014 04:41:03 +0000 From: "sandeep.kumar@halla.com" Subject: [IBIS-Users] Ibis Models - --_000_92f99a209f894698a441dd06024238afHGMSICAS01HALLAGRP_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIHNlYXJjaGVkIGEgbG90IGZvciB0aGUgSWJpcyBtb2Rl bCBvZiBQQ0llICxTQVRBICYgSERNSSBidXQgbm93aGVyZSBJIGhhdmUgZ290 IHRoZXNlIG1vZGVscyAuIElmIGFueW9uZSBpcyBoYXZpbmcgdGhlc2UgbW9k ZWxzIGtpbmRseSByZXZlcnQgYmFjay4NCg0KVGhhbmtzICYgUmVnYXJkcw0K U2FuZGVlcCBLdW1hcg0KRW5naW5lZXItSSwgRUNVIEhhcmR3YXJlIHRlYW0N Ck1hbmRvIFNvZnR0ZWNoIEluZGlhIFB2dC4gTHRkLiwNCk1vYmlsZSA6ICs5 MS05OTcxODczMDc5DQplLW1haWw6IFNhbmRlZXAua3VtYXJAaGFsbGEuY29t DQoNCg0KDQoNCg0KDQoNCg0KDQoNCgotLSAKVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kCmRhbmdlcm91cyBjb250ZW50 IGJ5IE1haWxTY2FubmVyLCBhbmQgaXMKYmVsaWV2ZWQgdG8gYmUgY2xlYW4u Cgo= - --_000_92f99a209f894698a441dd06024238afHGMSICAS01HALLAGRP_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I searched a lot for the Ibis model of PCIe ,SATA &a= mp; HDMI but nowhere I have got these models . If anyone is having these mo= dels kindly revert back.

 

Thanks & Regards

Sandeep Kumar<= o:p>

Engineer-I, = ECU Hardware team

Mando Softte= ch India Pvt. Ltd.,

Mobile : = 3;91-9971873079<= o:p>

e-mail: San= deep.kumar@halla.com

=

 

 

 
=

 

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --_000_92f99a209f894698a441dd06024238afHGMSICAS01HALLAGRP_-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Tue, 17 Jun 2014 21:34:34 +0000 From: "Mirmak, Michael" Subject: [IBIS-Users] IBISCHK6 IBIS 6.0 syntax parser executables now available! - --_000_942B8AE05D9831409A64517FFA4C46015E4A0DECfmsmsx120amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IBIS Open Forum is pleased to announce the availability of executables = for the IBISCHK6 Golden Parser, version 6.0.0. This parser supports all IB= IS versions through 6.0. In addition, this release resolves parser BUG rep= orts 147 through 149, 152 through 154, and 156, as listed at: http://www.eda.org/ibis/bugs/ibischk/ The executables, available free of charge, can be found at: http://www.eda.org/ibis/ibischk6/ Executables are available for DOS32 (Microsoft Windows*) and Linux operatin= g systems. Source code licensees will receive updates shortly. Those wish= ing to obtain a source code license may feel free to contact me or any memb= er of the IBIS Open Forum board directly (please do not reply to all). Note that there is no "installer" per se for these executables. Once uncom= pressed, the executables may be run at the operating system command line. Thank you for your support of IBIS! - - Michael Mirmak Intel Corp. Chair, IBIS Open Forum http://www.eda.org/ibis/ - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E4A0DECfmsmsx120amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IBIS Open Forum is pleased to announce the avail= ability of executables for the IBISCHK6 Golden Parser, version 6.0.0. = This parser supports all IBIS versions through 6.0.  In addition, thi= s release resolves parser BUG reports 147 through 149, 152 through 154, and 156, as listed at:

 

        &nbs= p;       http://www.eda.org/ibis/bugs/ibischk/   

 

The executables, available free of charge, can be fo= und at:

 

        &nbs= p;       http://www.eda.org/ibis/ibischk6/

 

Executables are available for DOS32 (Microsoft Windo= ws*) and Linux operating systems.  Source code licensees will receive = updates shortly.  Those wishing to obtain a source code license may fe= el free to contact me or any member of the IBIS Open Forum board directly (please do not reply to all).

 

Note that there is no "installer" per se f= or these executables.  Once uncompressed, the executables may be run a= t the operating system command line.

 

Thank you for your support of IBIS!

 

- Michael Mirmak

  Intel Corp.

  Chair, IBIS Open Forum

  http://w= ww.eda.org/ibis/


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E4A0DECfmsmsx120amrcor_-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Fri, 30 May 2014 01:31:42 +0000 From: "Mirmak, Michael" Subject: [IBIS-Users] Agenda, IBIS Summit at DAC - June 5, 2014 - --_000_942B8AE05D9831409A64517FFA4C46015E480BA5fmsmsx120amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please join us for the free IBIS Summit at DAC in San Francisco next week! Presentation materials will be available on-line after the event. DAC information, including registration, available at http://www.dac.com. - ----------------------------------------------------------------------- AGENDA - IBIS SUMMIT MEETING Thursday, June 5, 2014 Moscone Center San Francisco, California Room 202-210 Moscone South, East Mezzanine (look for signs) Sponsored by the EDA Consortium and the IBIS Open Forum - ----------------------------------------------------------------------- (titles, order, and times subject to change) 8:00 AM Refreshments & Sign In 8:30 AM Official Opening - Welcome to Summit - Introductions 8:45 AM Chair's Status Report Michael Mirmak, Intel Corporation 9:15 AM Overview of IEEE P2401 LSI-Package-Board Interoperable Design Genichi Tanaka, Renesas Electronics 10:00 AM BREAK 10:20 AM IBIS Interconnect BIRD Walter Katz, Signal Integrity Software (SiSoft) 11:20 AM IBISCHK5/6 Specification Document Update Bob Ross, Teraspeed Consulting Group Mike LaBonte, Signal Integrity Software (SiSoft) 11:50 AM ELECTION OF OFFICERS 12:05 PM LUNCH Pre-registration required 1:00 PM IBIS File Inspection Using ibisinf - A Basic Utility for the 80= /20 Rule Michael Schaeder, Zuken Presented by Bob Ross, Teraspeed Consulting Group 1:30 PM Solving Receiver Electrical Test Challenges using IBIS-AMI Mode= ling Techniques Venkatesh Avula, Avago 2:15 PM BIRD147 Backchannel Support Overview Brad Brim, Cadence Design Systems 3:00 PM Backchannel Proposal Overview Walter Katz, Signal Integrity Software (SiSoft) 2:55 PM IBIS-AMI Backchannel Discussion 3:10 PM BREAK 3:25 PM IBIS Summary Documents Bob Ross, Teraspeed Consulting Group 3:55 PM Open Discussion 4:45 PM Concluding Items - Next IBIS Open Forum Meeting: June 20, 2014 - ----------------------------------------------------------------- - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E480BA5fmsmsx120amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Please join us for the free IBIS Summit at DAC in San Francisco next week!<= o:p>

=  

= Presentation materials will be available on-line after the event.

=  

= DAC information, including registration, available at http://www.dac.com.  

=  

= - -----------------------------------------------------------------------

=  

=             &nb= sp;         AGENDA - IBIS SUMMIT ME= ETING

=  

=             &nb= sp;            Thurs= day, June 5, 2014

=  

=  

=             &nb= sp;            =     Moscone Center

=             &nb= sp;           San Francis= co, California

=  

=  

=              &n= bsp;            = ;   Room 202-210

=             &nb= sp;        Moscone South, East Mezzanine=

=             &nb= sp;            =   (look for signs)

=  

=  

=         Sponsored by the EDA Consortium = and the IBIS Open Forum        

=  

= - -----------------------------------------------------------------------

=  

=              (t= itles, order, and times subject to change)     

=  

=  

= 8:00 AM     Refreshments & Sign In

=  

= 8:30 AM     Official Opening

=             - Welcom= e to Summit

=             - Introd= uctions

=  

= 8:45 AM     Chair's Status Report

=             Michael = Mirmak, Intel Corporation

=  

= 9:15 AM     Overview of IEEE P2401 LSI-Package-Board In= teroperable Design

=             Genichi = Tanaka, Renesas Electronics

=  

= 10:00 AM    BREAK

=  

= 10:20 AM    IBIS Interconnect BIRD

=             Walter K= atz, Signal Integrity Software (SiSoft)

=  

= 11:20 AM    IBISCHK5/6 Specification Document Update

=             Bob Ross= , Teraspeed Consulting Group

=             Mike LaB= onte, Signal Integrity Software (SiSoft)

=  

= 11:50 AM    ELECTION OF OFFICERS

=            

= 12:05 PM    LUNCH

=             Pre-regi= stration required

=  

= 1:00 PM     IBIS File Inspection Using ibisinf - A Basi= c Utility for the 80/20 Rule

=             Michael = Schaeder, Zuken

=             Presente= d by Bob Ross, Teraspeed Consulting Group

=  

= 1:30 PM     Solving Receiver Electrical Test Challenges= using IBIS-AMI Modeling Techniques

=             Venkates= h Avula, Avago

=  

= 2:15 PM     BIRD147 Backchannel Support Overview

=             Brad Bri= m, Cadence Design Systems

=  

= 3:00 PM     Backchannel Proposal Overview

=             Walter K= atz, Signal Integrity Software (SiSoft)

=  

= 2:55 PM     IBIS-AMI Backchannel Discussion<= /span>

=  

= 3:10 PM     BREAK

=  

= 3:25 PM     IBIS Summary Documents

=             Bob Ross= , Teraspeed Consulting Group

=  

= 3:55 PM     Open Discussion

=  

= 4:45 PM     Concluding Items

=             - Next I= BIS Open Forum Meeting: June 20, 2014

=  

= - -----------------------------------------------------------------


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E480BA5fmsmsx120amrcor_-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Fri, 11 Jul 2014 18:59:25 -0700 From: "Bob Ross" 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 ------------------------------ Date: Thu, 29 May 2014 13:25:13 +0000 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] Issue with LVPECL output - --_000_EB55FD6CF8C21444BE032D68DDA5FB99B2CFFC6FNAMBX02mgcmento_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2lyaWphLA0KDQpUaGUgaW5mb3JtYXRpb24geW91IHN1cHBsaWVkIGlzIG5v dCBzdWZmaWNpZW50IHRvIGRldGVybWluZQ0KdGhlIHByb2JsZW0geW91IGhh dmUuDQoNCklmIHRoaXMgaXMgYSBIeXBlckx5bnggcHJvYmxlbSwgSSB3b3Vs ZCBzdWdnZXN0IHRvIGNvbnRhY3QNCnlvdXIgbmVhcmVzdCBNZW50b3Igc3Vw cG9ydCBwZW9wbGUuICBJZiBpdCBpcyBhIG1vZGVsDQpwcm9ibGVtLCBjb250 YWN0IHRoZSBtb2RlbCBtYWtlcuKAmXMgc3VwcG9ydCBwZW9wbGUuDQoNClRo YW5rcywNCg0KQXJwYWQNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpGcm9tOiBv d25lci1pYmlzLXVzZXJzQGVkYS5vcmcgW21haWx0bzpvd25lci1pYmlzLXVz ZXJzQGVkYS5vcmddIE9uIEJlaGFsZiBPZiBHaXJpamEgViBDaG91Z2FsYQ0K U2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCA3OjI1IEFNDQpUbzogaWJp cy11c2Vyc0BlZGEub3JnDQpDYzogaWJpcy1pbmZvQGVkYS5vcmcNClN1Ympl Y3Q6IFtJQklTLVVzZXJzXSBJc3N1ZSB3aXRoIExWUEVDTCBvdXRwdXQNCg0K SGkgQWxsLA0KDQpJIGhhdmUgdHJpZWQgdXNpbmcgNXA0OXY1OTAxICh2ZXJz YUNsb2NrQDUgKSBJQklTIG1vZGVsLiBJJ20gdHJ5aW5nIHRvDQpvYnNlcnZl IExWUEVDTCBvdXRwdXRzIHdpdGggcHJvcGVyIHRlcm1pbmF0aW9uLiBIeXBl cmx5bnggdG9vbCBpcyB1c2VkIGZvcg0Kc2ltdWxhdGlvbi4gU25hcHNob3Qg b2YgdGhlIHNjaGVtYXRpYyBhbmQgc2ltdWxhdGlvbiBvdXRwdXQgYXJlIGF0 dGFjaGVkLg0KDQpUaGUgTFZQRUNMIG91dHB1dCBpcyBub3QgYXQgYWxsIGRp ZmZlcmVudGlhbCBvdXRwdXQuIFZPSCAsIFZPTCBhcmUgc2Vjb25kYXJ5DQpj b25jZXJuLg0KDQpDb3VsZCBhbnlib2R5IHN1Z2dlc3Qgd2hhdCBpcyB3cm9u ZyBoZXJlLg0KDQpBIHF1aWNrIHJlcGx5IHdvdWxkIGJlIGhpZ2hseSBhcHBy ZWNpYXRlZC4NCg0KVGhhbmtzLA0KR2lyaWphDQpUaGlzIG1lc3NhZ2UgYW5k IGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBDeXByZXNzIChvciBpdHMg c3Vic2lkaWFyaWVzKSBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElmIGl0 IGhhcyBiZWVuIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgYWR2aXNlIHRo ZSBzZW5kZXIgYW5kIGltbWVkaWF0ZWx5IGRlbGV0ZSB0aGlzIG1lc3NhZ2Uu DQotLQ0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kDQpkYW5nZXJvdXMgY29udGVudCBieSBNYWlsU2Nhbm5lcjxodHRw Oi8vd3d3Lm1haWxzY2FubmVyLmluZm8vPiwgYW5kIGlzDQpiZWxpZXZlZCB0 byBiZSBjbGVhbi4NCgotLSAKVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kCmRhbmdlcm91cyBjb250ZW50IGJ5IE1haWxT Y2FubmVyLCBhbmQgaXMKYmVsaWV2ZWQgdG8gYmUgY2xlYW4uCgo= - --_000_EB55FD6CF8C21444BE032D68DDA5FB99B2CFFC6FNAMBX02mgcmento_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5v cmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0 Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9z b2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0N Ci8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkdpcmlqYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlRoZSBpbmZvcm1hdGlvbiB5b3Ugc3VwcGxpZWQgaXMgbm90IHN1 ZmZpY2llbnQgdG8gZGV0ZXJtaW5lPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPnRoZSBwcm9ibGVtIHlvdSBoYXZlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+SWYgdGhpcyBpcyBhIEh5cGVyTHlueCBwcm9ibGVt LCBJIHdvdWxkIHN1Z2dlc3QgdG8gY29udGFjdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj55b3VyIG5lYXJlc3QgTWVudG9yIHN1cHBvcnQg cGVvcGxlLiZuYnNwOyBJZiBpdCBpcyBhIG1vZGVsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPnByb2JsZW0sIGNvbnRhY3QgdGhlIG1vZGVs IG1ha2Vy4oCZcyBzdXBwb3J0IHBlb3BsZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkFycGFkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IG93bmVyLWliaXMtdXNlcnNAZWRhLm9yZyBb bWFpbHRvOm93bmVyLWliaXMtdXNlcnNAZWRhLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+R2lyaWphIFYgQ2hvdWdhbGE8YnI+DQo8Yj5TZW50OjwvYj4g VGh1cnNkYXksIE1heSAyOSwgMjAxNCA3OjI1IEFNPGJyPg0KPGI+VG86PC9i PiBpYmlzLXVzZXJzQGVkYS5vcmc8YnI+DQo8Yj5DYzo8L2I+IGliaXMtaW5m b0BlZGEub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJQklTLVVzZXJzXSBJ c3N1ZSB3aXRoIExWUEVDTCBvdXRwdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaTxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4gQWxsPC9zcGFuPiw8YnI+DQo8YnI+DQpJIGhh dmUgdHJpZWQgdXNpbmcgNXA0OXY1OTAxICh2ZXJzYUNsb2NrQDUgKSBJQklT IG1vZGVsLiBJJ20gdHJ5aW5nIHRvIDxicj4NCm9ic2VydmUgTFZQRUNMIG91 dHB1dHMgd2l0aCBwcm9wZXIgdGVybWluYXRpb24uIEh5cGVybHlueCB0b29s IGlzIHVzZWQgZm9yIDxicj4NCnNpbXVsYXRpb24uIDxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5TPC9zcGFuPm5hcHNob3Qgb2YgPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPg0KdGhlIDwvc3Bhbj5zY2hlbWF0aWMgYW5kIHNp bXVsYXRpb24gb3V0cHV0IDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5h cmU8L3NwYW4+IGF0dGFjaGVkLg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIExWUEVDTCBvdXRwdXQgaXMgbm90 IGF0IGFsbCBkaWZmZXJlbnRpYWwgb3V0cHV0LiBWT0ggLCBWT0wgYXJlIHNl Y29uZGFyeQ0KPGJyPg0KY29uY2Vybi48YnI+DQo8YnI+DQpDb3VsZCBhbnli b2R5IHN1Z2dlc3Qgd2hhdCBpcyB3cm9uZyBoZXJlLiAmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BIHF1aWNrIHJlcGx5 IHdvdWxkIGJlIGhpZ2hseSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+R2lyaWphPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gQ3lwcmVzcyAob3IgaXRz IHN1YnNpZGlhcmllcykgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiBp dCBoYXMgYmVlbiByZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNlIGFkdmlzZSB0 aGUgc2VuZGVyIGFuZCBpbW1lZGlhdGVseSBkZWxldGUgdGhpcyBtZXNzYWdl Lg0KPGJyPg0KLS0gPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIDxicj4NCmRhbmdlcm91cyBjb250ZW50IGJ5 IDxhIGhyZWY9Imh0dHA6Ly93d3cubWFpbHNjYW5uZXIuaW5mby8iPjxiPk1h aWxTY2FubmVyPC9iPjwvYT4sIGFuZCBpcw0KPGJyPg0KYmVsaWV2ZWQgdG8g YmUgY2xlYW4uIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YnIgLz4tLSAK PGJyIC8+VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kCjxiciAvPmRhbmdlcm91cyBjb250ZW50IGJ5CjxhIGhyZWY9Imh0 dHA6Ly93d3cubWFpbHNjYW5uZXIuaW5mby8iPjxiPk1haWxTY2FubmVyPC9i PjwvYT4sIGFuZCBpcwo8YnIgLz5iZWxpZXZlZCB0byBiZSBjbGVhbi4KPC9i b2R5Pg0KPC9odG1sPg0K - --_000_EB55FD6CF8C21444BE032D68DDA5FB99B2CFFC6FNAMBX02mgcmento_-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Fri, 23 May 2014 00:31:18 +0000 From: "Mirmak, Michael" Subject: [IBIS-Users] IBIS Summit at DAC 2014 - Final Call for Presentations and Participation - --_000_942B8AE05D9831409A64517FFA4C46015E47455Bfmsmsx120amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IBIS Open Forum is holding an IBIS Summit meeting as a colocated confer= ence at the Design Automation Conference, on Thursday, June 5, 2014 in San = Francisco, California. Thanks to the EDA Consortium for their kind sponsor= ship! IBIS Summits are intended to promote exchanges of ideas and methods among u= sers and developers of IBIS models and associated tools and specifications,= such as Touchstone and IBIS-ISS. The meeting is FREE. You are invited to register and also to submit presen= tation proposals. Registration for the Summit is now possible as part of = DAC registration through the DAC website at http://www.dac.com. Simply cli= ck on "Register Now" and be sure to select "IBIS Summit" under "Colocated C= onferences". We look forward to seeing you there! Michael Mirmak Chair, IBIS Open Forum =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IBIS Summit at DAC 2014 Final Call for Presentations and Participation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Time/Date: 08:00 - 17:00, Thursday, June 5, 2014 Location: Moscone Center 747 Howard St. San Francisco, California Rooms: 202-210 (Moscone South Building, East Mezzanine) Content: Presentations and Discussions Purpose: Solicit and exchange IBIS-related information and ide= as Sponsors: The EDA Consortium, IBIS Open Forum If your company would be interested in sponsoring this event, please contact Michael Mirmak (michael.mirmak@intel.c= om) DAC 2014: June 1 - 5, 2014 Registration: http://www.dac.com/ - ----------------------------------------------------------------------- BACKGROUND This meeting will be conducted as a formal IBIS Summit meeting. Presentations are expected to be publicly distributable and will be archi= ved in an electronic format. Presentations will be reviewed by the IBIS Open Forum Board for appropriateness before being accepted. Minutes of the meeting will be issued. The meeting is FREE and OPEN to everyone. Breaks with refreshments are p= lanned. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate. To register, please visit http://www.dac.com and be sure to select "IBIS = Summit" under "Colcoated Conferences". If you have any difficulty with registration for the IBIS Summit through = DAC, please provide the following information: Name: E-mail address: Company: Telephone: to Lance Wang (lwang@iometh.com) Deadline: May 29, 2014 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Some suggested subjects of interest are: - IBIS Model Development Experiences - Company IBIS Standards and Requirements - Generating & Validating IBIS Models - Future IBIS Developments and Requirements (e.g., IBIS-AMI) - Modeling of dedicated technology issues (e.g., connectors, and very high speed interfaces) - EMC/EMI and Power Integrity Issues - Related modeling issues (e.g., SPICE, S-Parameter modeling) - Experiences using IBIS in the PCB Design process Electronic Archival: We require electronic versions for so they can be projected, archived and made available to non-attendees. We prefer Microsoft PowerPoint* or Adobe PDF*. Please send presentations for processing and brief review. Otherwise please bring 20 copies to the meeting. If you plan a presentation, please supply: Title: Presenter: E-mail address: Company: Telephone: Estimated Time Required: Send this to: Bob Ross (bob@teraspeed.com) Deadline: May 23, 2014 Note, Vendor-specific or product promotional material is forbidden at IBIS Summits. Presentations must be submitted by the deadline for review. The IBIS Open Forum reserves the right to stop or reject a scheduled presentation that has not been reviewed. AGENDA The agenda includes presentations, discussions, breaks and refreshments. A complete agenda will be posted one week before the event. - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E47455Bfmsmsx120amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The IBIS Open Forum is holding an IBIS Summit meetin= g as a colocated conference at the Design Automation Conference, on Thursda= y, June 5, 2014 in San Francisco, California.  Thanks to the EDA Conso= rtium for their kind sponsorship!

 

IBIS Summits are intended to promote exchanges of id= eas and methods among users and developers of IBIS models and associated to= ols and specifications, such as Touchstone and IBIS-ISS. 

 

The meeting is FREE.  You are invited to regist= er and also to submit presentation proposals.   Registration for = the Summit is now possible as part of DAC registration through the DAC webs= ite at http://www.dac.com.  Simply click o= n “Register Now” and be sure to select “IBIS Summit”= ; under “Colocated Conferences”.

 

We look forward to seeing you there!

 

Michael Mirmak

Chair, IBIS Open Forum

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

         &nb= sp;            =     IBIS Summit at DAC 2014     &nb= sp;          

 

          Fi= nal Call for Presentations and Participation     &= nbsp;     

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

Time/Date:       =   08:00 - 17:00, Thursday, June 5, 2014

 

Location:       &= nbsp;      Moscone Center

747 Howa= rd St.

San Francisco, Californi= a

 

Rooms:       &nbs= p;         202-210 (Moscone South B= uilding, East Mezzanine)

 

Content:       &n= bsp;      Presentations and Discussions=

 

Purpose:       &n= bsp;      Solicit and exchange IBIS-related inform= ation and ideas

 

Sponsors:       &= nbsp;    The EDA Consortium, IBIS Open Forum

 

        &nbs= p;      If your company would be interested in spo= nsoring this

        &nbs= p;      event, please contact Michael Mirmak = (michael.mirmak@intel.com)

 

DAC 2014:       &= nbsp;    June 1 - 5, 2014

 

Registration:      http://www.dac.com/

 

----------------------------------------------------= - -------------------

 

BACKGROUND

 

  This meeting will be conducted as a formal IB= IS Summit meeting.

  Presentations are expected to be publicly dis= tributable and will be archived in an

  electronic format.  Presentations will b= e reviewed by the IBIS Open

  Forum Board for appropriateness before being = accepted. 

  Minutes of the meeting will be issued.

 

  The meeting is FREE and OPEN to everyone.&nbs= p; Breaks with refreshments are planned.

 

CALL FOR PARTICIPANTS

 

  People involved in IBIS Model development, ED= A tool development,

  and digital circuit design are invited to&nbs= p; participate.

 

  To register, please visit http://www.dac.com and be sure to select “IBIS Summit= ” under “Colcoated Conferences”.

 

  If you have any difficulty with registration = for the IBIS Summit through DAC, please provide the following information:<= o:p>

 

    Name:

    E-mail address: <= /p>

    Company:

    Telephone:

 

  to Lance Wang (lwang@iometh.com)

 

  Deadline: May 29, 2014

 

 

CALL FOR PRESENTATIONS

 

  We are seeking presentations from individuals= who have IBIS

  experiences or issues. Some suggested subject= s of interest are:

 

  - IBIS Model Development Experiences

  - Company IBIS Standards and Requirements

  - Generating & Validating IBIS Models

  - Future IBIS Developments and Requirements (= e.g., IBIS-AMI)

  - Modeling of dedicated technology issues (e.= g., connectors,

    and very high speed interfaces)

  - EMC/EMI and Power Integrity Issues

  - Related modeling issues (e.g., SPICE, S-Par= ameter modeling)

  - Experiences using IBIS in the PCB Design pr= ocess

 

  Electronic Archival:

 

  We require electronic versions for so they ca= n be projected, archived and

  made available to non-attendees.

 

  We prefer Microsoft PowerPoint* or Adobe PDF*= .

 

  Please send presentations for processing and = brief review.

  Otherwise please bring 20 copies to the meeti= ng.

 

  If you plan a presentation, please supply:

 

    Title:

    Presenter:

    E-mail address:

    Company:

    Telephone:

    Estimated Time Required:

 

  Send this to: Bob Ross (bob@teraspeed.com)

 

  Deadline: May 23, 2014

 

  Note, Vendor-specific or product promotional = material is forbidden

  at IBIS Summits.  Presentations must be = submitted by the deadline

  for review. The IBIS Open Forum reserves= the right to stop or

  reject a scheduled presentation that has= not been reviewed.

 

AGENDA

 

  The agenda includes presentations, discussion= s, breaks and

  refreshments. A complete agenda will be poste= d one week before

  the event.

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --_000_942B8AE05D9831409A64517FFA4C46015E47455Bfmsmsx120amrcor_-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Thu, 29 May 2014 10:17:27 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] Issue with LVPECL output This is a multipart message in MIME format. - ------=_NextPart_000_0E1F_01CF7B27.31F2A400 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The schematic was not included in the posting. But looking at the waveform= s I=E2=80=99ll take a stab at this issue. What is your termination on the = output? Is it a 50 Ohm resistor from each output to Vcc =E2=80=93 2V or is= it a 100 Ohm resistor tied between the two outputs? The former should wor= k, the latter will not work if this is a true ECL output. =20 Tom Dagostino =20 Teraspeed Labs 9999 SW Wilshire St. Suite 102 Portland, OR 97225 USA =20 971-279-5325 Office 971-279-5326 FAX 503-430-1065 Cell =20 tom@teraspeed.com=20 www.teraspeed.com =20=20 =20 Teraspeed Consulting Group LLC 16 Stormy Brook Road=20 Falmouth, ME 04105 401-284-1827 =20 From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf = Of Girija V Chougala Sent: Thursday, May 29, 2014 5:25 AM To: ibis-users@eda.org Cc: ibis-info@eda.org Subject: [IBIS-Users] Issue with LVPECL output =20 Hi All, I have tried using 5p49v5901 (versaClock@5 ) IBIS model. I'm trying to=20 observe LVPECL outputs with proper termination. Hyperlynx tool is used for= =20 simulation. Snapshot of the schematic and simulation output are attached.= =20 =20 The LVPECL output is not at all differential output. VOH , VOL are secondar= y=20 concern. Could anybody suggest what is wrong here.=20=20 =20 A quick reply would be highly appreciated. =20 Thanks, Girija This message and any attachments may contain Cypress (or its subsidiaries) = confidential information. If it has been received in error, please advise t= he sender and immediately delete this message.=20 - --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner, and is=20 believed to be clean.=20 - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------=_NextPart_000_0E1F_01CF7B27.31F2A400 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The schem= atic was not included in the posting.=C2=A0 But looking at the waveforms I= =E2=80=99ll take a stab at this issue.=C2=A0 What is your termination on th= e output?=C2=A0 Is it a 50 Ohm resistor from each output to Vcc =E2=80=93 2= V or is it a 100 Ohm resistor tied between the two outputs?=C2=A0 The forme= r should work, the latter will not work if this is a true ECL output.<= /o:p>

 

Tom Dagostino

 

Teraspeed Labs

9999 SW Wi= lshire St.

Suite 102<= /o:p>

Portland, OR 97225

USA

 

971-= 279-5325=C2=A0 Office

971-= 279-5326=C2=A0=C2=A0 FAX

5= 03-430-1065=C2=A0 Cell

 

tom@teraspeed.com

www.teraspeed.com

 

=

Teraspeed Consulting Group LLC

16 Stormy Brook Road

Falmouth, ME 04105

401-284-1827

 

Fr= om: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Beh= alf Of Girija V Chougala
Sent: Thursday, May 29, 2014 5:25 AM=
To: ibis-users@eda.org
Cc: ibis-info@eda.org
Sub= ject: [IBIS-Users] Issue with LVPECL output

=

 

Hi All,

I have tried using 5p49v5901 (versaC= lock@5 ) IBIS model. I'm trying to
observe LVPECL outputs with proper t= ermination. Hyperlynx tool is used for
simulation. Snapshot of the schem= atic and simulation output are attache= d.

 

The LVPECL output is= not at all differential output. VOH , VOL are secondary
concern.
Could anybody suggest what is wrong here.  

 

A quick reply would be hig= hly appreciated.

 <= /p>

Thanks,

Girija

This message and any attachments may contain = Cypress (or its subsidiaries) confidential information. If it has been rece= ived in error, please advise the sender and immediately delete this message= .
--
This message has been scanned for viruses and
dangerous co= ntent by MailScanner, a= nd is
believed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------=_NextPart_000_0E1F_01CF7B27.31F2A400-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Fri, 11 Jul 2014 17:44:52 +0000 From: "Muranyi, Arpad" 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 ------------------------------ Date: Fri, 18 Apr 2014 19:06:00 -0700 From: "Bob Ross" Subject: RE: [IBIS-Users] Strange implications of ISSO_P* keywords This is a multipart message in MIME format. - ------=_NextPart_000_0053_01CF5B39.3D23E5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael: The [ISSO_PU] and [ISSO_PD] keywords describe simulation implementation in terms of Ksso_pd and Ksso_pu multipliers to the K-tables used with [Pullup] and [Pulldown] tables. Therefore there is a strong implication that the keywords should be used only with I/O* and Output type buffers. The parser could be enhanced to prohibit Model_types Input*, Terminator, and Series for the [ISSO P*] keywords. Bob From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Mirmak, Michael Sent: Friday, April 18, 2014 6:01 PM To: 'ibis-users' (ibis-users@eda.org) Subject: [IBIS-Users] Strange implications of ISSO_P* keywords I was recently asked about IBIS and power-aware buffer modeling, but for *inputs*. At present, IBIS supports two sets of keywords for power-aware modeling: [Composite Current] and [ISSO_PU]/[ISSO_PD]. [Composite Current] requires the presence of [Rising Waveform] and/or [Falling Waveform], which in turn require output Model_types, such as Output, Open_sink, etc. However, there is no obvious requirement that [ISSO_PU]/[ISSO_PD] must be used with any particular Model_type at all. While there are notes about using the keywords with ECL buffers, and recommendations about the Open_drain, etc. types, no other mention of Model_type is made for these keywords in the specification. There are implications, though, in other language: the phrase "output transistors" is used, and there is no mention of Input or any I/O Model_type in the specification language for these keywords. Realistically, we should be concerned about SSO effects on input buffers connected to supplies shared with multiple transitioning outputs. Further, there's nothing in the time-dependent equations for the keywords that prevents the current distribution in the pullup and pulldown at an input from being calculated based on the V(t) of an incoming waveform at the pad. Finally, the parser has no problem with Model_type Input being used with [ISSO_PU] and [ISSO_PD]. Is there any reason why ISSO_P* cannot be used for input buffers? - - MM - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------=_NextPart_000_0053_01CF5B39.3D23E5E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael:

 

The [ISSO_PU] and [ISSO_PD] keywords describe simul= ation implementation

in terms of Ksso_pd and Ksso_pu multipliers to the K-tab= les used with [Pullup]

and [Pulldown] tables.     Therefor= e there is a strong implication that the keywords

should be used only with I/O= * and Output type buffers.

 

The parser could be enhanced to prohibit Model_= types Input*, Terminator, and Series

for the [ISSO P*] keywords.

 

Bob

 =

From: owner-ibis-users@e= da.org [mailto:owner-ibis-users@eda.org] On Behalf Of Mirmak, Michae= l
Sent: Friday, April 18, 2014 6:01 PM
To: 'ibis-users'= (ibis-users@eda.org)
Subject: [IBIS-Users] Strange implications = of ISSO_P* keywords

<= o:p> 

I was recently asked about IBIS an= d power-aware buffer modeling, but for *inputs*. 

 

At present= , IBIS supports two sets of keywords for power-aware modeling: [Composite C= urrent] and [ISSO_PU]/[ISSO_PD].  [Composite Current] requires the pre= sence of [Rising Waveform] and/or [Falling Waveform], which in turn require= output Model_types, such as Output, Open_sink, etc.

 

However, there is no= obvious requirement that [ISSO_PU]/[ISSO_PD] must be used with any particu= lar Model_type at all.  While there are notes about using the keywords= with ECL buffers, and recommendations about the Open_drain, etc. types, no= other mention of Model_type is made for these keywords in the specificatio= n.

 

There are implications, though, in other language: the phrase “o= utput transistors” is used, and there is no mention of Input or any I= /O Model_type in the specification language for these keywords.<= /p>

 

Realistic= ally, we should be concerned about SSO effects on input buffers connected t= o supplies shared with multiple transitioning outputs.  Further, there= ’s nothing in the time-dependent equations for the keywords that prev= ents the current distribution in the pullup and pulldown at an input from b= eing calculated based on the V(t) of an incoming waveform at the pad. = Finally, the parser has no problem with Model_type Input being used with [= ISSO_PU] and [ISSO_PD].

 

Is there any reason why ISSO_P* cannot be used fo= r input buffers?

 

-        = ;  MM

=  

 

 


--
This message has been = scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------=_NextPart_000_0053_01CF5B39.3D23E5E0-- - -------------------------------------------------------------------- |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 ------------------------------ Date: Mon, 14 Jul 2014 15:42:43 -0400 (EDT) From: Walter Katz Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns Arpad, What I meant to say is that if all data in an IV or VT Min or Max column is NA, then assume that all of the data in that column is the same as the Typ column. These models are effectively Typ only, so the EDA tool should assume the Min or Max columns are Typ, but the User should know that this model only has valid Typ data. This does not necessarily mean that the Model is bad, although I am always suspicious when I see models with NA in the Min and Max columns for IV or VT data. For SerDes devices Min and Max has less (or different) importance than in traditional models. 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 3:30 PM To: IBIS-users Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns Walter, Thanks for your reply, but I wasn't talking about rows... I was talking about the case when the entire column is NA for min/max. Imagine a case when the I-V tables have all three corners filled, but the waveform tables have only the typ column filled. This is legal according to the spec. What is the EDA tool supposed to do? We can synthesize the min/max waveform tables so that the end points are calculated from the min/max I-V curve / load line intersection and then scale the typical waveform according to those calculated end points. This would set the amplitude correctly for the synthesized waveform tables. But what about the time scale? If the [Ramp] has min/max data, we could look at the slope in the min/max [Ramp] and scale the time axis of the synthesized waveform table according to that. Now we have a reasonable synthesized min/max waveform data. But what if the [ISSO ***] or [Composite Current] tables are missing min/max columns? Such synthesis may be more and more difficult or impossible, yet the specification allows any combination for missing or existing min/max columns. Shouldn't the spec spell out some rules on not allowing that to happen? Thanks, Arpad ====================================================================== - -----Original Message----- From: Walter Katz [mailto:wkatz@sisoft.com] Sent: Monday, July 14, 2014 12:07 PM To: Muranyi, Arpad; IBIS-users Subject: RE: [IBIS-Users] A question on how to handle NA in the min/max columns 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 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 ------------------------------ End of ibis-users V1 #238 *************************