From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #108 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Wednesday, December 5 2007 Volume 01 : Number 108 ---------------------------------------------------------------------- Date: Tue, 20 Nov 2007 00:37:17 -0500 From: "Ambrish Varma" Subject: RE: [IBIS-Users] S2IBIS3 Queries This is a multi-part message in MIME format. - ------_=_NextPart_001_01C82B37.AC27DB2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Sudarshan, If I understand you correctly, you would not want to model either pc3b01_p or pc3b01d_p. You should be modeling PAD. pc3b01_p and pc3b01d_p are internal spice node name that you would be entering in the pin list ([pin]) in your .s2i file. You should look at the examples provided with s2ibis3 for a more detailed understanding. =20 As for your second question, there is a real life example posted in the s2ibis3 FAQ webpage at http://www.ece.ncsu.edu/erl/ibis/faq/S2IBIS3_FAQ.htm=20 Your third question is also explained in one of the examples in the s2ibis3 distribution. =20 Thanks, Ambrish. =20 =20 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Sudarshan H N Sent: Monday, November 19, 2007 12:23 AM To: Fabio BRINA Cc: ibis-users@eda.org Subject: Re: [IBIS-Users] S2IBIS3 Queries =20 Hi Fabio, I will show you a sample spice netlist i have. .SUBCKT pc3b01_p PAD I OEN CIN .. .. .. .ENDS .SUBCKT pc3b01d_p PAD I OEN CIN .. .. .. .ENDS With this example, suppose if i want to model only pc3b01_p, then how can i give this in the setup file. Since the pins are common to both the models how S2IBIS distinguishes between 2 models and how it will select the correct one. ?=20 As per the tools and scripts i have written, i will always search for the particular spice netlist with .SUBCKT option and then use that model . But i am not sure how S2IBIS is doing it . Can you explain me ? Regards Sudarshan On Nov 16, 2007 2:37 PM, Fabio BRINA wrote: Hello Sudarshan, I don't studied the java script. But I send you a .spi file=20 generated by S2ibis3, where you can see how work the tool: from this file it extract Power Clamp (typical). firstly you can see the netlist (.subckt INVBH2, CLPDPTT, ESDINTT etc.) secondly the models (.model DPPNWR etc : these are Eldo models) finally you find the NET added from the tool, voltage source VOUTS2I, VCLMPS2I etc, connected to the pin you are considering ( OEIN in this case ) If you have many .subckts inside the same file, I think you have also a top netlist were you can identify univocally the Pins. Regards, Fabio Brina Sudarshan H N wrote: Hi Fabio, Regarding the first question, my doubt was , if we have many IO pad netlists in a single file, how to give the names of those pads which we want to model it. Normally the spice netlists start with .SUBCKT structure. So i expected S2IBIS to search for this keyword and select the appropriate spice model. But i didnt find any such statement in the java scripts which will search for the netlists. How does S2IBIS identify different pad names ?=20 Regards Sudarshan On Nov 14, 2007 8:02 PM, Fabio BRINA wrote: Hi Sudarshan, 1. The only pads that will be modeled are those included in the [Pin] section: [Pin] VDD VDD VDD POWER VGND VGND VGND GND EN1 EN1 EN1 mod_en IN1 IN1 IN1 mod_in OUT OUT OUT mod_out - -> IN1 EN1 In this case only OUT , EN1 and IN1 will be modeled; obviously the other pad have to be fixed in the right level, with specific voltage source inside the netlist. 2. You have to separate the corners in three files, and insert them in the following specification: [Model file] corners_typ corners_min corners_max 3. You can consider each pin for time. Or you can fix the [Voltage Range ] under the [model]=20 associated to your pad pin. as you can read in s2ibis3.txt file. I hope this helpful for your work. Regards, Fabio Brina Sudarshan H N wrote: Hello, I downloaded new s2ibis3 from the site http://www.ece.ncsu.edu/erl/ibis/s2ibis3/s2ibis3.htm and tried using it. I was able generate IBIS models with the example given in that link. But i am not able to generate separate IBIS models for the spice models . While providing input to *.s2i file i have the following queries.=20 1. If the IO spice netlist contains all the IO pad netlists in a single file , how to give the only those IO pad names that i wish to model it. 2. In the process model file, if all the typical, min and max corner definitions are present in a single file, how do we separately mention process models for each corner.=20 eg: .lib '/home/sudarshann/ibis/S2IBIS/new/tsl018.lib' ff_hv for fast corner=20 .lib '/home/sudarshann/ibis/S2IBIS/new/tsl018.lib' ss_hv for slow corner =20 How can i achieve such kind of constructs in S2IBIS setup file .=20 3. How can i mention the separate voltage levels for each pin. For example how can i specify , say 1.2V on Input and enable pins and 3.3V on PAD pins. Let me know your answers. Regards Sudarshan=20 - --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner , and is believed to be clean.=20 =20 =20 =20 *Typ power clamp curve for model mod_dir *Spice Deck created by S2IBIS3 Version 1.1 *North Carolina State University *-------------------------------------------------------------------- *--------------------------------------------------------------------=20 ****** The NETLIST ******* *-------------------------- .GLOBAL GNDE + GND + VDD *-------------------------------------------------------------------- *--------------------------------------------------------------------=20 *[?param] *-------------------------------------------------------------------- *-------------------------------------------------------------------- .OPTION XA =3D 9.750000e-07 *--------------------------------------------------------------------=20 *-------------------------------------------------------------------- .SUBCKT INVBH2 A Y MM10 Y A GND GND EN3 W=3D3.5u L=3D5u AD=3D3.4125e-12 AS=3D3.4125e-12 +PD=3D5.45e-06 PS=3D5.45e-06 M=3D1 MM19 Y VDD NET24 NET24 EP3 W=3D10u L=3D 0.45u AD=3D3.51e-10 AS=3D3.51e-10 +PD=3D0.00036195 PS=3D0.00036195 M=3D1 MM11 Y A NET24 NET24 EP3 W=3D5u L=3D1u AD=3D5.85e-12 AS=3D5.85e-12 PD=3D7.9= 5e-06 +PS=3D7.95e-06 M=3D1 MM9 NET24 Y VDD NET24 EP3 W=3D310u L=3D0.35u AD=3D3.51e-10 AS=3D3.51e-10=20 +PD=3D0.00036195 PS=3D0.00036195 M=3D1 .ENDS INVBH2 *-------------------------------------------------------------------- *-------------------------------------------------------------------- .SUBCKT CLPDPTT INOUT=20 MM41 INOUT NET64 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11 +AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1 MM28 INOUT NET68 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11 +AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1=20 MM42 INOUT NET64 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11 +AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1 MM34 INOUT NET68 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11 +AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1=20 DD37 NET64 INOUT DPPNW AREA=3D3.3p DD29 NET68 INOUT DPPNW AREA=3D3.3p DD32 NET68 INOUT DPPNW AREA=3D3.3p DD38 NET64 INOUT DPPNW AREA=3D3.3p XR36 GNDE NET64 GND RPO1M1 r=3D3560 w=3D0.35e-06 nc=3D1 XR30 GNDE NET68 GND RPO1M1 r=3D3560 w=3D 0.35e-06 nc=3D1 XR35 GNDE NET64 GND RPO1M1 r=3D3560 w=3D0.35e-06 nc=3D1 XR31 GNDE NET68 GND RPO1M1 r=3D3560 w=3D0.35e-06 nc=3D1 .ENDS CLPDPTT *-------------------------------------------------------------------- *--------------------------------------------------------------------=20 .SUBCKT ESDINTT A RECIN XR40 NET11 RECIN GND RPO1M1 r=3D163 w=3D1.9e-06 nc=3D2 XR34 A NET17 GND RPO1M1 r=3D87 w=3D4.5e-06 nc=3D5 XR38 NET17 NET11 GND RNDIFFM1 r=3D196 w=3D1.9e-06 nc=3D2 DD4 GND NET17 DNPPSR AREA=3D308p PERI=3D36.8u=20 .ENDS ESDINTT *-------------------------------------------------------------------- *-------------------------------------------------------------------- .SUBCKT INV A Y MM10 Y A GND GND EN3 W=3Dwn L=3Dln M=3D1 MM9 Y A VDD VDD EP3 W=3Dwp L=3Dlp M=3D1 .ENDS INV *-------------------------------------------------------------------- *-------------------------------------------------------------------- .CONNECT GND GNDE XI11 NET23 NET9 INVBH2=20 XI9 OEIN CLPDPTT XI8 OEIN NET9 ESDINTT XI17 OEOUT NET23 INV ln=3D2u lp=3D2u wn=3D7u wp=3D13u XI10 NET23 OEOUT INV ln=3D0.35u lp=3D0.35u wn=3D44u wp=3D90u XI18 NET9 NET23 INV ln=3D0.35u lp=3D0.35u wn=3D20u wp=3D55u *---------------------------------------------------------------=20 * Spice Model : DPPNWR *--------------------------------------------------------------- *********** THE MODELS ************* *---------------------------------------------------------------------- * Simulator: #ELDO 4.5 *---------------------------------------------------------------------- * .model DPPNWR d + level=3D8 diolev=3D9 tnom=3D27 + vr=3D0 cjbr=3D0.001329 cjsr=3D3.146e-10=20 + cjgr=3D1.864e-10 jsdbr=3D1.9e-07 jsdsr=3D4.572e-14 + jsdgr=3D1e-20 jsgbr=3D4.057e-06 jsgsr=3D2.782e-11 + jsggr=3D4.751e-11 vdbr=3D0.8 vdsr=3D0.8 + vdgr=3D0.8 pb=3D 0.43 ps=3D0.33 + pg=3D0.43 *.endl DPPNWJU_typ *--------------------------------------------------------------- * Spice Model : EPMM9JU *---------------------------------------------------------------=20 * *---------------------------------------------------------------------- * PMOS : EP (Model : MM9JU - subckt Juncap) typ *---------------------------------------------------------------------- * Simulator: #ELDO 4.5 *---------------------------------------------------------------------- .SUBCKT EPMM9JU D G S B + param: W=3D10e-6 L=3D10e-6 nfing=3D1 + wfing=3D{w/nfing+0} + fd=3D{nfing-2*trunc(nfing/2)} + fs=3D{2-fd}=20 + AD=3D{wfing*(nfing*(1.15e-06)/2+fd*(1.15e-06)/2)} + AS=3D{wfing*(nfing*(1.15e-06)/2+fs*(1.15e-06)/2)} + PD=3D{nfing*2*(1.15e-06)/2+fd*(wfing+1.15e-06)} + PS=3D{nfing*2*(1.15e-06)/2+fs*(wfing+1.15e-06)}=20 M1 D G S B EPMM9JU W=3DW L=3DL AS=3DAS AD=3DAD PS=3DPS PD=3DPD .ENDS .MODEL EPMM9JU + pmos + level=3D59 + tox=3D8.2e-09 tr=3D27 ler=3D9.954e-06 + lvar=3D0 lap=3D2.2994e-08 wer=3D 9.8871e-06 + wvar=3D0 wot=3D5.6447e-08 vtor=3D0.605 + slvto=3D2.4157e-08 sl2vto=3D-8.8158e-15 swvto=3D-2.4478e-09 + stvto=3D-0.00093097 betsq=3D4.6238e-05 etabet=3D1.1695 + the1r=3D0.21277 slthe1r=3D 6.6646e-08 swthe1=3D-1.19e-09 + stthe1r=3D-0.00045468 stlthe1=3D-1.8179e-10 the2r=3D0.33738 + slthe2r=3D-3.7174e-08 swthe2=3D1.9299e-08 stthe2r=3D-0.0004339 + stlthe2=3D7.9686e-11 kor=3D0.65138 slko=3D-5.6962e-08=20 + swko=3D2.1928e-08 kr=3D0.65138 slk=3D-5.6962e-08 + swk=3D2.1928e-08 vsbxr=3D100 slvsbx=3D0 + swvsbx=3D0 phibr=3D0.84764 zet1r=3D1.8722 + slzet1=3D-1.6842e-07 etazet=3D1 mor=3D 0.30905 + slmo=3D8.3171e-06 stmo=3D0.00010119 etamr=3D1 + gamoor=3D0.0001689 slgamoo=3D1.1391e-15 etagamr=3D1 + vsbtr=3D100 slvsbt=3D0 gam1r=3D-0.0015083 + slgam1=3D1.4997e-08 swgam1=3D 8.7524e-10 etadsr=3D0.6 + vpr=3D10.86 alpr=3D0.022451 slalp=3D8.2822e-09 + swalp=3D-1.2618e-08 etaalp=3D1 the3r=3D-0.014429 + stlthe3=3D-6.7464e-11 swthe3=3D1.9606e-09 stthe3r=3D2.4982e-05=20 + slthe3r=3D7.3895e-09 a1r=3D3.844 sla1=3D2.9719e-07 + swa1=3D-9.356e-09 sta1=3D0.015722 a2r=3D29.335 + sla2=3D4.8732e-10 swa2=3D-3.0085e-10 a3r=3D1.1664 + sla3=3D-1.0574e-07 swa3=3D-3.3629e-09 col=3D6.1e-11 + ntr=3D2.2e-20 nfr=3D4.182e-12 * Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17 * -- JUNCAP Electrical Parameters for S/D regions (Simulator specific) + diolev=3D9 tnom=3D27 vr=3D0=20 + cjbr=3D0.001329 cjsr=3D3.146e-10 cjgr=3D1.864e-10 + jsdbr=3D1.9e-07 jsdsr=3D4.572e-14 jsdgr=3D1e-20 + jsgbr=3D4.057e-06 jsgsr=3D2.782e-11 jsggr=3D4.751e-11 + vdbr=3D0.8 vdsr=3D 0.8 vdgr=3D0.8 + pb=3D0.43 ps=3D0.33 pg=3D0.43 + dcaplev=3D0 rlev=3D1 alev=3D3 *(1)+rsh=3D2.4 rs=3D70 rd=3D70 + ldif=3D0 hdif=3D 4.875e-07 *--------------------------------------------------------------- * Spice Model : ENMM9JU *--------------------------------------------------------------- * *.LIB ENMM9JU_typ *----------------------------------------------------------------------=20 * NMOS : EN (Model : MM9JU - subckt Juncap) typ *---------------------------------------------------------------------- * Simulator: #ELDO 4.5 *----------------------------------------------------------------------=20 .SUBCKT ENMM9JU D G S B + param: W=3D10e-6 L=3D10e-6 nfing=3D1 + wfing=3D{w/nfing+0} + fd=3D{nfing-2*trunc(nfing/2)} + fs=3D{2-fd} + AD=3D{wfing*(nfing*(1.15e-06)/2+fd*(1.15e-06)/2)} + AS=3D{wfing*(nfing*(1.15e-06)/2+fs*(1.15e-06)/2)} + PD=3D{nfing*2*(1.15e-06)/2+fd*(wfing+1.15e-06)} + PS=3D{nfing*2*(1.15e-06)/2+fs*(wfing+1.15e-06)} M1 D G S B ENMM9JU W=3DW L=3DL AS=3DAS AD=3DAD PS=3DPS PD=3DPD=20 .ENDS .MODEL ENMM9JU + nmos + level=3D59 + tox=3D7.6e-09 tr=3D27 ler=3D9.9839e-06 + lvar=3D0 lap=3D8.045e-09 wer=3D9.7552e-06 + wvar=3D0 wot=3D1.224e-07 vtor=3D0.635 + slvto=3D7.0216e-08 sl2vto=3D-2.4754e-14 swvto=3D2.3042e-08 + stvto=3D-0.00087141 betsq=3D0.0002259 etabet=3D1.6336 + the1r=3D0.2364 slthe1r=3D1.3077e-07 swthe1=3D-8.2823e-08 + stthe1r=3D- 6.6798e-06 stlthe1=3D-5.1702e-10 the2r=3D0.15491 + slthe2r=3D-2.1137e-08 swthe2=3D9.6765e-08 stthe2r=3D0.0003788 + stlthe2=3D-2.1968e-11 kor=3D0.536 slko=3D-7.6164e-08 + swko=3D2.7463e-08 kr=3D0.536 slk=3D- 7.3164e-08 + swk=3D2.7463e-08 vsbxr=3D100 slvsbx=3D0 + swvsbx=3D0 phibr=3D0.84764 zet1r=3D2.5785 + slzet1=3D-0.00012272 etazet=3D0.5 mor=3D0.31129 + slmo=3D-1.3606e-06 stmo=3D- 0.00082026 etamr=3D1 + gamoor=3D0.00096059 slgamoo=3D2.9931e-15 etagamr=3D1 + vsbtr=3D100 slvsbt=3D0 gam1r=3D0.00063636 + slgam1=3D1.2818e-08 swgam1=3D-4.7172e-10 etadsr=3D0.6 + vpr=3D17.25 alpr=3D0.01 slalp=3D0 + swalp=3D0 etaalp=3D1 the3r=3D-0.025862 + stlthe3=3D-2.8694e-10 swthe3=3D-2.4e-08 stthe3r=3D-4.1862e-05 + slthe3r=3D1.014e-07 a1r=3D5.5559 sla1=3D 5.4355e-07 + swa1=3D-3.3508e-07 sta1=3D0.0084971 a2r=3D20 + sla2=3D0 swa2=3D0 a3r=3D1.1206 + sla3=3D-1.4134e-07 swa3=3D-1.0882e-08 col=3D6.1e-11 + ntr=3D2.2e-20 nfr=3D6.085e-12=20 * Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17 * -- JUNCAP Electrical Parameters for S/D regions (Simulator specific) + diolev=3D9 tnom=3D27 vr=3D0 + cjbr=3D0.000933 cjsr=3D 2.994e-10 cjgr=3D2.085e-10 + jsdbr=3D1.295e-08 jsdsr=3D1e-20 jsdgr=3D9.999e-16 + jsgbr=3D4.86e-07 jsgsr=3D2.4e-11 jsggr=3D1.8e-12 + vdbr=3D0.8 vdsr=3D0.8 vdgr=3D0.8 + pb=3D0.37 ps=3D0.21 pg=3D0.37 + dcaplev=3D0 rlev=3D1 alev=3D3 *(1)+rsh=3D2.7 rs=3D48 rd=3D48 + ldif=3D0 hdif=3D4.875e-07 *--------------------------------------------------------------- * Spice Model : DNPPSR *--------------------------------------------------------------- *.model DNPPSR *BIB:HC6XXX_ELDO.DNPPSR_TYP *{DNPPSJU_TYP}=20 *---------------------------------------------------------------------- * DIODE : DNPPS (Model : Juncap) typ *---------------------------------------------------------------------- * Simulator: #ELDO 4.5 *---------------------------------------------------------------------- * .model DNPPSR d + level=3D8 diolev=3D9 tnom=3D27 + vr=3D0 cjbr=3D0.000933 cjsr=3D2.994e-10 + cjgr=3D2.085e-10 jsdbr=3D1.295e-08 jsdsr=3D1e-20 + jsdgr=3D9.999e-16 jsgbr=3D4.86e-07 jsgsr=3D2.4e-11 + jsggr=3D1.8e-12 vdbr=3D0.8 vdsr=3D0.8 + vdgr=3D0.8 pb=3D0.37 ps=3D 0.21 + pg=3D0.37 *.endl DNPPSJU_typ *--------------------------------------------------------------- * Spice Model : RNDIFFM1 *--------------------------------------------------------------- *.subckt RNDIFFM1 *BIB:HC6XXX_ELDO.RNDIFFM1_TYP=20 *{RNDIFFM1_TYP} *---------------------------------------------------------------------- * RESISTOR : RNDIFF (Model : M1) typ *---------------------------------------------------------------------- *.lib RNDIFFM1_typ=20 .subckt RNDIFFM1 + PLUS MINUS SUB param: r=3D0.0 w=3D0.8e-6 nc=3D1 *---------------------------------------------------------------------- .param rt_typ=3D{4.5/nc+(4.5945e-05)/(w-(-0.17e-6))} .param l=3D{0.0e-6+(r-2*rt_typ)*(w-(- 0.17e-6))/48.0} *---------------------------------------------------------------------- .param rt=3D{4.5/nc+4.5945e-05/(w-(-0.17e-6))} RES PLUS MINUS {48.0*(l-(0.0e-6))/(w-(-0.17e-6)) + 2*rt } tc=3D1.533e-3,2.023e-7=20 *---------------------------------------------------------------------- * Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17 .model DNPPS d level=3D8 diolev=3D9 tnom=3D27 + vr=3D0 cjbr=3D 0.000933 cjsr=3D2.994e-10 + cjgr=3D2.085e-10 jsdbr=3D1.295e-08 jsdsr=3D1e-20 + jsdgr=3D9.999e-16 jsgbr=3D4.86e-07 jsgsr=3D2.4e-11 + jsggr=3D1.8e-12 vdbr=3D0.8 vdsr=3D0.8 + vdgr=3D 0.8 pb=3D0.37 ps=3D0.21 + pg=3D0.37 .param lr=3D{l+2*0.35e-6+2*0.0e-6+2*2.0e-7+2*0.4e-6} D1 SUB PLUS DNPPS area=3D{0.5*(w-(-0.17e-6))*lr} peri=3D{w-(-0.17e-6)+lr} D2 SUB MINUS DNPPS area=3D{ 0.5*(w-(-0.17e-6))*lr} peri=3D{w-(-0.17e-6)+lr} .ends RNDIFFM1 *.endl RNDIFFM1_typ *--------------------------------------------------------------- * Spice Model : RPO1M1 *---------------------------------------------------------------=20 *.subckt RPO1M1 *BIB:HC6XXX_ELDO.RPO1M1_TYP *{RPO1M1_TYP} *---------------------------------------------------------------------- * RESISTOR : RPO1 (Model : M1) typ *----------------------------------------------------------------------=20 .subckt RPO1M1 + PLUS MINUS SUB param: r=3D0.0 w=3D0.8e-6 nc=3D1 *---------------------------------------------------------------------- .param rt_typ=3D{5.5/nc+(5.577e-05)/(w-(0.02e-6))} .param l=3D{0.0e-6+(r-2*rt_typ)*(w-( 0.02e-6))/133.0} *---------------------------------------------------------------------- .param rt=3D{5.5/nc+5.577e-05/(w-(0.02e-6))} Rres PLUS MINUS {133.0*(l-(0.0e-6))/(w-(0.02e-6)) + 2*rt } tc=3D-4.50e-4,1.450e-6=20 *---------------------------------------------------------------------- .param lr=3D{l+2*0.35e-6+2*0.0e-6+2*2.0e-7+2*0.4e-6} C1 PLUS SUB {8.21e-5*0.5*(w-(0.02e-6))*lr+2.26e-11*(w-(0.02e-6)+lr)} C2 MINUS SUB { 8.21e-5*0.5*(w-(0.02e-6))*lr+2.26e-11*(w-(0.02e-6)+lr)} .ends RPO1M1 *.endl RPO1M1_typ *--------------------------------------------------------------- * Spice Model : DPPNW *---------------------------------------------------------------=20 *.model DPPNW *BIB:HC6XXX_ELDO.DPPNW_TYP *{DPPNWJU_TYP} *---------------------------------------------------------------------- * DIODE : DPPNW (Model : Juncap) typ *----------------------------------------------------------------------=20 * Simulator: #ELDO 4.5 *---------------------------------------------------------------------- * .model DPPNW d + level=3D8 diolev=3D9 tnom=3D27 + vr=3D0 cjbr=3D0.001329 cjsr=3D3.146e-10 + cjgr=3D1.864e-10 jsdbr=3D1.9e-07 jsdsr=3D4.572e-14 + jsdgr=3D1e-20 jsgbr=3D4.057e-06 jsgsr=3D2.782e-11 + jsggr=3D4.751e-11 vdbr=3D0.8 vdsr=3D0.8 + vdgr=3D 0.8 pb=3D0.43 ps=3D0.33 + pg=3D0.43 *.endl DPPNWJU_typ *--------------------------------------------------------------- * Spice Model : EP3 *---------------------------------------------------------------=20 *{EPMM9_TYP} * .MODEL EP3 pmos *---------------------------------------------------------------------- * Family pmos Model EP mm9 typ *----------------------------------------------------------------------=20 + level=3D59 + tox=3D8.2e-09 tr=3D27 ler=3D9.954e-06 + lvar=3D0 lap=3D2.2994e-08 wer=3D9.8871e-06 + wvar=3D0 wot=3D5.6447e-08 vtor=3D0.605 + slvto=3D2.4157e-08 sl2vto=3D-8.8158e-15 swvto=3D-2.4478e-09 + stvto=3D-0.00093097 betsq=3D4.6238e-05 etabet=3D1.1695 + the1r=3D0.21277 slthe1r=3D6.6646e-08 swthe1=3D-1.19e-09 + stthe1r=3D-0.00045468 stlthe1=3D-1.8179e-10 the2r=3D0.33738 + slthe2r=3D-3.7174e-08 swthe2=3D1.9299e-08 stthe2r=3D-0.0004339 + stlthe2=3D7.9686e-11 kor=3D0.65138 slko=3D-5.6962e-08 + swko=3D2.1928e-08 kr=3D0.65138 slk=3D-5.6962e-08 + swk=3D 2.1928e-08 vsbxr=3D100 slvsbx=3D0 + swvsbx=3D0 phibr=3D0.84764 zet1r=3D1.8722 + slzet1=3D-1.6842e-07 etazet=3D1 mor=3D0.30905 + slmo=3D8.3171e-06 stmo=3D0.00010119 etamr=3D1=20 + gamoor=3D0.0001689 slgamoo=3D1.1391e-15 etagamr=3D1 + vsbtr=3D100 slvsbt=3D0 gam1r=3D-0.0015083 + slgam1=3D1.4997e-08 swgam1=3D8.7524e-10 etadsr=3D0.6 + vpr=3D10.86 alpr=3D0.022451 slalp=3D8.2822e-09 + swalp=3D-1.2618e-08 etaalp=3D1 the3r=3D-0.014429 + stlthe3=3D-6.7464e-11 swthe3=3D1.9606e-09 stthe3r=3D2.4982e-05 + slthe3r=3D7.3895e-09 a1r=3D3.844 sla1=3D2.9719e-07=20 + swa1=3D-9.356e-09 sta1=3D0.015722 a2r=3D29.335 + sla2=3D4.8732e-10 swa2=3D-3.0085e-10 a3r=3D1.1664 + sla3=3D-1.0574e-07 swa3=3D-3.3629e-09 col=3D6.1e-11 + ntr=3D2.2e-20 nfr=3D4.182e-12=20 * Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17 * -- JUNCAP Diode Electrical Parameters for S/D regions (Simulator specific) + diolev=3D9 tnom=3D27 vr=3D0 + cjbr=3D0.001329 cjsr=3D 3.146e-10 cjgr=3D1.864e-10 + jsdbr=3D1.9e-07 jsdsr=3D4.572e-14 jsdgr=3D1e-20 + jsgbr=3D4.057e-06 jsgsr=3D2.782e-11 jsggr=3D4.751e-11 + vdbr=3D0.8 vdsr=3D0.8 vdgr=3D0.8 + pb=3D0.43 ps=3D0.33 pg=3D0.43 + dcaplev=3D0 rlev=3D1 alev=3D3 *(1)+rsh=3D2.4 rs=3D70 rd=3D70 + ldif=3D0 hdif=3D4.875e-07 *.ENDL=20 *--------------------------------------------------------------- * Spice Model : EN3 *--------------------------------------------------------------- *.model EN3 *BIB:HC6XXX_ELDO.EN3_TYP *{ENMM9_TYP} .MODEL EN3 nmos *---------------------------------------------------------------------- * Family nmos Model EN mm9 typ *---------------------------------------------------------------------- + level=3D59 + tox=3D 7.6e-09 tr=3D27 ler=3D9.9839e-06 + lvar=3D0 lap=3D8.045e-09 wer=3D9.7552e-06 + wvar=3D0 wot=3D1.224e-07 vtor=3D0.635 + slvto=3D7.0216e-08 sl2vto=3D-2.4754e-14 swvto=3D2.3042e-08 + stvto=3D-0.00087141 betsq=3D0.0002259 etabet=3D1.6336 + the1r=3D0.2364 slthe1r=3D1.3077e-07 swthe1=3D-8.2823e-08 + stthe1r=3D-6.6798e-06 stlthe1=3D-5.1702e-10 the2r=3D0.15491 + slthe2r=3D- 2.1137e-08 swthe2=3D9.6765e-08 stthe2r=3D0.0003788 + stlthe2=3D-2.1968e-11 kor=3D0.536 slko=3D-7.6164e-08 + swko=3D2.7463e-08 kr=3D0.536 slk=3D-7.3164e-08 + swk=3D2.7463e-08 vsbxr=3D100 slvsbx=3D0=20 + swvsbx=3D0 phibr=3D0.84764 zet1r=3D2.5785 + slzet1=3D-0.00012272 etazet=3D0.5 mor=3D0.31129 + slmo=3D-1.3606e-06 stmo=3D-0.00082026 etamr=3D1 + gamoor=3D0.00096059 slgamoo=3D2.9931e-15 etagamr=3D1 + vsbtr=3D100 slvsbt=3D0 gam1r=3D0.00063636 + slgam1=3D1.2818e-08 swgam1=3D-4.7172e-10 etadsr=3D0.6 + vpr=3D17.25 alpr=3D0.01 slalp=3D0 + swalp=3D0 etaalp=3D1 the3r=3D- 0.025862 + stlthe3=3D-2.8694e-10 swthe3=3D-2.4e-08 stthe3r=3D-4.1862e-05 + slthe3r=3D1.014e-07 a1r=3D5.5559 sla1=3D5.4355e-07 + swa1=3D-3.3508e-07 sta1=3D0.0084971 a2r=3D20 + sla2=3D0 swa2=3D0 a3r=3D 1.1206 + sla3=3D-1.4134e-07 swa3=3D-1.0882e-08 col=3D6.1e-11 + ntr=3D2.2e-20 nfr=3D6.085e-12 * Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17 * -- JUNCAP Diode Electrical Parameters for S/D regions (Simulator specific)=20 + diolev=3D9 tnom=3D27 vr=3D0 + cjbr=3D0.000933 cjsr=3D2.994e-10 cjgr=3D2.085e-10 + jsdbr=3D1.295e-08 jsdsr=3D1e-20 jsdgr=3D9.999e-16 + jsgbr=3D4.86e-07 jsgsr=3D2.4e-11 jsggr=3D1.8e-12 + vdbr=3D0.8 vdsr=3D0.8 vdgr=3D0.8 + pb=3D0.37 ps=3D0.21 pg=3D0.37 + dcaplev=3D0 rlev=3D1 alev=3D3 *(1)+rsh=3D2.7 rs=3D48 rd=3D48=20 + ldif=3D0 hdif=3D4.875e-07 *.ENDL *** *** ADDING NET (from S2ibis3) *** VOUTS2I OEIN 0 DC 0.0 VCLMPS2I VDDE 0 DC 3.0 VGCLMPS2I GNDE 0 DC 0.0 .TEMP 27.0 .DC VOUTS2I 3.0 6.0 0.04 .PRINT DC I(VOUTS2I) .END - --=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_01C82B37.AC27DB2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Sudarshan,

