From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #137 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Thursday, January 28 2010 Volume 01 : Number 137 ---------------------------------------------------------------------- Date: Wed, 27 Jan 2010 16:17:36 -0800 From: Bob Ross Subject: [IBIS-Users] Agenda, IBIS Summit at DesignCon for February 4, 2010 IBIS Summit Participants: Below is the planned agenda. We look forward to some very interesting technical content and discussions. If you want to participate, please register directly with the information below: Name: E-mail address: Company: Telephone: Send to: Lance Wang Also DesignCon on-line registration closes on Thursday, noon Central time to take advantage of exhibition passes and discounts: http://www.designcon.com/2010/vip_passes/ibis.html Bob - ----------------------------------------------------------------------- AGENDA - IBIS SUMMIT MEETING Thursday, February 4, 2010 Santa Clara Convention Center Santa Clara, California Room: 203 in the Convention Center, Second Floor (look for signs) - ----------------------------------------------------------------------- 8:00 AM Refreshments & Sign In 8:30 AM Official Opening - Welcome to Summit - Introductions - Opens for Issues & Discussion Topics 8:45 AM IBIS Activities and Future Plans Bob Ross, Teraspeed Consulting Group 9:05 AM Top 10 Issues As Seen During IBIS Model Reviews Lynne Green, Green Streak Programs 9:25 AM IBIS Quality Checklist Rev. 2.0 Moshiul Haque and Randy Wolff, Micron Technology 9:55 AM Pin-Pair Oriented Extraction Method for Differential Pair IBIS Modeling Lance Wang, IO Methodology 10:15 AM BREAK 10:30 AM Signal Loop Inductance in [Pin] and [Package Model]s Randy Wolff, Micron Technology 11:00 AM An Introduction to Model Connection Protocols Brad Brim, Sigrity 11:20 AM Quality Metrics for S-parameter Models Yuriy Shlepnev, Simberian 12:00 PM LUNCH - (Hosted by Cisco Systems and IBIS Open Forum) Pre-registration required 1:00 PM SI/PI Co-Analysis and Linearity Indicator Myoung Joon Choi and Vishram Pandit, Intel Corporation 1:30 PM IBIS-ATM Task Group Report Arpad Muranyi, Mentor Graphics Corporation 1:40 PM Predicting BER with IBIS-AMI: Experiences Correlating SerDes Simulations and Measurement Todd Westerhoff*, Adge Hawes**, Michael Steinberger*, Kent Dramstad**, Walter Katz*, Barry Katz*, *Signal Integrity Software (SiSoft), and **IBM 2:20 PM Growing Pains with IBIS-AMI Modeling Arpad Muranyi, Mentor Graphics Corporation 2:45 PM BREAK 3:00 PM Open Discussion - Future Projects 4:45 PM Concluding Items - Next Open Forum Meeting: February 19, 2010 - European IBIS Summit: May 12, 2010, Hildesheim, Germany with Signal Propogation on Interconnects Workshop 5:00 PM End of Meeting Room Availability - ------------------------------------------------------------------ Sponsors: Cisco Systems, DesignCon, IBIS Open Forum DesignCon: February 1 - 4, 2010 Santa Clara Convention Center Santa Clara, California See http://www.designcon.com/ for more information. LIST OF NEARBY HOTELS See http://www.designcon.com/2010/hotel/index.asp for travel directions, hotels and other information. - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 18 Nov 2009 10:55:25 -0500 From: Eric Monteiro Subject: [IBIS-Users] AMI convolution - --_000_B66E0103B6CB5145AD5408F15549A1E8211ADC0DC2EXCHANGEadgen_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, I was hoping someone could clarify who is responsible for convolution in IB= IS-AMI (EDA tool, or the modeler). Clearly the convolution involving an FIR filter is upon the modeler, the co= nvolution I speak of is the one that is done with the channel response. My understanding has been as follows: (please correct me if I'm wrong) (a) -- (Tx IC) -- (passive channel) --(b)--(Rx IC) You force an impulse at (a), measure the response at (b). (b) is the analo= g channel response hAC(t). GetWave then needs a wave, which should be an i= deal bit train, convolved with the bit period (creates a piece wise linear = wave) which is then convolved with hAC(t) to produce the wave fed into GetW= ave. There was discussion as to whether the modeler or the EDA tool should= do the above convolution. Has it been decided who this task falls on? Best Regards, Eric Monteiro ________________________________ This communication contains confidential information intended only for the = addressee(s). If you have received this communication in error, please noti= fy us immediately and delete this communication from your mail box. - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --_000_B66E0103B6CB5145AD5408F15549A1E8211ADC0DC2EXCHANGEadgen_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = everyone,
 
I w= as hoping someone could clarify who is responsible for convolution in IBIS-= AMI (EDA tool, or the modeler).
 
Cle= arly the convolution involving an FIR filter is upon the modeler, the convo= lution I speak of is the one that is done with the channel response.=
 