If I understand you correctly, you wou= ld not want to model either pc3b01_p or pc3b01d_p. You should be modeling PAD. pc3= b01_p and pc3b01d_p are internal spice node name that you would be entering in the pin list ([pin]) in your .s2i file. You should look at the examples provided with s2ibis3 for a more detailed understanding.

 

As for your second question, there is a real life example posted in the s2ibis3 FAQ webpage at http://www.ec= e.ncsu.edu/erl/ibis/faq/S2IBIS3_FAQ.htm

Your third question is also explained = in one of the examples in the s2ibis3 distribution.

 

Thanks,

Ambrish.

 

 

From:= owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Sudarshan H N
Sent: Monday, November 19, 2= 007 12:23 AM
To: Fabio BRINA
Cc: ibis-users@eda.org
Subject: Re: [IBIS-Users] S2= IBIS3 Queries

 

Hi Fabio,

I will show you a sample spice netlist i have.

.SUBCKT pc3b01_p   PAD I OEN CIN
..
..
..
.ENDS
.SUBCKT pc3b01d_p   PAD I OEN CIN
..
..
..
.ENDS

With this example, suppose if i want to model only pc3b01_p, then how can i give this in the setup file. Since the pins are common to both the models h= ow S2IBIS distinguishes between 2 models and how it will select the correct one.  ?

As per the tools and scripts i have written,  i will always search for= the particular spice netlist with .SUBCKT option and then use that model . But = i am not sure how S2IBIS is doing it .
Can you explain me ?

Regards
Sudarshan

On Nov 16, 2007 2:37 PM, Fabio BRINA <fabio.brina@st.com> wrote:

Hello Sudarshan,

I don't studied the java script. But I send you a  .spi file
generated by S2ibis3,  where you can see how work the
tool:

from this file it extract Power Clamp (typical).

firstly you can see the netlist (.subckt INVBH2, CLPDPTT, ESDINTT etc.)
secondly the models (.model DPPNWR etc : these are Eldo models)
finally you find the NET added from the tool,  voltage source  VOUTS2I,  VCLMPS2I etc,
connected to the pin you are considering ( OEIN in this case )

If you have many  .subckts  inside the same file, I think you
have also a top netlist were you can identify univocally the Pins.



Regards,
Fabio Brina




Sudarshan H N wrote:

Hi Fabio,

Regarding the first question, my doubt was , if we have many IO pad netlist= s in a single file, how to give the names of those pads which we want to model i= t. Normally the spice netlists start with .SUBCKT structure. So i expected S2I= BIS to search for this keyword and select the appropriate spice model. But i di= dnt find any such statement in the java scripts which will search for the netli= sts. How does S2IBIS identify different pad names ?

Regards
Sudarshan

On Nov 14, 2007 8:02 PM, Fabio BRINA <fabio.brina@st.com= > wrote:


Hi Sudarshan,

1. The only pads that will be modeled are those included in the [Pin] secti= on:

[Pin]

VDD      VDD     VDD       POWER
VGND   VGND  VGND    GND
EN1        EN1       EN1       mod_en
IN1         IN1         IN1        mod_in
OUT       OUT       OUT      mod_out
- ->  IN1    EN1

In this case only OUT , EN1 and IN1 will be modeled;
obviously the other pad have to be fixed in the right level, with specific voltage source inside the netlist.

2. You have to separate the corners in three files, and insert them in the following specification:

[Model file]    corners_typ     corners_min    corners_max


3. You can consider each pin for time.  Or you can fix the [Voltage Range ] under the [model]
    associated to your pad pin. as you can read in  s2ibis3.= txt  file.


I hope this  helpful for  your work.

Regards,

Fabio Brina




Sudarshan H N wrote:

Hello,

I downloaded new s2ibis3 from the site http://www.ece.ncsu.edu/erl/ibis/s2ibis3/s2ibis3.htm and tried using it.

I was able generate IBIS models with the example given in that link. But i = am not able to generate separate IBIS models for the spice models . While providing input to *.s2i file i have the following queries.

1.      If the IO spice netlist contains all the IO pad netlists in a single file , ho= w to give the only those IO pad names that i wish to model it.

2.      In the process model file, if all the typical, min and max corner definitions = are present in a single file, how do we separately mention process models for e= ach corner.

        =   eg: .lib  '/home/sudarshann/ibis/S2IBIS/new/tsl018.lib' ff_hv &nb= sp; for fast corner
            &nb= sp;   .lib  '/home/sudarshann/ibis/S2IBIS/new/tsl018.lib' ss_hv for slow cor= ner
 
           How can i achi= eve such kind of constructs in S2IBIS setup file .
     3.  How can i mention the separate voltage levels = for each pin. For example how can i specify , say 1.2V on Input and enable pins= and 3.3V on PAD pins.

Let me know your answers.

Regards
Sudarshan

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

=  

=  

=  


*Typ power clamp curve for model mod_dir
*Spice Deck created by S2IBIS3 Version 1.1
*North Carolina State University
*--------------------------------------------------------------------
*--------------------------------------------------------------------
****** The  NETLIST *******
*--------------------------
.GLOBAL GNDE
+ GND
+ VDD
*--------------------------------------------------------------------
*--------------------------------------------------------------------
*[?param]
*--------------------------------------------------------------------
*--------------------------------------------------------------------
.OPTION XA =3D 9.750000e-07
*--------------------------------------------------------------------
*--------------------------------------------------------------------
.SUBCKT INVBH2 A Y
MM10 Y A GND GND EN3 W=3D3.5u L=3D5u AD=3D3.4125e-12 AS=3D3.4125e-12
+PD=3D5.45e-06 PS=3D5.45e-06 M=3D1
MM19 Y VDD NET24 NET24 EP3 W=3D10u L=3D 0.45u AD=3D3.51e-10 AS=3D3.51e-10 +PD=3D0.00036195 PS=3D0.00036195 M=3D1
MM11 Y A NET24 NET24 EP3 W=3D5u L=3D1u AD=3D5.85e-12 AS=3D5.85e-12 PD=3D7.9= 5e-06
+PS=3D7.95e-06 M=3D1
MM9 NET24 Y VDD NET24 EP3 W=3D310u L=3D0.35u AD=3D3.51e-10 AS=3D3.51e-10 +PD=3D0.00036195 PS=3D0.00036195 M=3D1
.ENDS INVBH2
*--------------------------------------------------------------------
*--------------------------------------------------------------------
.SUBCKT CLPDPTT INOUT
MM41 INOUT NET64 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11
+AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1
MM28 INOUT NET68 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11
+AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1
MM42 INOUT NET64 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11
+AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1
MM34 INOUT NET68 GNDE GNDE EN3 W=3D74.6u L=3D0.4u AD=3D7.2735e-11
+AS=3D7.2735e-11 PD=3D7.655e-05 PS=3D7.655e-05 M=3D1
DD37 NET64 INOUT DPPNW AREA=3D3.3p
DD29 NET68 INOUT DPPNW AREA=3D3.3p
DD32 NET68 INOUT DPPNW AREA=3D3.3p
DD38 NET64 INOUT DPPNW AREA=3D3.3p
XR36 GNDE NET64 GND RPO1M1 r=3D3560 w=3D0.35e-06 nc=3D1
XR30 GNDE NET68 GND RPO1M1 r=3D3560 w=3D 0.35e-06 nc=3D1
XR35 GNDE NET64 GND RPO1M1 r=3D3560 w=3D0.35e-06 nc=3D1
XR31 GNDE NET68 GND RPO1M1 r=3D3560 w=3D0.35e-06 nc=3D1
.ENDS CLPDPTT
*--------------------------------------------------------------------
*--------------------------------------------------------------------
.SUBCKT ESDINTT A RECIN
XR40 NET11 RECIN GND RPO1M1 r=3D163 w=3D1.9e-06 nc=3D2
XR34 A NET17 GND RPO1M1 r=3D87 w=3D4.5e-06 nc=3D5
XR38 NET17 NET11 GND RNDIFFM1 r=3D196 w=3D1.9e-06 nc=3D2
DD4 GND NET17 DNPPSR AREA=3D308p PERI=3D36.8u
.ENDS ESDINTT
*--------------------------------------------------------------------
*--------------------------------------------------------------------
.SUBCKT INV A Y
MM10 Y A GND GND EN3 W=3Dwn L=3Dln M=3D1
MM9 Y A VDD VDD EP3 W=3Dwp L=3Dlp M=3D1
.ENDS INV
*--------------------------------------------------------------------
*--------------------------------------------------------------------
.CONNECT  GND  GNDE
XI11  NET23 NET9 INVBH2
XI9  OEIN CLPDPTT
XI8  OEIN NET9 ESDINTT
XI17  OEOUT NET23 INV ln=3D2u lp=3D2u wn=3D7u wp=3D13u
XI10  NET23 OEOUT INV ln=3D0.35u lp=3D0.35u wn=3D44u wp=3D90u
XI18  NET9 NET23 INV ln=3D0.35u lp=3D0.35u wn=3D20u wp=3D55u
*---------------------------------------------------------------
* Spice Model : DPPNWR
*---------------------------------------------------------------
*********** THE MODELS *************
*----------------------------------------------------------------------
* Simulator:  #ELDO 4.5
*----------------------------------------------------------------------
*
.model  DPPNWR d
+ level=3D8               diolev=3D9 &nb= sp;             tnom=3D27
+ vr=3D0                  cjbr=3D0.001329         cjsr=3D3.146e-10
+ cjgr=3D1.864e-10         jsdbr=3D1.9e-07    = ;     jsdsr=3D4.572e-14
+ jsdgr=3D1e-20           jsgbr=3D4.057e-06  =     jsgsr=3D2.782e-11
+ jsggr=3D4.751e-11        vdbr=3D0.8     &nb= sp;        vdsr=3D0.8
+ vdgr=3D0.8              pb=3D 0.43 &nb= sp;             ps=3D0.33
+ pg=3D0.43
*.endl DPPNWJU_typ

*---------------------------------------------------------------
* Spice Model : EPMM9JU
*---------------------------------------------------------------
*
*----------------------------------------------------------------------
* PMOS : EP  (Model : MM9JU - subckt Juncap)  typ
*----------------------------------------------------------------------
* Simulator:  #ELDO 4.5
*----------------------------------------------------------------------
.SUBCKT  EPMM9JU D G S B
+       param: W=3D10e-6 L=3D10e-6 nfing=3D1
+       wfing=3D{w/nfing+0}
+       fd=3D{nfing-2*trunc(nfing/2)}
+       fs=3D{2-fd}
+       AD=3D{wfing*(nfing*(1.15e-06)/2+fd*(1.15e-06)/2)}
+       AS=3D{wfing*(nfing*(1.15e-06)/2+fs*(1.15e-06)/2)}
+       PD=3D{nfing*2*(1.15e-06)/2+fd*(wfing+1.15e-06)}
+       PS=3D{nfing*2*(1.15e-06)/2+fs*(wfing+1.15e-06)}
M1 D G S B EPMM9JU W=3DW L=3DL= AS=3DAS AD=3DAD PS=3DPS PD=3DPD
.ENDS


.MODEL EPMM9JU
+ pmos
+ level=3D59
+ tox=3D8.2e-09           tr=3D27     &n= bsp;           ler=3D9.954e-06
+ lvar=3D0                lap=3D2.2= 994e-08        wer=3D 9.8871e-06
+ wvar=3D0                wot=3D5.6= 447e-08        vtor=3D0.605
+ slvto=3D2.4157e-08      sl2vto=3D-8.8158e-15    swvto=3D-2.4478e-09
+ stvto=3D-0.00093097     betsq=3D4.6238e-05      etabet=3D1.1695
+ the1r=3D0.21277         slthe1r=3D 6.6646e-08    swthe1=3D-1.19e-09
+ stthe1r=3D-0.00045468   stlthe1=3D-1.8179e-10   the2r=3D0.33738=
+ slthe2r=3D-3.7174e-08   swthe2=3D1.9299e-08     stthe2r=3D= - -0.0004339
+ stlthe2=3D7.9686e-11    kor=3D0.65138       &nbs= p;   slko=3D-5.6962e-08
+ swko=3D2.1928e-08       kr=3D0.65138       =      slk=3D-5.6962e-08
+ swk=3D2.1928e-08        vsbxr=3D100     &nb= sp;       slvsbx=3D0
+ swvsbx=3D0              phibr=3D0.8476= 4         zet1r=3D1.8722
+ slzet1=3D-1.6842e-07    etazet=3D1         =      mor=3D 0.30905
+ slmo=3D8.3171e-06       stmo=3D0.00010119     &n= bsp; etamr=3D1
+ gamoor=3D0.0001689      slgamoo=3D1.1391e-15    etagamr=3D1
+ vsbtr=3D100             slvsbt=3D0   &= nbsp;          gam1r=3D-0.0015083
+ slgam1=3D1.4997e-08     swgam1=3D 8.7524e-10     etad= sr=3D0.6
+ vpr=3D10.86             alpr=3D0.022451 &nb= sp;       slalp=3D8.2822e-09
+ swalp=3D-1.2618e-08     etaalp=3D1         =      the3r=3D-0.014429
+ stlthe3=3D-6.7464e-11   swthe3=3D1.9606e-09     stthe3r=3D= 2.4982e-05
+ slthe3r=3D7.3895e-09    a1r=3D3.844        =     sla1=3D2.9719e-07
+ swa1=3D-9.356e-09       sta1=3D0.015722     &nbs= p;   a2r=3D29.335
+ sla2=3D4.8732e-10       swa2=3D-3.0085e-10      a3r=3D1.1664
+ sla3=3D-1.0574e-07      swa3=3D-3.3629e-09      col=3D6.1e-11
+ ntr=3D2.2e-20           nfr=3D4.182e-12
* Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17
* -- JUNCAP Electrical Parameters for S/D regions  (Simulator specific= )
+ diolev=3D9              tnom=3D27 &nbs= p;             vr=3D0
+ cjbr=3D0.001329         cjsr=3D3.146e-10    = ;    cjgr=3D1.864e-10
+  jsdbr=3D1.9e-07         jsdsr=3D4.572e-14  = ;     jsdgr=3D1e-20
+ jsgbr=3D4.057e-06       jsgsr=3D2.782e-11     &n= bsp; jsggr=3D4.751e-11
+  vdbr=3D0.8              vdsr=3D = 0.8              vdgr=3D0.8
+ pb=3D0.43               ps=3D0.33 &nbs= p;             pg=3D0.43
+  dcaplev=3D0             rlev=3D1 &nbs= p;              alev=3D3

*(1)+rsh=3D2.4               rs=3D70 &nb= sp;               rd=3D70
+ ldif=3D0                hdif=3D 4= .875e-07

*---------------------------------------------------------------
* Spice Model : ENMM9JU
*---------------------------------------------------------------
*
*.LIB ENMM9JU_typ
*----------------------------------------------------------------------
* NMOS : EN  (Model : MM9JU - subckt Juncap)  typ
*----------------------------------------------------------------------
* Simulator:  #ELDO 4.5
*----------------------------------------------------------------------
.SUBCKT  ENMM9JU D G S B
+       param: W=3D10e-6 L=3D10e-6 nfing=3D1
+       wfing=3D{w/nfing+0}
+       fd=3D{nfing-2*trunc(nfing/2)}
+       fs=3D{2-fd}
+       AD=3D{wfing*(nfing*(1.15e-06)/2+fd*(1.15e-06)/2)}
+       AS=3D{wfing*(nfing*(1.15e-06)/2+fs*(1.15e-06)/2)}
+       PD=3D{nfing*2*(1.15e-06)/2+fd*(wfing+1.15e-06)}
+       PS=3D{nfing*2*(1.15e-06)/2+fs*(wfing+1.15e-06)}
M1 D G S B ENMM9JU W=3DW L=3DL= AS=3DAS AD=3DAD PS=3DPS PD=3DPD
.ENDS


.MODEL ENMM9JU
+ nmos
+  level=3D59
+ tox=3D7.6e-09           tr=3D27     &n= bsp;           ler=3D9.9839e-06
+ lvar=3D0                lap=3D8.0= 45e-09         wer=3D9.7552e-06
+ wvar=3D0                wot=3D1.2= 24e-07         vtor=3D0.635
+ slvto=3D7.0216e-08      sl2vto=3D-2.4754e-14    = swvto=3D2.3042e-08
+ stvto=3D-0.00087141     betsq=3D0.0002259       etabet=3D1.6336
+ the1r=3D0.2364          slthe1r=3D1.3077e-07 &nb= sp;  swthe1=3D-8.2823e-08
+ stthe1r=3D- 6.6798e-06   stlthe1=3D-5.1702e-10   the2r=3D0.1549= 1
+ slthe2r=3D-2.1137e-08   swthe2=3D9.6765e-08     stthe2r=3D= 0.0003788
+ stlthe2=3D-2.1968e-11   kor=3D0.536         &nbs= p;   slko=3D-7.6164e-08
+ swko=3D2.7463e-08       kr=3D0.536       &n= bsp;      slk=3D- 7.3164e-08
+ swk=3D2.7463e-08        vsbxr=3D100     &nb= sp;       slvsbx=3D0
+ swvsbx=3D0              phibr=3D0.8476= 4         zet1r=3D2.5785
+ slzet1=3D-0.00012272    etazet=3D0.5        = ;    mor=3D0.31129
+ slmo=3D-1.3606e-06      stmo=3D- 0.00082026      etamr=3D1
+ gamoor=3D0.00096059     slgamoo=3D2.9931e-15    etaga= mr=3D1
+ vsbtr=3D100             slvsbt=3D0   &= nbsp;          gam1r=3D0.00063636
+ slgam1=3D1.2818e-08     swgam1=3D-4.7172e-10    etads= r=3D0.6
+ vpr=3D17.25             alpr=3D0.01   =           slalp=3D0
+ swalp=3D0               etaalp=3D1 &nb= sp;            the3r=3D-0.025862
+ stlthe3=3D-2.8694e-10   swthe3=3D-2.4e-08       stthe3r=3D-4.1862e-05
+ slthe3r=3D1.014e-07     a1r=3D5.5559        = ;    sla1=3D 5.4355e-07
+ swa1=3D-3.3508e-07      sta1=3D0.0084971     &nb= sp;  a2r=3D20
+ sla2=3D0                swa2=3D0 =                a3r=3D1.1206
+ sla3=3D-1.4134e-07      swa3=3D-1.0882e-08      col=3D6.1e-11
+ ntr=3D2.2e-20           nfr=3D6.085e-12
* Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17
* -- JUNCAP Electrical Parameters for S/D regions  (Simulator specific= )
+ diolev=3D9              tnom=3D27 &nbs= p;             vr=3D0
+ cjbr=3D0.000933         cjsr=3D 2.994e-10   &nbs= p;    cjgr=3D2.085e-10
+  jsdbr=3D1.295e-08       jsdsr=3D1e-20     =       jsdgr=3D9.999e-16
+ jsgbr=3D4.86e-07        jsgsr=3D2.4e-11    =     jsggr=3D1.8e-12
+  vdbr=3D0.8              vdsr=3D0= .8              vdgr=3D0.8
+ pb=3D0.37               ps=3D0.21 &nbs= p;             pg=3D0.37
+  dcaplev=3D0             rlev=3D1 &nbs= p;              alev=3D3