My = understanding has been as follows: (please correct me if I'm wrong)<= /font>
 
(a)= -- (Tx IC) -- (passive channel) --(b)--(Rx IC)
 
You= force an impulse at (a), measure the response at (b).  (b) is the ana= log channel response hAC(t).  GetWave then needs a wave, which should = be an ideal bit train, convolved with the bit period (creates a piece wise linear wave) which is then convolved with hAC(t) to = produce the wave fed into GetWave.  There was discussion as to whether= the modeler or the EDA tool should do the above convolution.  Has it = been decided who this task falls on?
 
Bes= t Regards,
Eri= c Monteiro

This communication contains = confidential information intended only for the addressee(s). If you have re= ceived this communication in error, please notify us immediately and delete= this communication from your mail box.
--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --_000_B66E0103B6CB5145AD5408F15549A1E8211ADC0DC2EXCHANGEadgen_-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Fri, 22 Jan 2010 14:58:26 -0000 From: "Nikonchuk Sergey-R6294C" Subject: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and proposed Solutions This is a multi-part message in MIME format. - ------_=_NextPart_001_01CA9B73.54A2F7B7 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA9B73.54A2F7B7" - ------_=_NextPart_002_01CA9B73.54A2F7B7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear IBIS Users Community. This is a first time when I send e-mail to the IBIS community. So, be patient, please, if I am use wrong e-mail address or asking questions which one already clarified in some documentation. Just point me on right source. My particular questions that I hope to get answers highlighted below as "Q1, Q2, Q3" =20 During detailed evaluation of IBIS characterization flow, especially for ODT (On-Die Termination) cells, we find some issues in Existing s2ibis3 implementation for Clamp current capturing and printing in to IBIS model. =20 1. The Voltage range not cover Max condition for [Pullup]/[Pulldown]/[GND_clamp]/[POWER_clamp] I-V Curves As recommended by IBIS standards and Cookbook , the range for the IV curves have to be -Vcc::2*Vcc Now, for "Vcc" value the "Typ" value used. It mean, if we have Typ Vcc =3D1.8V +/- 0.1V for Max/Min conditions, we have -1.8V::3.6V range for IV curves, which one cover Typ and Min recommendation, But not enough for Max condition, which one should be -1.9V::3.8V =20 I suggest to extend the range for IV Curves capturing up to Max [Voltage Range] value. That's have to be applied for All 4 IV curves - [Pullup]/[Pulldown]/[GND clamp]/[POWER clamp]=20 =20 Q1. Is there any particular reasons, comments - Why IV curves referenced to Typ Vref? Is there concern to extend IV ranges up to Max Vref ? =20 =20 2. The Minimum recommended range for Clamp IV capturing cause non-monotonysity issue in Final IBIS models. Existing implementation of s2ibis3 Assume the Minimum Voltage ranges for Clamp Curves: [GND_clamp] -Vcc::Vcc [POWER_clamp] Vcc:2*Vcc (Ground referenced) =20 Below is example: =20 [Voltage Range] 3.3000V 3.0000V 3.6000V |=20=20 [GND_clamp]=20 |Voltage I(typ) I(min) I(max) |=20=20 -3.30 -3.5860A -3.6101A -3.4617A -3.23 -3.4782A -3.5024A -3.3533A -3.16 -3.3704A -3.3947A -3.2450A ..... 3.14 31.9335uA 32.7227uA 40.1997uA 3.21 32.7095uA 73.2482uA 41.1226uA 3.28 33.5298uA 0.2503mA 42.0514uA |=20=20 [POWER_clamp]=20 |Voltage I(typ) I(min) I(max) |=20=20 -3.28 3.5775A 3.6016A 3.4528A -3.24 3.5154A 3.5397A 3.3904A -3.20 3.4534A 3.4777A 3.3281A ..... -0.08 35.8263uA 26.4944uA 47.5355uA -0.04 34.5005uA 25.3183uA 46.9642uA 0.00 33.7999uA 24.7033uA 46.4029uA Looks fine so far? Now remind that we have [POWER_clamp] values in IBIS file referenced to [Voltage range] Vtable =3D Vreference - Voutput So, if we will re-print the [Power_clamp] table for the Ground-reference voltages, we will have something like as following: [POWER_clamp]=20 |Voltage I(typ) I(min) I(max) |=20=20 6.88 3.4528A 6.84 3.3904A 6.80 3.3281A .... 6.58 3.5775A 2.4528A 6.54 3.5154A 2.3904A 6.50 3.4534A 2.3281A .... 6.28 2.5775A 3.6016A 1.4528A 6.24 2.5154A 3.5397A 1.3904A 6.20 2.4534A 3.4777A 1.3281A ..... 3.68 39.8263uA 46.4944uA 47.5355uA 3.64 38.5005uA 45.3183uA 46.9642uA 3.60 37.7999uA 44.7033uA 46.4029uA ........... 3.38 35.8263uA 36.4944uA ????????? 3.34 34.5005uA 35.3183uA ????????? 3.30 33.7999uA 34.7033uA ????????? ........ 3.08 26.4944uA 3.04 25.3183uA 3.00 24.7033uA=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 And when [POWER_clamp] and [GND_clamp] combined together and added to [Pullip]/[Pulldown] for simulation, We have double counting "Min" clamps between 3.0V and 3.3V And we have kind of "Hole" for Max clamp between 3.28V and 3.6V=20 Does it looks negligible? =20 inischk4 say No. =20 WARNING - Model v330_11_c4: POWER Clamp : Typical value never becomes zero WARNING - Model v330_11_c4: POWER Clamp : Minimum value never becomes zero WARNING - Model v330_11_c4: POWER Clamp : Maximum value never becomes zero WARNING - Combined Pulldown for Model: v330_11_c4 Typical data is non-monotonic WARNING - Combined Pullup for Model: v330_11_c4 Typical data is non-monotonic WARNING - Combined Pulldown for Model: v330_11_c4 Minimum data is non-monotonic WARNING - Combined Pullup for Model: v330_11_c4 Minimum data is non-monotonic WARNING - Combined Pulldown for Model: v330_11_c4 Maximum data is non-monotonic WARNING - Combined Pullup for Model: v330_11_c4 Maximum data is non-monotonic =20 That's Especially Important for the ODT models, where Clamp currents is quite significant And cause issues related to accuracy of models simulation. =20 What the Solution could be for the issue above? =20 Proposed Solution to extend Simulation ranges for both [Power_clamp] and [GND_clamp] to -Vcc::2*Vcc (See IBIS_Cookbook_v4.pdf, Table 5-6) In this case we will cover whole range. BUT! If we will print All the data "As Is" in to IBIS model, Clamp Currents will be Duplicated! One of the Option to avoid duplication described in IBIS cookbook - Sections 5.1.3.4, 5.1.3.5 If we just "Clip" the data as described - we have to be take care about Extrapolation Errors (Section 5.1.3.9) At the end - it would be almost the same as "minimal range" and will NOT resolve all ibischk4 warning and simulation concerns. =20 More reasonable Approach, applicable for ODT models as well described in Following Presentation: http://www.vhdl.org/pub/ibis/summits/jun03b/muranyi3.pdf =20 This called as "Clip and Extend" =20 * Sweep device from -Vcc to 2*Vcc twice: GND and Vcc relative * Cut clamp curves where they reach zero current going left to right * Extrapolate all clamp curves horizontally to 2*Vcc =20 Opposite to Cookbook Proposal, this approach Cut clamp current when it's going from Positive to Negative value And Extend (Extrapolate) this value to end of characterization range. =20 In a reality, for plain (non-ODT) buffers it mean=20 GND_clamp range: -Vcc::0=20 POWER_clamp range 0::2*Vcc (Ground referenced) =20 Q2: Why Cookbook 4.0 Sections 5.1.3.4, 5.1.3.5 recommend to clip the date by Differerent ranges? GND_clamp range: -Vcc::Vcc=20 POWER_clamp range Vcc::2*Vcc (Ground referenced) Is there any concerns to use "Clip and Extend" Approach for All Buffer types, not ODT only? GND_clamp range: -Vcc::0=20 POWER_clamp range 0::2*Vcc (Ground referenced) =20 The Cookbook recommended Clamp ranges seems contradictive with what IBISCHK really expected and potentially could confuse simulators.=20 Am I miss something here? =20 At the same time, during investigation of this issue we find Alternative (claimed as more accurate for ODT) approach called as DEC: http://www.vhdl.org/pub/ibis/summits/sep05/ross2.pdf =20 This Approach seems more tricky for Implementation with questionable added value in term of accuracy. =20 Q3: Does anybody implement this approach in they models? What is impact in terms of simulation accuracy vs. "Clip and extend"? Can anybody share particular code to split clamps according to DEC algorithms? =20 =20 I will greatly appreciate any feedback and proposals to address issues above. =20 Sergey Nikonchuk=20 Characterization and View Generation=20 TSO / DT / L&M / IO Pad Cell Libraries Freescale Semiconductor, Inc.=20 www.freescale.com =20 Contacts:=20 Phone +7 (495) 589 1839=20 Mobile +7 (916) 993 3467=20 Fax +7 (495) 787 0151=20 Sergey.Nikonchuk@freescale.com =20 This e-mail and any attachments have been classified as:=20 [x] Public=20 [ ] Internal Use Only=20 [ ] Confidential Proprietary=20 =20 =20 - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------_=_NextPart_002_01CA9B73.54A2F7B7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Dear IBIS Users= =20 Community.
This= is a=20 first time when I send e-mail to the IBIS community.
So, = be=20 patient, please, if I am use wrong e-mail  address or asking questions= =20 which one already clarified in some documentation.
Just= point me=20 on right source.
My p= articular=20 questions that I hope to get answers highlighted below as "Q1, Q2, Q3"
 
During detailed evaluation of IBIS=20 characterization flow, especially for ODT (On-Die Termination)=20 cells,
we find some issues in Existing s2ibi= s3 implementation for Clamp current captur= ing and=20 printing in to IBIS model.
 
1. The Voltage range not cover Max co= ndition=20 for [Pullup]/[Pulldown]/[GND_clamp]/[POWER_clamp] I-V Curves
As recommended by IBIS standards and= =20 Cookbook , the range for the IV curves have to be -Vcc::2*Vcc
Now, for "Vcc" value the "Typ" value= =20 used.
It mean, if we have Typ Vcc =3D1.8V += /- 0.1V=20 for Max/Min conditions,
we have -1.8V::3.6V range for IV curv= es,=20 which one cover Typ and Min recommendation,
But not enough for Max condition, whi= ch one=20 should be -1.9V::3.8V
 
I suggest to extend the range for IV = Curves=20 capturing up to Max [Voltage Range] value.
That's have to be applied for All 4 I= V=20 curves - [Pullup]/[Pulldown]/[GND clamp]/[POWER clamp]
 
Q1. Is there any particular reasons, comments - Why IV = curves=20 referenced to Typ Vref? Is there  concern to extend IV ranges up to M= ax Vref=20 ?
 
 
2. The Minimum recommended range for = Clamp=20 IV capturing cause non-monotonysity issue in Final IBIS models.
Existing implementation of s2ibis3  Assume the Minimum Voltage ranges= for=20 Clamp Curves:
[GND_clamp] -Vcc::Vcc
[POWER_clamp] Vcc:2*Vcc (Ground=20 referenced)
 
Below is example:
 
[Voltage Rang=
e]        3.3000V    =
;       3.0000V     =
        3.6000V
|  
[GND_clam=
p] 
|Voltage   I(typ)       =
;       I(min)     &=
nbsp;        I(max)
|  
 =
; -3.30    -3.5860A       =
;   -3.6101A         =
;   -3.4617A
  -3.23    -3.4782A &nbs=
p;        -3.5024A   &nbs=
p;        -3.3533A
  -3.16 =
   -3.3704A         =
 -3.3947A           =
 -3.2450A
.....
  3.14    31.9335uA&nbs=
p;        32.7227uA   &nb=
sp;       40.1997uA
  3.21  =
;  32.7095uA         73.2482uA=
           41.1226uA
&=
nbsp; 3.28    33.5298uA      &=
nbsp;  0.2503mA         &=
nbsp;  42.0514uA
|  
[POWER_clamp] 
|Voltage  =
 I(typ)           &n=
bsp;  I(min)         &nbs=
p;    I(max)
|  
  -3.28    3=
.5775A           3.6016A&=
nbsp;            3.4=
528A
  -3.24    3.5154A     =
;      3.5397A      =
       3.3904A
  -3.20  &nb=
sp; 3.4534A           3.4=
777A            =
; 3.3281A
.....
  -0.08    35.8263u=
A         26.4944uA  &nbs=
p;        47.5355uA
  -0.04 =
;   34.5005uA         25.=
3183uA           46.9642u=
A
   0.00 &n=
bsp;  33.7999uA         24.703=
3uA           46.4029uA
Looks fine so=20 far?
Now remind that we= have=20 [POWER_clamp] values in IBIS file referenc= ed to=20 [Voltage range]

Vtable =3D Vreference - Voutput
So, if we will re-print the [Power_clamp] table = for the=20 Ground-reference voltages, we will have something like as=20 following:
[POWER_clamp] 
|Voltage &nb=
sp; I(typ)           =
;   I(min)         &=
nbsp;    I(max)
|  
  6.88  &=
nbsp;           &nbs=
p;            &=
nbsp;            &nb=
sp;    3.4528A
  6.84    &n=
bsp;            =
;            &n=
bsp;            =
;   3.3904A
  6.80      &nb=
sp;            =
            &nb=
sp;            =
 3.3281A
....
  6.58    3.5775A =
            &nb=
sp;            =
          2.4528A
&nbs=
p; 6.54    3.5154A       =
            &nb=
sp;            =
    2.3904A
  6.50    3.4534A&nb=
sp;            =
            &nb=
sp;          2.3281A
....
  6.28    2.5775A  =
         3.6016A   &=
nbsp;         1.4528A
  6.2=
4    2.5154A        =
   3.5397A         &=
nbsp;   1.3904A
  6.20    2.4534A &nb=
sp;         3.4777A  &nbs=
p;          1.3281A

...=
..
   3.68=
    39.8263uA &=
nbsp;       46.4944uA         =
  47.5355uA
   3.=
64    38.5005uA      &n=
bsp;  45.3183uA &nbs=
p;         46.9642uA
  =
; 3.60    37.7999uA         44.7033uA      &=
nbsp;    46.4029uA
...........
  =
; 3.38    35.82=
63uA        36.4944uA        &=
nbsp;   ?????????        &=
nbsp;                  &nbs=
p;            &=
nbsp; 
   3.34    34.5005uA        35.3183uA         &n=
bsp;  ????=
?????         &n=
bsp;            =
;       =
;            &n=
bsp;          
=
   3.30    33.7999uA   &n=
bsp;    34.7033=
uA            <=
FONT color=3D#ff0000>????????? =
;           &=
nbsp;                  &nbs=
p;            &=
nbsp;    
=
........
   3.08     =
;            &n=
bsp;   26.4944uA   &n=
bsp;            =
;            &n=
bsp;       
   3.04&=
nbsp;           &nbs=
p;        25.=
3183uA          &n=
bsp;            =
;            &n=
bsp;
   3.00 =
;            &n=
bsp;       24.7033=
uA           =
            &nb=
sp;         
And when [POWER_clamp] and [GND_clamp= ]=20 combined together and added to [Pullip]/[Pulldown] for simulation,
We have double counting "Min" clamps = between=20 3.0V and 3.3V
And we have kind of "Hole" for Max cl= amp=20 between 3.28V and 3.6V
Does= it looks=20 negligible?
<= SPAN=20 class=3D514525413-20012010> 
inischk4 say No.
 
WARNING - Model v330_11_c4: POWER Cla= mp :=20 Typical value never becomes zero
WARNING - Model v330_11_c4: POWER Clamp= :=20 Minimum value never becomes zero
WARNING - Model v330_11_c4: POWER Clamp= :=20 Maximum value never becomes zero
WARNING - Combined Pulldown for Model:= =20 v330_11_c4 Typical data is non-monotonic
WARNING - Combined Pullup for M= odel:=20 v330_11_c4 Typical data is non-monotonic
WARNING - Combined Pulldown for= =20 Model: v330_11_c4 Minimum data is non-monotonic
WARNING - Combined Pullu= p for=20 Model: v330_11_c4 Minimum data is non-monotonic
WARNING - Combined Pulld= own=20 for Model: v330_11_c4 Maximum data is non-monotonic
WARNING - Combined P= ullup=20 for Model: v330_11_c4 Maximum data is non-monotonic
 
That's Especially Important for the O= DT=20 models, where Clamp currents is quite significant
And cause issues related to accuracy= =20 of  models simulation.
 
What the Solution could be for the is= sue=20 above?
 
Proposed Solution to extend Simulatio= n=20 ranges for both [Power_clamp] and [GND_clamp] to -Vcc::2*Vcc
(See IBIS_Cookbook_v4.pdf, Table=20 5-6)
In this case we will cover  whol= e=20 range.
BUT! If we will print All the data "A= s Is"=20 in to IBIS model, Clamp Currents will be Duplicated!
One of the Option to avoid duplicatio= n=20 described in IBIS cookbook - Sections 5.1.3.4, 5.1.3.5
If we just "Clip" the data as describ= ed=20 - - we have to be take care about Extrapolation Errors (Section=20 5.1.3.9)
At t= he end -=20 it would be almost the same as "minimal range" and will NOT resolve all ibi= schk4=20 warning and simulation concerns.
 
More reasonable Approach, applicable = for ODT=20 models as well described in Following Presentation:
http://ww= w.vhdl.org/pub/ibis/summits/jun03b/muranyi3.pdf
 
This called as "Clip and=20 Extend"
 
• Sweep device f= rom -Vcc to=20 2*Vcc twice: GND and Vcc relative
• Cut clamp curves where they reach zero current going left to right
• Extrapolate all clamp curves hor= izontally to=20 2*Vcc
 
Opposite to Cookbook Proposal, this a= pproach=20 Cut clamp current when it's going from Positive to Negative value
And Extend (Extrapolate) this value t= o end=20 of characterization range.
 
In a reality, for plain (non-ODT) buf= fers it=20 mean
GND_clamp range: -Vcc::0 =
POWER_clamp range 0::2*Vcc (Ground=20 referenced)
 
Q2: = Why Cookbook 4.0 Sections 5.1.3.4, 5.1.3.5 recom= mend to=20 clip the date by Differerent ranges?
GND_clamp r= ange:=20 - -Vcc::Vcc 
POWER_clamp= range=20 Vcc::2*Vcc (Ground=20 referenced)
Is there an= y=20 concerns to use "Clip and Extend" Approach for All Buffer types, not ODT=20 only?
GND_clamp r= ange:=20 - -Vcc::0 
POWER_clamp= range=20 0::2*Vcc (Ground=20 referenced)
 
The Cookbook recommended Clamp= =20 ranges  seems contradictive with what IBISCHK really expected and=20 potentially could confuse simulators.
Am I miss something here?
 
At the same time, during investigatio= n of=20 this issue we find Alternative (claimed as more accurate for ODT) approach= =20 called as DEC:
http://www.vh= dl.org/pub/ibis/summits/sep05/ross2.pdf
 
This Approach seems more tricky for= =20 Implementation with questionable added value in term of accuracy.
 
Q3: Does anybody imple= ment this=20 approach in they models? What is impact in terms of simulation accuracy vs.= =20 "Clip and extend"?
Can anybody share part= icular=20 code to split clamps according to DEC=20 algorithms?
 
 
I=20  will greatly appreciate any feedback and proposals to address= =20 issues above.
 

Sergey Nikonchuk
Characterizat= ion and=20 View Generation
TSO / DT / L&M / IO Pad Cell=20 Libraries
Freescale Semiconductor, Inc.
www.freescale.com

Contacts:
Phone +7 (495) 589 1= 839=20
Mobile +7 (916) 993 3467
Fax +7 (495) 787 0151
Sergey.Nikonchuk@frees= cale.com

This e-mail and any attachments ha= ve been=20 classified as:
[x] Public
[= =20 ] Internal Use Only
[ ] Confidential Proprietary=20

 

 

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------_=_NextPart_002_01CA9B73.54A2F7B7-- - ------_=_NextPart_001_01CA9B73.54A2F7B7 Content-Type: image/gif; name="att88d04.gif" Content-Transfer-Encoding: base64 Content-ID: <234315714@22012010-23DE> Content-Description: att88d04.gif Content-Location: att88d04.gif R0lGODlhwgBYAPcAAM3LzGVhYvvCFbW1thcTFO9jJHl2dubl5fz8/PPz8/GR ZfrVZfS6nfrgrPrj0/vx3/f29vr5+IuIiCYiI8LBwuvr6z87PN7e3tXU1VRQ UaupqvDv752bm////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQEAAAAACwA AAAAwgBYAAAI/wA7CBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPH jyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjR o0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz1jwAAACGA1QRHKgwOELYBBIsTFgcAMFUChYiZ6gANkIA ApgxB6AqIbMFx18HYJ6QWQLVy6QNhDVAgLQFDhoAS42QoTUBDl4RbKhQm7QE BBA6HKBAHECHCH0JXuAgoTkH2QYTDGje3PhBAMyba6AcfTp16wWXU/+XwAED QQykMVMguME7efDeNWjosDzBUQCRFy+OvLkz6Qwc1KaacAak59l8oB3HgQWZ jWZAcAg4BkAGBmJmgQTQIaABgw1OEAB0CRTY4GgSGNaBaBZeIFAEC444wYMd bGAAbBZckBh3RXEw2mKZNXbZaJnhdkFtLra2nkAhjmgbAaYJREGFQBJggXkQ sFYkARls0EECP+645JE6/mdflUqm1yQHAwAQAAcGfHiUBhkwSNoEGWQwwAZy VkhBAr1JaYCI/5nY2WgBGCBna+ZdkGehAXD4YgUIWOlao0sO0IGOo8U2wKG4 RWrbgIO2VuihE6gowQAUSJDBnyoa5Zh/BDT/JhB6S1oQQImwBtDqk6MBRoFn R/KW2XywDkhfm9Zp0CCGwl322gYIBKDffAL1Od8GfeL2q4XBEknAfBRgcAEF A2BwJ1IQoMbkQCguhqFjF6Q3AQYQbGCvo8api5u9EcCKW5+vYWBfB6Bha9tm A2FgQKuCHXDABQmM22JrxsWbmaVdXrtBv7Y1+dQBHH47EKwZEBTmfpHlp59f c06Qcso8coBAb/Laup1Aos15ZELtGcqjbRZQtm1rF9CKMsw8euwUrRQPpK6x HaAGZYcHKLukkpjhhmlrFU7ZAWuuBZfQhi7ymIFjYUp5KddYBxmV1VIOjKdt uAk092IZBKD33gGs/5rkpHzvncGRcBr4swHRHjxQggIhEKqUaz4tENixfg10 4HrXubNTuSYsL3hMT7BeBBEgEAEGJlrW8XGl06cl4wkAoIEBFJoNQZ8IE1wQ r61x0Kq11a6urmmkG3bB61L1aSyKUrZKn4HUCsSBhwCYLvlA+FmggX0bNFcQ 5ZsBbGIHGAAIKeUe8z6BcSDbtt71s1pg58BPJXBo9GlnQP/tQAMAgY3yMpVt JqCB3ZAta5vCjAEAkIDYeWs+YEuNXw44GdxVoD2HqlEH1KciyhHQgCGLnlMA 8LmBUA5qHfDPnOLUIA4YhoQDjEyDdJWn1uTHNhkwzLZ45LLMTMCFNHOZo//E tDbXaIlXc5Jhj7QEFbhZQDYVCFndBrKBH0FJewR53IgMYB/8tA1L0AlV1yy1 tqtJqUeT65Gg2vYisUFlevwR25BStjm7+Ww0FlhYQRCwoJoFYHMVSIzhAES/ 42yoZswSCAQkUDM05cc0kXLZDxd3SDz+kSoQgEAEIJAg4GRyfAYZzgDSVMiC xG6UFIBO45AEgFEO4AKgJMgpSXmQC4ySgYr8JMEymUnGbamVqFKlXoYJllNR BDYLySQxQ1KuidBmiggx5jIZEgENSMA607HUBmT3HA1woF7GSQBzzLNBY0Kg lRIwDwKmA6e+aElc5dRABCBjGhtxgDIYkB0Tl1n/pVtZADsZSIwGnmSoPF5o ABk4QKEMhYEAJaY8HqpTiAz6zxrRZgBwSgx5JnCqgOqNN7bCETHx9MdR5hGh t2qMBDZjAPK0VFYDWJB5AhSgc9pJgytF6P9uahxz6TSg5LPApgYQy2FWYAC0 m9GFcrqmDtgpakhVlaUQYKOSpfBPpuFASifn0g0CyKqDkcDCNEiBDMCpqMNc 6QYWtCC+BKB8FMDTX/45uEIdYKUy3VRZIUieKQ1gAkgNwIQCsCkAQGYAhcKA 9srXHFlNc1Z1+mOI8qaBC3zIshXAwFsDUIGy5k1gtDMrl8xjgAEoNG8ZwABk +qaBKtVJZrRbTp0ksEgRWT42AhAbyAUoEwH79PY4CQCOYzZwgQQdj2DBRUBw CQYx0BBGd/ThTgIO4BiHIal1j2WJL7PL3e5697vgDa94x0ve8pr3vOhNr3rX y972uve98I2vfOdLkoAAACH5BAQAAAAALAEAPQANAAkAAAg+ADsIHNgBwQOC CDs4UFCAAYSECRgUmDiRwUGBDBhSpKhAocaNFSM4AMnxIoIGHwsocJAQwcKG CBIOjHARYUAAIfkEBAAAAAAsAQAuACUAGAAACGUAOwgcSLCgwYMDETxAyLDh QQcKCjCA4LDiwQQMCmjUyGChRYsMIm7cqOCjQ4gjRzKIYJKhg5QkPbZEiKCB SI0KHMy0iAAlAwQ7TUaQGbSo0aNIkypdyrSp06dQo0qdSrWqVaYBAQAh+QQE AAAAACwZACUAHQASAAAIWQA7CBxIsKDBDggeHFzIUKADBQUYQGhIsUMCBgUy ZmSgsKJBBhA1alSAwOPAhyJFMohg0mHKkR1bImwQMqMCBzINIkDJoGTOgxFi /hxKtKjRo0iTKl3K1GNAACH5BAQAAAAALAIAPQAMAAgAAAg2ADsIHPhgwYOB CBE0EMBwgQOEDhYwnChgQYeCFCk2WJix4cEGEikaRBiBo4AGCBAOhNDgoMqA ACH5BAQAAAAALAIANAAbABEAAAhRADsIHEiwoMEHCx4YXMiwA4IGAiIucNCw ooMFETMKWFDxIEaNGRt0JAgRpESFIwc2+JgxYUqDEUoKaIDgJUMIDVDa3Mmz p8+fQIMKHUq0aIeAACH5BAQAAAAALBEALAAZABAAAAhOADsIHEiwIMEHCx4Y XLgQQQMBEBc4YEjRwQKIGAUsoFgQYcaMDTgOfPgxokKRAhtczJgQZcEIJAU0 QOByIYQGJ2vq3Mmzp8+fQIMK9RkQACH5BAQAAAAALAAAPQANAAgAAAg4ADsI HNjBgQOCCCMwKFCAwQOEBRUwnMjgYIcHEidqbPBgocaJCh56/KjAokAHGRky QAAxYkiIAQEAIfkEBAAAAAAsAAA4ABYADQAACEgAOwgcSLBgBwcODCosGIFB gQIMHixU6EDBw4sMEk7s8MDixY8NJj5w+PGiAokTSZZUoHHjQY8PGSBwWbDi SZo4c+rcybOny4AAIfkEBAAAAAAsCQAyABcADgAACEwAOwgcSLCgQAcOBkYw yFBgBAYFCjB40LChAwURMzJIWFHgA4wZQzbo+ABiyIwKKHY0eVIBx44HQUZk gACmwYspbercybOnz59AgwYEACH5BAQAAAAALAAANgANAAgAAAg7ADsIHNjB wQOCCCMwKKCAQQSEHRooKECRIYODHR5MrMjR4EKOFRUc/AhSgYOBEBhspMgA AUSFDSFADAgAIfkEBAAAAAAsAAAoACQAFgAACJkAOwgcSLCgwYMCHTxAyLBh wQgMCihgEMGhRYMNFBTYKJHBwosOH2jkSNIBSIYPIpLkqODjyYMqVyowiaDB y4MQGIzcyABBBwcLBNxECHEihA4PggoQOtRhg6VQmzpVulSqQQcmBUZ4WtWq VpUeB0Jo4FKqg508s3pFipakTa8pV7IsKzUmyZlrCZ4l2TPvVQUt/QoeTLhw 04AAIfkEBAAAAAAsFwAbACIAFQAACKEAOwgcSLCgwYMOHhxcyNBgBAYFFDCI 0LCiwQYKCmiMyEChxYYPMm4c6eDjwgcQR25U4NGkwZQqFZR0uRACA5EaGSCg WfGhRAg8gwodSnQggpZFDTrIyABo0oEJYOZEOvSmSo0Kdg5dejUnxa1dI1IN igDjSJkHtVZ8sKAlAq46FwKoWFaA3QUzO0QYS5BDQwcL7AoWsMCkhpOBBwtu YBJBQAAh+QQEAAAAACwDADQADQAIAAAIMwA7CBzYocGCCAQJPlggoGEDhAMX NpzosEOEBhQpHpSYUcCCBwI5UmyAICHHjwkVgkwZEAAh+QQEAAAAACwDACoA HQASAAAIfgA7CBxIsKBBgQ0WRDjIsOGDBQIiNljYsOLDiBglVjwYoUHGjAo3 Frz4UcCCByINkszYAIFAlCkJkjw50GNMlTBrLrjJ0IGDgRR5AmVQoACDnEIF OlBQtCmDn0IfMG1KtQHPB0SpNlWANGVWrQqgJl1KlYHLpASXckXLti3BgAAh +QQEAAAAACwTACIAGwAQAAAIewA7CBxIsKDBBgsiGFzIsMODBQIiNlDYkOHD iBglViwYoUHGjAk3Drz4UcCCByIJkszYAEGHBAxSjoRoEmUHBgoKyFRp00HO Ajp3FnQAtKjQggga/Ay686HNDgh8MhWZFOMCBwMjPN3ogCZIoSs/NtjpsWRN oQg/nlwYEAAh+QQEAAAAACwAADYADQAIAAAIOwA7CBzYAYGDBwQTOlBQQAGD CAkTMCxAsSEDgQgYVNxY4CKDiRwVOOgAAeRGBggGRmgA8mFCjB9HJgwIACH5 BAQAAAAALAAAMAAXAA4AAAhYADsIHEiwoEAEDh4YXGjQgYICChhEYLgwwcMC GCEyoDgQAYOMIAts5MjgYkgFDjh2gGASJAMEDxSojNDApMQHHwuoPFgyZYec OncudBhU6FCjSJMqXbozIAAh+QQEAAAAACwKACgAGQAQAAAIfgA7CBxIsCBB BA4eGFzI0IGCAgoYRGBIMcHDAhghMqBYEAGDjCALbOQokMHFkAockBQI4SRI Bgg6xFwZocFJiQIdLFg50GNKgQ8WCBDAc2GDoUOLGmwgNKlSByoF1nRK86NI hSwb8HQYkkHUlQ9cgtRK8oHVkBCxkjwL8mfBgAAh+QQEAAAAACwDACwADQAI AAAIOQA7CBz4YMGCBwMTImggoKGABhEGLnRI8WCHghQdLmjQgWHGhg0QCMRY EWHCDg4WCLB4UuIDkS0DAgAh+QQEAAAAACwDACIAHQASAAAIigA7CBxIsKDB Dg8WLHhwsGFDBA0ESBTQIILDixAnalx48WBCjRMXNOhoMCJIiQ0QkDT4cSPD lQ0dLBDAUSACBy9hDkTwQKVABwoKKNDZMEHQAkiJFkTAAKnTAkoHMjj6FGpU CFSfMogqMEIDqgwsct051YHAnGMJRkxbcgHbDg7Mdk0boWkBBi8DAgAh+QQE AAAAACwTABgAHwASAAAIoQA7CBxIsKDBgQ8WLHhwsKHDDggaCJgooEGEhxgj Uty4EGPDhBspLmjg8aDEkBMbIOhwsSRBkBwZdmigwKVBBwsEdOzwQEGBAjYN Iniw8gGDnz+DOjyKFKjSgxAY+Ez6VGCDBS1ZSmVQFWbFrF1zoiT5NMJJlFgh yizpNaZABz65shW7UWWHBEypNkTgYC3MnVKbOj0It4ACBlkfyCwsuEBAACH5 BAQAAAAALAIAJAAOAAgAAAg8ADsIHNgBAgMHBBMiYFCgoQKECR0oaEixgAII Ah9MrEiRAYSFHCk+FAiSo4IGCTs4YNiQQYSUA1dCTBgQACH5BAQAAAAALAIA HAAbABAAAAhWADsIHEiwYEEIDBwYXMiwAwIGBSIqUNiwoQMFETMWUAChYsEH GDVmZNDRo0OIIiVSNHkypYIGLA06QFmAQYSYDGeuxMmzp8+fQIMK7bkTaAKM Qh9mDAgAIfkEBPQBAAAsDwAUABwAEAAACHEAOwgcSLCgQQgMHBhcyFAgAgYF IipQ2LCiAwURMxZQAKGiwQcYNWZk0NGjQ4giJVI0eTKlggYOYbIU6ABlAQYR OiBoIEDATII1KT5Y0NPnT4M8ixo9SnCoUqYLHRBdAHUhggcIqmrdurXBgpxc nfYMCAA7 - ------_=_NextPart_001_01CA9B73.54A2F7B7-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 14 Dec 2009 12:00:02 -0500 From: Lance Wang Subject: [IBIS-Users] RE: Old IBIS Meitng Anouncemnt Issue - Could Not Send Hi, Bob and Mike, I still can not send out to either of addresses in eda.org. And no returned mails. I also noticed I did not receive any emails from these mailing lists except yours last Friday. Can you guys try it to see if it is only me? Thanks, BYW, I would suspect no one would receive emails from support@eda.org either. I would suggest sending an email to someone using TechAmerica email address. Regards, Lance Wang 978-764-2298 IO Methodology Inc. - -----Original Message----- From: Bob Ross [mailto:bob@teraspeed.com] Sent: Monday, December 14, 2009 11:07 AM To: support@eda.org Cc: lwang@iometh.com; bob@teraspeed.com; milabont@cisco.com Subject: Old IBIS Meitng Anouncemnt Issue - Could Not Send Steve or whoever. For two of our meetings every year, we have a repeat issue that is not fully understood or resolve. Otherwise everything is normal. I cannot sent this attached email to just the IBIS-Users@eda.org reflector. I did sent it on Friday to the ibis@eda.org reflector. I sssuming the ibis-users@eda.org reflector is not stalled. Steve, or anyone, can you use any extra privileges if needed to forward this message on behalf of Lance Wang (after temporarily re-subscibing?) to ibis-users@eda.org. I send it as text embedded in my e-mail versus sending it as an attachment. This also serves as a test message to monitor what is happening, if needed. - ------ This is not a high priority issue because we were able to get the announcement out to most of our members. But this is still annoying. Thanks, Bob - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- 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. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------ Date: Thu, 29 Oct 2009 12:39:15 -0800 From: Bob Ross Subject: [IBIS-Users] IBISCHK5 Version 5.0.0 Executables Available All: Ibischk5, Version 5.0.0 executables are now available for six operating systems: http://www.eda.org/pub/ibis/ibischk5/ Source code has been distributed to those companies who have purchased the license. Ibischk5 adds -ami and -numbered flags: Usage: ibischk5 : ibischk5 -ebd : ibischk5 -pkg : ibischk5 -ami Usage: ibischk5 -caution -numbered : ibischk5 -caution -numbered -ebd : ibischk5 -caution -numbered -pkg : ibischk5 -caution -numbered -ami The flags prior to the file name can be in any order, and the -caution and/or -numbered flags are optional. Algorithmic modeling interface files (.ami) are checked according to the IBIS Version 5.0 0 specification (and agreed interpretation). Work is continuing in this area. The syntax for .ami files referenced within .ibs files are automatically checked. The optional -numbered flag provides four digit numbers for error, warning, caution, and notes messages. Ibischk5 checks all major versions of IBIS (i.e., 5.0, 4.2, 3.2, 2.1, 1.1) based on the [IBIS Ver] entry. So the new executables can replace existing executables. Bob Chair, IBIS Open Forum - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 16 Dec 2009 08:12:29 +0100 From: Lars Snith Subject: Re: [IBIS-Users] PullUp/PullDown toggle? Hello Al and Tom, Thank You for your input, it's good to have this pinpointed! Tom, to answer your questions: - - Single Ended GPIOs, all quite similar - - 0.25um CMOS - - Behaviour visible both ways (but most obvious in displayed example) Best regards, Lars - -- Those who can, Do Those who can't, Simulate - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 15 Dec 2009 23:41:19 -0500 From: al davis Subject: Re: [IBIS-Users] PullUp/PullDown toggle? On Tuesday 15 December 2009, Lars Snith wrote: > 2.40 -12.7710mA -7.5000mA -21.3261mA > 2.46 -12.8090mA -8.0000mA -21.3770mA > 2.52 -12.8400mA -7.0000mA -21.4280mA > 2.58 -12.9000mA -7.0000mA -21.4810mA > 2.64 -13.0000mA -7.0000mA -21.5310mA > 2.70 -13.0000mA -8.0000mA -21.5800mA > 2.76 -13.0000mA -8.0000mA -21.6300mA > 2.82 -13.0000mA -10.0000mA -22.0000mA > 2.88 -13.0000mA 0.0A -22.0000mA > 2.94 -10.0000mA -10.0000mA -22.0000mA > 3.00 -10.0000mA -10.0000mA -22.0000mA > 3.06 -20.0000mA -10.0000mA -20.0000mA > 3.12 -20.0000mA 0.0A -20.0000mA > 3.18 -10.0000mA -10.0000mA -30.0000mA > 3.24 -10.0000mA -10.0000mA -20.0000mA > 3.30 -10.0000mA -10.0000mA -20.0000mA > 3.36 -10.0000mA -10.0000mA -30.0000mA > 3.42 -20.0000mA 0.0A -20.0000mA > 3.48 -20.0000mA -10.0000mA -20.0000mA > 3.54 -10.0000mA -10.0000mA -30.0000mA > 3.60 -10.0000mA -10.0000mA -20.0000mA It's not toggle. It's numerical noise. It's not just noise buried under the numbers, those numbers are nothing but numerical noise. You get things like this from the subtraction that separates the clamps from the composite. The clamp current in this region is usually huge, and exists only as a figment of the simulator. A real device would let the smoke out and not work any more. You need more precision in currents, and less precision in voltage. It may cause convergence problems seemingly at random. Some have argued that only the sum of the clamps and pullup/down matters, but you can still get glitches that cause trouble. Usually, it doesn't matter because it never operates in this region, where clamp diodes are forward biased. Once in a while, a non-converged iteration will land there and throw the process off, leading to non-convergence, or more likely just a few more iterations. This problem has existed for years. Most dedicated SI simulators will filter out bad data like this, without even a warning. - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 15 Dec 2009 09:14:53 -0800 From: "Tom Dagostino" Subject: RE: [IBIS-Users] PullUp/PullDown toggle? I've seen some characteristics similar to this but not to the extreme you are showing here. The buffers that showed this kind of behavior had feedback in them. What technology is this buffer? Were the other buffers that displayed this the same technology or different? Are these single ended buffers or differential? I'm surprised that this buffer passes IBIS check. What does the corresponding clamp curve look like? Does it have the opposite jumps in current? Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 503-430-1285 FAX tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 - -----Original Message----- From: owner-ibis-users@server.eda.org [mailto:owner-ibis-users@server.eda.org] On Behalf Of Lars Snith Sent: Tuesday, December 15, 2009 8:49 AM To: Lenski, Eckhard (NSN - DE/Munich) Cc: ibis-users@server.eda.org Subject: Re: [IBIS-Users] PullUp/PullDown toggle? Servus Eckhard, Hello Timothy, Thanks for your feedback. I'm sure I'll get my act together with this to help me! Eckhard, to answer your questions: - - Only warnings are for encrypted content (models) which is normal and then one for a node without DC path. But it is autoconnected to the right node anyway, so it should not matter. - - I did not try a "slow" transient extraction, I have used only the testbenches provided by s2ibis3 and the other tool. - - Nope, the curves reflect this "jumpy" behaviour. But IBISCHK5 does not mind a bit. Best regards, Lars - -- Those who can, Do Those who can't, Simulate - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 20 Jan 2010 10:39:35 -0500 From: "Lance Wang" Subject: [IBIS-Users] IBIS Summit at DesignCon 2010: Fourth Call for Participation and Presentations To All: This is the final announcement for the DesignCon 2010 IBIS Summit meeting to be held at the Santa Clara Convention Center in Santa Clara, California. We have about eleven presentations plus a discussion planned so far. These are noted in the AGENDA section of the announcement below. The IBIS Open Forum is sponsoring the event, but we welcome additional sponsors to cover some of the meeting expenses, including the free lunch and refreshments. Also note that VIP discounts are offered for all DesignCon 2010 conference packages (including free exhibition admission) through links given below. Several IBIS members are also actively participating and presenting material in the DesignCon program. Best Regards, Lance Wang IO Methodology Inc. www.iometh.com - ----------------------------------------------------------------------- IBIS SUMMIT FOURTH CALL FOR PARTICIPATION & PRESENTATIONS - ----------------------------------------------------------------------- I B I S S U M M I T M E E T I N G Time/Date: Thursday, February 4, 2010 8:00 AM to 5:00 PM Location: Santa Clara Convention Center 5101 Great America Parkway, Santa Clara, California, USA Room: 203 in Convention Center where DesignCon is being held Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and ideas. Sponsors: Cisco Systems, IBIS, International Engineering Consortium (DesignCon) We are seeking more co-sponsors. Please contact Lance Wang . The benefits to sponsors include recognition at the meeting and acknowledgement in the Calls for Papers and meeting minutes. Your financial support strengthens the organization by allowing IBIS to focus resources on industry activities rather than raising money, and you will receive generous thanks for your support. DesignCon 2010 Conference: February 1 - 4, 2010 Santa Clara Convention Center Santa Clara, CA http://www.designcon.com/2010/ Exhibits registration: http://www.designcon.com/2010/register/index.asp IBIS Summit participants can register at discounted rates through this link for both the conference and exhibition: http://www.designcon.com/2010/vip_passes/ibis.html However, please also notify Lance Wang (lwang@iometh.com) if you are planning to attend the IBIS Summit. Conference Schedule: http://www.designcon.com/2010/attendees/program_schedule.asp BACKGROUND DesignCon is the premier annual Silicon Valley event for the electronic design automation (EDA) and semiconductor industry. Topics of current interest to the IBIS Open Forum are addressed at DesignCon. This meeting will be conducted as a formal IBIS meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to - Lance Wang Registration deadline is Wednesday, January 27, 2010 to receive the free lunch. CALL FOR PRESENTATIONS We are seeking presentations from individuals who have experiences of interest to the IBIS modeling community. In the past, these have included, but not limited to: Demonstrations of modeling techniques Explanations of behavioral algorithms Descriptions of difficulties encountered Model correlation Modeling building experiences Comparisons to other modeling methods New technologies for modeling buffers and component New technologies for modeling packaging and interconnects Algorithmic modeling topics Etc. Presentations may be addressed to any and all levels of IBIS experience, from beginning to advanced. Presentation Format: A conference laptop with LCD projector. Powerpoint* or Acrobat* electronic formats are favored and will pre-loaded on the Windows*-based meeting laptop prior to the meeting. Time: Usually 15-30 Minutes Electronic Archival: Presentations will be archived under the IBIS Summits site and also must be submitted in time for uploading and copying. Final submission deadline is: Wednesday, January 27, 2010 Otherwise, you should bring 50 copies for distribution. If you plan a presentation, please supply the following information as soon as possible: Tentative Title: Presenter: E-mail address: Company: Telephone: Estimated Time: Send to - Bob Ross Note, vendor-specific or product promotion material is illegal at IBIS meeting. We strongly advise that the presentations be submitted by the deadline. The IBIS Open Forum reserves the right to stop or reject a scheduled presentation that has not been previewed. AGENDA The agenda includes presentations, discussions, breaks, and a FREE lunch. So far the tentative titles or topics are shown. IBIS Activities and Future Plans Bob Ross, Teraspeed Consulting Group Top 10 Issues As Seen During IBIS Model Reviews Lynne Green, Green Streak Programs IBIS Quality Checklist Rev. 2.0 Moshiul Haque and Randy Wolff, Micron Technology Are We Over Designing? Model and Measurement Correlation topic Tom Dagostino, Teraspeed Consulting Group Pin-Pair Oriented Extraction Method for Differential Pair Buffers Lance Wang, IO Methodology Quality Metrics for S-parameter Models Yuriy Shlepnev, Simberian Model Connection Protocol overview topic Brad Brim, Sigrity Signal Loop Inductance in [Pin] and [Package Model]s Randy Wolff, Micron Technology SI/PI Co-Analysis and Linearity Indicator Myoung Joon Choi and Vishram Pandit, Intel Corporation IBIS-AMI Report topic Arpad Muranyi, Mentor Graphics Corporation Predicting BER with IBIS-AMI: Experiences Correlating SerDes Simulations and Measurement Todd Westerhoff*, Adge Hawes**, Michael Steinberger*, Kent Dramstad**, Walter Katz*, Barry Katz*, *Signal Integrity Software (SiSoft), and **IBM LIST OF NEARBY HOTELS The Hotel and Travel Link provides a conference hotel discount, and use internet search engines other good lodging deals: http://www.designcon.com/2010/hotel/index.asp - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 15 Dec 2009 09:45:48 +0100 From: Lars Snith Subject: [IBIS-Users] PullUp/PullDown toggle? Hello, In some of my models the pullup/pulldown curves end up by toggling +/- 10mA. It is not of much actual consequence, but estethically foul. An example follows below. I get the same result with s2ibis3 and one other independent tool (also using HSpice for simulation), so I suspect this is really in the HSpice result files. Has anyone seen something similar before? 2.40 -12.7710mA -7.5000mA -21.3261mA 2.46 -12.8090mA -8.0000mA -21.3770mA 2.52 -12.8400mA -7.0000mA -21.4280mA 2.58 -12.9000mA -7.0000mA -21.4810mA 2.64 -13.0000mA -7.0000mA -21.5310mA 2.70 -13.0000mA -8.0000mA -21.5800mA 2.76 -13.0000mA -8.0000mA -21.6300mA 2.82 -13.0000mA -10.0000mA -22.0000mA 2.88 -13.0000mA 0.0A -22.0000mA 2.94 -10.0000mA -10.0000mA -22.0000mA 3.00 -10.0000mA -10.0000mA -22.0000mA 3.06 -20.0000mA -10.0000mA -20.0000mA 3.12 -20.0000mA 0.0A -20.0000mA 3.18 -10.0000mA -10.0000mA -30.0000mA 3.24 -10.0000mA -10.0000mA -20.0000mA 3.30 -10.0000mA -10.0000mA -20.0000mA 3.36 -10.0000mA -10.0000mA -30.0000mA 3.42 -20.0000mA 0.0A -20.0000mA 3.48 -20.0000mA -10.0000mA -20.0000mA 3.54 -10.0000mA -10.0000mA -30.0000mA 3.60 -10.0000mA -10.0000mA -20.0000mA Best regards, Lars Snith - -- Those who can, Do Those who can't, Simulate - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 19 Nov 2009 16:11:10 -0800 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] AMI convolution This is a multi-part message in MIME format. - ------_=_NextPart_001_01CA6975.F73EA101 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, =20 My message from yesterday didn't make it through because I had a screen shot of a presentation in it, so I am going to refer you to slide 1 of the following presentation: =20 http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20090921/arpadmurany i/AMI%20flows:%20IBIS%205.0%20and%202009%20Sept%208,15%20proposals/AMI_F lows.pdf =20 This flow diagram represents what is described by the current AMI specification in IBIS v5.0. =20 I know others may have already answered your question, but hopefully this will also help you in getting a better understanding of the flow. Please note that the IBIS ATM group is working on corrections to this flow, and the plan is to have the corrected version in IBIS v5.1 once the BIRD written for it is ratified. The proposed flow can be found at this link: =20 http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20091118/arpadmurany i/Final%20AMI%20flow%20for%20IBIS%205.1/AMI_Flows_5_final.pdf =20 Please let us know if you have any other questions or suggestions. =20 Thanks, =20 Arpad =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=3D=3D=3D= =3D=3D=3D =20 ________________________________ From: Muranyi, Arpad=20 Sent: Wednesday, November 18, 2009 10:38 AM To: ibis-users@eda.org Subject: RE: [IBIS-Users] AMI convolution Eric, =20 The IBIS 5.0 AMI flow looks like this in a graphical representation: =20 [screen shot deleted] =20 I hope this helps. =20 Arpad =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 ________________________________ From: owner-ibis-users@server.eda.org [mailto:owner-ibis-users@server.eda.org] On Behalf Of Eric Monteiro Sent: Wednesday, November 18, 2009 9:55 AM To: ibis-users@eda.org Subject: [IBIS-Users] AMI convolution Hi everyone, =20 I was hoping someone could clarify who is responsible for convolution in IBIS-AMI (EDA tool, or the modeler). =20 Clearly the convolution involving an FIR filter is upon the modeler, the convolution I speak of is the one that is done with the channel response. =20 My understanding has been as follows: (please correct me if I'm wrong) =20 (a) -- (Tx IC) -- (passive channel) --(b)--(Rx IC) =20 You force an impulse at (a), measure the response at (b). (b) is the analog channel response hAC(t). GetWave then needs a wave, which should be an ideal bit train, convolved with the bit period (creates a piece wise linear wave) which is then convolved with hAC(t) to produce the wave fed into GetWave. There was discussion as to whether the modeler or the EDA tool should do the above convolution. Has it been decided who this task falls on? =20 Best Regards, Eric Monteiro ________________________________ This communication contains confidential information intended only for the addressee(s). If you have received this communication in error, please notify us immediately and delete this communication from your mail box. - --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner , and is 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_001_01CA6975.F73EA101 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Eric,
 
My message from yesterday didn't make it=20 through
because I had a screen shot of a presentation=20 in
it, so I am going to refer you to slide 1 of=20 the
following presentation:
 
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20090921/ar= padmuranyi/AMI%20flows:%20IBIS%205.0%20and%202009%20Sept%208,15%20proposals= /AMI_Flows.pdf
 
T= his flow=20 diagram represents what is described by
t= he current=20 AMI specification in IBIS v5.0.
 
I= know=20 others may have already answered your question,
but hopefully this will also help you in getting= =20 a
b= etter=20 understanding of the flow.  Please note that
t= he IBIS ATM=20 group is working on corrections to this
f= low, and=20 the plan is to have the corrected version
i= n IBIS v5.1=20 once the BIRD written for it is ratified.
T= he proposed=20 flow can be found at this link:
 
<= A=20 href=3D"http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20091118/arpadm= uranyi/Final%20AMI%20flow%20for%20IBIS%205.1/AMI_Flows_5_final.pdf">http://= www.vhdl.org/pub/ibis/macromodel_wip/archive/20091118/arpadmuranyi/Final%20= AMI%20flow%20for%20IBIS%205.1/AMI_Flows_5_final.pdf
 
P= lease let=20 us know if you have any other questions or
suggestions.
 
Thanks,
 
Arpad
=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=3D=3D=3D=3D=3D=3D
 
From: Muranyi, Arpad
Sent: W= ednesday,=20 November 18, 2009 10:38 AM
To: ibis-users@eda.org
Subject:<= /B>=20 RE: [IBIS-Users] AMI convolution

Eric,
 
The IBIS 5.0 AMI flow looks like this in a=20 graphical
representation:
 
[screen shot=20 deleted]
 
I hope this helps.
 
Arpad
=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

From: owner-ibis-users@server.eda.org= =20 [mailto:owner-ibis-users@server.eda.org] On Behalf Of Eric=20 Monteiro
Sent: Wednesday, November 18, 2009 9:55 AM
To:= =20 ibis-users@eda.org
Subject: [IBIS-Users] AMI=20 convolution

Hi=20 everyone,
 
I was hop= ing someone=20 could clarify who is responsible for convolution in IBIS-AMI (EDA tool, or = the=20 modeler).
 
Clearly t= he=20 convolution involving an FIR filter is upon the modeler, the convolution I = speak=20 of is the one that is done with the channel response.
 
My unders= tanding has=20 been as follows: (please correct me if I'm wrong)
 
(a) -- (T= x IC) --=20 (passive channel) --(b)--(Rx IC)
 
You force= an impulse=20 at (a), measure the response at (b).  (b) is the analog channel respon= se=20 hAC(t).  GetWave then needs a wave, which should be an ideal bit train= ,=20 convolved with the bit period (creates a piece wise linear wave) which is t= hen=20 convolved with hAC(t) to produce the wave fed into GetWave.  There was= =20 discussion as to whether the modeler or the EDA tool should do the above=20 convolution.  Has it been decided who this task falls=20 on?
 
Best=20 Regards,
Eric=20 Monteiro

This communication contains confid= ential=20 information intended only for the addressee(s). If you have received this= =20 communication in error, please notify us immediately and delete this=20 communication from your mail box.

--
This message has bee= n=20 scanned for viruses and
dangerous content by MailScanner, and is
be= lieved=20 to be clean.
--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------_=_NextPart_001_01CA6975.F73EA101-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 15 Dec 2009 10:51:23 -0500 From: "Timothy Coyle" Subject: RE: [IBIS-Users] PullUp/PullDown toggle? Hi Lars, In the past I have seen this type of oscillation at the end of the IV curve usually resulting from a) improper tool extraction method for clamp and pulldown/pullup IV curves b) improper loading in IV data extraction c) actual circuit SPICE issues. I would look at the raw pulldown/pullup IV curves before anything is extracted to make sure it's not an extraction calculation issue. You could also try using a different IV data extraction (DC vs Transient AC) as sometimes this can give you a slightly different result due to setup conditions in SPICE model. Finally you may want to adjust some of your HSPICE .option settings to make sure you are not getting any convergence issues or other HSPICE runtime issues that may affect your results. You could also manually edit the end of the IV curves to be smoothed out (some tools let you do this interactively) but I would only do this if you can do full correlation to verify it won't affect simulation performance and accuracy. Best, Timothy Coyle President Signal Consulting Group LLC 405 Western Ave #430 South Portland, ME 04106 Tel: 617.297.2566 Email: tim.coyle@siconsultant.com Web: http://www.siconsultant.com SharkSim - Signal Integrity IBIS Modeling Software (www.sharksim.com) - -----Original Message----- From: owner-ibis-users@server.eda.org [mailto:owner-ibis-users@server.eda.org] On Behalf Of Lars Snith Sent: Tuesday, December 15, 2009 3:46 AM To: ibis-users@server.eda.org Subject: [IBIS-Users] PullUp/PullDown toggle? Hello, In some of my models the pullup/pulldown curves end up by toggling +/- 10mA. It is not of much actual consequence, but estethically foul. An example follows below. I get the same result with s2ibis3 and one other independent tool (also using HSpice for simulation), so I suspect this is really in the HSpice result files. Has anyone seen something similar before? 2.40 -12.7710mA -7.5000mA -21.3261mA 2.46 -12.8090mA -8.0000mA -21.3770mA 2.52 -12.8400mA -7.0000mA -21.4280mA 2.58 -12.9000mA -7.0000mA -21.4810mA 2.64 -13.0000mA -7.0000mA -21.5310mA 2.70 -13.0000mA -8.0000mA -21.5800mA 2.76 -13.0000mA -8.0000mA -21.6300mA 2.82 -13.0000mA -10.0000mA -22.0000mA 2.88 -13.0000mA 0.0A -22.0000mA 2.94 -10.0000mA -10.0000mA -22.0000mA 3.00 -10.0000mA -10.0000mA -22.0000mA 3.06 -20.0000mA -10.0000mA -20.0000mA 3.12 -20.0000mA 0.0A -20.0000mA 3.18 -10.0000mA -10.0000mA -30.0000mA 3.24 -10.0000mA -10.0000mA -20.0000mA 3.30 -10.0000mA -10.0000mA -20.0000mA 3.36 -10.0000mA -10.0000mA -30.0000mA 3.42 -20.0000mA 0.0A -20.0000mA 3.48 -20.0000mA -10.0000mA -20.0000mA 3.54 -10.0000mA -10.0000mA -30.0000mA 3.60 -10.0000mA -10.0000mA -20.0000mA Best regards, Lars Snith - -- Those who can, Do Those who can't, Simulate - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 13 Jan 2010 16:20:22 -0500 From: "Lance Wang" Subject: [IBIS-Users] IBIS Summit at DesignCon 2010: Second Call for Participation and Presentations - resent This is re-sent message since we had some difficulties for eda.org reflectors. ========================================================================== To All: This is the second announcement for the DesignCon 2010 IBIS Summit meeting to be held at the Santa Clara Convention Center in Santa Clara, California. The IBIS Open Forum is sponsoring the event, but we welcome additional sponsors to cover some of the meeting expenses, including the free lunch and refreshments. Also note that VIP discounts are offered for all DesignCon 2010 conference packages (including free exhibition admission) through links given below. Several IBIS members are also actively participating and presenting material in the DesignCon program. Best Regards, Lance Wang IO Methodology Inc. www.iometh.com - ----------------------------------------------------------------------- IBIS SUMMIT SECOND CALL FOR PARTICIPATION & PRESENTATIONS - ----------------------------------------------------------------------- I B I S S U M M I T M E E T I N G Time/Date: Thursday, February 4, 2010 8:00 AM to 5:00 PM Location: Santa Clara Convention Center 5101 Great America Parkway, Santa Clara, California, USA Room: To Be Determined Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and ideas. Sponsors: Cisco Systems, IBIS, International Engineering Consortium (DesignCon) We are seeking more co-sponsors. Please contact Lance Wang . The benefits to sponsors include recognition at the meeting and acknowledgement in the Calls for Papers and meeting minutes. Your financial support strengthens the organization by allowing IBIS to focus resources on industry activities rather than raising money, and you will receive generous thanks for your support. DesignCon 2010 Conference: February 1 - 4, 2010 Santa Clara Convention Center Santa Clara, CA http://www.designcon.com/2010/ Exhibits registration: http://www.designcon.com/2010/register/index.asp IBIS Summit participants can register at discounted rates through this link for both the conference and exhibition: http://www.designcon.com/2010/vip_passes/ibis.html However, please also notify Lance Wang (lwang@iometh.com) if you are planning to attend the IBIS Summit. Conference Schedule: http://www.designcon.com/2010/attendees/program_schedule.asp BACKGROUND DesignCon is the premier annual Silicon Valley event for the electronic design automation (EDA) and semiconductor industry. Topics of current interest to the IBIS Open Forum are addressed at DesignCon. This meeting will be conducted as a formal IBIS meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to - Lance Wang Registration deadline is Wednesday, January 27, 2010 to receive the free lunch. CALL FOR PRESENTATIONS We are seeking presentations from individuals who have experiences of interest to the IBIS modeling community. In the past, these have included, but not limited to: Demonstrations of modeling techniques Explanations of behavioral algorithms Descriptions of difficulties encountered Model correlation Modeling building experiences Comparisons to other modeling methods New technologies for modeling buffers and component New technologies for modeling packaging and interconnects Algorithmic modeling topics Etc. Presentations may be addressed to any and all levels of IBIS experience, from beginning to advanced. Presentation Format: A conference laptop with LCD projector. Powerpoint* or Acrobat* electronic formats are favored and will pre-loaded on the Windows*-based meeting laptop prior to the meeting. Time: Usually 15-30 Minutes Electronic Archival: Presentations will be archived under the IBIS Summits site and also must be submitted in time for uploading and copying. Final submission deadline is: Wednesday, January 27, 2010 Otherwise, you should bring 50 copies for distribution. If you plan a presentation, please supply the following information as soon as possible: Tentative Title: Presenter: E-mail address: Company: Telephone: Estimated Time: Send to - Bob Ross Note, vendor-specific or product promotion material is illegal at IBIS meeting. We strongly advise that the presentations be submitted by the deadline. The IBIS Open Forum reserves the right to stop or reject a scheduled presentation that has not been previewed. AGENDA The agenda includes presentations, discussions, breaks, and a FREE lunch. The agenda details will be developed as proposals are received. LIST OF NEARBY HOTELS The Hotel and Travel Link provides a conference hotel discount, and use internet search engines other good lodging deals: http://www.designcon.com/2010/hotel/index.asp - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 15 Dec 2009 17:48:48 +0100 From: Lars Snith Subject: Re: [IBIS-Users] PullUp/PullDown toggle? Servus Eckhard, Hello Timothy, Thanks for your feedback. I'm sure I'll get my act together with this to help me! Eckhard, to answer your questions: - - Only warnings are for encrypted content (models) which is normal and then one for a node without DC path. But it is autoconnected to the right node anyway, so it should not matter. - - I did not try a "slow" transient extraction, I have used only the testbenches provided by s2ibis3 and the other tool. - - Nope, the curves reflect this "jumpy" behaviour. But IBISCHK5 does not mind a bit. Best regards, Lars - -- Those who can, Do Those who can't, Simulate - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Fri, 22 Jan 2010 14:59:27 -0800 From: Bob Ross Subject: Re: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and proposed Solutions Hi Nikonchuk: This is the right group to ask IBIS questions. Here is a quick responses without commenting on all of the points you raised. Q1. You are correct that the ranges for I-V table are based on the typical Vcc rather than the actual Vcc. So the minimum column can have some overlap and the maximium column can miss some currents at the ends of the range (if it were extended to - -Vcc_max to 2*Vcc_max). As a practical matter, EDA tools can and will extend the range if needed, either by extrapolation or extension of the table. That should be accurate enough for the unlikely case of having simulations converge in that region. (It that were the case, there is probably a design problem or simulation setup problem that needs to be resolved.) So there was no compelling reason for use the Vcc_max value as the basis for suggesting the table ranges. However, you are allowed to go beyond the ranges suggested by IBIS as long as they apply for all three columns. Q2. The specific question is why the ranges -Vcc to Vcc were chosen for [Gnd Clamp], and Vcc to 2Vcc for [Power Clamp]. In the early days of IBIS (1993), the specification was written for both CMOS and bi-polar transistors and TTL devices (e.g., 74F244) where the input had a bias resistor to Vcc through a diode. So the I-V table showedsmall negative current until the voltage reached about 2 V (with a 5 V Vcc). Then it cut off to nearly 0 A. The IBIS authors chose to use the [Gnd Clamp] table extended to Vcc to capture this effect. Otherwise, the authors might have split the difference an had the ranges of the [Gnd Clamp] and [Power Clamp] table meet in the middle (Vcc/2). But that choice would have produced a clamp table "gap" at that point of interest if the ranges had not been chosen to extend to Vcc_max per Q1. There are other comments with your other statements, which I will only summarize. If the non-monotonic issues is in the numerical "noise" region or as a result of some double counting due to the extraction tool algorithm, it would be permissible to correct the data and take out a few points or zero the data of one of the tables. If there are on-die terminators, then the correction of the tables need to be carefully considered based on other information to avoid double counting - based on what rail or rails the ODT is referenced. But the main point is that the currents of both the [Power Clamp] and {Gnd Clamp] add together for all points in both tables including the extended points that are not specified in either table. Q3. Without giving specific names, I know of several vendors that implement the DEQ-style method and split up the ODT into the components referenced by each rail so that their models correspond to the physical device structure. The accuracy issue is depends on the type of analyis and assumptions. But there are theoretical issues based on tool setups and capabilities if power and ground package model elements are used, or if SSO analysis is done (now and with future features). These issues relate to the Vcc to Gnd impedance changes that may cause the model to switch abruptly in a manner that does not correpond to the physical device operation. Bob Nikonchuk Sergey-R6294C wrote: > Dear IBIS Users Community. > This is a first time when I send e-mail to the IBIS community. > So, be patient, please, if I am use wrong e-mail address or asking > questions which one already clarified in some documentation. > Just point me on right source. > My particular questions that I hope to get answers highlighted below as > "Q1, Q2, Q3" > > During detailed evaluation of IBIS characterization flow, especially for > ODT (On-Die Termination) cells, > we find some issues in Existing s2ibis3 implementation for Clamp current > capturing and printing in to IBIS model. > > 1. The Voltage range not cover Max condition for > [Pullup]/[Pulldown]/[GND_clamp]/[POWER_clamp] I-V Curves > As recommended by IBIS standards and Cookbook , the range for the IV > curves have to be -Vcc::2*Vcc > Now, for "Vcc" value the "Typ" value used. > It mean, if we have Typ Vcc =1.8V +/- 0.1V for Max/Min conditions, > we have -1.8V::3.6V range for IV curves, which one cover Typ and Min > recommendation, > But not enough for Max condition, which one should be -1.9V::3.8V > > I suggest to extend the range for IV Curves capturing up to Max [Voltage > Range] value. > That's have to be applied for All 4 IV curves - [Pullup]/[Pulldown]/[GND > clamp]/[POWER clamp] > > Q1. Is there any particular reasons, comments - Why IV curves referenced > to Typ Vref? Is there concern to extend IV ranges up to Max Vref ? > > > 2. The Minimum recommended range for Clamp IV capturing cause > non-monotonysity issue in Final IBIS models. > Existing implementation of s2ibis3 Assume the Minimum Voltage ranges > for Clamp Curves: > [GND_clamp] -Vcc::Vcc > [POWER_clamp] Vcc:2*Vcc (Ground referenced) > > Below is example: > > > [Voltage Range] 3.3000V 3.0000V 3.6000V > | > [GND_clamp] > |Voltage I(typ) I(min) I(max) > | > -3.30 -3.5860A -3.6101A -3.4617A > -3.23 -3.4782A -3.5024A -3.3533A > -3.16 -3.3704A -3.3947A -3.2450A > ..... > > 3.14 31.9335uA 32.7227uA 40.1997uA > 3.21 32.7095uA 73.2482uA 41.1226uA > 3.28 33.5298uA 0.2503mA 42.0514uA > | > [POWER_clamp] > |Voltage I(typ) I(min) I(max) > | > -3.28 3.5775A 3.6016A 3.4528A > -3.24 3.5154A 3.5397A 3.3904A > -3.20 3.4534A 3.4777A 3.3281A > ..... > > -0.08 35.8263uA 26.4944uA 47.5355uA > -0.04 34.5005uA 25.3183uA 46.9642uA > 0.00 33.7999uA 24.7033uA 46.4029uA > > Looks fine so far? > Now remind that we have [POWER_clamp] values in IBIS file referenced to > [Voltage range] > > Vtable = Vreference - Voutput > > So, if we will re-print the [Power_clamp] table for the Ground-reference > voltages, we will have something like as following: > > [POWER_clamp] > |Voltage I(typ) I(min) I(max) > | > 6.88 3.4528A > 6.84 3.3904A > 6.80 3.3281A > > .... > 6.58 3.5775A 2.4528A > 6.54 3.5154A 2.3904A > 6.50 3.4534A 2.3281A > > .... > > 6.28 2.5775A 3.6016A 1.4528A > 6.24 2.5154A 3.5397A 1.3904A > 6.20 2.4534A 3.4777A 1.3281A > > ..... > > 3.68 39.8263uA 46.4944uA 47.5355uA > 3.64 38.5005uA 45.3183uA 46.9642uA > 3.60 37.7999uA 44.7033uA 46.4029uA > > ........... > 3.38 35.8263uA 36.4944uA ????????? > 3.34 34.5005uA 35.3183uA ????????? > 3.30 33.7999uA 34.7033uA ????????? > > ........ > 3.08 26.4944uA > 3.04 25.3183uA > 3.00 24.7033uA > > And when [POWER_clamp] and [GND_clamp] combined together and added to > [Pullip]/[Pulldown] for simulation, > We have double counting "Min" clamps between 3.0V and 3.3V > And we have kind of "Hole" for Max clamp between 3.28V and 3.6V > Does it looks negligible? > > inischk4 say No. > > WARNING - Model v330_11_c4: POWER Clamp : Typical value never becomes zero > WARNING - Model v330_11_c4: POWER Clamp : Minimum value never becomes zero > WARNING - Model v330_11_c4: POWER Clamp : Maximum value never becomes zero > WARNING - Combined Pulldown for Model: v330_11_c4 Typical data is > non-monotonic > WARNING - Combined Pullup for Model: v330_11_c4 Typical data is > non-monotonic > WARNING - Combined Pulldown for Model: v330_11_c4 Minimum data is > non-monotonic > WARNING - Combined Pullup for Model: v330_11_c4 Minimum data is > non-monotonic > WARNING - Combined Pulldown for Model: v330_11_c4 Maximum data is > non-monotonic > WARNING - Combined Pullup for Model: v330_11_c4 Maximum data is > non-monotonic > > That's Especially Important for the ODT models, where Clamp currents is > quite significant > And cause issues related to accuracy of models simulation. > > What the Solution could be for the issue above? > > Proposed Solution to extend Simulation ranges for both [Power_clamp] and > [GND_clamp] to -Vcc::2*Vcc > (See IBIS_Cookbook_v4.pdf, Table 5-6) > In this case we will cover whole range. > BUT! If we will print All the data "As Is" in to IBIS model, Clamp > Currents will be Duplicated! > One of the Option to avoid duplication described in IBIS cookbook - > Sections 5.1.3.4, 5.1.3.5 > If we just "Clip" the data as described - we have to be take care about > Extrapolation Errors (Section 5.1.3.9) > At the end - it would be almost the same as "minimal range" and will NOT > resolve all ibischk4 warning and simulation concerns. > > More reasonable Approach, applicable for ODT models as well described in > Following Presentation: > http://www.vhdl.org/pub/ibis/summits/jun03b/muranyi3.pdf > > This called as "Clip and Extend" > > ? Sweep device from -Vcc to 2*Vcc twice: GND and Vcc relative > ? Cut clamp curves where they reach zero current going left to right > ? Extrapolate all clamp curves horizontally to 2*Vcc > > Opposite to Cookbook Proposal, this approach Cut clamp current when it's > going from Positive to Negative value > And Extend (Extrapolate) this value to end of characterization range. > > In a reality, for plain (non-ODT) buffers it mean > GND_clamp range: -Vcc::0 > POWER_clamp range 0::2*Vcc (Ground referenced) > > Q2: Why Cookbook 4.0 Sections 5.1.3.4, 5.1.3.5 recommend to clip the > date by Differerent ranges? > GND_clamp range: -Vcc::Vcc > POWER_clamp range Vcc::2*Vcc (Ground referenced) > Is there any concerns to use "Clip and Extend" Approach for All Buffer > types, not ODT only? > GND_clamp range: -Vcc::0 > POWER_clamp range 0::2*Vcc (Ground referenced) > > The Cookbook recommended Clamp ranges seems contradictive with what > IBISCHK really expected and potentially could confuse simulators. > Am I miss something here? > > At the same time, during investigation of this issue we find Alternative > (claimed as more accurate for ODT) approach called as DEC: > http://www.vhdl.org/pub/ibis/summits/sep05/ross2.pdf > > This Approach seems more tricky for Implementation with questionable > added value in term of accuracy. > > Q3: Does anybody implement this approach in they models? What is impact > in terms of simulation accuracy vs. "Clip and extend"? > Can anybody share particular code to split clamps according to DEC > algorithms? > > > I will greatly appreciate any feedback and proposals to address issues > above. > > > Sergey Nikonchuk > Characterization and View Generation > TSO / DT / L&M / IO Pad Cell Libraries > Freescale Semiconductor, Inc. > www.freescale.com > > Contacts: > Phone +7 (495) 589 1839 > Mobile +7 (916) 993 3467 > Fax +7 (495) 787 0151 > Sergey.Nikonchuk@freescale.com > > This e-mail and any attachments have been classified as: > [x] Public > [ ] Internal Use Only > [ ] Confidential Proprietary > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner , and is > believed to be clean. - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 25 Jan 2010 07:57:21 -0000 From: "Nikonchuk Sergey-R6294C" Subject: RE: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and proposed Solutions Hi Bob, Thank You very much for valuable and helpful feedback! Seems like IBIS Cookbook have to be enhanced/clarified, especially for a future 5.0 standard, features And modern technologies/designs. Do you have some specific working group for? Is it possible to participate in - at least for review? Sergey Nikonchuk Characterization and View Generation Digital Standard Cell and IO Pad Cell Libraries TSO / DT / L&M / Libraries Organization www.freescale.com Phone: +7 (495) 589 1839 Phone: +7 (495) 536 9987 Mobile: +7 (916) 993 3467 - -----Original Message----- From: Bob Ross [mailto:bob@teraspeed.com] Sent: Saturday, January 23, 2010 1:59 AM To: Nikonchuk Sergey-R6294C Cc: ibis-users@eda.org; bob@teraspeed.com Subject: Re: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and proposed Solutions Hi Nikonchuk: This is the right group to ask IBIS questions. Here is a quick responses without commenting on all of the points you raised. Q1. You are correct that the ranges for I-V table are based on the typical Vcc rather than the actual Vcc. So the minimum column can have some overlap and the maximium column can miss some currents at the ends of the range (if it were extended to -Vcc_max to 2*Vcc_max). As a practical matter, EDA tools can and will extend the range if needed, either by extrapolation or extension of the table. That should be accurate enough for the unlikely case of having simulations converge in that region. (It that were the case, there is probably a design problem or simulation setup problem that needs to be resolved.) So there was no compelling reason for use the Vcc_max value as the basis for suggesting the table ranges. However, you are allowed to go beyond the ranges suggested by IBIS as long as they apply for all three columns. Q2. The specific question is why the ranges -Vcc to Vcc were chosen for [Gnd Clamp], and Vcc to 2Vcc for [Power Clamp]. In the early days of IBIS (1993), the specification was written for both CMOS and bi-polar transistors and TTL devices (e.g., 74F244) where the input had a bias resistor to Vcc through a diode. So the I-V table showedsmall negative current until the voltage reached about 2 V (with a 5 V Vcc). Then it cut off to nearly 0 A. The IBIS authors chose to use the [Gnd Clamp] table extended to Vcc to capture this effect. Otherwise, the authors might have split the difference an had the ranges of the [Gnd Clamp] and [Power Clamp] table meet in the middle (Vcc/2). But that choice would have produced a clamp table "gap" at that point of interest if the ranges had not been chosen to extend to Vcc_max per Q1. There are other comments with your other statements, which I will only summarize. If the non-monotonic issues is in the numerical "noise" region or as a result of some double counting due to the extraction tool algorithm, it would be permissible to correct the data and take out a few points or zero the data of one of the tables. If there are on-die terminators, then the correction of the tables need to be carefully considered based on other information to avoid double counting - based on what rail or rails the ODT is referenced. But the main point is that the currents of both the [Power Clamp] and {Gnd Clamp] add together for all points in both tables including the extended points that are not specified in either table. Q3. Without giving specific names, I know of several vendors that implement the DEQ-style method and split up the ODT into the components referenced by each rail so that their models correspond to the physical device structure. The accuracy issue is depends on the type of analyis and assumptions. But there are theoretical issues based on tool setups and capabilities if power and ground package model elements are used, or if SSO analysis is done (now and with future features). These issues relate to the Vcc to Gnd impedance changes that may cause the model to switch abruptly in a manner that does not correpond to the physical device operation. Bob Nikonchuk Sergey-R6294C wrote: > Dear IBIS Users Community. > This is a first time when I send e-mail to the IBIS community. > So, be patient, please, if I am use wrong e-mail address or asking > questions which one already clarified in some documentation. > Just point me on right source. > My particular questions that I hope to get answers highlighted below > as "Q1, Q2, Q3" > > During detailed evaluation of IBIS characterization flow, especially > for ODT (On-Die Termination) cells, we find some issues in Existing > s2ibis3 implementation for Clamp current capturing and printing in to > IBIS model. > > 1. The Voltage range not cover Max condition for > [Pullup]/[Pulldown]/[GND_clamp]/[POWER_clamp] I-V Curves As > recommended by IBIS standards and Cookbook , the range for the IV > curves have to be -Vcc::2*Vcc Now, for "Vcc" value the "Typ" value > used. > It mean, if we have Typ Vcc =1.8V +/- 0.1V for Max/Min conditions, we > have -1.8V::3.6V range for IV curves, which one cover Typ and Min > recommendation, But not enough for Max condition, which one should be > -1.9V::3.8V > > I suggest to extend the range for IV Curves capturing up to Max > [Voltage Range] value. > That's have to be applied for All 4 IV curves - > [Pullup]/[Pulldown]/[GND clamp]/[POWER clamp] > > Q1. Is there any particular reasons, comments - Why IV curves > referenced to Typ Vref? Is there concern to extend IV ranges up to Max Vref ? > > > 2. The Minimum recommended range for Clamp IV capturing cause > non-monotonysity issue in Final IBIS models. > Existing implementation of s2ibis3 Assume the Minimum Voltage ranges > for Clamp Curves: > [GND_clamp] -Vcc::Vcc > [POWER_clamp] Vcc:2*Vcc (Ground referenced) > > Below is example: > > > [Voltage Range] 3.3000V 3.0000V 3.6000V > | > [GND_clamp] > |Voltage I(typ) I(min) I(max) > | > -3.30 -3.5860A -3.6101A -3.4617A > -3.23 -3.4782A -3.5024A -3.3533A > -3.16 -3.3704A -3.3947A -3.2450A > ..... > > 3.14 31.9335uA 32.7227uA 40.1997uA > 3.21 32.7095uA 73.2482uA 41.1226uA > 3.28 33.5298uA 0.2503mA 42.0514uA > | > [POWER_clamp] > |Voltage I(typ) I(min) I(max) > | > -3.28 3.5775A 3.6016A 3.4528A > -3.24 3.5154A 3.5397A 3.3904A > -3.20 3.4534A 3.4777A 3.3281A > ..... > > -0.08 35.8263uA 26.4944uA 47.5355uA > -0.04 34.5005uA 25.3183uA 46.9642uA > 0.00 33.7999uA 24.7033uA 46.4029uA > > Looks fine so far? > Now remind that we have [POWER_clamp] values in IBIS file referenced > to [Voltage range] > > Vtable = Vreference - Voutput > > So, if we will re-print the [Power_clamp] table for the > Ground-reference voltages, we will have something like as following: > > [POWER_clamp] > |Voltage I(typ) I(min) I(max) > | > 6.88 3.4528A > 6.84 3.3904A > 6.80 3.3281A > > .... > 6.58 3.5775A 2.4528A > 6.54 3.5154A 2.3904A > 6.50 3.4534A 2.3281A > > .... > > 6.28 2.5775A 3.6016A 1.4528A > 6.24 2.5154A 3.5397A 1.3904A > 6.20 2.4534A 3.4777A 1.3281A > > ..... > > 3.68 39.8263uA 46.4944uA 47.5355uA > 3.64 38.5005uA 45.3183uA 46.9642uA > 3.60 37.7999uA 44.7033uA 46.4029uA > > ........... > 3.38 35.8263uA 36.4944uA ????????? > 3.34 34.5005uA 35.3183uA ????????? > 3.30 33.7999uA 34.7033uA ????????? > > ........ > 3.08 26.4944uA > 3.04 25.3183uA > 3.00 24.7033uA > > And when [POWER_clamp] and [GND_clamp] combined together and added to > [Pullip]/[Pulldown] for simulation, We have double counting "Min" > clamps between 3.0V and 3.3V And we have kind of "Hole" for Max clamp > between 3.28V and 3.6V Does it looks negligible? > > inischk4 say No. > > WARNING - Model v330_11_c4: POWER Clamp : Typical value never becomes > zero WARNING - Model v330_11_c4: POWER Clamp : Minimum value never > becomes zero WARNING - Model v330_11_c4: POWER Clamp : Maximum value > never becomes zero WARNING - Combined Pulldown for Model: v330_11_c4 > Typical data is non-monotonic WARNING - Combined Pullup for Model: > v330_11_c4 Typical data is non-monotonic WARNING - Combined Pulldown > for Model: v330_11_c4 Minimum data is non-monotonic WARNING - Combined > Pullup for Model: v330_11_c4 Minimum data is non-monotonic WARNING - > Combined Pulldown for Model: v330_11_c4 Maximum data is non-monotonic > WARNING - Combined Pullup for Model: v330_11_c4 Maximum data is > non-monotonic > > That's Especially Important for the ODT models, where Clamp currents > is quite significant And cause issues related to accuracy of models > simulation. > > What the Solution could be for the issue above? > > Proposed Solution to extend Simulation ranges for both [Power_clamp] > and [GND_clamp] to -Vcc::2*Vcc (See IBIS_Cookbook_v4.pdf, Table 5-6) > In this case we will cover whole range. > BUT! If we will print All the data "As Is" in to IBIS model, Clamp > Currents will be Duplicated! > One of the Option to avoid duplication described in IBIS cookbook - > Sections 5.1.3.4, 5.1.3.5 If we just "Clip" the data as described - we > have to be take care about Extrapolation Errors (Section 5.1.3.9) At > the end - it would be almost the same as "minimal range" and will NOT > resolve all ibischk4 warning and simulation concerns. > > More reasonable Approach, applicable for ODT models as well described > in Following Presentation: > http://www.vhdl.org/pub/ibis/summits/jun03b/muranyi3.pdf > > This called as "Clip and Extend" > > ? Sweep device from -Vcc to 2*Vcc twice: GND and Vcc relative ? Cut > clamp curves where they reach zero current going left to right ? > Extrapolate all clamp curves horizontally to 2*Vcc > > Opposite to Cookbook Proposal, this approach Cut clamp current when > it's going from Positive to Negative value And Extend (Extrapolate) > this value to end of characterization range. > > In a reality, for plain (non-ODT) buffers it mean GND_clamp range: > -Vcc::0 POWER_clamp range 0::2*Vcc (Ground referenced) > > Q2: Why Cookbook 4.0 Sections 5.1.3.4, 5.1.3.5 recommend to clip the > date by Differerent ranges? > GND_clamp range: -Vcc::Vcc > POWER_clamp range Vcc::2*Vcc (Ground referenced) Is there any concerns > to use "Clip and Extend" Approach for All Buffer types, not ODT only? > GND_clamp range: -Vcc::0 > POWER_clamp range 0::2*Vcc (Ground referenced) > > The Cookbook recommended Clamp ranges seems contradictive with what > IBISCHK really expected and potentially could confuse simulators. > Am I miss something here? > > At the same time, during investigation of this issue we find > Alternative (claimed as more accurate for ODT) approach called as DEC: > http://www.vhdl.org/pub/ibis/summits/sep05/ross2.pdf > > This Approach seems more tricky for Implementation with questionable > added value in term of accuracy. > > Q3: Does anybody implement this approach in they models? What is > impact in terms of simulation accuracy vs. "Clip and extend"? > Can anybody share particular code to split clamps according to DEC > algorithms? > > > I will greatly appreciate any feedback and proposals to address > issues above. > > > Sergey Nikonchuk > Characterization and View Generation > TSO / DT / L&M / IO Pad Cell Libraries Freescale Semiconductor, Inc. > www.freescale.com > > Contacts: > Phone +7 (495) 589 1839 > Mobile +7 (916) 993 3467 > Fax +7 (495) 787 0151 > Sergey.Nikonchuk@freescale.com > > This e-mail and any attachments have been classified as: > [x] Public > [ ] Internal Use Only > [ ] Confidential Proprietary > > > > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner , and is believed to be > clean. - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 22 Oct 2009 19:24:01 +0200 From: "Kobi Pinhas" Subject: RE: [IBIS-Users] Clamp graphs issue. This is a multi-part message in MIME format. - ------=_NextPart_000_0EAD_01CA534D.35F3FC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. Thanks you. I missed the sub model section. _____ From: rrwolff@micron.com [mailto:rrwolff@micron.com] Sent: Thursday, October 22, 2009 7:19 PM To: kobi.pinhas@wintegra.co.il; ibis-users@eda.org Subject: RE: [IBIS-Users] Clamp graphs issue. Kobi, Is the Termination data contained in [Submodel] I-V curves? Your IBIS viewer program doesn't plot I-V data in Submodels. You can look under the [Model] keyword for something like the following: [Add Submodel] | Submodel Name Mode 120ohm_ODT_1066 Non-Driving Regards, Randy From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Kobi Pinhas Sent: Thursday, October 22, 2009 9:57 AM To: ibis-users@eda.org Subject: [IBIS-Users] Clamp graphs issue. Hi all. I have some conceptual issue. The next graph represents gnd clamp of an input model of a memory with 120 ohm ODT This is model of a famous company which I download: I don't understand how it is possible that the current is zero fot V> -0.5V. The meaning of ODT is resistor that connected from the input to the gnd. So for this range (when V>-0.5V) I was expecting to see linear current with a slope that equal to the resistor. For example when I simulated gnd clamp of an input buffer with 50 ohm ODT I received the next plot: You can see that the plot is liner for V> -0.5V as expected. I looked in a lot of ibis file and I never saw common behavior. So I guess that maybe I am doing something wrong. I will be glad to hear your comments. Thanks a lot. Kobi. - -- 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_0EAD_01CA534D.35F3FC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes.