*(1)+rsh=3D2.7               rs=3D48 &nb= sp;               rd=3D48
+ ldif=3D0                hdif=3D4.= 875e-07

*---------------------------------------------------------------
* Spice Model : DNPPSR
*---------------------------------------------------------------
*.model DNPPSR *BIB:HC6XXX_ELDO.DNPPSR_TYP
*{DNPPSJU_TYP}
*----------------------------------------------------------------------
* DIODE : DNPPS (Model : Juncap) typ
*----------------------------------------------------------------------
* Simulator:  #ELDO 4.5
*----------------------------------------------------------------------
*
.model  DNPPSR d
+ level=3D8               diolev=3D9 &nb= sp;             tnom=3D27
+ vr=3D0                  cjbr=3D0.000933         cjsr=3D2.994e-10
+ cjgr=3D2.085e-10         jsdbr=3D1.295e-08   &nb= sp;   jsdsr=3D1e-20
+ jsdgr=3D9.999e-16       jsgbr=3D4.86e-07     &nb= sp;  jsgsr=3D2.4e-11
+ jsggr=3D1.8e-12          vdbr=3D0.8    = ;          vdsr=3D0.8
+ vdgr=3D0.8              pb=3D0.37 &nbs= p;             ps=3D 0.21
+ pg=3D0.37
*.endl DNPPSJU_typ

*---------------------------------------------------------------
* Spice Model : RNDIFFM1
*---------------------------------------------------------------
*.subckt RNDIFFM1 *BIB:HC6XXX_ELDO.RNDIFFM1_TYP
*{RNDIFFM1_TYP}
*----------------------------------------------------------------------
* RESISTOR  : RNDIFF   (Model : M1) typ
*----------------------------------------------------------------------
*.lib RNDIFFM1_typ
.subckt  RNDIFFM1
+ PLUS MINUS SUB  param: r=3D0.0 w=3D0.8e-6 nc=3D1
*----------------------------------------------------------------------
.param rt_typ=3D{4.5/nc+(4.5945e-05)/(w-(-0.17e-6))}
.param l=3D{0.0e-6+(r-2*rt_typ)*(w-(- 0.17e-6))/48.0}
*----------------------------------------------------------------------
.param rt=3D{4.5/nc+4.5945e-05/(w-(-0.17e-6))}
RES  PLUS MINUS  {48.0*(l-(0.0e-6))/(w-(-0.17e-6)) + 2*rt } tc=3D1.533e-3,2.023e-7
*----------------------------------------------------------------------
* Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17
.model DNPPS d level=3D8               diolev=3D9              tnom=3D27
+ vr=3D0                  cjbr= =3D 0.000933         cjsr=3D2.994e-10
+ cjgr=3D2.085e-10         jsdbr=3D1.295e-08   &nb= sp;   jsdsr=3D1e-20
+ jsdgr=3D9.999e-16       jsgbr=3D4.86e-07     &nb= sp;  jsgsr=3D2.4e-11
+ jsggr=3D1.8e-12          vdbr=3D0.8    = ;          vdsr=3D0.8
+ vdgr=3D 0.8              pb=3D0.37 &nb= sp;             ps=3D0.21
+ pg=3D0.37

.param lr=3D{l+2*0.35e-6+2*0.0e-6+2*2.0e-7+2*0.4e-6}
D1  SUB PLUS  DNPPS area=3D{0.5*(w-(-0.17e-6))*lr} peri=3D{w-(-0.17e-6)+lr}
D2  SUB MINUS  DNPPS area=3D{ 0.5*(w-(-0.17e-6))*lr} peri=3D{w-(-0.17e-6)+lr}
.ends RNDIFFM1
*.endl RNDIFFM1_typ

*---------------------------------------------------------------
* Spice Model : RPO1M1
*---------------------------------------------------------------
*.subckt RPO1M1 *BIB:HC6XXX_ELDO.RPO1M1_TYP
*{RPO1M1_TYP}
*----------------------------------------------------------------------
* RESISTOR  : RPO1   (Model : M1) typ
*----------------------------------------------------------------------
.subckt  RPO1M1
+ PLUS MINUS SUB  param: r=3D0.0 w=3D0.8e-6 nc=3D1
*----------------------------------------------------------------------
.param rt_typ=3D{5.5/nc+(5.577e-05)/(w-(0.02e-6))}
.param l=3D{0.0e-6+(r-2*rt_typ)*(w-( 0.02e-6))/133.0}
*----------------------------------------------------------------------
.param rt=3D{5.5/nc+5.577e-05/(w-(0.02e-6))}
Rres  PLUS MINUS  {133.0*(l-(0.0e-6))/(w-(0.02e-6)) + 2*rt } tc=3D-4.50e-4,1.450e-6
*----------------------------------------------------------------------
.param lr=3D{l+2*0.35e-6+2*0.0e-6+2*2.0e-7+2*0.4e-6}
C1  PLUS SUB  {8.21e-5*0.5*(w-(0.02e-6))*lr+2.26e-11*(w-(0.02e-6)+lr)}
C2  MINUS SUB  { 8.21e-5*0.5*(w-(0.02e-6))*lr+2.26e-11*(w-(0.02e-6)+lr)}
.ends RPO1M1
*.endl RPO1M1_typ

*---------------------------------------------------------------
* Spice Model : DPPNW
*---------------------------------------------------------------
*.model DPPNW *BIB:HC6XXX_ELDO.DPPNW_TYP
*{DPPNWJU_TYP}
*----------------------------------------------------------------------
* DIODE : DPPNW (Model : Juncap) typ
*----------------------------------------------------------------------
* Simulator:  #ELDO 4.5
*----------------------------------------------------------------------
*
.model  DPPNW d
+ level=3D8               diolev=3D9 &nb= sp;             tnom=3D27
+ vr=3D0                  cjbr=3D0.001329         cjsr=3D3.146e-10
+ cjgr=3D1.864e-10         jsdbr=3D1.9e-07    = ;     jsdsr=3D4.572e-14
+ jsdgr=3D1e-20           jsgbr=3D4.057e-06  =     jsgsr=3D2.782e-11
+ jsggr=3D4.751e-11        vdbr=3D0.8     &nb= sp;        vdsr=3D0.8
+ vdgr=3D 0.8              pb=3D0.43 &nb= sp;             ps=3D0.33
+ pg=3D0.43
*.endl DPPNWJU_typ

*---------------------------------------------------------------
* Spice Model : EP3
*---------------------------------------------------------------
*{EPMM9_TYP}
*
.MODEL  EP3 pmos
*----------------------------------------------------------------------
* Family pmos Model EP mm9 typ
*----------------------------------------------------------------------
+ level=3D59
+  tox=3D8.2e-09           tr=3D27   &nb= sp;             ler=3D9.954e-06
+ lvar=3D0                lap=3D2.2= 994e-08        wer=3D9.8871e-06
+ wvar=3D0                wot=3D5.6= 447e-08        vtor=3D0.605
+ slvto=3D2.4157e-08      sl2vto=3D-8.8158e-15    swvto=3D-2.4478e-09
+ stvto=3D-0.00093097     betsq=3D4.6238e-05      etabet=3D1.1695
+ the1r=3D0.21277         slthe1r=3D6.6646e-08    swthe1=3D-1.19e-09
+ stthe1r=3D-0.00045468   stlthe1=3D-1.8179e-10   the2r=3D0.33738=
+ slthe2r=3D-3.7174e-08   swthe2=3D1.9299e-08     stthe2r=3D= - -0.0004339
+ stlthe2=3D7.9686e-11    kor=3D0.65138       &nbs= p;   slko=3D-5.6962e-08
+ swko=3D2.1928e-08       kr=3D0.65138       =      slk=3D-5.6962e-08
+ swk=3D 2.1928e-08        vsbxr=3D100     &n= bsp;       slvsbx=3D0
+ swvsbx=3D0              phibr=3D0.8476= 4         zet1r=3D1.8722
+ slzet1=3D-1.6842e-07    etazet=3D1         =      mor=3D0.30905
+ slmo=3D8.3171e-06       stmo=3D0.00010119     &n= bsp; etamr=3D1
+ gamoor=3D0.0001689      slgamoo=3D1.1391e-15    etagamr=3D1
+ vsbtr=3D100             slvsbt=3D0   &= nbsp;          gam1r=3D-0.0015083
+ slgam1=3D1.4997e-08     swgam1=3D8.7524e-10     etads= r=3D0.6
+ vpr=3D10.86             alpr=3D0.022451 &nb= sp;       slalp=3D8.2822e-09
+ swalp=3D-1.2618e-08     etaalp=3D1         =      the3r=3D-0.014429
+ stlthe3=3D-6.7464e-11   swthe3=3D1.9606e-09     stthe3r=3D= 2.4982e-05
+ slthe3r=3D7.3895e-09    a1r=3D3.844        =     sla1=3D2.9719e-07
+ swa1=3D-9.356e-09       sta1=3D0.015722     &nbs= p;   a2r=3D29.335
+ sla2=3D4.8732e-10       swa2=3D-3.0085e-10      a3r=3D1.1664
+ sla3=3D-1.0574e-07      swa3=3D-3.3629e-09      col=3D6.1e-11
+ ntr=3D2.2e-20           nfr=3D4.182e-12
* Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17
* -- JUNCAP Diode Electrical Parameters for S/D regions  (Simulator specific)
+ diolev=3D9              tnom=3D27 &nbs= p;             vr=3D0
+ cjbr=3D0.001329         cjsr=3D 3.146e-10   &nbs= p;    cjgr=3D1.864e-10
+  jsdbr=3D1.9e-07         jsdsr=3D4.572e-14  = ;     jsdgr=3D1e-20
+ jsgbr=3D4.057e-06       jsgsr=3D2.782e-11     &n= bsp; jsggr=3D4.751e-11
+  vdbr=3D0.8              vdsr=3D0= .8              vdgr=3D0.8
+ pb=3D0.43               ps=3D0.33 &nbs= p;             pg=3D0.43
+  dcaplev=3D0             rlev=3D1 &nbs= p;              alev=3D3

*(1)+rsh=3D2.4               rs=3D70 &nb= sp;               rd=3D70
+ ldif=3D0                hdif=3D4.= 875e-07
*.ENDL

*---------------------------------------------------------------
* Spice Model : EN3
*---------------------------------------------------------------
*.model EN3 *BIB:HC6XXX_ELDO.EN3_TYP
*{ENMM9_TYP}
.MODEL  EN3 nmos
*----------------------------------------------------------------------
* Family nmos Model EN mm9 typ
*----------------------------------------------------------------------
+ level=3D59
+  tox=3D 7.6e-09           tr=3D27   &n= bsp;             ler=3D9.9839e-06
+ lvar=3D0                lap=3D8.0= 45e-09         wer=3D9.7552e-06
+ wvar=3D0                wot=3D1.2= 24e-07         vtor=3D0.635
+ slvto=3D7.0216e-08      sl2vto=3D-2.4754e-14    swvto=3D2.3042e-08
+ stvto=3D-0.00087141     betsq=3D0.0002259       etabet=3D1.6336
+ the1r=3D0.2364          slthe1r=3D1.3077e-07 &nb= sp;  swthe1=3D-8.2823e-08
+ stthe1r=3D-6.6798e-06   stlthe1=3D-5.1702e-10   the2r=3D0.15491=
+ slthe2r=3D- 2.1137e-08   swthe2=3D9.6765e-08     stthe2r= =3D0.0003788
+ stlthe2=3D-2.1968e-11   kor=3D0.536         &nbs= p;   slko=3D-7.6164e-08
+ swko=3D2.7463e-08       kr=3D0.536       &n= bsp;      slk=3D-7.3164e-08
+ swk=3D2.7463e-08        vsbxr=3D100     &nb= sp;       slvsbx=3D0
+ swvsbx=3D0              phibr=3D0.8476= 4         zet1r=3D2.5785
+ slzet1=3D-0.00012272    etazet=3D0.5        = ;    mor=3D0.31129
+ slmo=3D-1.3606e-06      stmo=3D-0.00082026      etamr=3D1
+ gamoor=3D0.00096059     slgamoo=3D2.9931e-15    etaga= mr=3D1
+ vsbtr=3D100             slvsbt=3D0   &= nbsp;          gam1r=3D0.00063636
+ slgam1=3D1.2818e-08     swgam1=3D-4.7172e-10    etads= r=3D0.6
+ vpr=3D17.25             alpr=3D0.01   =           slalp=3D0
+ swalp=3D0               etaalp=3D1 &nb= sp;            the3r=3D- 0.025862
+ stlthe3=3D-2.8694e-10   swthe3=3D-2.4e-08       stthe3r=3D-4.1862e-05
+ slthe3r=3D1.014e-07     a1r=3D5.5559        = ;    sla1=3D5.4355e-07
+ swa1=3D-3.3508e-07      sta1=3D0.0084971     &nb= sp;  a2r=3D20
+ sla2=3D0                swa2=3D0 =                a3r=3D 1.1206
+ sla3=3D-1.4134e-07      swa3=3D-1.0882e-08      col=3D6.1e-11
+ ntr=3D2.2e-20           nfr=3D6.085e-12
* Parameters file : diode.dds,v 1.2 1999/01/06 10:27:17
* -- JUNCAP Diode Electrical Parameters for S/D regions  (Simulator specific)
+ diolev=3D9              tnom=3D27 &nbs= p;             vr=3D0
+ cjbr=3D0.000933         cjsr=3D2.994e-10    = ;    cjgr=3D2.085e-10
+  jsdbr=3D1.295e-08       jsdsr=3D1e-20     =       jsdgr=3D9.999e-16
+ jsgbr=3D4.86e-07        jsgsr=3D2.4e-11    =     jsggr=3D1.8e-12
+  vdbr=3D0.8              vdsr=3D0= .8              vdgr=3D0.8
+ pb=3D0.37               ps=3D0.21 &nbs= p;             pg=3D0.37
+  dcaplev=3D0             rlev=3D1 &nbs= p;              alev=3D3

*(1)+rsh=3D2.7               rs=3D48 &nb= sp;               rd=3D48
+ ldif=3D0                hdif=3D4.= 875e-07
*.ENDL

***
*** ADDING NET (from S2ibis3)
***

VOUTS2I OEIN 0 DC 0.0

VCLMPS2I VDDE 0  DC 3.0
VGCLMPS2I GNDE 0  DC 0.0


.TEMP 27.0


.DC VOUTS2I 3.0 6.0 0.04
.PRINT DC I(VOUTS2I)

.END

=

- --
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_001_01C82B37.AC27DB2E-- - -------------------------------------------------------------------- |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, 29 Nov 2007 09:42:37 +0530 From: "Ummalaneni, Venu Babu (Venu)" Subject: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode Dmitry and all, I am curious to know your experiences on the experiments with "trimming V-t curves". Could some one please comment on the behavior of IBIS model with Hspice simulator before and after trimming? I mean, whether the correlation of the IBIS vs golden model in over clocking mode improved after trimming the V-t curves? Thanks & Best Regards, Venu - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Dimitry Eisenshtat Sent: Tuesday, January 16, 2007 3:32 AM To: Todd Westerhoff Cc: ibis@eda-stds.org; ibis-users@eda.org Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour Hi Todd, first of all - thanks for your reply, as I said, I'm writing script for trimming V/T tables in order to satisfy Cookbook recommendation, so your explanation is really useful. Thank you :) Ok, I see from your virtual DDR example that "over clocking" should require special treatment on IBIS simulator side, and I finally decide to avoid such situations and create IBIS models with V/T tables time window up to half of minimum signal period the buffer designed for. Now some words about HOW I will do it. I think the most important point you mentioned is "time correlation" of all given corner curves. I want use simple algorithm for automatically trimming V/T curves, let me explain. Lets say we have 12 transients, exactly as in your (most common) example of push-pull buffer simulated in 3 corners with load of 50 ohm once to supply, once to ground. The steps will be: 1) Run spice simulations (with s2ibis* or manually, does not matter) with as small time step as it possible for simulation time large enough for weakest conditions (corner/load) transition to be finally completed. The idea is to begin with "ideal" time resolution for all transitions regions in our 12 curves. 2) For each curve find largest time interval (T1,T2) which satisfy voltage tolerance of delta from initial and final DC solutions, i.e. |(V(T1)-Vstart)/VDD| < Vtol, |(V(T2)-Vend)/VDD| < Vtol where Vtol tolerance chosen smaller than IBISCHK's one so the checker will not report "DC endpoints" warning on trimmed tables latter. All data points outside of this interval (T1,T2) are declared "dead zones" and have no importance. So the Vtol value actually plays as "dead zones" definition criteria and should be the parameter to be changed if needed. 3) For all curves (rising/falling/load) of given corner find the minimum T1 value, lets define it as T1_typ, T1_slow, T1_fast or T1_. 4) Calculate maximum interval dT_max = max {|T2-T1_|} for ALL curves. 5) Shift all curves for given corner left in time by T1_ value. 6) Truncate all curves at time dT_max (from new 0 time after shifting) 7) Add one points to end of each curve in order to form a line with zero slope for case of some simulators extrapolation will be needed. 8) Remember, we start from "the best" time resolution, so it is possible that we get desire time window from overclocking point of view, but number of points in final V/T tables still exceeds the maximum allowed by IBIS spec. In this case I suggest to use "greatest change algorithm" in order to decrease the number of tables points, as it described in Cookbook (pages 63-64). As the result, if I have no mistake, we will get "corner time- correlated" tables. However, across corners correlation is not guaranteed. My assumption is that the user will be interested in analyzing the buffer's (buffer itself, I mean not control logic but pullup/pulldown devices which actually drive the pad) corner-specific behavioral/differences, so I at least do not worsen the model quality, or even improve it. Anyway, in some cases there will be no possibility to satisfy "overclocking free" condition without shifting the corner's curves one to each other, in other words without trimming different amounts from different corners. Does it make sense? I like to complete realizing this algorithm in perl and try it on last DDR2 model I produced. Only IBIS simulator I have is HSpice, so the plan is to compare the behavioral of IBIS model before and after trimming. I hope the HSpice is bad enough in "over clocking" scenario, otherwise I will see no difference/improvements anyway :) Regards, Dmitry Todd Westerhoff wrote: > Sorry for the delay in reply - I took the weekend off ;-) > > As far as non-time correlation between IBIS and transistor models goes > - no, it isn't a problem at all. It's just important that people > understand what a model represents and what it doesn't, so that they > can draw the right conclusions from their simulations. I was just > re-iterating one of my favorite points with "time 0 in an IBIS model is arbitrary". > > To your point, it's worth noting that time 0 in a spice model-based > simulation is often arbitrary as well. A spice model represents only > the output buffer at most, so if you're analyzing a device with a > clock-to-out timing specification, you still need to figure out how to > combine the delays measured in simulation with the timing spec for the device. > > I think people often ascribe too much credibility to spice models. > The model you receive is a function of how the netlist and parasitics > for the buffer were extracted - it's far too easy to become confused > about what part of the overall device the spice model represents. > > As to page 70 of the IBIS cookbook - I agree with what it says. That > particular page is assuming a DDR device, so that a 100 MHz clock > yields 200M transfers/sec, each with a 5 ns UI. Let's suppose you > have a model with a 6ns rising V-T curve for this case. The simulator > will trigger the curve, begin sweeping the output, and then get > retriggered at the 5ns point > - before the rising edge is complete. What should the simulator do? > > - should it just jump to the start of the falling curve (if it does, > you may get a discontinuity on the output that can either glitch the > output or cause a convergence problem) > > - should the simulator "pipeline" the waveform results, and just > remember the next edge starts 1 ns later - and if the input edges keep > coming faster than the curve length, how long should the simulator > keep this up before it starts clipping data? > > ... my earlier point was that the IBIS spec has no guidance on how a > simulator should handle "overclocking" and different simulators DO > handle this issue different ways. That being the case, it's best to > avoid the problem by complying with the strong recommendation on page 70. > > As far as curve trimming goes, allow me to provide a *brief* overview, > although I'm sure this subject has been discussed previously. > Pointers into the archive for this subject from others would be appreciated. > > Let's consider a push-pull output stage instead of open drain - > open-drain will just be a simpler case. > > Each output should have the following V-T curves > > [Corners] x [Edge] x [Loading] > > [Min / Typ / Max] x [Rising / Falling] x [50 ohms GND / 50 ohms VDDQ] > > ... for a total of 12 sets of V-T curves. > > ... for each [Corner]/[Loading] combination, it is ESSENTIAL that if > you trim dead time off one curve, you trim the SAME amount of dead > time off the other. As an example, if you trim 1ns off the start of > the [Min]/[Rising]/[50 ohms GND] curve, you MUST trim 1ns off the > [Min]/[Rising]/[50 ohms VDDQ] curve. If the second curve was already > rising at that point, well, you need to trim less. > > This is what's called "time correlation" between curves, and it must > be maintained. > > ... good practice dictates that you coordinate your trimming across > all four of the V-T waveforms for any corner. If you don't do this, > you'll introduce duty cycle distortion into the simulated waveform > without meaning to. I believe this is now considered to be required > practice. So, if you trim 1ns off the start of the [Min]/[Rising]/[50 > ohms GND] curve, you really, really should trim 1ns off the following curves: > > [Min]/[Rising]/[50 ohms VDDQ] > [Min]/[Falling]/[50 ohms GND] > [Min]/[Falling]/[50 ohms VDDQ] > > ... so that time correlation is maintained across all the [Min] > curves. As before, if you go to trim any of the curves and find the > transition was already starting, you need to trim less. > > I don't believe IBIS requires that you coordinate trimming across corners. > Thus, you can trim different amounts from the [Min] and [Typ] curve sets. > In practice, you'll find this is useful because if you try to > coordinate trimming across a 3 corners, the amount you are able to > trim may be sharply limited. It's important to understand, though, > that if you trim different amounts from the different corners, the > time correlation between the corners will be lost. Strictly speaking, > that's not a problem, as time 0 in an IBIS simulation is arbitrary. > HOWEVER - if users of the model simulate the [Min] and [Typ] cases and > overlay the results, they will draw incorrect conclusions if they assume the curves are time-correlated. > > It probably goes without saying, but - you can trim any amount of dead > time you want off the END of a curve once the slope is zero. Good > practice says the last two points should form a line with zero slope, > so that any extrapolation the simulator performs does what you expect. > > As in all modeling - knowing what you've got is the first step in > understanding what conclusions you can draw. > > Arpad & others - please correct me if I've gotten any of this wrong ... > > Todd. > > Todd Westerhoff > VP, Software Products > SiSoft > 6 Clock Tower Place, Suite 250 > Maynard, MA 01754 > (978) 461-0449 x24 > twesterh@sisoft.com > www.sisoft.com > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On > Behalf Of Dimitry Eisenshtat > Sent: Saturday, January 13, 2007 3:58 AM > To: Todd Westerhoff > Cc: ibis@eda-stds.org; ibis-users@eda.org > Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour > > Todd, > ok, we understand that time correlation between IBIS and HSpice is not > guaranteed, but is it really problem? I mean, in the most often > situation there is no place for such comparison at all, because you > have only IBIS model, no spice netlist is available. This is the first > reason for making IBIS (if simulator speed is not an issue), is it > right? Lets say, I'm with semiconductor vendor side, I have the > netlist of the buffer, I make the IBIS model based on spice > simulations, not lab measurements, so on final step when the model is > ready I like to check it vs. original spice behavioral. This is the > only situation I agree the comparison is important. But in such case > there is no REAL problem - I know exactly about the delay, and if it > is the only difference between the IBIS & spice - I don't care. > > I want ask you about IBIS simulator aspect of the point we are talking > about. Look, I find in "Cookbook for ver4" strongly recommendation to > trim IBIS model time tables at least to half of max buffer frequency > period. (http://www.vhdl.org/pub/ibis/cookbook/cookbook-v4.pdf page > 70, > 5.4.2 V-T Table Windowing). Can you please prefer from simulator > software side - is it really problem for the simulator if the time > table window is more then such time interval? And one additional > point, you wrote "There are specific restrictions on how the dead time > may be trimmed, which is a longer discussion" - right now I writes > perl script which will trim tables in order to leave only transition > region and decrease the time window as the Cookbook recommends to do. > So, can you please explain about these restrictions? > > Thanks, > Dmitry > > ... (previous thread clipped) > > - -- +---------------------------------------------------------+ | Dmitry Aizenshtat Circuit Design Engineer, NSTA | | Tel : 972-9-9702-020 Fax : 972-9-9702-001 | | mailto:dimita@taux01.nsc.com | +---------------------------------------------------------+ ======================================================================== =================== The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond. - -- 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, 5 Dec 2007 15:47:10 +0530 From: "Ummalaneni, Venu Babu (Venu)" Subject: RE: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode This is a multi-part message in MIME format. - ------_=_NextPart_001_01C83727.FE90A661 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Amit Kumar, =20 Thanks for your response. I too experienced the similar results with the hspice on "before trimming vs after trimming the V-t curves".=20 =20 Regards, Venu ________________________________ From: Amit KUMAR [mailto:amit-hpc.kumar@st.com]=20 Sent: Thursday, November 29, 2007 4:59 PM To: Ummalaneni, Venu Babu (Venu) Cc: Dimitry Eisenshtat; ibis@eda-stds.org; ibis-users@eda.org; Todd Westerhoff Subject: Re: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode Hello Dmitry I have been using Hspice to simulate IBIS models for a while and i have observed that there is no difference(or let me say miniscule diffrences) after trimming V-t curves. It can make difference only if you have missed many intermediate points before trimming and=20 after trimming they are included. But if you have been careful enough to extract your V-t waveforms=20 i feel trimming does not bring any improvement in the results. Also i have felt that Ramp data is also not important if you have given V-t waveforms. No matter how weird your ramp data may look simulation results will be good if your=20 V-t waveforms are extracted properly. One parameter which changes the waveform considerably is C_comp. One should be careful in extracting C_comp as wrong calculation of C_comp can lead to bad results. I leave to the experts to comment on my observations. Regards Amit Kumar ST Microelectronics-Noida Ummalaneni, Venu Babu (Venu) wrote: Dmitry and all, =09 I am curious to know your experiences on the experiments with "trimming V-t curves". Could some one please comment on the behavior of IBIS model with Hspice simulator before and after trimming? I mean, whether the correlation of the IBIS vs golden model in over clocking mode improved after trimming the V-t curves? =09 Thanks & Best Regards, Venu =09 -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Dimitry Eisenshtat Sent: Tuesday, January 16, 2007 3:32 AM To: Todd Westerhoff Cc: ibis@eda-stds.org; ibis-users@eda.org Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour =09 Hi Todd, first of all - thanks for your reply, as I said, I'm writing script for trimming V/T tables in order to satisfy Cookbook recommendation, so your explanation is really useful. Thank you :) =09 Ok, I see from your virtual DDR example that "over clocking" should require special treatment on IBIS simulator side, and I finally decide to avoid such situations and create IBIS models with V/T tables time window up to half of minimum signal period the buffer designed for. =09 Now some words about HOW I will do it. I think the most important point you mentioned is "time correlation" of all given corner curves. I want use simple algorithm for automatically trimming V/T curves, let me explain. Lets say we have 12 transients, exactly as in your (most common) example of push-pull buffer simulated in 3 corners with load of 50 ohm once to supply, once to ground. The steps will be: =09 1) Run spice simulations (with s2ibis* or manually, does not matter) with as small time step as it possible for simulation time large enough for weakest conditions (corner/load) transition to be finally completed. =09 The idea is to begin with "ideal" time resolution for all transitions regions in our 12 curves. =09 2) For each curve find largest time interval (T1,T2) which satisfy voltage tolerance of delta from initial and final DC solutions, i.e. |(V(T1)-Vstart)/VDD| < Vtol, |(V(T2)-Vend)/VDD| < Vtol where Vtol tolerance chosen smaller than IBISCHK's one so the checker will not report "DC endpoints" warning on trimmed tables latter. All data points outside of this interval (T1,T2) are declared "dead zones"=20 and have no importance. So the Vtol value actually plays as "dead zones" =09 definition criteria and should be the parameter to be changed if needed. =09 3) For all curves (rising/falling/load) of given corner find the minimum T1 value, lets define it as T1_typ, T1_slow, T1_fast or T1_. =09 4) Calculate maximum interval dT_max =3D max {|T2-T1_|} for ALL curves. =09 5) Shift all curves for given corner left in time by T1_ value. =09 6) Truncate all curves at time dT_max (from new 0 time after shifting) =09 7) Add one points to end of each curve in order to form a line with zero slope for case of some simulators extrapolation will be needed. =09 8) Remember, we start from "the best" time resolution, so it is possible that we get desire time window from overclocking point of view, but number of points in final V/T tables still exceeds the maximum allowed by IBIS spec. In this case I suggest to use "greatest change algorithm"=20 in order to decrease the number of tables points, as it described in Cookbook (pages 63-64). =09 As the result, if I have no mistake, we will get "corner time- correlated" tables. However, across corners correlation is not guaranteed. My assumption is that the user will be interested in analyzing the buffer's (buffer itself, I mean not control logic but pullup/pulldown devices which actually drive the pad) corner-specific behavioral/differences, so I at least do not worsen the model quality, or even improve it. Anyway, in some cases there will be no possibility to satisfy "overclocking free" condition without shifting the corner's curves one to each other, in other words without trimming different amounts from different corners. =09 Does it make sense? I like to complete realizing this algorithm in perl and try it on last DDR2 model I produced. Only IBIS simulator I have is HSpice, so the plan is to compare the behavioral of IBIS model before and after trimming. I hope the HSpice is bad enough in "over clocking"=20 scenario, otherwise I will see no difference/improvements anyway :) =09 Regards, Dmitry =09 =09 Todd Westerhoff wrote: =09=20=20 Sorry for the delay in reply - I took the weekend off ;-) =09=09 As far as non-time correlation between IBIS and transistor models goes - no, it isn't a problem at all. It's just important that people=20 understand what a model represents and what it doesn't, so that they=20 can draw the right conclusions from their simulations. I was just=20 re-iterating one of my favorite points with "time 0 in an IBIS model =09=09=20=20=20=20 is arbitrary". =09=20=20 To your point, it's worth noting that time 0 in a spice model-based=20 simulation is often arbitrary as well. A spice model represents only=20 the output buffer at most, so if you're analyzing a device with a=20 clock-to-out timing specification, you still need to figure out how to =09=09=20=20=20=20 =09 =09=20=20 combine the delays measured in simulation with the timing spec for the =09=09=20=20=20=20 device. =09=20=20 I think people often ascribe too much credibility to spice models.=20=20 The model you receive is a function of how the netlist and parasitics=20 for the buffer were extracted - it's far too easy to become confused=20 about what part of the overall device the spice model represents. =09=09 As to page 70 of the IBIS cookbook - I agree with what it says. That=20 particular page is assuming a DDR device, so that a 100 MHz clock=20 yields 200M transfers/sec, each with a 5 ns UI. Let's suppose you=20 have a model with a 6ns rising V-T curve for this case. The simulator =09=09=20=20=20=20 =09 =09=20=20 will trigger the curve, begin sweeping the output, and then get=20 retriggered at the 5ns point - before the rising edge is complete. What should the simulator do? =09=09 - should it just jump to the start of the falling curve (if it does,=20 you may get a discontinuity on the output that can either glitch the=20 output or cause a convergence problem) =09=09 - should the simulator "pipeline" the waveform results, and just=20 remember the next edge starts 1 ns later - and if the input edges keep =09=09=20=20=20=20 =09 =09=20=20 coming faster than the curve length, how long should the simulator=20 keep this up before it starts clipping data? =09=09 ... my earlier point was that the IBIS spec has no guidance on how a=20 simulator should handle "overclocking" and different simulators DO=20 handle this issue different ways. That being the case, it's best to=20 avoid the problem by complying with the strong recommendation on page =09=09=20=20=20=20 70. =09=20=20 As far as curve trimming goes, allow me to provide a *brief* overview, =09=09=20=20=20=20 =09 =09=20=20 although I'm sure this subject has been discussed previously. Pointers into the archive for this subject from others would be =09=09=20=20=20=20 appreciated. =09=20=20 Let's consider a push-pull output stage instead of open drain -=20 open-drain will just be a simpler case. =09=09 Each output should have the following V-T curves =09=09=09 [Corners] x [Edge] x [Loading] =09=09 [Min / Typ / Max] x [Rising / Falling] x [50 ohms GND / 50 ohms =09=09=20=20=20=20 VDDQ] =09=20=20 ... for a total of 12 sets of V-T curves.=20=20 =09=09 ... for each [Corner]/[Loading] combination, it is ESSENTIAL that if=20 you trim dead time off one curve, you trim the SAME amount of dead=20 time off the other. As an example, if you trim 1ns off the start of=20 the [Min]/[Rising]/[50 ohms GND] curve, you MUST trim 1ns off the=20 [Min]/[Rising]/[50 ohms VDDQ] curve. If the second curve was already=20 rising at that point, well, you need to trim less. =09=09 This is what's called "time correlation" between curves, and it must=20 be maintained. =09=09 ... good practice dictates that you coordinate your trimming across=20 all four of the V-T waveforms for any corner. If you don't do this,=20 you'll introduce duty cycle distortion into the simulated waveform=20 without meaning to. I believe this is now considered to be required=20 practice. So, if you trim 1ns off the start of the [Min]/[Rising]/[50 =09=09=20=20=20=20 =09 =09=20=20 ohms GND] curve, you really, really should trim 1ns off the following =09=09=20=20=20=20 curves: =09=20=20 [Min]/[Rising]/[50 ohms VDDQ] [Min]/[Falling]/[50 ohms GND] [Min]/[Falling]/[50 ohms VDDQ] =09=09 ... so that time correlation is maintained across all the [Min]=20 curves. As before, if you go to trim any of the curves and find the=20 transition was already starting, you need to trim less. =09=09 I don't believe IBIS requires that you coordinate trimming across =09=09=20=20=20=20 corners. =09=20=20 Thus, you can trim different amounts from the [Min] and [Typ] curve =09=09=20=20=20=20 sets. =09=20=20 In practice, you'll find this is useful because if you try to=20 coordinate trimming across a 3 corners, the amount you are able to=20 trim may be sharply limited. It's important to understand, though,=20 that if you trim different amounts from the different corners, the=20 time correlation between the corners will be lost. Strictly speaking, =09=09=20=20=20=20 =09 =09=20=20 that's not a problem, as time 0 in an IBIS simulation is arbitrary. HOWEVER - if users of the model simulate the [Min] and [Typ] cases and =09=09=20=20=20=20 =09 =09=20=20 overlay the results, they will draw incorrect conclusions if they =09=09=20=20=20=20 assume the curves are time-correlated. =09=20=20 It probably goes without saying, but - you can trim any amount of dead =09=09=20=20=20=20 =09 =09=20=20 time you want off the END of a curve once the slope is zero. Good=20 practice says the last two points should form a line with zero slope,=20 so that any extrapolation the simulator performs does what you expect. =09=09 As in all modeling - knowing what you've got is the first step in=20 understanding what conclusions you can draw. =09=09 Arpad & others - please correct me if I've gotten any of this wrong =09=09=20=20=20=20 ... =09=20=20 Todd. =09=09 Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On=20 Behalf Of Dimitry Eisenshtat Sent: Saturday, January 13, 2007 3:58 AM To: Todd Westerhoff Cc: ibis@eda-stds.org; ibis-users@eda.org Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour =09=09 Todd, ok, we understand that time correlation between IBIS and HSpice is not =09=09=20=20=20=20 =09 =09=20=20 guaranteed, but is it really problem? I mean, in the most often=20 situation there is no place for such comparison at all, because you=20 have only IBIS model, no spice netlist is available. This is the first =09=09=20=20=20=20 =09 =09=20=20 reason for making IBIS (if simulator speed is not an issue), is it=20 right? Lets say, I'm with semiconductor vendor side, I have the=20 netlist of the buffer, I make the IBIS model based on spice=20 simulations, not lab measurements, so on final step when the model is=20 ready I like to check it vs. original spice behavioral. This is the=20 only situation I agree the comparison is important. But in such case=20 there is no REAL problem - I know exactly about the delay, and if it=20 is the only difference between the IBIS & spice - I don't care. =09=09 I want ask you about IBIS simulator aspect of the point we are talking =09=09=20=20=20=20 =09 =09=20=20 about. Look, I find in "Cookbook for ver4" strongly recommendation to=20 trim IBIS model time tables at least to half of max buffer frequency=20 period. (http://www.vhdl.org/pub/ibis/cookbook/cookbook-v4.pdf page=20 70, 5.4.2 V-T Table Windowing). Can you please prefer from simulator=20 software side - is it really problem for the simulator if the time=20 table window is more then such time interval? And one additional=20 point, you wrote "There are specific restrictions on how the dead time =09=09=20=20=20=20 =09 =09=20=20 may be trimmed, which is a longer discussion" - right now I writes=20 perl script which will trim tables in order to leave only transition=20 region and decrease the time window as the Cookbook recommends to do. So, can you please explain about these restrictions? =09=09 Thanks, Dmitry =09=09 ... (previous thread clipped) =09=09 =09=09 =09=09=20=20=20=20 =09 =09 -- +---------------------------------------------------------+ | Dmitry Aizenshtat Circuit Design Engineer, NSTA | | Tel : 972-9-9702-020 Fax : 972-9-9702-001 | | mailto:dimita@taux01.nsc.com | +---------------------------------------------------------+ =09 =09 =09 =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=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 The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond. =09 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. =09 =09 =09 - -------------------------------------------------------------------- |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 =09 =09=20=20 - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------_=_NextPart_001_01C83727.FE90A661 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Thanks for your response. I too experienced the similar results with the hs= pice on=20 "before trimming vs after trimming the V-t curves".=20
 
Regards,
= Venu<= BR>
From: Amit KUMAR [mailto:amit-hpc.kumar= @st.com]=20
Sent: Thursday, November 29, 2007 4:59 PM
To: Ummalane= ni,=20 Venu Babu (Venu)
Cc: Dimitry Eisenshtat; ibis@eda-stds.org;=20 ibis-users@eda.org; Todd Westerhoff
Subject: Re: [IBIS-Users] RE:= =20 Trimming V-t curves - IBIS model behavior in over clocking=20 mode

Hello Dmitry

I have been using Hspice to simulate IBIS mo= dels=20 for a while and i have observed that
there is no difference(or let me sa= y=20 miniscule diffrences) after trimming V-t curves.
It can make difference = only=20 if you have missed many intermediate points before trimming and
after= =20 trimming they are included.
But if you have been careful enough to extra= ct=20 your V-t waveforms
i feel trimming does not bring any improvement in th= e=20 results.

Also i have felt that Ramp data is also not important if yo= u=20 have given V-t waveforms.
No matter how weird your ramp data may look=20 simulation results will be good if your
V-t waveforms are extracted=20 properly.

One parameter which changes the waveform considerably is= =20 C_comp.
One should be careful in extracting C_comp as wrong calculation = of=20 C_comp can lead to bad results.

I leave to the experts to comment on= my=20 observations.

Regards
Amit Kumar
ST=20 Microelectronics-Noida

Ummalaneni, Venu Babu (Venu) wrote:
Dmitry and all,

I am curious to know your experiences on the experiments with "trimming
V-t curves". Could some one please comment on the behavior of IBIS model
with Hspice simulator before and after trimming? I mean, whether the
correlation of the IBIS vs golden model in over clocking mode improved
after trimming the V-t curves?

Thanks & Best Regards,
Venu

- -----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On
Behalf Of Dimitry Eisenshtat
Sent: Tuesday, January 16, 2007 3:32 AM
To: Todd Westerhoff
Cc: i=
bis@eda-stds.org; ibis-users@eda.org
Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour

Hi Todd,
first of all - thanks for your reply, as I said, I'm writing script for
trimming V/T tables in order to satisfy Cookbook recommendation, so your
explanation is really useful. Thank you :)