Thanks you.

I missed the sub model section.

 

From: rrwolff@micron.com [mailto:rrwolff@micron.com]
Sent: Thursday, October 22, = 2009 7:19 PM
To: kobi.pinhas@wintegra.co.= il; ibis-users@eda.org
Subject: RE: [IBIS-Users] Cl= amp graphs issue.

 

Kobi,

 

Is the Termination data contained in [Submodel] I-V curves?  Your IBIS vi= ewer program doesn’t plot I-V data in Submodels.  You can look under = the [Model] keyword for something like the following:<= /p>

 

[Add Submodel]

| Submodel Name        Mode

120ohm_ODT_1066         Non-Driving

 

Regards,

Randy

 

 

 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Be= half Of Kobi Pinhas
Sent: Thursday, October 22, = 2009 9:57 AM
To: ibis-users@eda.org
Subject: [IBIS-Users] Clamp = graphs issue.

 

Hi all.

I have some conceptual issue.

The next graph represents gnd clamp of an input model of a memory with 120 ohm = ODT

This is model of a famous company which I download:

 

 

I don’t understand how it is possible that the current is zero fot V> - -0.5V.

The meaning of ODT is resistor that connected from the input to the gnd.

So for this range (when V>-0.5V) I was expecting to see linear current with= a slope that equal to the resistor.

 