Ok, I see from your virtual DDR example that "over clocking" should
require special treatment on IBIS simulator side, and I finally decide
to avoid such situations and create IBIS models with V/T tables time
window up to  half of minimum signal period the buffer designed for.

Now some words about HOW I will do it. I think the most important point
you mentioned is "time correlation" of all given corner curves. I want
use simple algorithm for automatically trimming V/T curves, let me
explain. Lets say we have 12 transients, exactly as in your (most
common) example of push-pull buffer simulated in 3 corners with load of
50 ohm once to supply, once to ground. The steps will be:

1) Run spice simulations (with s2ibis* or manually, does not matter)
with as small time step as it possible for simulation time large enough
for weakest conditions (corner/load) transition to be finally completed.

The idea is to begin with "ideal" time resolution for all transitions
regions in our 12 curves.

2) For each curve find largest time interval (T1,T2) which satisfy
voltage tolerance of delta from initial and final DC solutions, i.e.
  |(V(T1)-Vstart)/VDD|  < Vtol,
  |(V(T2)-Vend)/VDD|    < Vtol
where Vtol tolerance chosen smaller than IBISCHK's one so the checker
will not report "DC endpoints" warning on trimmed tables latter. All
data points outside of this interval (T1,T2) are declared "dead zones"=20
and have no importance. So the Vtol value actually plays as "dead zones"

definition criteria and should be the parameter to be changed if needed.

3) For all curves (rising/falling/load) of given corner find the minimum
T1 value, lets define it as T1_typ, T1_slow, T1_fast or T1_<corner>.

4) Calculate maximum interval dT_max =3D max {|T2-T1_<corner>|} for A=
LL
curves.

5) Shift all curves for given corner left in time by T1_<corner> valu=
e.

6) Truncate all curves at time dT_max (from new 0 time after shifting)

7) Add one points to end of each curve in order to form a line with zero
slope for case of some simulators extrapolation will be needed.

8) Remember, we start from "the best" time resolution, so it is possible
that we get desire time window from overclocking point of view, but
number of points in final V/T tables still exceeds the maximum allowed
by IBIS spec. In this case I suggest to use "greatest change algorithm"=20
in order to decrease the number of tables points, as it described in
Cookbook (pages 63-64).

As the result, if I have no mistake, we will get "corner time-
correlated" tables. However, across corners correlation is not
guaranteed. My assumption is that the user will be interested in
analyzing the buffer's (buffer itself, I mean not control logic but
pullup/pulldown devices which actually drive the pad) corner-specific
behavioral/differences, so I at least do not worsen the model quality,
or even improve it. Anyway,  in some cases there will be no possibility
to satisfy "overclocking free" condition without shifting the corner's
curves one to each other, in other words without trimming different
amounts from different corners.

Does it make sense? I like to complete realizing this algorithm in perl
and try it on last DDR2 model I produced. Only IBIS simulator I have is
HSpice, so the plan is to compare the behavioral of IBIS model before
and after trimming. I hope the HSpice is bad enough in "over clocking"=20
scenario, otherwise I will see no difference/improvements anyway :)

Regards,
    Dmitry


Todd Westerhoff wrote:
  
Sorry for the delay in reply - I=
 took the weekend off ;-)

As far as non-time correlation between IBIS and transistor models goes
- - no, it isn't a problem at all.  It's just important that people=20
understand what a model represents and what it doesn't, so that they=20
can draw the right conclusions from their simulations.  I was just=20
re-iterating one of my favorite points with "time 0 in an IBIS model
    
is arbitrary".
  
To your point, it's worth noting=
 that time 0 in a spice model-based=20
simulation is often arbitrary as well.  A spice model represents only=20
the output buffer at most, so if you're analyzing a device with a=20
clock-to-out timing specification, you still need to figure out how to
    

  
combine the delays measured in s=
imulation with the timing spec for the
    
device.
  
I think people often ascribe too=
 much credibility to spice models.=20=20
The model you receive is a function of how the netlist and parasitics=20
for the buffer were extracted - it's far too easy to become confused=20
about what part of the overall device the spice model represents.

As to page 70 of the IBIS cookbook - I agree with what it says.  That=20
particular page is assuming a DDR device, so that a 100 MHz clock=20
yields 200M transfers/sec, each with a 5 ns UI.  Let's suppose you=20
have a model with a 6ns rising V-T curve for this case.  The simulator
    

  
will trigger the curve, begin sw=
eeping the output, and then get=20
retriggered at the 5ns point
- - before the rising edge is complete.  What should the simulator do?

- - should it just jump to the start of the falling curve (if it does,=20
you may get a discontinuity on the output that can either glitch the=20
output or cause a convergence problem)

- - should the simulator "pipeline" the waveform results, and just=20
remember the next edge starts 1 ns later - and if the input edges keep
    

  
coming faster than the curve len=
gth, how long should the simulator=20
keep this up before it starts clipping data?

... my earlier point was that the IBIS spec has no guidance on how a=20
simulator should handle "overclocking" and different simulators DO=20
handle this issue different ways.  That being the case, it's best to=20
avoid the problem by complying with the strong recommendation on page
    
70.
  
As far as curve trimming goes, a=
llow me to provide a *brief* overview,
    

  
although I'm sure this subject h=
as been discussed previously.
Pointers into the archive for this subject from others would be
    
appreciated.
  
Let's consider a push-pull outpu=
t stage instead of open drain -=20
open-drain will just be a simpler case.

Each output should have the following V-T curves
=09
	[Corners]         x [Edge]             x [Loading]

	[Min / Typ / Max] x [Rising / Falling] x [50 ohms GND / 50 ohms
    
VDDQ]
  
... for a total of 12 sets of V-=
T curves.=20=20

... for each [Corner]/[Loading] combination, it is ESSENTIAL that if=20
you trim dead time off one curve, you trim the SAME amount of dead=20
time off the other.  As an example, if you trim 1ns off the start of=20
the [Min]/[Rising]/[50 ohms GND] curve, you MUST trim 1ns off the=20
[Min]/[Rising]/[50 ohms VDDQ] curve.  If the second curve was already=20
rising at that point, well, you need to trim less.

This is what's called "time correlation" between curves, and it must=20
be maintained.

... good practice dictates that you coordinate your trimming across=20
all four of the V-T waveforms for any corner.  If you don't do this,=20
you'll introduce duty cycle distortion into the simulated waveform=20
without meaning to.  I believe this is now considered to be required=20
practice.  So, if you trim 1ns off the start of the [Min]/[Rising]/[50
    

  
ohms GND] curve, you really, rea=
lly should trim 1ns off the following
    
curves:
  
	[Min]/[Rising]/[50 ohms VDDQ]
	[Min]/[Falling]/[50 ohms GND]
	[Min]/[Falling]/[50 ohms VDDQ]

... so that time correlation is maintained across all the [Min]=20
curves.  As before, if you go to trim any of the curves and find the=20
transition was already starting, you need to trim less.

I don't believe IBIS requires that you coordinate trimming across
    
corners.
  
Thus, you can trim different amo=
unts from the [Min] and [Typ] curve
    
sets.
  
In practice, you'll find this is=
 useful because if you try to=20
coordinate trimming across a 3 corners, the amount you are able to=20
trim may be sharply limited.  It's important to understand, though,=20
that if you trim different amounts from the different corners, the=20
time correlation between the corners will be lost.  Strictly speaking,
    

  
that's not a problem, as time 0 =
in an IBIS simulation is arbitrary.
HOWEVER - if users of the model simulate the [Min] and [Typ] cases and
    

  
overlay the results, they will d=
raw incorrect conclusions if they
    
assume the curves are time-cor=
related.
  
It probably goes without saying,=
 but - you can trim any amount of dead
    

  
time you want off the END of a c=
urve once the slope is zero.  Good=20
practice says the last two points should form a line with zero slope,=20
so that any extrapolation the simulator performs does what you expect.

As in all modeling - knowing what you've got is the first step in=20
understanding what conclusions you can draw.

Arpad & others - please correct me if I've gotten any of this wrong
    
...
  
Todd.

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA  01754
(978) 461-0449 x24
twe=
sterh@sisoft.com
www.siso=
ft.com
- -----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] O=
n=20
Behalf Of Dimitry Eisenshtat
Sent: Saturday, January 13, 2007 3:58 AM
To: Todd Westerhoff
Cc: i=
bis@eda-stds.org; ibis-users@eda.org
Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour

Todd,
ok, we understand that time correlation between IBIS and HSpice is not
    

  
guaranteed, but is it really pro=
blem? I mean, in the most often=20
situation there is no place for such comparison at all, because you=20
have only IBIS model, no spice netlist is available. This is the first
    

  
reason for making IBIS (if simul=
ator speed is not an issue), is it=20
right? Lets say, I'm with semiconductor vendor side, I have the=20
netlist of the buffer, I  make the IBIS model based on spice=20
simulations, not lab measurements, so on final step when the model is=20
ready I like to check it vs. original spice behavioral. This is the=20
only situation I agree the comparison is important. But in such case=20
there is no REAL problem - I know exactly about the delay, and if it=20
is the only difference between the IBIS & spice - I don't care.

I want ask you about IBIS simulator aspect of the point we are talking
    

  
about. Look, I find in "Cookbook=
 for ver4" strongly recommendation to=20
trim IBIS model time tables at least to half of max buffer frequency=20
period. (http://www.vhdl.org/pub/ibis/cookbook/cookboo=
k-v4.pdf page=20
70,
5.4.2 V-T Table Windowing). Can you please prefer from simulator=20
software side - is it really problem for the simulator if the time=20
table window is more then such time interval? And one additional=20
point, you wrote "There are specific restrictions on how the dead time
    

  
may be trimmed, which is a longe=
r discussion" - right now I writes=20
perl script which will trim tables in order to leave only transition=20
region and decrease the time window as the Cookbook recommends to do.
So, can you please explain about these restrictions?

Thanks,
  Dmitry

... (previous thread clipped)


    


- --
  +---------------------------------------------------------+
  | Dmitry Aizenshtat         Circuit Design Engineer, NSTA |
  | Tel : 972-9-9702-020               Fax : 972-9-9702-001 |
  | =
mailto:dimita@taux01.nsc.com                            |
  +---------------------------------------------------------+


=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=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
The privileged confidential information contained in this email is
intended for use only by the addressees as indicated by the original
sender of this email. If you are not the addressee indicated in this
email or are not responsible for delivery of the email to such  a
person, please kindly reply to the sender indicating this fact and
delete all copies of it from your computer and network server
immediately. Your cooperation is highly appreciated. It is advised that
any unauthorized use of confidential information of Winbond is strictly
prohibited; and any information in this email irrelevant to the official
business of Winbond shall be deemed as neither given nor endorsed by
Winbond.

- --
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       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------_=_NextPart_001_01C83727.FE90A661-- - -------------------------------------------------------------------- |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, 5 Dec 2007 11:30:23 -0500 From: "Todd Westerhoff" Subject: RE: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode This is a multi-part message in MIME format. - ------=_NextPart_000_006F_01C83732.3A591BF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, The simulated behavior of an IBIS model with properly trimmed IBIS curves shouldn't change - that's the definition of "proper trimming". The only time you should see a difference in behavior is when you switch the buffer's state before the full time in the V-T curve has elapsed (usually referred to as "overclocking"). V-T curves with extra dead time in the start of the curve will overclock at lower speeds than trimmed curves will, which is why we trim V-T curves in the first place. We trim curves based on the understanding that a device really will operate at a target speed, but that V-T curves with extra dead time will give the incorrect results. You're correct that [Ramp] data is generally not used for simulation when V-T curves are present, but that doesn't mean it's not important. Some tools use [Ramp] data to choose what drivers to use for crosstalk simulations (based on the theory that the fastest edge rate will produce the greatest crosstalk). Some tools will also use [Ramp] data as a fallback if they encounter problems using V-T curves for analysis. Hope that helps, Todd Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com _____ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Ummalaneni, Venu Babu (Venu) Sent: Wednesday, December 05, 2007 5:17 AM To: Amit KUMAR Cc: Dimitry Eisenshtat; ibis@eda-stds.org; ibis-users@eda.org; Todd Westerhoff Subject: RE: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode Amit Kumar, Thanks for your response. I too experienced the similar results with the hspice on "before trimming vs after trimming the V-t curves". Regards, Venu _____ From: Amit KUMAR [mailto:amit-hpc.kumar@st.com] Sent: Thursday, November 29, 2007 4:59 PM To: Ummalaneni, Venu Babu (Venu) Cc: Dimitry Eisenshtat; ibis@eda-stds.org; ibis-users@eda.org; Todd Westerhoff Subject: Re: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode Hello Dmitry I have been using Hspice to simulate IBIS models for a while and i have observed that there is no difference(or let me say miniscule diffrences) after trimming V-t curves. It can make difference only if you have missed many intermediate points before trimming and after trimming they are included. But if you have been careful enough to extract your V-t waveforms i feel trimming does not bring any improvement in the results. Also i have felt that Ramp data is also not important if you have given V-t waveforms. No matter how weird your ramp data may look simulation results will be good if your V-t waveforms are extracted properly. One parameter which changes the waveform considerably is C_comp. One should be careful in extracting C_comp as wrong calculation of C_comp can lead to bad results. I leave to the experts to comment on my observations. Regards Amit Kumar ST Microelectronics-Noida Ummalaneni, Venu Babu (Venu) wrote: Dmitry and all, I am curious to know your experiences on the experiments with "trimming V-t curves". Could some one please comment on the behavior of IBIS model with Hspice simulator before and after trimming? I mean, whether the correlation of the IBIS vs golden model in over clocking mode improved after trimming the V-t curves? Thanks & Best Regards, Venu - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Dimitry Eisenshtat Sent: Tuesday, January 16, 2007 3:32 AM To: Todd Westerhoff Cc: ibis@eda-stds.org; ibis-users@eda.org Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour Hi Todd, first of all - thanks for your reply, as I said, I'm writing script for trimming V/T tables in order to satisfy Cookbook recommendation, so your explanation is really useful. Thank you :) Ok, I see from your virtual DDR example that "over clocking" should require special treatment on IBIS simulator side, and I finally decide to avoid such situations and create IBIS models with V/T tables time window up to half of minimum signal period the buffer designed for. Now some words about HOW I will do it. I think the most important point you mentioned is "time correlation" of all given corner curves. I want use simple algorithm for automatically trimming V/T curves, let me explain. Lets say we have 12 transients, exactly as in your (most common) example of push-pull buffer simulated in 3 corners with load of 50 ohm once to supply, once to ground. The steps will be: 1) Run spice simulations (with s2ibis* or manually, does not matter) with as small time step as it possible for simulation time large enough for weakest conditions (corner/load) transition to be finally completed. The idea is to begin with "ideal" time resolution for all transitions regions in our 12 curves. 2) For each curve find largest time interval (T1,T2) which satisfy voltage tolerance of delta from initial and final DC solutions, i.e. |(V(T1)-Vstart)/VDD| < Vtol, |(V(T2)-Vend)/VDD| < Vtol where Vtol tolerance chosen smaller than IBISCHK's one so the checker will not report "DC endpoints" warning on trimmed tables latter. All data points outside of this interval (T1,T2) are declared "dead zones" and have no importance. So the Vtol value actually plays as "dead zones" definition criteria and should be the parameter to be changed if needed. 3) For all curves (rising/falling/load) of given corner find the minimum T1 value, lets define it as T1_typ, T1_slow, T1_fast or T1_. 4) Calculate maximum interval dT_max = max {|T2-T1_|} for ALL curves. 5) Shift all curves for given corner left in time by T1_ value. 6) Truncate all curves at time dT_max (from new 0 time after shifting) 7) Add one points to end of each curve in order to form a line with zero slope for case of some simulators extrapolation will be needed. 8) Remember, we start from "the best" time resolution, so it is possible that we get desire time window from overclocking point of view, but number of points in final V/T tables still exceeds the maximum allowed by IBIS spec. In this case I suggest to use "greatest change algorithm" in order to decrease the number of tables points, as it described in Cookbook (pages 63-64). As the result, if I have no mistake, we will get "corner time- correlated" tables. However, across corners correlation is not guaranteed. My assumption is that the user will be interested in analyzing the buffer's (buffer itself, I mean not control logic but pullup/pulldown devices which actually drive the pad) corner-specific behavioral/differences, so I at least do not worsen the model quality, or even improve it. Anyway, in some cases there will be no possibility to satisfy "overclocking free" condition without shifting the corner's curves one to each other, in other words without trimming different amounts from different corners. Does it make sense? I like to complete realizing this algorithm in perl and try it on last DDR2 model I produced. Only IBIS simulator I have is HSpice, so the plan is to compare the behavioral of IBIS model before and after trimming. I hope the HSpice is bad enough in "over clocking" scenario, otherwise I will see no difference/improvements anyway :) Regards, Dmitry Todd Westerhoff wrote: Sorry for the delay in reply - I took the weekend off ;-) As far as non-time correlation between IBIS and transistor models goes - - no, it isn't a problem at all. It's just important that people understand what a model represents and what it doesn't, so that they can draw the right conclusions from their simulations. I was just re-iterating one of my favorite points with "time 0 in an IBIS model is arbitrary". To your point, it's worth noting that time 0 in a spice model-based simulation is often arbitrary as well. A spice model represents only the output buffer at most, so if you're analyzing a device with a clock-to-out timing specification, you still need to figure out how to combine the delays measured in simulation with the timing spec for the device. I think people often ascribe too much credibility to spice models. The model you receive is a function of how the netlist and parasitics for the buffer were extracted - it's far too easy to become confused about what part of the overall device the spice model represents. As to page 70 of the IBIS cookbook - I agree with what it says. That particular page is assuming a DDR device, so that a 100 MHz clock yields 200M transfers/sec, each with a 5 ns UI. Let's suppose you have a model with a 6ns rising V-T curve for this case. The simulator will trigger the curve, begin sweeping the output, and then get retriggered at the 5ns point - - before the rising edge is complete. What should the simulator do? - - should it just jump to the start of the falling curve (if it does, you may get a discontinuity on the output that can either glitch the output or cause a convergence problem) - - should the simulator "pipeline" the waveform results, and just remember the next edge starts 1 ns later - and if the input edges keep coming faster than the curve length, how long should the simulator keep this up before it starts clipping data? ... my earlier point was that the IBIS spec has no guidance on how a simulator should handle "overclocking" and different simulators DO handle this issue different ways. That being the case, it's best to avoid the problem by complying with the strong recommendation on page 70. As far as curve trimming goes, allow me to provide a *brief* overview, although I'm sure this subject has been discussed previously. Pointers into the archive for this subject from others would be appreciated. Let's consider a push-pull output stage instead of open drain - open-drain will just be a simpler case. Each output should have the following V-T curves [Corners] x [Edge] x [Loading] [Min / Typ / Max] x [Rising / Falling] x [50 ohms GND / 50 ohms VDDQ] ... for a total of 12 sets of V-T curves. ... for each [Corner]/[Loading] combination, it is ESSENTIAL that if you trim dead time off one curve, you trim the SAME amount of dead time off the other. As an example, if you trim 1ns off the start of the [Min]/[Rising]/[50 ohms GND] curve, you MUST trim 1ns off the [Min]/[Rising]/[50 ohms VDDQ] curve. If the second curve was already rising at that point, well, you need to trim less. This is what's called "time correlation" between curves, and it must be maintained. ... good practice dictates that you coordinate your trimming across all four of the V-T waveforms for any corner. If you don't do this, you'll introduce duty cycle distortion into the simulated waveform without meaning to. I believe this is now considered to be required practice. So, if you trim 1ns off the start of the [Min]/[Rising]/[50 ohms GND] curve, you really, really should trim 1ns off the following curves: [Min]/[Rising]/[50 ohms VDDQ] [Min]/[Falling]/[50 ohms GND] [Min]/[Falling]/[50 ohms VDDQ] ... so that time correlation is maintained across all the [Min] curves. As before, if you go to trim any of the curves and find the transition was already starting, you need to trim less. I don't believe IBIS requires that you coordinate trimming across corners. Thus, you can trim different amounts from the [Min] and [Typ] curve sets. In practice, you'll find this is useful because if you try to coordinate trimming across a 3 corners, the amount you are able to trim may be sharply limited. It's important to understand, though, that if you trim different amounts from the different corners, the time correlation between the corners will be lost. Strictly speaking, that's not a problem, as time 0 in an IBIS simulation is arbitrary. HOWEVER - if users of the model simulate the [Min] and [Typ] cases and overlay the results, they will draw incorrect conclusions if they assume the curves are time-correlated. It probably goes without saying, but - you can trim any amount of dead time you want off the END of a curve once the slope is zero. Good practice says the last two points should form a line with zero slope, so that any extrapolation the simulator performs does what you expect. As in all modeling - knowing what you've got is the first step in understanding what conclusions you can draw. Arpad & others - please correct me if I've gotten any of this wrong ... Todd. Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Dimitry Eisenshtat Sent: Saturday, January 13, 2007 3:58 AM To: Todd Westerhoff Cc: ibis@eda-stds.org; ibis-users@eda.org Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour Todd, ok, we understand that time correlation between IBIS and HSpice is not guaranteed, but is it really problem? I mean, in the most often situation there is no place for such comparison at all, because you have only IBIS model, no spice netlist is available. This is the first reason for making IBIS (if simulator speed is not an issue), is it right? Lets say, I'm with semiconductor vendor side, I have the netlist of the buffer, I make the IBIS model based on spice simulations, not lab measurements, so on final step when the model is ready I like to check it vs. original spice behavioral. This is the only situation I agree the comparison is important. But in such case there is no REAL problem - I know exactly about the delay, and if it is the only difference between the IBIS & spice - I don't care. I want ask you about IBIS simulator aspect of the point we are talking about. Look, I find in "Cookbook for ver4" strongly recommendation to trim IBIS model time tables at least to half of max buffer frequency period. (http://www.vhdl.org/pub/ibis/cookbook/cookbook-v4.pdf page 70, 5.4.2 V-T Table Windowing). Can you please prefer from simulator software side - is it really problem for the simulator if the time table window is more then such time interval? And one additional point, you wrote "There are specific restrictions on how the dead time may be trimmed, which is a longer discussion" - right now I writes perl script which will trim tables in order to leave only transition region and decrease the time window as the Cookbook recommends to do. So, can you please explain about these restrictions? Thanks, Dmitry ... (previous thread clipped) - -- +---------------------------------------------------------+ | Dmitry Aizenshtat Circuit Design Engineer, NSTA | | Tel : 972-9-9702-020 Fax : 972-9-9702-001 | | mailto:dimita@taux01.nsc.com | +---------------------------------------------------------+ ======================================================================== =================== The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond. - -- 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. - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------=_NextPart_000_006F_01C83732.3A591BF0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All,

 

The simulated behavior of an IBIS model with properly trimmed IBIS curves shouldn’t change – that’= ;s the definition of “proper trimming”.  The only time you sh= ould see a difference in behavior is when you switch the buffer’s state be= fore the full time in the V-T curve has elapsed (usually referred to as “o= verclocking”).   V-T curves with extra dead time in the start of the curve will overcl= ock at lower speeds than trimmed curves will, which is why we trim V-T curves in t= he first place.  We trim curves based on the understanding that a device really will operate at a target speed, but that V-T curves with extra dead = time will give the incorrect results.

 

You’re correct that [Ramp] data = is generally not used for simulation when V-T curves are present, but that doe= sn’t mean it’s not important.  Some tools use [Ramp] data to choose w= hat drivers to use for crosstalk simulations (based on the theory that the fast= est edge rate will produce the greatest crosstalk).  Some tools will also = use [Ramp] data as a fallback if they encounter problems using V-T curves for analysis.

 

Hope that helps,

 

Todd


Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@sisoft.com
www.sisoft.com

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Ummalaneni, Venu Babu (V= enu)
Sent: Wednesday, December 05= , 2007 5:17 AM
To: Amit KUMAR
Cc: Dimitry Eisenshtat; ibis@eda-stds.org; ibis-users@eda.org; Todd Westerhoff
Subject: RE: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode

 

Amit Kumar,

 

Thanks for your response. I too experienced the similar results with the hspice on "before trimming vs after trimming the V-t curves".

 

Regards,

Venu

From:= = Amit KUMAR [mailto:amit-hpc.kumar@st.com]
Sent: Thursday, November 29,= 2007 4:59 PM
To: Ummalaneni, Venu Babu (V= enu)
Cc: Dimitry Eisenshtat; ibis@eda-stds.org; ibis-users@eda.org; Todd Westerhoff
Subject: Re: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode

Hello Dmitry

I have been using Hspice to simulate IBIS models for a while and i have observed that
there is no difference(or let me say miniscule diffrences) after trimming V= - -t curves.
It can make difference only if you have missed many intermediate points bef= ore trimming and
after trimming they are included.
But if you have been careful enough to extract your V-t waveforms
i feel trimming does not bring any improvement in the results.

Also i have felt that Ramp data is also not important if you have given V-t waveforms.
No matter how weird your ramp data may look simulation results will be good= if your
V-t waveforms are extracted properly.

One parameter which changes the waveform considerably is C_comp.
One should be careful in extracting C_comp as wrong calculation of C_comp c= an lead to bad results.

I leave to the experts to comment on my observations.

Regards
Amit Kumar
ST Microelectronics-Noida

Ummalaneni, Venu Babu (Venu) wrote:

Dmitry and all,
 <=
/o:p>
I am curious=
 to know your experiences on the experiments with "trimming=

V-t curves&q=
uot;. Could some one please comment on the behavior of IBIS model
with Hspice =
simulator before and after trimming? I mean, whether the<=
/font>
correlation =
of the IBIS vs golden model in over clocking mode improved
after trimmi=
ng the V-t curves?
 <=
/o:p>
Thanks &=
 Best Regards,
Venu
 <=
/o:p>
-----Origina=
l Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On
Behalf Of Di=
mitry Eisenshtat
Sent: Tuesda=
y, January 16, 2007 3:32 AM
To: Todd Wes=
terhoff
Cc: ibis@eda-stds.org; ibis-users@eda.org=

Subject: Re:=
 [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour
 <=
/o:p>
Hi Todd,
first of all=
 - thanks for your reply, as I said, I'm writing script for
trimming V/T=
 tables in order to satisfy Cookbook recommendation, so your
explanation =
is really useful. Thank you :)
 <=
/o:p>
Ok, I see fr=
om your virtual DDR example that "over clocking" should
require spec=
ial treatment on IBIS simulator side, and I finally decide
to avoid suc=
h situations and create IBIS models with V/T tables time<=
/font>
window up to=
  half of minimum signal period the buffer designed for.
 <=
/o:p>
Now some wor=
ds about HOW I will do it. I think the most important point
you mentione=
d is "time correlation" of all given corner curves. I want
use simple a=
lgorithm for automatically trimming V/T curves, let me
explain. Let=
s say we have 12 transients, exactly as in your (most
common) exam=
ple of push-pull buffer simulated in 3 corners with load of
50 ohm once =
to supply, once to ground. The steps will be:
 <=
/o:p>
1) Run spice=
 simulations (with s2ibis* or manually, does not matter)<=
/font>
with as smal=
l time step as it possible for simulation time large enough
for weakest =
conditions (corner/load) transition to be finally completed.
 <=
/o:p>
The idea is =
to begin with "ideal" time resolution for all transitions
regions in o=
ur 12 curves.
 <=
/o:p>
2) For each =
curve find largest time interval (T1,T2) which satisfy
voltage tole=
rance of delta from initial and final DC solutions, i.e.<=
/font>
  |(V(T=
1)-Vstart)/VDD|  < Vtol,
  |(V(T=
2)-Vend)/VDD|    < Vtol
where Vtol t=
olerance chosen smaller than IBISCHK's one so the checker=

will not rep=
ort "DC endpoints" warning on trimmed tables latter. All
data points =
outside of this interval (T1,T2) are declared "dead zones" <=
/o:p>
and have no =
importance. So the Vtol value actually plays as "dead zones"=

 <=
/o:p>
definition c=
riteria and should be the parameter to be changed if needed.
 <=
/o:p>
3) For all c=
urves (rising/falling/load) of given corner find the minimum
T1 value, le=
ts define it as T1_typ, T1_slow, T1_fast or T1_<corner>.
 <=
/o:p>
4) Calculate=
 maximum interval dT_max =3D max {|T2-T1_<corner>|} for ALL
curves.=

 <=
/o:p>
5) Shift all=
 curves for given corner left in time by T1_<corner> value.
 <=
/o:p>
6) Truncate =
all curves at time dT_max (from new 0 time after shifting)
 <=
/o:p>
7) Add one p=
oints to end of each curve in order to form a line with zero
slope for ca=
se of some simulators extrapolation will be needed.
 <=
/o:p>
8) Remember,=
 we start from "the best" time resolution, so it is possible=

that we get =
desire time window from overclocking point of view, but
number of po=
ints in final V/T tables still exceeds the maximum allowed
by IBIS spec=
. In this case I suggest to use "greatest change algorithm" =

in order to =
decrease the number of tables points, as it described in<=
/font>
Cookbook (pa=
ges 63-64).
 <=
/o:p>
As the resul=
t, if I have no mistake, we will get "corner time-
correlated&q=
uot; tables. However, across corners correlation is not
guaranteed. =
My assumption is that the user will be interested in
analyzing th=
e buffer's (buffer itself, I mean not control logic but
pullup/pulld=
own devices which actually drive the pad) corner-specific=

behavioral/d=
ifferences, so I at least do not worsen the model quality,
or even impr=
ove it. Anyway,  in some cases there will be no possibility=

to satisfy &=
quot;overclocking free" condition without shifting the corner's
curves one t=
o each other, in other words without trimming different
amounts from=
 different corners.
 <=
/o:p>
Does it make=
 sense? I like to complete realizing this algorithm in perl
and try it o=
n last DDR2 model I produced. Only IBIS simulator I have is
HSpice, so t=
he plan is to compare the behavioral of IBIS model before=

and after tr=
imming. I hope the HSpice is bad enough in "over clocking" <=
/o:p>
scenario, ot=
herwise I will see no difference/improvements anyway :)
 <=
/o:p>
Regards,
  =
  Dmitry
 <=
/o:p>
 <=
/o:p>
Todd Westerh=
off wrote:
  =
Sorry for th= e delay in reply - I took the weekend off ;-)
 <=
/o:p>
As far as no=
n-time correlation between IBIS and transistor models goes
- no, it isn=
't a problem at all.  It's just important that people 
understand w=
hat a model represents and what it doesn't, so that they =

can draw the=
 right conclusions from their simulations.  I was just 
re-iterating=
 one of my favorite points with "time 0 in an IBIS model
  =
  
is arbitrary".
  =
To your poin= t, it's worth noting that time 0 in a spice model-based <= /font>
simulation i=
s often arbitrary as well.  A spice model represents only <=
/span>
the output b=
uffer at most, so if you're analyzing a device with a 
clock-to-out=
 timing specification, you still need to figure out how to
  =
  
 
  =
combine the = delays measured in simulation with the timing spec for the
  =
  
device.
  =
I think peop= le often ascribe too much credibility to spice models.  
The model yo=
u receive is a function of how the netlist and parasitics 
for the buff=
er were extracted - it's far too easy to become confused =

about what p=
art of the overall device the spice model represents.
 <=
/o:p>
As to page 7=
0 of the IBIS cookbook - I agree with what it says.  That <=
/span>
particular p=
age is assuming a DDR device, so that a 100 MHz clock 
yields 200M =
transfers/sec, each with a 5 ns UI.  Let's suppose you 
have a model=
 with a 6ns rising V-T curve for this case.  The simulator<=
/span>
  =
  
 
  =
will trigger= the curve, begin sweeping the output, and then get 
retriggered =
at the 5ns point
- before the=
 rising edge is complete.  What should the simulator do?
 <=
/o:p>
- should it =
just jump to the start of the falling curve (if it does, =

you may get =
a discontinuity on the output that can either glitch the =

output or ca=
use a convergence problem)
 <=
/o:p>
- should the=
 simulator "pipeline" the waveform results, and just <=
/span>
remember the=
 next edge starts 1 ns later - and if the input edges keep
  =
  
 
  =
coming faste= r than the curve length, how long should the simulator 
keep this up=
 before it starts clipping data?
 <=
/o:p>
... my earli=
er point was that the IBIS spec has no guidance on how a =

simulator sh=
ould handle "overclocking" and different simulators DO 
handle this =
issue different ways.  That being the case, it's best to 
avoid the pr=
oblem by complying with the strong recommendation on page=

  =
  
70.
  =
As far as cu= rve trimming goes, allow me to provide a *brief* overview,
  =
  
 
  =
although I'm= sure this subject has been discussed previously.<= /pre>
Pointers int=
o the archive for this subject from others would be
  =
  
appreciated.
  =
Let's consid= er a push-pull output stage instead of open drain - 
open-drain w=
ill just be a simpler case.
 <=
/o:p>
Each output =
should have the following V-T curves
  =

  [Corn=
ers]         x [Edge]  &n=
bsp;          x [Loading]=

 <=
/o:p>
  [Min =
/ Typ / Max] x [Rising / Falling] x [50 ohms GND / 50 ohms
  =
  
VDDQ]
  =
... for a to= tal of 12 sets of V-T curves.  
 <=
/o:p>
... for each=
 [Corner]/[Loading] combination, it is ESSENTIAL that if =

you trim dea=
d time off one curve, you trim the SAME amount of dead 
time off the=
 other.  As an example, if you trim 1ns off the start of 
the [Min]/[R=
ising]/[50 ohms GND] curve, you MUST trim 1ns off the 
[Min]/[Risin=
g]/[50 ohms VDDQ] curve.  If the second curve was already <=
/span>
rising at th=
at point, well, you need to trim less.
<=
font
size=3D2 face=3D"Courier New"> <=
/o:p>
This is what=
's called "time correlation" between curves, and it must 
be maintaine=
d.
 <=
/o:p>
... good pra=
ctice dictates that you coordinate your trimming across <=
/font>
all four of =
the V-T waveforms for any corner.  If you don't do this, 
you'll intro=
duce duty cycle distortion into the simulated waveform 
without mean=
ing to.  I believe this is now considered to be required 
practice.&nb=
sp; So, if you trim 1ns off the start of the [Min]/[Rising]/[50<=
/span>
  =
  
 
  =
ohms GND] cu= rve, you really, really should trim 1ns off the following= 
  =
  
curves:
  =
  [Min]= /[Rising]/[50 ohms VDDQ]
  [Min]=
/[Falling]/[50 ohms GND]
  [Min]=
/[Falling]/[50 ohms VDDQ]
 <=
/o:p>
... so that =
time correlation is maintained across all the [Min] 
curves. =
; As before, if you go to trim any of the curves and find the 
transition w=
as already starting, you need to trim less.
<= pre> <= /o:p>
I don't beli=
eve IBIS requires that you coordinate trimming across
  =
  
corners.
  =
Thus, you ca= n trim different amounts from the [Min] and [Typ] curve
  =
  
sets.
  =
In practice,= you'll find this is useful because if you try to = 
coordinate t=
rimming across a 3 corners, the amount you are able to 
trim may be =
sharply limited.  It's important to understand, though, 
that if you =
trim different amounts from the different corners, the 
time correla=
tion between the corners will be lost.  Strictly speaking,<=
/span>
  =
  
 
  =
that's not a= problem, as time 0 in an IBIS simulation is arbitrary.
HOWEVER - if=
 users of the model simulate the [Min] and [Typ] cases and
  =
  
 
  =
overlay the = results, they will draw incorrect conclusions if they
  =
  
assume the curves are time-correlated.
  =




It probably =
goes without saying, but - you can trim any amount of dead
  =
  
 
  =
time you wan= t off the END of a curve once the slope is zero.  Good 
practice say=
s the last two points should form a line with zero slope, 
so that any =
extrapolation the simulator performs does what you expect.
 <=
/o:p>
As in all mo=
deling - knowing what you've got is the first step in 
understandin=
g what conclusions you can draw.
 <=
/o:p>
Arpad & =
others - please correct me if I've gotten any of this wrong
  =
  
...
  =
Todd.
 <=
/o:p>
Todd Westerh=
off
VP, Software=
 Products
SiSoft<=
/o:p>
6 Clock Tower Place, Suite 250
Maynard, MA  01754
(978) 461-04=
49 x24
twesterh@sisoft.com
www.sisoft.com<=
/pre>
-----Origina=
l Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On 
Behalf Of Di=
mitry Eisenshtat
Sent: Saturd=
ay, January 13, 2007 3:58 AM
To: Todd Wes=
terhoff
Cc: ibis@eda-stds.org; ibis-users@eda.org=

Subject: Re:=
 [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour
 <=
/o:p>
Todd,
ok, we under=
stand that time correlation between IBIS and HSpice is not
  =
  
 
  =
guaranteed, = but is it really problem? I mean, in the most often 
situation th=
ere is no place for such comparison at all, because you <=
/font>
have only IB=
IS model, no spice netlist is available. This is the first
  =
  
 
  =
reason for m= aking IBIS (if simulator speed is not an issue), is it 
right? Lets =
say, I'm with semiconductor vendor side, I have the 
netlist of t=
he buffer, I  make the IBIS model based on spice 
simulations,=
 not lab measurements, so on final step when the model is 
ready I like=
 to check it vs. original spice behavioral. This is the <=
/font>
only situati=
on I agree the comparison is important. But in such case =

there is no =
REAL problem - I know exactly about the delay, and if it =

is the only =
difference between the IBIS & spice - I don't care.
 <=
/o:p>
I want ask y=
ou about IBIS simulator aspect of the point we are talking
  =
  
 
  =
about. Look,= I find in "Cookbook for ver4" strongly recommendation to 
trim IBIS mo=
del time tables at least to half of max buffer frequency =

period. (http://www.v=
hdl.org/pub/ibis/cookbook/cookbook-v4.pdf page 
70,
5.4.2 V-T Ta=
ble Windowing). Can you please prefer from simulator 
software sid=
e - is it really problem for the simulator if the time 
table window=
 is more then such time interval? And one additional 
point, you w=
rote "There are specific restrictions on how the dead time<=
/span>
  =
  
 
  =
may be trimm= ed, which is a longer discussion" - right now I writes 
perl script =
which will trim tables in order to leave only transition =

region and d=
ecrease the time window as the Cookbook recommends to do.=

So, can you =
please explain about these restrictions?
 <= /o:p>
Thanks,=

  Dmitr=
y
 <=
/o:p>
... (previou=
s thread clipped)
 <=
/o:p>
 <=
/o:p>
  =
  
 
 <=
/o:p>
--
  +----=
- -----------------------------------------------------+
  | Dmi=
try Aizenshtat         Circuit Desi=
gn Engineer, NSTA |
  | Tel=
 : 972-9-9702-020         &nbs=
p;     Fax : 972-9-9702-001 |<=
/pre>
  | mailto:dimita@taux01.nsc.com =
;            &n=
bsp;            =
;  |
  +----=
- -----------------------------------------------------+
 <=
/o:p>
 <=
/o:p>
=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=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
The privileg=
ed confidential information contained in this email is
intended for=
 use only by the addressees as indicated by the original<=
/font>
sender of th=
is email. If you are not the addressee indicated in this<=
/font>
email or are=
 not responsible for delivery of the email to such  a
person, plea=
se kindly reply to the sender indicating this fact and
delete all c=
opies of it from your computer and network server<=
/pre>
immediately.=
 Your cooperation is highly appreciated. It is advised that
any unauthor=
ized use of confidential information of Winbond is strictly
prohibited; =
and any information in this email irrelevant to the official
business of =
Winbond shall be deemed as neither given nor endorsed by<=
/font>
Winbond.
 <=
/o:p>
--
This message=
 has been scanned for viruses and dangerous content by
MailScanner,=
 and is believed to be clean.
 <=
/o:p>
 <=
/o:p>
------------=
- --------------------------------------------------------<=
/font>
|For help or=
 to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the ap=
propriate command message(s) in the body:
|=

|  help=

|  subs=
cribe   ibis       <optional e-m=
ail address, if different>
|  subs=
cribe   ibis-users <optional e-mail address, if different><=
o:p>
|  unsu=
bscribe ibis       <optional e-mail addres=
s, if different>
|  unsu=
bscribe ibis-users <optional e-mail address, if different>=

|=

|or e-mail a=
 request to ibis-request@eda-stds.org.
|=

|IBIS reflec=
tor archives exist under:
|=

|  http://www.eda-std=
s.org/pub/ibis/email_archive/ Recent
|  http://www.eda-std=
s.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pu=
b/ibis/email/         E-mail si=
nce 1993
 <=
/o:p>
  =

 


--=20
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_006F_01C83732.3A591BF0-- - -------------------------------------------------------------------- |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 #108 *************************
Amit Kumar,