For example when I simulated gnd clamp of an input buffer with 50 ohm ODT I received the next plot:

 

 

You can see that the plot is liner for V> -0.5V as expected.

I looked in a lot of ibis file and I never saw common behavior.

So I guess that maybe I am doing something wrong.

 

I will be glad to hear your comments.

 

Thanks a lot.

 

Kobi.


- --
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_0EAD_01CA534D.35F3FC90-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 28 Jan 2010 10:53:04 -0800 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] The spice2ibis IV Clamp Issues and proposed Solutions Sergey, Sorry for using your last name, it was an oversight that I think Bob started and then I continued. I usually use people's first name in my emails... Are you Russian? (I am Hungarian)... Also, sorry for the slow response, things are busy around here... Regarding pg. 28, I am not quite sure what is bothering you about it, but it seems that you are thinking that the ranges that I am trying to describe on pg. 28 are also effecting the behavior of the model. This is not true. Pg. 28 talks only about how to format the data properly to obey the rules about having a point at the ends of the I-V tables. Actually it is not required to use the typ value for this purpose. You can also use the max value for this purpose. The point is that the I-V tables use only one voltage column which is applied to all three conditions (typ., min., max.) and you need to get the sweep ranges so that the single voltage column would work for all three conditions with the rule of having a point at the end of each of the columns. I hope this helps. Let me know if you have more questions. Arpad =========================================================== - -----Original Message----- From: Nikonchuk Sergey-R6294C [mailto:R6294C@freescale.com] Sent: Wednesday, January 27, 2010 3:07 AM To: Muranyi, Arpad; ibis-users@eda.org Subject: RE: [IBIS-Users] The spice2ibis IV Clamp Issues and proposed Solutions Hi Arpad, Thank you for pointing on useful and helpful training classes. I have at least one question about slide 28: ======================================================= What about typ., min., and max. supply voltages? * the voltage range should be based on the typical value only because there is one voltage column for each case, and a numerical value is required in the first and last points ======================================================= There is quite strange recommendation from my point of view, because [Voltage range] IBIS keyword used not just as a reference voltage for [Pullup]/[Power clamp], But! It is define IO Buffer operation voltage as well, according to IBIS standard (see below) |======================================================================= ====== | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], [POWER | Clamp Reference], and [GND Clamp Reference] are not present | Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the [Pullup] and [POWER Clamp] I-V data | is referenced. Could you clarify more detailed, please? How we will be able to use exactly same (typical) voltage range with different typ/min/max supply voltages? According to standard it is exactly same value. Isn't it? The only one thing that we can change is - voltage that we sweep on a pad (Voutput in terms of Cookbook). But PullUp/Power clamp curves would be mismatched any way - either Vcc referenced or ground referenced. Isn't it? The cookbook more/less well defined for One (let's say typ values) But - almost nothing about max/min waveforms capturing and printing. BTW, my first name is Sergey. Use surname is not really necessary for a future communications :-) Thanks, Sergey Nikonchuk Characterization and View Generation Digital Standard Cell and IO Pad Cell Libraries TSO / DT / L&M / Libraries Organization www.freescale.com Phone: +7 (495) 589 1839 Phone: +7 (495) 536 9987 Mobile: +7 (916) 993 3467 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad Sent: Tuesday, January 26, 2010 7:18 PM To: ibis-users@eda.org Subject: RE: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and proposed Solutions Nikonchuk, In addition to Bob's answer, I would suggest that you look at slides 26-28 and 85-92 in the "IBIS_class_2003_11_03.PDF" file in http://www.vhdl.org/pub/ibis/training/IBIS_class_2003.zip Even though there are not too many words on these slides, I hope that the pictures will help you to understand these details about I-V curves. I would also recommend that you look at the IBIS Cookbook: http://www.vhdl.org/pub/ibis/cookbook/cookbook-v4.pdf Starting at Section 5.1.3.3 the Cookbook deals with I-V curve extraction for the various tables for IBIS models. Regarding what s2ibis does, I had a chance to talk with the authors at the time it was first being developed and made similar observations as you, and suggested alternative ways, but they still decided to do it the way it is. That was their choice, which does not necessarily mean that it is the best method. I hope these answers will help you in your work. Thanks, Arpad ============================================================= - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Friday, January 22, 2010 4:59 PM To: Nikonchuk Sergey-R6294C Cc: ibis-users@eda.org; bob@teraspeed.com Subject: Re: [IBIS-Users] RE: The spice2ibis IV Clamp Issues and proposed Solutions Hi Nikonchuk: This is the right group to ask IBIS questions. Here is a quick responses without commenting on all of the points you raised. Q1. You are correct that the ranges for I-V table are based on the typical Vcc rather than the actual Vcc. So the minimum column can have some overlap and the maximium column can miss some currents at the ends of the range (if it were extended to -Vcc_max to 2*Vcc_max). As a practical matter, EDA tools can and will extend the range if needed, either by extrapolation or extension of the table. That should be accurate enough for the unlikely case of having simulations converge in that region. (It that were the case, there is probably a design problem or simulation setup problem that needs to be resolved.) So there was no compelling reason for use the Vcc_max value as the basis for suggesting the table ranges. However, you are allowed to go beyond the ranges suggested by IBIS as long as they apply for all three columns. Q2. The specific question is why the ranges -Vcc to Vcc were chosen for [Gnd Clamp], and Vcc to 2Vcc for [Power Clamp]. In the early days of IBIS (1993), the specification was written for both CMOS and bi-polar transistors and TTL devices (e.g., 74F244) where the input had a bias resistor to Vcc through a diode. So the I-V table showedsmall negative current until the voltage reached about 2 V (with a 5 V Vcc). Then it cut off to nearly 0 A. The IBIS authors chose to use the [Gnd Clamp] table extended to Vcc to capture this effect. Otherwise, the authors might have split the difference an had the ranges of the [Gnd Clamp] and [Power Clamp] table meet in the middle (Vcc/2). But that choice would have produced a clamp table "gap" at that point of interest if the ranges had not been chosen to extend to Vcc_max per Q1. There are other comments with your other statements, which I will only summarize. If the non-monotonic issues is in the numerical "noise" region or as a result of some double counting due to the extraction tool algorithm, it would be permissible to correct the data and take out a few points or zero the data of one of the tables. If there are on-die terminators, then the correction of the tables need to be carefully considered based on other information to avoid double counting - based on what rail or rails the ODT is referenced. But the main point is that the currents of both the [Power Clamp] and {Gnd Clamp] add together for all points in both tables including the extended points that are not specified in either table. Q3. Without giving specific names, I know of several vendors that implement the DEQ-style method and split up the ODT into the components referenced by each rail so that their models correspond to the physical device structure. The accuracy issue is depends on the type of analyis and assumptions. But there are theoretical issues based on tool setups and capabilities if power and ground package model elements are used, or if SSO analysis is done (now and with future features). These issues relate to the Vcc to Gnd impedance changes that may cause the model to switch abruptly in a manner that does not correpond to the physical device operation. Bob Nikonchuk Sergey-R6294C wrote: > Dear IBIS Users Community. > This is a first time when I send e-mail to the IBIS community. > So, be patient, please, if I am use wrong e-mail address or asking > questions which one already clarified in some documentation. > Just point me on right source. > My particular questions that I hope to get answers highlighted below as > "Q1, Q2, Q3" > > During detailed evaluation of IBIS characterization flow, especially for > ODT (On-Die Termination) cells, > we find some issues in Existing s2ibis3 implementation for Clamp current > capturing and printing in to IBIS model. > > 1. The Voltage range not cover Max condition for > [Pullup]/[Pulldown]/[GND_clamp]/[POWER_clamp] I-V Curves As > recommended by IBIS standards and Cookbook , the range for the IV > curves have to be -Vcc::2*Vcc Now, for "Vcc" value the "Typ" value > used. > It mean, if we have Typ Vcc =1.8V +/- 0.1V for Max/Min conditions, we > have -1.8V::3.6V range for IV curves, which one cover Typ and Min > recommendation, But not enough for Max condition, which one should be > -1.9V::3.8V > > I suggest to extend the range for IV Curves capturing up to Max [Voltage > Range] value. > That's have to be applied for All 4 IV curves - [Pullup]/[Pulldown]/[GND > clamp]/[POWER clamp] > > Q1. Is there any particular reasons, comments - Why IV curves referenced > to Typ Vref? Is there concern to extend IV ranges up to Max Vref ? > > > 2. The Minimum recommended range for Clamp IV capturing cause > non-monotonysity issue in Final IBIS models. > Existing implementation of s2ibis3 Assume the Minimum Voltage ranges > for Clamp Curves: > [GND_clamp] -Vcc::Vcc > [POWER_clamp] Vcc:2*Vcc (Ground referenced) > > Below is example: > > > [Voltage Range] 3.3000V 3.0000V 3.6000V > | > [GND_clamp] > |Voltage I(typ) I(min) I(max) > | > -3.30 -3.5860A -3.6101A -3.4617A > -3.23 -3.4782A -3.5024A -3.3533A > -3.16 -3.3704A -3.3947A -3.2450A > ..... > > 3.14 31.9335uA 32.7227uA 40.1997uA > 3.21 32.7095uA 73.2482uA 41.1226uA > 3.28 33.5298uA 0.2503mA 42.0514uA > | > [POWER_clamp] > |Voltage I(typ) I(min) I(max) > | > -3.28 3.5775A 3.6016A 3.4528A > -3.24 3.5154A 3.5397A 3.3904A > -3.20 3.4534A 3.4777A 3.3281A > ..... > > -0.08 35.8263uA 26.4944uA 47.5355uA > -0.04 34.5005uA 25.3183uA 46.9642uA > 0.00 33.7999uA 24.7033uA 46.4029uA > > Looks fine so far? > Now remind that we have [POWER_clamp] values in IBIS file referenced to > [Voltage range] > > Vtable = Vreference - Voutput > > So, if we will re-print the [Power_clamp] table for the Ground-reference > voltages, we will have something like as following: > > [POWER_clamp] > |Voltage I(typ) I(min) I(max) > | > 6.88 3.4528A > 6.84 3.3904A > 6.80 3.3281A > > .... > 6.58 3.5775A 2.4528A > 6.54 3.5154A 2.3904A > 6.50 3.4534A 2.3281A > > .... > > 6.28 2.5775A 3.6016A 1.4528A > 6.24 2.5154A 3.5397A 1.3904A > 6.20 2.4534A 3.4777A 1.3281A > > ..... > > 3.68 39.8263uA 46.4944uA 47.5355uA > 3.64 38.5005uA 45.3183uA 46.9642uA > 3.60 37.7999uA 44.7033uA 46.4029uA > > ........... > 3.38 35.8263uA 36.4944uA ????????? > 3.34 34.5005uA 35.3183uA ????????? > 3.30 33.7999uA 34.7033uA ????????? > > ........ > 3.08 26.4944uA > 3.04 25.3183uA > 3.00 24.7033uA > > And when [POWER_clamp] and [GND_clamp] combined together and added to > [Pullip]/[Pulldown] for simulation, We have double counting "Min" > clamps between 3.0V and 3.3V And we have kind of "Hole" for Max clamp > between 3.28V and 3.6V Does it looks negligible? > > inischk4 say No. > > WARNING - Model v330_11_c4: POWER Clamp : Typical value never becomes zero > WARNING - Model v330_11_c4: POWER Clamp : Minimum value never becomes zero > WARNING - Model v330_11_c4: POWER Clamp : Maximum value never becomes zero > WARNING - Combined Pulldown for Model: v330_11_c4 Typical data is > non-monotonic WARNING - Combined Pullup for Model: v330_11_c4 Typical > data is non-monotonic WARNING - Combined Pulldown for Model: > v330_11_c4 Minimum data is non-monotonic WARNING - Combined Pullup for > Model: v330_11_c4 Minimum data is non-monotonic WARNING - Combined > Pulldown for Model: v330_11_c4 Maximum data is non-monotonic WARNING - > Combined Pullup for Model: v330_11_c4 Maximum data is non-monotonic > > That's Especially Important for the ODT models, where Clamp currents is > quite significant > And cause issues related to accuracy of models simulation. > > What the Solution could be for the issue above? > > Proposed Solution to extend Simulation ranges for both [Power_clamp] and > [GND_clamp] to -Vcc::2*Vcc > (See IBIS_Cookbook_v4.pdf, Table 5-6) > In this case we will cover whole range. > BUT! If we will print All the data "As Is" in to IBIS model, Clamp > Currents will be Duplicated! > One of the Option to avoid duplication described in IBIS cookbook - > Sections 5.1.3.4, 5.1.3.5 If we just "Clip" the data as described - we > have to be take care about > Extrapolation Errors (Section 5.1.3.9) At the end - it would be almost > the same as "minimal range" and will NOT > resolve all ibischk4 warning and simulation concerns. > > More reasonable Approach, applicable for ODT models as well described in > Following Presentation: > http://www.vhdl.org/pub/ibis/summits/jun03b/muranyi3.pdf > > This called as "Clip and Extend" > > ? Sweep device from -Vcc to 2*Vcc twice: GND and Vcc relative ? Cut > clamp curves where they reach zero current going left to right ? > Extrapolate all clamp curves horizontally to 2*Vcc > > Opposite to Cookbook Proposal, this approach Cut clamp current when it's > going from Positive to Negative value > And Extend (Extrapolate) this value to end of characterization range. > > In a reality, for plain (non-ODT) buffers it mean GND_clamp range: > -Vcc::0 POWER_clamp range 0::2*Vcc (Ground referenced) > > Q2: Why Cookbook 4.0 Sections 5.1.3.4, 5.1.3.5 recommend to clip the > date by Differerent ranges? > GND_clamp range: -Vcc::Vcc > POWER_clamp range Vcc::2*Vcc (Ground referenced) Is there any concerns > to use "Clip and Extend" Approach for All Buffer > types, not ODT only? > GND_clamp range: -Vcc::0 > POWER_clamp range 0::2*Vcc (Ground referenced) > > The Cookbook recommended Clamp ranges seems contradictive with what > IBISCHK really expected and potentially could confuse simulators. > Am I miss something here? > > At the same time, during investigation of this issue we find Alternative > (claimed as more accurate for ODT) approach called as DEC: > http://www.vhdl.org/pub/ibis/summits/sep05/ross2.pdf > > This Approach seems more tricky for Implementation with questionable > added value in term of accuracy. > > Q3: Does anybody implement this approach in they models? What is impact > in terms of simulation accuracy vs. "Clip and extend"? > Can anybody share particular code to split clamps according to DEC > algorithms? > > > I will greatly appreciate any feedback and proposals to address issues > above. > > > Sergey Nikonchuk > Characterization and View Generation > TSO / DT / L&M / IO Pad Cell Libraries Freescale Semiconductor, Inc. > www.freescale.com > > Contacts: > Phone +7 (495) 589 1839 > Mobile +7 (916) 993 3467 > Fax +7 (495) 787 0151 > Sergey.Nikonchuk@freescale.com > > This e-mail and any attachments have been classified as: > [x] Public > [ ] Internal Use Only > [ ] Confidential Proprietary > > > > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner , and is > believed to be clean. - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- 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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/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 majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ End of ibis-users V1 #137 *************************