From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #153 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Wednesday, October 13 2010 Volume 01 : Number 153 ---------------------------------------------------------------------- Date: Wed, 13 Oct 2010 22:52:45 -0500 From: "Baker, Bonnie" Subject: [IBIS-Users]: Using HSPICE to run IBIS model - --_000_9863FC115479184193CC60C8C2F26B10136EE9B7F4dlee04enttico_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am using Hspice to run IBIS and comparing it to a Spice simulation. The S= pice simulates the buffer well but the Hspice program is having problems. M= y buffer type is I/O_open_drain. The circuit diagram is: - ------------- I/O / R=3D0.5 L=3D2,5e-9 Open- /-----------/\/\/\/\-------|------/\_/\_/\_/\---------|---------O = output Drain / | | Buffer / --- ---- - ------------ --- C=3D1e-12 ---- C= =3D5e-12 | = | GND GND The I/O buffer is driven with a rail to rail input signal. The output signa= l does to reach the rail as expected. It actually looks like: - ---------------------expected-output-high----------------------------------= - ---------------- ____= ___ _______/ _______/ _____/ ___/ __/ _/ / / / __/______________________________________________________ I expect - ---------------------expected-and-actual-output-high-----------------------= - --------------------------- / / / / / / / / / / / __/______________________________________________________ It appears as if Hspice does not recognize the fact that this buffer is ope= n drain. Has anyone else experienced this and is the a work around? The Hspice netlist is: * * HSPICED IBIS I/O open drain BUFFER TEST BENCH * Temperature .TEMP 27 * POWER SUPPLIES and SIGNAL VOLTAGES VVCC VCC 0 DC=3DVCC VGND GND 0 DC=3DGND *PARAMETER DEFINITIONS .PARAM GND =3D 0V .PARAM VCC =3D VCC_typ .PARAM VCC_typ =3D 1.8 * Simulation Options .OPTIONS ACCT ACCURATE NOPAGE OPTS POST SCALE=3D1e-6 .OPTIONS METHOD=3DGEAR *=3D=3D=3D=3D=3D=3D=3D=3D=3DTRANSIENT ANALYSIS sim=3D=3D=3D=3D=3D=3D=3D=3D .TRAN 0.1e-9 13000e-9 START =3D0.0e-9 * TD VIN_ibis IN_ibis GND PULSE VCC GND 0ps 0.01ns 0.01ns 149.99ns 300n *******************AC LOAD************** B_IO nd_pu nd_pd Out_ibis IN_ibis nd_en SDA_signal nd_pc nd_gc + file =3D 'tsc2014_nokia_3.ibs' model =3D 'SDA_1' + typ =3D typ power =3D on + buffer =3D 6 + ramp_fwf=3D1 ramp_rwf=3D1 Rpcb Out_ibis n1_pcb 0.50 Lpcb n1_pcb OUT_pcb_ibis 2.5e-9 Cpcb n1_pcb GND 1e-12 Cpcbload OUT_pcb_ibis GND 5e-12 Bonnie - --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - --_000_9863FC115479184193CC60C8C2F26B10136EE9B7F4dlee04enttico_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am using Hspice to run IBIS and comparing it to a Spice simulation. The Spice simulates the buffer well but= the Hspice program is having problems. My buffer type is I/O_open_drain. <= /o:p>

The circuit diagram is:

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

I/O &nb= sp; / = ; R=3D0.5 &n= bsp; L=3D2,5e-9<= /span>

Open- /-----------/\= /\/\/\-------|------/\_/\_/\_/\---------|---------O output

Drain /&= nbsp; &nbs= p; &= nbsp; | &n= bsp; = ; |

Buffer / = &nb= sp; = - --- = &nb= sp; - ----

------------ &n= bsp; = ; - --- C=3D1e-12 &n= bsp; - ---- C=3D5e-12

&n= bsp; = ; &n= bsp; | &n= bsp; = ; |

&n= bsp; = ; &n= bsp; GND = &nb= sp; GND

The I/O buffer is driven with a rail to rail input signal. The output signal does to reach the rail as expected. It= actually looks like:

&n= bsp; = ;

---------------------expected-output-h= igh--------------------------------------------------

&n= bsp; = ; &n= bsp; = ; &n= bsp; = ; _______

&n= bsp; = ; &n= bsp; = ; _______/

&n= bsp; = ; &n= bsp; _______/

&n= bsp; = ; _____/

&n= bsp; ___/

&n= bsp; __/

&n= bsp; _/

&n= bsp; /

/<= /o:p>

__/___________________________________= ___________________

I expect

---------------------expected-and-actu= al-output-high--------------------------------------------------=

&n= bsp; /

/<= /o:p>

__/___________________________________= ___________________

It appears as if Hspice does not recog= nize the fact that this buffer is open drain.

Has anyone else experienced this and is the a work around?

The Hspice netlist is:

* HSPICED IBIS I/O open drain BUFFER T= EST BENCH

* Temperature=

.TEMP 27

* POWER SUPPLIES and SIGNAL VOLTAGES

VVCC &nbs= p; VCC 0 DC=3DVCC

VGND &nbs= p; GND 0 DC=3DGND

*PARAMETER DEFINITIONS

.PARAM GND =3D 0V

.PARAM VCC =3D VCC_typ

.PARAM VCC_typ =3D 1.8

* Simulation Options=

.OPTIONS ACCT ACCURATE NOPAGE OPTS POST SCALE=3D1e-6

.OPTIONS METHOD=3DGEAR &nbs= p;

*=3D=3D=3D=3D=3D=3D=3D=3D=3DTRAN= SIENT ANALYSIS sim=3D=3D=3D=3D=3D=3D=3D=3D

.TRAN 0.1e-9 13000e= - -9 START =3D0.0e-9

* &= nbsp; &nbs= p; &= nbsp; TD

VIN_ibis IN_ibis GND PULSE VCC GND 0ps 0.01ns 0.01ns 149.99ns 300n

*******************AC LOAD************= **

B_IO nd_pu nd_pd Out_ibis IN_ibis nd_en SDA_signal nd_pc nd_gc

+ file =3D 'tsc2014_nokia_3.ibs' model= =3D 'SDA_1'

+ typ =3D typ power =3D on =

+ buffer =3D 6

+ ramp_fwf=3D1 ramp_rwf=3D1=

Rpcb Out_ibis n1_pcb 0.50

Lpcb n1_pcb OUT_pcb_ibis 2.5e-9

Cpcb n1_pcb GND = 1e-12

Cpcbload OUT_pcb_ibis GND 5e-12

<= span style=3D'font-size:12.0pt;color:blue'>

Bonnie

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - --_000_9863FC115479184193CC60C8C2F26B10136EE9B7F4dlee04enttico_-- - -------------------------------------------------------------------- |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, 29 Sep 2010 07:49:24 -0700 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min Lance, Add to that the different values needed some times for high and low states too... In addition, you may also want to consider the different amount of capacitance between the output and the GND or the output and the Power rails. Arpad ============================================= - -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Lance Wang Sent: Wednesday, September 29, 2010 9:45 AM To: 'ibis@server.eda.org'; 'ibis-users' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I would like to echo Bob's comment. Accurate C-comp value is more important nowadays for high-speed buffers. Depending on my knowledge, the biggest inconsistency issue is that IBIS only allows one C-comp value for an I/O buffer. (per corner, of course) If we spell-out with two values for driving and receiving in IBIS, the IBIS simulations will give out more accurate results related to ringing and timing issues. I think it will be a great news especially for high-speed memory buffers. Best regards, Lance Wang 978-764-2298 IO Methodology Inc. www.iometh.com � � - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Haller, Robert Sent: Wednesday, September 29, 2010 8:51 AM To: Bob Ross; Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I always wanted to have separate values of C_COMP for Inputs and Outputs in IO cells because they tend to optimize to slightly different values. In general I found to split the difference or lean toward the input value, particularly on a Multi-load network. Bob - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Wednesday, September 29, 2010 1:33 AM To: Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min All: Thanks Bonnie for your solution to the problem. You comply with IBIS, but provide a comment line for the value-to-corner mapping. That is the best we can do with IBIS today. For consistency for a particular PVT setting, all corner entries for a [Model] should have been for the same PVT conditions. [Model Spec] is already consistent in that respect. I have a number of objections to [Model Corner] proposal. One concern is that the C_comp parameters are related to actual silicon or Spice extraction values, and the other parameters are specification parmeters. overrides, spec. test setups, and limits. C_comp should remain separate. For better consistency, the IBIS committee should have defined a corner aligned C_comp by a keyword [C_comp] like [Pullup], etc. We did decide on a statistical range C_comp because in the early days, buffer to buffer differences due to metalization was a factor. We intend to let the user try different C_comp values to check design robustness. I now believe that was the wrong decision. Bob Baker, Bonnie wrote: > All, > > I had big concerns about this a few months ago. Originally, I was posting my IBIS models from my CMOS devices with the c_comp warnings from the parser. I then chose to list these values in numerical order to get away from those warnings because the IBIS standard and I felt the warnings were red flags to my customer. I have been reading the string over the last few days and I want to share our "solution" to this problem. Embedded in each buffer we have the following text: > > | typ min max > | (nom PVT) (Fast PVT) (slow PVT) > C_comp 9.298e-13 9.221e-13 9.527e-13 > | > | Where nom PVT is Nominal Process, 3.3V, 25C > | Fast PVT is Strong Process, 3.6V, -40C > | Slow PVT is Weak Process, 3.0V, 85C > > > Bonnie Baker > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of > Walter Katz > Sent: Tuesday, September 28, 2010 8:22 AM > To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All, > > What Bob is proposing will work for C_Comp, but will leave all the > other > 100 or so other parameters that have typ min max, that may need typ > slow fast, along with a number of other insonsistant methods of > defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc > are defined by corner in several JEDEC specs, while they are defined with sensitivity in IBIS 5.0. > > We have found that being able to specify parameters by Corner in > addition to Range is an important feature that is used very often in AMI modeling. > > Walter > > -----Original Message----- > From: Bob Ross [mailto:bob@teraspeed.com] > Sent: Monday, September 27, 2010 9:17 PM > To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All: > > The reasons for why we decided at that time to specify C_comp by > numerical value are well stated, and they are quite valid. But the > decision created a consistency mistake because we did not specify > buffer values completely for direct corner correlation. > > I would favor just addressing only the C_comp issue. A simpler > alternate proposal would be to introduce a new model sub-parameter > such as "C_comp_corner" that specifies the value to be used for the > corresponding corner. That would fit in with existing IBIS. > > We could establish rules such as > > C_comp is always required for full range > which could be outside the corner range for > buffer tolerance design and also to provide a > guarenteed support path for all existing tools. > > C_comp_corner is optional for picking a corner value > for direct corner correlation. > > Or we could require one or the other. > > Bob > > > > Walter Katz wrote: > >>All, >> >> >> >>There is a very simple solution to this issue, please review the >>enclosed draft {Model Corner] draft BIRD. >> >> >> >>Walter >> >> >> >>-----Original Message----- >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Mirmak, Michael >>Sent: Monday, September 27, 2010 12:02 PM >>To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>One other item to note: not all device technologies associate a >>numerically-smallest capacitance with the ?fast/strong? process. >> Assuming that CMOS rules universally apply would not have been >>appropriate, and IBIS does not include any notations as to which >>process technology is used in the design for the data presented. >>Without that information or some basic ordering assumption, parsers >>have no means to confirm that the C_comp data had been entered correctly. >> >> >> >>As Arpad states, the only way to have enforceable parsing rules was to >>order the C_comp from numerically-smallest to ?largest, with the >>assumption that the EDA tool would supply the missing information, >>likely from asking the user (for example, the tool might inquire about >>the process used for the IC in question). >> >> >> >>Michael Mirmak >> >>Intel Corp. >> >>Chair, IBIS Open Forum >> >> >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Muranyi, Arpad >>Sent: Monday, September 27, 2010 7:35 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>Fabio, >> >> >> >>The reason you are getting that message is because the die capacitance >> >>does not have a direct relationship with the fast/slow process corners >> >>and when we wrote the IBIS specification we decided that it was best >> >>to just put the small number into the min place and the big number >>into >> >>the max place. It was expected that an EDA tool would allow the user >> >>to try out all possible combinations between min/max curves and C_comp. >> >> >> >>Arpad >> >>====================================================================== >>== >> >> >> >>---------------------------------------------------------------------- >>-- >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Fabio BRINA >>Sent: Monday, September 27, 2010 7:12 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: [IBIS] C_comp Max < C_comp Min >> >>Hello Ibis experts, >> >> >> >> I'm working in CMOS tecnology; >> >> very often in the C_comp extraction I obtain the Min value bigger >>then Max value: >> >> the values come from ac simulations in these conditions: >> >> >> >> C_comp Min value consider: Vcc Min, Process Min, Temp Max >> >> C_comp Max value consider: Vcc Max, Process Max, Temp Min >> >> >> >> The Ibis Check output is: >> >> >> >>WARNING (line 76) - >> >> Model mod1: C_comp min value is not the smallest value listed >> >>WARNING (line 76) - >> >> Model mod1: C_comp max value is not the largest value listed >> >> >> >>Is that situation acceptable? >> >>or I have to switch the Min Value with Max Value? >> >> >> >>... suggestions are welcome ! >> >> >> >>Thank you, >> >>Fabio >> >> >> >> >>-- >>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. >> >> >>-- >>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. > > > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- 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, 29 Sep 2010 08:50:42 -0400 From: "Haller, Robert" Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I always wanted to have separate values of C_COMP for Inputs and Outputs in IO cells because they tend to optimize to slightly different values. In general I found to split the difference or lean toward the input value, particularly on a Multi-load network. Bob - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Wednesday, September 29, 2010 1:33 AM To: Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min All: Thanks Bonnie for your solution to the problem. You comply with IBIS, but provide a comment line for the value-to-corner mapping. That is the best we can do with IBIS today. For consistency for a particular PVT setting, all corner entries for a [Model] should have been for the same PVT conditions. [Model Spec] is already consistent in that respect. I have a number of objections to [Model Corner] proposal. One concern is that the C_comp parameters are related to actual silicon or Spice extraction values, and the other parameters are specification parmeters. overrides, spec. test setups, and limits. C_comp should remain separate. For better consistency, the IBIS committee should have defined a corner aligned C_comp by a keyword [C_comp] like [Pullup], etc. We did decide on a statistical range C_comp because in the early days, buffer to buffer differences due to metalization was a factor. We intend to let the user try different C_comp values to check design robustness. I now believe that was the wrong decision. Bob Baker, Bonnie wrote: > All, > > I had big concerns about this a few months ago. Originally, I was posting my IBIS models from my CMOS devices with the c_comp warnings from the parser. I then chose to list these values in numerical order to get away from those warnings because the IBIS standard and I felt the warnings were red flags to my customer. I have been reading the string over the last few days and I want to share our "solution" to this problem. Embedded in each buffer we have the following text: > > | typ min max > | (nom PVT) (Fast PVT) (slow PVT) > C_comp 9.298e-13 9.221e-13 9.527e-13 > | > | Where nom PVT is Nominal Process, 3.3V, 25C > | Fast PVT is Strong Process, 3.6V, -40C > | Slow PVT is Weak Process, 3.0V, 85C > > > Bonnie Baker > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of > Walter Katz > Sent: Tuesday, September 28, 2010 8:22 AM > To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All, > > What Bob is proposing will work for C_Comp, but will leave all the > other > 100 or so other parameters that have typ min max, that may need typ > slow fast, along with a number of other insonsistant methods of > defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc > are defined by corner in several JEDEC specs, while they are defined with sensitivity in IBIS 5.0. > > We have found that being able to specify parameters by Corner in > addition to Range is an important feature that is used very often in AMI modeling. > > Walter > > -----Original Message----- > From: Bob Ross [mailto:bob@teraspeed.com] > Sent: Monday, September 27, 2010 9:17 PM > To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All: > > The reasons for why we decided at that time to specify C_comp by > numerical value are well stated, and they are quite valid. But the > decision created a consistency mistake because we did not specify > buffer values completely for direct corner correlation. > > I would favor just addressing only the C_comp issue. A simpler > alternate proposal would be to introduce a new model sub-parameter > such as "C_comp_corner" that specifies the value to be used for the > corresponding corner. That would fit in with existing IBIS. > > We could establish rules such as > > C_comp is always required for full range > which could be outside the corner range for > buffer tolerance design and also to provide a > guarenteed support path for all existing tools. > > C_comp_corner is optional for picking a corner value > for direct corner correlation. > > Or we could require one or the other. > > Bob > > > > Walter Katz wrote: > >>All, >> >> >> >>There is a very simple solution to this issue, please review the >>enclosed draft {Model Corner] draft BIRD. >> >> >> >>Walter >> >> >> >>-----Original Message----- >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Mirmak, Michael >>Sent: Monday, September 27, 2010 12:02 PM >>To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>One other item to note: not all device technologies associate a >>numerically-smallest capacitance with the ?fast/strong? process. >> Assuming that CMOS rules universally apply would not have been >>appropriate, and IBIS does not include any notations as to which >>process technology is used in the design for the data presented. >>Without that information or some basic ordering assumption, parsers >>have no means to confirm that the C_comp data had been entered correctly. >> >> >> >>As Arpad states, the only way to have enforceable parsing rules was to >>order the C_comp from numerically-smallest to ?largest, with the >>assumption that the EDA tool would supply the missing information, >>likely from asking the user (for example, the tool might inquire about >>the process used for the IC in question). >> >> >> >>Michael Mirmak >> >>Intel Corp. >> >>Chair, IBIS Open Forum >> >> >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Muranyi, Arpad >>Sent: Monday, September 27, 2010 7:35 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>Fabio, >> >> >> >>The reason you are getting that message is because the die capacitance >> >>does not have a direct relationship with the fast/slow process corners >> >>and when we wrote the IBIS specification we decided that it was best >> >>to just put the small number into the min place and the big number >>into >> >>the max place. It was expected that an EDA tool would allow the user >> >>to try out all possible combinations between min/max curves and C_comp. >> >> >> >>Arpad >> >>====================================================================== >>== >> >> >> >>---------------------------------------------------------------------- >>-- >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Fabio BRINA >>Sent: Monday, September 27, 2010 7:12 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: [IBIS] C_comp Max < C_comp Min >> >>Hello Ibis experts, >> >> >> >> I'm working in CMOS tecnology; >> >> very often in the C_comp extraction I obtain the Min value bigger >>then Max value: >> >> the values come from ac simulations in these conditions: >> >> >> >> C_comp Min value consider: Vcc Min, Process Min, Temp Max >> >> C_comp Max value consider: Vcc Max, Process Max, Temp Min >> >> >> >> The Ibis Check output is: >> >> >> >>WARNING (line 76) - >> >> Model mod1: C_comp min value is not the smallest value listed >> >>WARNING (line 76) - >> >> Model mod1: C_comp max value is not the largest value listed >> >> >> >>Is that situation acceptable? >> >>or I have to switch the Min Value with Max Value? >> >> >> >>... suggestions are welcome ! >> >> >> >>Thank you, >> >>Fabio >> >> >> >> >>-- >>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. >> >> >>-- >>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. > > > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Fri, 01 Oct 2010 14:22:21 -0400 From: Mike LaBonte Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I liked the proposal from some time ago to allow for a passive subcircuit to represent die capacitance. This could model complexities such as frequency dependence. Maybe there is a reasonable way to have it also model state dependence. And the idea looks even better now that we are on the verge of having IBIS-ISS as the circuit language. Mike On 9/30/10 11:17 PM, "Mirmak, Michael" wrote: > Not to "pile on", but should we not consider having voltage- and > frequency-dependent C_comp values? > > This topic has been the subject of various proposals over the years. > > - MM > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of > Lance Wang > Sent: Wednesday, September 29, 2010 8:04 AM > To: 'ibis@server.eda.org'; 'ibis-users' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > Arpad, > Thanks for adding these valid points. > > I was trying to focus on the biggest concern and it was based on my > knowledge only. :) > > Regards, > > Lance Wang > 978-764-2298 > IO Methodology Inc. > www.iometh.com > > > > > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf > Of Muranyi, Arpad > Sent: Wednesday, September 29, 2010 10:49 AM > To: ibis@server.eda.org; ibis-users > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > Lance, > > Add to that the different values needed > some times for high and low states too... > > In addition, you may also want to consider > the different amount of capacitance between > the output and the GND or the output and > the Power rails. > > Arpad > ============================================= > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Lance Wang > Sent: Wednesday, September 29, 2010 9:45 AM > To: 'ibis@server.eda.org'; 'ibis-users' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > I would like to echo Bob's comment. > > Accurate C-comp value is more important nowadays for high-speed buffers. > Depending on my knowledge, the biggest inconsistency issue is that IBIS only > allows one C-comp value for an I/O buffer. (per corner, of course) > > If we spell-out with two values for driving and receiving in IBIS, the IBIS > simulations will give out more accurate results related to ringing and > timing issues. I think it will be a great news especially for high-speed > memory buffers. > > Best regards, > > Lance Wang > 978-764-2298 > IO Methodology Inc. > www.iometh.com > > > > > > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf > Of Haller, Robert > Sent: Wednesday, September 29, 2010 8:51 AM > To: Bob Ross; Baker, Bonnie > Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; > 'ibis-users@server.eda.org' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > I always wanted to have separate values of C_COMP for Inputs and Outputs in > IO cells because they tend to optimize to slightly different values. > In general I found to split the difference or lean toward the input value, > particularly on a Multi-load network. > Bob > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf > Of Bob Ross > Sent: Wednesday, September 29, 2010 1:33 AM > To: Baker, Bonnie > Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; > 'ibis-users@server.eda.org' > Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All: > > Thanks Bonnie for your solution to the problem. You comply with IBIS, but > provide a comment line for the value-to-corner mapping. That is the best we > can do with IBIS today. > > For consistency for a particular PVT setting, all corner entries for a > [Model] should have been for the same PVT conditions. [Model Spec] is > already consistent in that respect. > > I have a number of objections to [Model Corner] proposal. One concern is > that the C_comp parameters are related to actual silicon or Spice extraction > values, and the other parameters are specification parmeters. overrides, > spec. test setups, and limits. C_comp should remain separate. > > For better consistency, the IBIS committee should have defined a corner > aligned C_comp by a keyword [C_comp] like [Pullup], etc. > > We did decide on a statistical range C_comp because in the early days, > buffer to buffer differences due to metalization was a factor. We intend to > let the user try different C_comp values to check design robustness. I now > believe that was the wrong decision. > > Bob > > Baker, Bonnie wrote: >> All, >> >> I had big concerns about this a few months ago. Originally, I was posting > my IBIS models from my CMOS devices with the c_comp warnings from the > parser. I then chose to list these values in numerical order to get away > from those warnings because the IBIS standard and I felt the warnings were > red flags to my customer. I have been reading the string over the last few > days and I want to share our "solution" to this problem. Embedded in each > buffer we have the following text: >> >> | typ min max >> | (nom PVT) (Fast PVT) (slow PVT) >> C_comp 9.298e-13 9.221e-13 9.527e-13 >> | >> | Where nom PVT is Nominal Process, 3.3V, 25C >> | Fast PVT is Strong Process, 3.6V, -40C >> | Slow PVT is Weak Process, 3.0V, 85C >> >> >> Bonnie Baker >> >> -----Original Message----- >> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >> Walter Katz >> Sent: Tuesday, September 28, 2010 8:22 AM >> To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' >> Cc: 'ibis-users@server.eda.org' >> Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min >> >> All, >> >> What Bob is proposing will work for C_Comp, but will leave all the >> other >> 100 or so other parameters that have typ min max, that may need typ >> slow fast, along with a number of other insonsistant methods of >> defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc >> are defined by corner in several JEDEC specs, while they are defined with > sensitivity in IBIS 5.0. >> >> We have found that being able to specify parameters by Corner in >> addition to Range is an important feature that is used very often in AMI > modeling. >> >> Walter >> >> -----Original Message----- >> From: Bob Ross [mailto:bob@teraspeed.com] >> Sent: Monday, September 27, 2010 9:17 PM >> To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; > 'ibis@server.eda.org' >> Cc: 'ibis-users@server.eda.org' >> Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min >> >> All: >> >> The reasons for why we decided at that time to specify C_comp by >> numerical value are well stated, and they are quite valid. But the >> decision created a consistency mistake because we did not specify >> buffer values completely for direct corner correlation. >> >> I would favor just addressing only the C_comp issue. A simpler >> alternate proposal would be to introduce a new model sub-parameter >> such as "C_comp_corner" that specifies the value to be used for the >> corresponding corner. That would fit in with existing IBIS. >> >> We could establish rules such as >> >> C_comp is always required for full range >> which could be outside the corner range for >> buffer tolerance design and also to provide a >> guarenteed support path for all existing tools. >> >> C_comp_corner is optional for picking a corner value >> for direct corner correlation. >> >> Or we could require one or the other. >> >> Bob >> >> >> >> Walter Katz wrote: >> >>> All, >>> >>> >>> >>> There is a very simple solution to this issue, please review the >>> enclosed draft {Model Corner] draft BIRD. >>> >>> >>> >>> Walter >>> >>> >>> >>> -----Original Message----- >>> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>> Mirmak, Michael >>> Sent: Monday, September 27, 2010 12:02 PM >>> To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org >>> Subject: RE: [IBIS] C_comp Max < C_comp Min >>> >>> >>> >>> One other item to note: not all device technologies associate a >>> numerically-smallest capacitance with the ?fast/strong? process. >>> Assuming that CMOS rules universally apply would not have been >>> appropriate, and IBIS does not include any notations as to which >>> process technology is used in the design for the data presented. >>> Without that information or some basic ordering assumption, parsers >>> have no means to confirm that the C_comp data had been entered correctly. >>> >>> >>> >>> As Arpad states, the only way to have enforceable parsing rules was to >>> order the C_comp from numerically-smallest to ?largest, with the >>> assumption that the EDA tool would supply the missing information, >>> likely from asking the user (for example, the tool might inquire about >>> the process used for the IC in question). >>> >>> >>> >>> Michael Mirmak >>> >>> Intel Corp. >>> >>> Chair, IBIS Open Forum >>> >>> >>> >>> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>> Muranyi, Arpad >>> Sent: Monday, September 27, 2010 7:35 AM >>> To: ibis@server.eda.org; ibis-users@server.eda.org >>> Subject: RE: [IBIS] C_comp Max < C_comp Min >>> >>> >>> >>> Fabio, >>> >>> >>> >>> The reason you are getting that message is because the die capacitance >>> >>> does not have a direct relationship with the fast/slow process corners >>> >>> and when we wrote the IBIS specification we decided that it was best >>> >>> to just put the small number into the min place and the big number >>> into >>> >>> the max place. It was expected that an EDA tool would allow the user >>> >>> to try out all possible combinations between min/max curves and C_comp. >>> >>> >>> >>> Arpad >>> >>> ====================================================================== >>> == >>> >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>> Fabio BRINA >>> Sent: Monday, September 27, 2010 7:12 AM >>> To: ibis@server.eda.org; ibis-users@server.eda.org >>> Subject: [IBIS] C_comp Max < C_comp Min >>> >>> Hello Ibis experts, >>> >>> >>> >>> I'm working in CMOS tecnology; >>> >>> very often in the C_comp extraction I obtain the Min value bigger >>> then Max value: >>> >>> the values come from ac simulations in these conditions: >>> >>> >>> >>> C_comp Min value consider: Vcc Min, Process Min, Temp Max >>> >>> C_comp Max value consider: Vcc Max, Process Max, Temp Min >>> >>> >>> >>> The Ibis Check output is: >>> >>> >>> >>> WARNING (line 76) - >>> >>> Model mod1: C_comp min value is not the smallest value listed >>> >>> WARNING (line 76) - >>> >>> Model mod1: C_comp max value is not the largest value listed >>> >>> >>> >>> Is that situation acceptable? >>> >>> or I have to switch the Min Value with Max Value? >>> >>> >>> >>> ... suggestions are welcome ! >>> >>> >>> >>> Thank you, >>> >>> Fabio >>> >>> >>> >>> >>> -- >>> 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. >>> >>> >>> -- >>> 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. >> >> >> > > > -- > Bob Ross > Teraspeed Consulting Group LLC Teraspeed Labs > 121 North River Drive 13610 SW Harness Lane > Narragansett, RI 02882 Beaverton, OR 97008 > 401-284-1827 503-430-1065 > http://www.teraspeed.com 503-246-8048 Direct > bob@teraspeed.com > > Teraspeed is a registered service mark of Teraspeed Consulting Group LLC > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 30 Sep 2010 22:33:02 -0700 From: Bob Ross Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min Michael: To add, one proposal documented as BIRD79 with 24 new subparameters was considered and rejected. A number of different ideas already are on the table, which require up to 10 new/relocated sub-parameters (adding a separate driving and non-driving C_comp), or a global re-mapping method for all C_comp entries from by-value to by corner (usually just sybollically interchanging min and max). Bob Just dealing with some of the primary issues has Mirmak, Michael wrote: > Not to "pile on", but should we not consider having voltage- and frequency-dependent C_comp values? > > This topic has been the subject of various proposals over the years. > > - MM > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Lance Wang > Sent: Wednesday, September 29, 2010 8:04 AM > To: 'ibis@server.eda.org'; 'ibis-users' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > Arpad, > Thanks for adding these valid points. > > I was trying to focus on the biggest concern and it was based on my > knowledge only. :) > > Regards, > > Lance Wang > 978-764-2298 > IO Methodology Inc. > www.iometh.com > > > > > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf > Of Muranyi, Arpad > Sent: Wednesday, September 29, 2010 10:49 AM > To: ibis@server.eda.org; ibis-users > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > Lance, > > Add to that the different values needed > some times for high and low states too... > > In addition, you may also want to consider > the different amount of capacitance between > the output and the GND or the output and > the Power rails. > > Arpad > ============================================= > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Lance Wang > Sent: Wednesday, September 29, 2010 9:45 AM > To: 'ibis@server.eda.org'; 'ibis-users' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > I would like to echo Bob's comment. > > Accurate C-comp value is more important nowadays for high-speed buffers. > Depending on my knowledge, the biggest inconsistency issue is that IBIS only > allows one C-comp value for an I/O buffer. (per corner, of course) > > If we spell-out with two values for driving and receiving in IBIS, the IBIS > simulations will give out more accurate results related to ringing and > timing issues. I think it will be a great news especially for high-speed > memory buffers. > > Best regards, > > Lance Wang > 978-764-2298 > IO Methodology Inc. > www.iometh.com > > > > > > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf > Of Haller, Robert > Sent: Wednesday, September 29, 2010 8:51 AM > To: Bob Ross; Baker, Bonnie > Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; > 'ibis-users@server.eda.org' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > I always wanted to have separate values of C_COMP for Inputs and Outputs in > IO cells because they tend to optimize to slightly different values. > In general I found to split the difference or lean toward the input value, > particularly on a Multi-load network. > Bob > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf > Of Bob Ross > Sent: Wednesday, September 29, 2010 1:33 AM > To: Baker, Bonnie > Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; > 'ibis-users@server.eda.org' > Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All: > > Thanks Bonnie for your solution to the problem. You comply with IBIS, but > provide a comment line for the value-to-corner mapping. That is the best we > can do with IBIS today. > > For consistency for a particular PVT setting, all corner entries for a > [Model] should have been for the same PVT conditions. [Model Spec] is > already consistent in that respect. > > I have a number of objections to [Model Corner] proposal. One concern is > that the C_comp parameters are related to actual silicon or Spice extraction > values, and the other parameters are specification parmeters. overrides, > spec. test setups, and limits. C_comp should remain separate. > > For better consistency, the IBIS committee should have defined a corner > aligned C_comp by a keyword [C_comp] like [Pullup], etc. > > We did decide on a statistical range C_comp because in the early days, > buffer to buffer differences due to metalization was a factor. We intend to > let the user try different C_comp values to check design robustness. I now > believe that was the wrong decision. > > Bob > > Baker, Bonnie wrote: > >>All, >> >>I had big concerns about this a few months ago. Originally, I was posting > > my IBIS models from my CMOS devices with the c_comp warnings from the > parser. I then chose to list these values in numerical order to get away > from those warnings because the IBIS standard and I felt the warnings were > red flags to my customer. I have been reading the string over the last few > days and I want to share our "solution" to this problem. Embedded in each > buffer we have the following text: > >>| typ min max >>| (nom PVT) (Fast PVT) (slow PVT) >>C_comp 9.298e-13 9.221e-13 9.527e-13 >>| >>| Where nom PVT is Nominal Process, 3.3V, 25C >>| Fast PVT is Strong Process, 3.6V, -40C >>| Slow PVT is Weak Process, 3.0V, 85C >> >> >>Bonnie Baker >> >>-----Original Message----- >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Walter Katz >>Sent: Tuesday, September 28, 2010 8:22 AM >>To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' >>Cc: 'ibis-users@server.eda.org' >>Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min >> >>All, >> >>What Bob is proposing will work for C_Comp, but will leave all the >>other >>100 or so other parameters that have typ min max, that may need typ >>slow fast, along with a number of other insonsistant methods of >>defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc >>are defined by corner in several JEDEC specs, while they are defined with > > sensitivity in IBIS 5.0. > >>We have found that being able to specify parameters by Corner in >>addition to Range is an important feature that is used very often in AMI > > modeling. > >>Walter >> >>-----Original Message----- >>From: Bob Ross [mailto:bob@teraspeed.com] >>Sent: Monday, September 27, 2010 9:17 PM >>To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; > > 'ibis@server.eda.org' > >>Cc: 'ibis-users@server.eda.org' >>Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min >> >>All: >> >>The reasons for why we decided at that time to specify C_comp by >>numerical value are well stated, and they are quite valid. But the >>decision created a consistency mistake because we did not specify >>buffer values completely for direct corner correlation. >> >>I would favor just addressing only the C_comp issue. A simpler >>alternate proposal would be to introduce a new model sub-parameter >>such as "C_comp_corner" that specifies the value to be used for the >>corresponding corner. That would fit in with existing IBIS. >> >>We could establish rules such as >> >> C_comp is always required for full range >> which could be outside the corner range for >> buffer tolerance design and also to provide a >> guarenteed support path for all existing tools. >> >> C_comp_corner is optional for picking a corner value >> for direct corner correlation. >> >>Or we could require one or the other. >> >>Bob >> >> >> >>Walter Katz wrote: >> >> >>>All, >>> >>> >>> >>>There is a very simple solution to this issue, please review the >>>enclosed draft {Model Corner] draft BIRD. >>> >>> >>> >>>Walter >>> >>> >>> >>>-----Original Message----- >>>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>>Mirmak, Michael >>>Sent: Monday, September 27, 2010 12:02 PM >>>To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org >>>Subject: RE: [IBIS] C_comp Max < C_comp Min >>> >>> >>> >>>One other item to note: not all device technologies associate a >>>numerically-smallest capacitance with the ?fast/strong? process. >>>Assuming that CMOS rules universally apply would not have been >>>appropriate, and IBIS does not include any notations as to which >>>process technology is used in the design for the data presented. >>>Without that information or some basic ordering assumption, parsers >>>have no means to confirm that the C_comp data had been entered correctly. >>> >>> >>> >>>As Arpad states, the only way to have enforceable parsing rules was to >>>order the C_comp from numerically-smallest to ?largest, with the >>>assumption that the EDA tool would supply the missing information, >>>likely from asking the user (for example, the tool might inquire about >>>the process used for the IC in question). >>> >>> >>> >>>Michael Mirmak >>> >>>Intel Corp. >>> >>>Chair, IBIS Open Forum >>> >>> >>> >>>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>>Muranyi, Arpad >>>Sent: Monday, September 27, 2010 7:35 AM >>>To: ibis@server.eda.org; ibis-users@server.eda.org >>>Subject: RE: [IBIS] C_comp Max < C_comp Min >>> >>> >>> >>>Fabio, >>> >>> >>> >>>The reason you are getting that message is because the die capacitance >>> >>>does not have a direct relationship with the fast/slow process corners >>> >>>and when we wrote the IBIS specification we decided that it was best >>> >>>to just put the small number into the min place and the big number >>>into >>> >>>the max place. It was expected that an EDA tool would allow the user >>> >>>to try out all possible combinations between min/max curves and C_comp. >>> >>> >>> >>>Arpad >>> >>>====================================================================== >>>== >>> >>> >>> >>>---------------------------------------------------------------------- >>>-- >>> >>>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>>Fabio BRINA >>>Sent: Monday, September 27, 2010 7:12 AM >>>To: ibis@server.eda.org; ibis-users@server.eda.org >>>Subject: [IBIS] C_comp Max < C_comp Min >>> >>>Hello Ibis experts, >>> >>> >>> >>>I'm working in CMOS tecnology; >>> >>>very often in the C_comp extraction I obtain the Min value bigger >>>then Max value: >>> >>>the values come from ac simulations in these conditions: >>> >>> >>> >>>C_comp Min value consider: Vcc Min, Process Min, Temp Max >>> >>>C_comp Max value consider: Vcc Max, Process Max, Temp Min >>> >>> >>> >>>The Ibis Check output is: >>> >>> >>> >>>WARNING (line 76) - >>> >>> Model mod1: C_comp min value is not the smallest value listed >>> >>>WARNING (line 76) - >>> >>> Model mod1: C_comp max value is not the largest value listed >>> >>> >>> >>>Is that situation acceptable? >>> >>>or I have to switch the Min Value with Max Value? >>> >>> >>> >>>... suggestions are welcome ! >>> >>> >>> >>>Thank you, >>> >>>Fabio >>> >>> >>> >>> >>>-- >>>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. >>> >>> >>>-- >>>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. >> >> >> > > > -- > Bob Ross > Teraspeed Consulting Group LLC Teraspeed Labs > 121 North River Drive 13610 SW Harness Lane > Narragansett, RI 02882 Beaverton, OR 97008 > 401-284-1827 503-430-1065 > http://www.teraspeed.com 503-246-8048 Direct > bob@teraspeed.com > > Teraspeed is a registered service mark of Teraspeed Consulting Group LLC > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > > -- > 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 > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 30 Sep 2010 21:17:10 -0600 From: "Mirmak, Michael" Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min Not to "pile on", but should we not consider having voltage- and frequency-dependent C_comp values? This topic has been the subject of various proposals over the years. - - MM - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Lance Wang Sent: Wednesday, September 29, 2010 8:04 AM To: 'ibis@server.eda.org'; 'ibis-users' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min Arpad, Thanks for adding these valid points. I was trying to focus on the biggest concern and it was based on my knowledge only. :) Regards, Lance Wang 978-764-2298 IO Methodology Inc. www.iometh.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad Sent: Wednesday, September 29, 2010 10:49 AM To: ibis@server.eda.org; ibis-users Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min Lance, Add to that the different values needed some times for high and low states too... In addition, you may also want to consider the different amount of capacitance between the output and the GND or the output and the Power rails. Arpad ============================================= - -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Lance Wang Sent: Wednesday, September 29, 2010 9:45 AM To: 'ibis@server.eda.org'; 'ibis-users' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I would like to echo Bob's comment. Accurate C-comp value is more important nowadays for high-speed buffers. Depending on my knowledge, the biggest inconsistency issue is that IBIS only allows one C-comp value for an I/O buffer. (per corner, of course) If we spell-out with two values for driving and receiving in IBIS, the IBIS simulations will give out more accurate results related to ringing and timing issues. I think it will be a great news especially for high-speed memory buffers. Best regards, Lance Wang 978-764-2298 IO Methodology Inc. www.iometh.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Haller, Robert Sent: Wednesday, September 29, 2010 8:51 AM To: Bob Ross; Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I always wanted to have separate values of C_COMP for Inputs and Outputs in IO cells because they tend to optimize to slightly different values. In general I found to split the difference or lean toward the input value, particularly on a Multi-load network. Bob - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Wednesday, September 29, 2010 1:33 AM To: Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min All: Thanks Bonnie for your solution to the problem. You comply with IBIS, but provide a comment line for the value-to-corner mapping. That is the best we can do with IBIS today. For consistency for a particular PVT setting, all corner entries for a [Model] should have been for the same PVT conditions. [Model Spec] is already consistent in that respect. I have a number of objections to [Model Corner] proposal. One concern is that the C_comp parameters are related to actual silicon or Spice extraction values, and the other parameters are specification parmeters. overrides, spec. test setups, and limits. C_comp should remain separate. For better consistency, the IBIS committee should have defined a corner aligned C_comp by a keyword [C_comp] like [Pullup], etc. We did decide on a statistical range C_comp because in the early days, buffer to buffer differences due to metalization was a factor. We intend to let the user try different C_comp values to check design robustness. I now believe that was the wrong decision. Bob Baker, Bonnie wrote: > All, > > I had big concerns about this a few months ago. Originally, I was posting my IBIS models from my CMOS devices with the c_comp warnings from the parser. I then chose to list these values in numerical order to get away from those warnings because the IBIS standard and I felt the warnings were red flags to my customer. I have been reading the string over the last few days and I want to share our "solution" to this problem. Embedded in each buffer we have the following text: > > | typ min max > | (nom PVT) (Fast PVT) (slow PVT) > C_comp 9.298e-13 9.221e-13 9.527e-13 > | > | Where nom PVT is Nominal Process, 3.3V, 25C > | Fast PVT is Strong Process, 3.6V, -40C > | Slow PVT is Weak Process, 3.0V, 85C > > > Bonnie Baker > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of > Walter Katz > Sent: Tuesday, September 28, 2010 8:22 AM > To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All, > > What Bob is proposing will work for C_Comp, but will leave all the > other > 100 or so other parameters that have typ min max, that may need typ > slow fast, along with a number of other insonsistant methods of > defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc > are defined by corner in several JEDEC specs, while they are defined with sensitivity in IBIS 5.0. > > We have found that being able to specify parameters by Corner in > addition to Range is an important feature that is used very often in AMI modeling. > > Walter > > -----Original Message----- > From: Bob Ross [mailto:bob@teraspeed.com] > Sent: Monday, September 27, 2010 9:17 PM > To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All: > > The reasons for why we decided at that time to specify C_comp by > numerical value are well stated, and they are quite valid. But the > decision created a consistency mistake because we did not specify > buffer values completely for direct corner correlation. > > I would favor just addressing only the C_comp issue. A simpler > alternate proposal would be to introduce a new model sub-parameter > such as "C_comp_corner" that specifies the value to be used for the > corresponding corner. That would fit in with existing IBIS. > > We could establish rules such as > > C_comp is always required for full range > which could be outside the corner range for > buffer tolerance design and also to provide a > guarenteed support path for all existing tools. > > C_comp_corner is optional for picking a corner value > for direct corner correlation. > > Or we could require one or the other. > > Bob > > > > Walter Katz wrote: > >>All, >> >> >> >>There is a very simple solution to this issue, please review the >>enclosed draft {Model Corner] draft BIRD. >> >> >> >>Walter >> >> >> >>-----Original Message----- >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Mirmak, Michael >>Sent: Monday, September 27, 2010 12:02 PM >>To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>One other item to note: not all device technologies associate a >>numerically-smallest capacitance with the ?fast/strong? process. >> Assuming that CMOS rules universally apply would not have been >>appropriate, and IBIS does not include any notations as to which >>process technology is used in the design for the data presented. >>Without that information or some basic ordering assumption, parsers >>have no means to confirm that the C_comp data had been entered correctly. >> >> >> >>As Arpad states, the only way to have enforceable parsing rules was to >>order the C_comp from numerically-smallest to ?largest, with the >>assumption that the EDA tool would supply the missing information, >>likely from asking the user (for example, the tool might inquire about >>the process used for the IC in question). >> >> >> >>Michael Mirmak >> >>Intel Corp. >> >>Chair, IBIS Open Forum >> >> >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Muranyi, Arpad >>Sent: Monday, September 27, 2010 7:35 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>Fabio, >> >> >> >>The reason you are getting that message is because the die capacitance >> >>does not have a direct relationship with the fast/slow process corners >> >>and when we wrote the IBIS specification we decided that it was best >> >>to just put the small number into the min place and the big number >>into >> >>the max place. It was expected that an EDA tool would allow the user >> >>to try out all possible combinations between min/max curves and C_comp. >> >> >> >>Arpad >> >>====================================================================== >>== >> >> >> >>---------------------------------------------------------------------- >>-- >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Fabio BRINA >>Sent: Monday, September 27, 2010 7:12 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: [IBIS] C_comp Max < C_comp Min >> >>Hello Ibis experts, >> >> >> >> I'm working in CMOS tecnology; >> >> very often in the C_comp extraction I obtain the Min value bigger >>then Max value: >> >> the values come from ac simulations in these conditions: >> >> >> >> C_comp Min value consider: Vcc Min, Process Min, Temp Max >> >> C_comp Max value consider: Vcc Max, Process Max, Temp Min >> >> >> >> The Ibis Check output is: >> >> >> >>WARNING (line 76) - >> >> Model mod1: C_comp min value is not the smallest value listed >> >>WARNING (line 76) - >> >> Model mod1: C_comp max value is not the largest value listed >> >> >> >>Is that situation acceptable? >> >>or I have to switch the Min Value with Max Value? >> >> >> >>... suggestions are welcome ! >> >> >> >>Thank you, >> >>Fabio >> >> >> >> >>-- >>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. >> >> >>-- >>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. > > > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 05 Oct 2010 14:26:00 -0700 From: Bob Ross Subject: [IBIS-Users] [SI-LIST] Asian IBIS Summit (China) - Fifth Announcement To All: The IBIS Open Forum is holding an Asian IBIS Summit Meeting in Shenzhen, China, a major technology center on Tuesday, November 9, 2010. Up to 10 presentations or topics are listed below. A few more are expected. Several of these will be given at the other Asian Summits. Several companies listed below are co-sponsoring this large event to be held at the Four Points by Sheraton, Shenzhen. Like in previous years, we are planning for a large number of attendees including several IBIS experts from the USA. We encourage technical contributions from Asia. We expect a full agenda of relevant material. For travel consideration, two other Asian IBIS Summits follow this event: Taipei, Taiwan, Friday, November 12, Sherwood Hotel Tokyo, Japan, Monday, November 15, JEITA headquarters Bob Ross Teraspeed Consulting Group Lance Wang IO Methodology Inc. - ----------------------------------------------------------------------- ASIAN IBIS SUMMIT (CHINA) FIFTH CALL FOR PARTICIPATION AND PRESENTATIONS - ----------------------------------------------------------------------- http://www.eda.org/pub/ibis/summits/nov10a/announcement_chinese.pdf ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A S I A N I B I S S U M M I T ( C H I N A ) Time/Date: Tuesday, November 9, 2010, 8:00 AM to 5:30 PM Meeting starts at 9:00 AM Location: Four Points by Sheraton 5 Guihua Road Futian Free Trade Zone Shenzhen, Guangdong 518038 P. R. China http://www.starwoodhotels.com/fourpoints/property/overview/index.html?propertyID=1489& EM=VTY_FP_1489_shenzhen_overview or http://tinyurl.com/2s6esb Content: Presentations and Discussions Purpose: Solicit and exchange IBIS and interconnect model related information and ideas. Primary Sponsor: Huawei Technologies Co-sponsors (in alphabetical order): Agilent Technologies, Ansoft Corporation, Cadence Design Systems, Cybernet, Intel Corporation, IO Methodology, Mentor Graphics Corporation, Signal Integrity Software (SiSoft), Sigrity, Synopsys, and ZTE Corporation. Cost: FREE, including refreshments and buffet lunch Vendors: Some vendors will have information tables outside the meeting room Contact us for details regarding sponsorship. BACKGROUND We have held five successful meetings in Shenzhen, Shanghai and Beijing. This year we are meeting again in Shenzhen where many Chinese and foreign high technology companies operate. These events are archived along with all our other Summits: http://www.eda.org/pub/ibis/summits/ Our objective is to reach out internationally to communicate with the local experts and to learn of regional concerns. CONFERENCE LANGUAGE The conference language is English, but we will plan for technical translations in English and Chinese. So presenters can optionally deliver in Chinese as long as an English version of the material is available. IBIS SUMMIT This meeting will be conducted as a formal IBIS Summit Meeting. Presentations will be archived in an electronic format on our Summits site, and minutes of the meeting will be issued. However, no formal decisions requiring votes will be planned. CALL FOR PARTICIPANTS People involved in IBIS and interconnect model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register using the information below (in English): Name: E-mail address: Company: Top-level Web Link: Country: Telephone: Comments: (Such as assistance for the travel requirements at the end) Send to BOTH: Bob Ross, Teraspeed Consulting Group bob@teraspeed.com Lance Wang, IO Methology Inc. lwang@iometh.com SIGNUP DEADLINE: November 4, 2010 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS and interconnect modeling experiences or issues. If we have to select presentations for the number of time slots available, we will give preferential consideration to presentations from Asia. Presentation Format: LCD Projection from meeting laptop computer Time: 15-30 Minutes including questions Electronic Archival: All presentations will uploaded to our public IBIS Summit archives Electronic Format: Power Point or Acrobat Presentation Booklet: Available at the meeting for all attendees Presentation Deadline: October 12, 2010 to produce the presentation booklet for the meeting If you plan a presentation, please ADD to the above registration information: Title of Presentation: Estimated Time: (30 minutes or less) We will notify you of acceptance and may follow up with questions when we form the program agenda. Note: Vendor promotional or business information is prohibited. Submitted presentations must be in English, although the delivery can be in Mandarin. Submissions from Asia are encouraged along with other submissions world-wide. Topics may include behavioral modeling of buffers, interconnects or other system components. AGENDA 8:15 - 9:00 Vendor table setup and tables 8:30 - 9:00 Sign in 9:00 - 12:00 Presentations 12:00 - 13:30 Free buffet lunch, vendor tables 13:30 - 17:00 Presentations The specific agenda is being developed. We expect nine or ten presentations covering a range of issues from existing customer experiences, existing clarifications and some future technical directions in IBIS. Several major IBIS Committee presentations from IBIS officers or active members are planned. Several presentations on IBIS applications and behavioral modeling issues, including interconnects, and system components are expected from co-sponsor companies and/or their customers. Tentative Titles or Topics: Intel Corporation: IBIS Chair Introduction topic IBIS-ISS topic Agilent Technologies: "Automated AMI Model Generation & Validation" Huawei Technologies: "Modeling the Loop Inductance of High Frequency Capacitance and Analyzing Capacitance' Global Decouple Effect" IO Methodology: "Point Reduction Method for IBIS Curves" Cadence Design Systems and Sigrity: "Model Connection Protocol Extensions for Mixed Signal SiP" Flextronics and Cadence Design Systems: "Extending/Leveraging IBIS Constructs to Model High-Speed I/Os and Packages using AMI, Spice, and S-Parameters" Sigrity: BIRD95 Power Integrity Analysis Using IBIS topic ZTE Corporation: "IBIS-AMI Simulation for High-Speed System Design" OR/AND "Modeling Methods for Complex S-parameters in Touchstone 2.0" LIST OF NEARBY HOTELS AND TRAVEL RULES Hotels in all price ranges can be found through internet searches. Comply with your travel rules, such as indicated in the link below to China and Shenzhen. Work with your travel agent. Notify us as a sign-up comment if you need assistance. Visas, if needed, should fall in the visit/business category: http://travel.state.gov/travel/cis_pa_tw/cis/cis_1089.html - ----------------------------------------------------------------- - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@freelists.org with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: http://www.freelists.org/webpage/si-list For help: si-list-request@freelists.org with 'help' in the Subject field List technical documents are available at: http://www.si-list.net List archives are viewable at: http://www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu - -- 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, 29 Sep 2010 11:04:20 -0400 From: "Lance Wang" Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min Arpad, Thanks for adding these valid points. I was trying to focus on the biggest concern and it was based on my knowledge only. :) Regards, Lance Wang 978-764-2298 IO Methodology Inc. www.iometh.com � � - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad Sent: Wednesday, September 29, 2010 10:49 AM To: ibis@server.eda.org; ibis-users Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min Lance, Add to that the different values needed some times for high and low states too... In addition, you may also want to consider the different amount of capacitance between the output and the GND or the output and the Power rails. Arpad ============================================= - -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Lance Wang Sent: Wednesday, September 29, 2010 9:45 AM To: 'ibis@server.eda.org'; 'ibis-users' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I would like to echo Bob's comment. Accurate C-comp value is more important nowadays for high-speed buffers. Depending on my knowledge, the biggest inconsistency issue is that IBIS only allows one C-comp value for an I/O buffer. (per corner, of course) If we spell-out with two values for driving and receiving in IBIS, the IBIS simulations will give out more accurate results related to ringing and timing issues. I think it will be a great news especially for high-speed memory buffers. Best regards, Lance Wang 978-764-2298 IO Methodology Inc. www.iometh.com � � - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Haller, Robert Sent: Wednesday, September 29, 2010 8:51 AM To: Bob Ross; Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I always wanted to have separate values of C_COMP for Inputs and Outputs in IO cells because they tend to optimize to slightly different values. In general I found to split the difference or lean toward the input value, particularly on a Multi-load network. Bob - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Wednesday, September 29, 2010 1:33 AM To: Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min All: Thanks Bonnie for your solution to the problem. You comply with IBIS, but provide a comment line for the value-to-corner mapping. That is the best we can do with IBIS today. For consistency for a particular PVT setting, all corner entries for a [Model] should have been for the same PVT conditions. [Model Spec] is already consistent in that respect. I have a number of objections to [Model Corner] proposal. One concern is that the C_comp parameters are related to actual silicon or Spice extraction values, and the other parameters are specification parmeters. overrides, spec. test setups, and limits. C_comp should remain separate. For better consistency, the IBIS committee should have defined a corner aligned C_comp by a keyword [C_comp] like [Pullup], etc. We did decide on a statistical range C_comp because in the early days, buffer to buffer differences due to metalization was a factor. We intend to let the user try different C_comp values to check design robustness. I now believe that was the wrong decision. Bob Baker, Bonnie wrote: > All, > > I had big concerns about this a few months ago. Originally, I was posting my IBIS models from my CMOS devices with the c_comp warnings from the parser. I then chose to list these values in numerical order to get away from those warnings because the IBIS standard and I felt the warnings were red flags to my customer. I have been reading the string over the last few days and I want to share our "solution" to this problem. Embedded in each buffer we have the following text: > > | typ min max > | (nom PVT) (Fast PVT) (slow PVT) > C_comp 9.298e-13 9.221e-13 9.527e-13 > | > | Where nom PVT is Nominal Process, 3.3V, 25C > | Fast PVT is Strong Process, 3.6V, -40C > | Slow PVT is Weak Process, 3.0V, 85C > > > Bonnie Baker > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of > Walter Katz > Sent: Tuesday, September 28, 2010 8:22 AM > To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All, > > What Bob is proposing will work for C_Comp, but will leave all the > other > 100 or so other parameters that have typ min max, that may need typ > slow fast, along with a number of other insonsistant methods of > defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc > are defined by corner in several JEDEC specs, while they are defined with sensitivity in IBIS 5.0. > > We have found that being able to specify parameters by Corner in > addition to Range is an important feature that is used very often in AMI modeling. > > Walter > > -----Original Message----- > From: Bob Ross [mailto:bob@teraspeed.com] > Sent: Monday, September 27, 2010 9:17 PM > To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All: > > The reasons for why we decided at that time to specify C_comp by > numerical value are well stated, and they are quite valid. But the > decision created a consistency mistake because we did not specify > buffer values completely for direct corner correlation. > > I would favor just addressing only the C_comp issue. A simpler > alternate proposal would be to introduce a new model sub-parameter > such as "C_comp_corner" that specifies the value to be used for the > corresponding corner. That would fit in with existing IBIS. > > We could establish rules such as > > C_comp is always required for full range > which could be outside the corner range for > buffer tolerance design and also to provide a > guarenteed support path for all existing tools. > > C_comp_corner is optional for picking a corner value > for direct corner correlation. > > Or we could require one or the other. > > Bob > > > > Walter Katz wrote: > >>All, >> >> >> >>There is a very simple solution to this issue, please review the >>enclosed draft {Model Corner] draft BIRD. >> >> >> >>Walter >> >> >> >>-----Original Message----- >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Mirmak, Michael >>Sent: Monday, September 27, 2010 12:02 PM >>To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>One other item to note: not all device technologies associate a >>numerically-smallest capacitance with the ?fast/strong? process. >> Assuming that CMOS rules universally apply would not have been >>appropriate, and IBIS does not include any notations as to which >>process technology is used in the design for the data presented. >>Without that information or some basic ordering assumption, parsers >>have no means to confirm that the C_comp data had been entered correctly. >> >> >> >>As Arpad states, the only way to have enforceable parsing rules was to >>order the C_comp from numerically-smallest to ?largest, with the >>assumption that the EDA tool would supply the missing information, >>likely from asking the user (for example, the tool might inquire about >>the process used for the IC in question). >> >> >> >>Michael Mirmak >> >>Intel Corp. >> >>Chair, IBIS Open Forum >> >> >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Muranyi, Arpad >>Sent: Monday, September 27, 2010 7:35 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>Fabio, >> >> >> >>The reason you are getting that message is because the die capacitance >> >>does not have a direct relationship with the fast/slow process corners >> >>and when we wrote the IBIS specification we decided that it was best >> >>to just put the small number into the min place and the big number >>into >> >>the max place. It was expected that an EDA tool would allow the user >> >>to try out all possible combinations between min/max curves and C_comp. >> >> >> >>Arpad >> >>====================================================================== >>== >> >> >> >>---------------------------------------------------------------------- >>-- >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Fabio BRINA >>Sent: Monday, September 27, 2010 7:12 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: [IBIS] C_comp Max < C_comp Min >> >>Hello Ibis experts, >> >> >> >> I'm working in CMOS tecnology; >> >> very often in the C_comp extraction I obtain the Min value bigger >>then Max value: >> >> the values come from ac simulations in these conditions: >> >> >> >> C_comp Min value consider: Vcc Min, Process Min, Temp Max >> >> C_comp Max value consider: Vcc Max, Process Max, Temp Min >> >> >> >> The Ibis Check output is: >> >> >> >>WARNING (line 76) - >> >> Model mod1: C_comp min value is not the smallest value listed >> >>WARNING (line 76) - >> >> Model mod1: C_comp max value is not the largest value listed >> >> >> >>Is that situation acceptable? >> >>or I have to switch the Min Value with Max Value? >> >> >> >>... suggestions are welcome ! >> >> >> >>Thank you, >> >>Fabio >> >> >> >> >>-- >>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. >> >> >>-- >>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. > > > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- 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, 29 Sep 2010 10:44:50 -0400 From: "Lance Wang" Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I would like to echo Bob's comment. Accurate C-comp value is more important nowadays for high-speed buffers. Depending on my knowledge, the biggest inconsistency issue is that IBIS only allows one C-comp value for an I/O buffer. (per corner, of course) If we spell-out with two values for driving and receiving in IBIS, the IBIS simulations will give out more accurate results related to ringing and timing issues. I think it will be a great news especially for high-speed memory buffers. Best regards, Lance Wang 978-764-2298 IO Methodology Inc. www.iometh.com � � - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Haller, Robert Sent: Wednesday, September 29, 2010 8:51 AM To: Bob Ross; Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min I always wanted to have separate values of C_COMP for Inputs and Outputs in IO cells because they tend to optimize to slightly different values. In general I found to split the difference or lean toward the input value, particularly on a Multi-load network. Bob - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Wednesday, September 29, 2010 1:33 AM To: Baker, Bonnie Cc: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org'; 'ibis-users@server.eda.org' Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min All: Thanks Bonnie for your solution to the problem. You comply with IBIS, but provide a comment line for the value-to-corner mapping. That is the best we can do with IBIS today. For consistency for a particular PVT setting, all corner entries for a [Model] should have been for the same PVT conditions. [Model Spec] is already consistent in that respect. I have a number of objections to [Model Corner] proposal. One concern is that the C_comp parameters are related to actual silicon or Spice extraction values, and the other parameters are specification parmeters. overrides, spec. test setups, and limits. C_comp should remain separate. For better consistency, the IBIS committee should have defined a corner aligned C_comp by a keyword [C_comp] like [Pullup], etc. We did decide on a statistical range C_comp because in the early days, buffer to buffer differences due to metalization was a factor. We intend to let the user try different C_comp values to check design robustness. I now believe that was the wrong decision. Bob Baker, Bonnie wrote: > All, > > I had big concerns about this a few months ago. Originally, I was posting my IBIS models from my CMOS devices with the c_comp warnings from the parser. I then chose to list these values in numerical order to get away from those warnings because the IBIS standard and I felt the warnings were red flags to my customer. I have been reading the string over the last few days and I want to share our "solution" to this problem. Embedded in each buffer we have the following text: > > | typ min max > | (nom PVT) (Fast PVT) (slow PVT) > C_comp 9.298e-13 9.221e-13 9.527e-13 > | > | Where nom PVT is Nominal Process, 3.3V, 25C > | Fast PVT is Strong Process, 3.6V, -40C > | Slow PVT is Weak Process, 3.0V, 85C > > > Bonnie Baker > > -----Original Message----- > From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of > Walter Katz > Sent: Tuesday, September 28, 2010 8:22 AM > To: 'Bob Ross'; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: RE: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All, > > What Bob is proposing will work for C_Comp, but will leave all the > other > 100 or so other parameters that have typ min max, that may need typ > slow fast, along with a number of other insonsistant methods of > defining corner conditions (e.g. Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc > are defined by corner in several JEDEC specs, while they are defined with sensitivity in IBIS 5.0. > > We have found that being able to specify parameters by Corner in > addition to Range is an important feature that is used very often in AMI modeling. > > Walter > > -----Original Message----- > From: Bob Ross [mailto:bob@teraspeed.com] > Sent: Monday, September 27, 2010 9:17 PM > To: Walter Katz; 'Mirmak, Michael'; 'Muranyi, Arpad'; 'ibis@server.eda.org' > Cc: 'ibis-users@server.eda.org' > Subject: Re: [IBIS-Users] RE: [IBIS] C_comp Max < C_comp Min > > All: > > The reasons for why we decided at that time to specify C_comp by > numerical value are well stated, and they are quite valid. But the > decision created a consistency mistake because we did not specify > buffer values completely for direct corner correlation. > > I would favor just addressing only the C_comp issue. A simpler > alternate proposal would be to introduce a new model sub-parameter > such as "C_comp_corner" that specifies the value to be used for the > corresponding corner. That would fit in with existing IBIS. > > We could establish rules such as > > C_comp is always required for full range > which could be outside the corner range for > buffer tolerance design and also to provide a > guarenteed support path for all existing tools. > > C_comp_corner is optional for picking a corner value > for direct corner correlation. > > Or we could require one or the other. > > Bob > > > > Walter Katz wrote: > >>All, >> >> >> >>There is a very simple solution to this issue, please review the >>enclosed draft {Model Corner] draft BIRD. >> >> >> >>Walter >> >> >> >>-----Original Message----- >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Mirmak, Michael >>Sent: Monday, September 27, 2010 12:02 PM >>To: Muranyi, Arpad; ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>One other item to note: not all device technologies associate a >>numerically-smallest capacitance with the ?fast/strong? process. >> Assuming that CMOS rules universally apply would not have been >>appropriate, and IBIS does not include any notations as to which >>process technology is used in the design for the data presented. >>Without that information or some basic ordering assumption, parsers >>have no means to confirm that the C_comp data had been entered correctly. >> >> >> >>As Arpad states, the only way to have enforceable parsing rules was to >>order the C_comp from numerically-smallest to ?largest, with the >>assumption that the EDA tool would supply the missing information, >>likely from asking the user (for example, the tool might inquire about >>the process used for the IC in question). >> >> >> >>Michael Mirmak >> >>Intel Corp. >> >>Chair, IBIS Open Forum >> >> >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Muranyi, Arpad >>Sent: Monday, September 27, 2010 7:35 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: RE: [IBIS] C_comp Max < C_comp Min >> >> >> >>Fabio, >> >> >> >>The reason you are getting that message is because the die capacitance >> >>does not have a direct relationship with the fast/slow process corners >> >>and when we wrote the IBIS specification we decided that it was best >> >>to just put the small number into the min place and the big number >>into >> >>the max place. It was expected that an EDA tool would allow the user >> >>to try out all possible combinations between min/max curves and C_comp. >> >> >> >>Arpad >> >>====================================================================== >>== >> >> >> >>---------------------------------------------------------------------- >>-- >> >>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >>Fabio BRINA >>Sent: Monday, September 27, 2010 7:12 AM >>To: ibis@server.eda.org; ibis-users@server.eda.org >>Subject: [IBIS] C_comp Max < C_comp Min >> >>Hello Ibis experts, >> >> >> >> I'm working in CMOS tecnology; >> >> very often in the C_comp extraction I obtain the Min value bigger >>then Max value: >> >> the values come from ac simulations in these conditions: >> >> >> >> C_comp Min value consider: Vcc Min, Process Min, Temp Max >> >> C_comp Max value consider: Vcc Max, Process Max, Temp Min >> >> >> >> The Ibis Check output is: >> >> >> >>WARNING (line 76) - >> >> Model mod1: C_comp min value is not the smallest value listed >> >>WARNING (line 76) - >> >> Model mod1: C_comp max value is not the largest value listed >> >> >> >>Is that situation acceptable? >> >>or I have to switch the Min Value with Max Value? >> >> >> >>... suggestions are welcome ! >> >> >> >>Thank you, >> >>Fabio >> >> >> >> >>-- >>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. >> >> >>-- >>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. > > > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 29 Sep 2010 11:31:38 -0400 From: "Walter Katz" Subject: [IBIS-Users] I have read IBIS again and still am confused about typ min max rules, and the parser handles this inconsistantly This is a multi-part message in MIME format. - ------=_NextPart_000_0037_01CB5FC9.E161A850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, From IBIS 5.0: | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum must be placed on | a single line and must be separated by at least one white | space. All four columns are required under the [Model Spec] | keyword. However, data is required only in the typical | column. If minimum and/or maximum values are not available, | the reserved word "NA" must be used indicating the typical | value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage Range settings. The parser complains when "min <= typ <= max" is violated for [Model] parameters (e.g. C_Comp), but does not complain when this is violated for [Model Specific] parameters. So is this a bug in the parser, or should the document say that "min <= typ <= max" is not required for [Model Specific] parameters. Walter Walter Katz 303.449-2308 Mobile 303.883-2120 wkatz@sisoft.com www.sisoft.com - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - ------=_NextPart_000_0037_01CB5FC9.E161A850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,=

From= IBIS 5.0:

| Usage Rules: [Model= Spec] must follow all other subparameters under the

| [Model] keyword.

| <= /font>

| For each subparamet= er contained in the first column, the

| remaining three hol= d its typical, minimum and maximum values.

| The entries of typi= cal, minimum and maximum must be placed on

| a single line and m= ust be separated by at least one white

| space. All four col= umns are required under the [Model Spec]

| keyword. However, d= ata is required only in the typical

| column. If minimum = and/or maximum values are not available,

| the reserved word "NA" must be used indicating the typical

| value by default. <= o:p>

| <= /font>

| The minimum and max= imum values are used for specifications

| subparameter values= that may track the min and max operation

| conditions of the [= Model]. Usually it is related to the

| Voltage Range setti= ngs.

<= /o:p>

The = parser complains when “min <=3D typ <=3D max” is violated for [M= odel] parameters (e.g. C_Comp), but does not complain when this is violated for [Model Specific] p= arameters.

So i= s this a bug in the parser, or should the document say that “min <=3D typ <=3D max” is not required= for [Model Specific] parameters.

Walt= er

Walter Katz

303.449-230= 8

Mobile 303.883-2120<= /span>

wkatz@sisof= t.com

www.sisoft.= com

<= font color=3Dblack>

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. - ------=_NextPart_000_0037_01CB5FC9.E161A850-- - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 05 Oct 2010 14:26:00 -0700 From: Bob Ross Subject: [IBIS-Users] Asian IBIS Summit (China) - Fifth Announcement To All: The IBIS Open Forum is holding an Asian IBIS Summit Meeting in Shenzhen, China, a major technology center on Tuesday, November 9, 2010. Up to 10 presentations or topics are listed below. A few more are expected. Several of these will be given at the other Asian Summits. Several companies listed below are co-sponsoring this large event to be held at the Four Points by Sheraton, Shenzhen. Like in previous years, we are planning for a large number of attendees including several IBIS experts from the USA. We encourage technical contributions from Asia. We expect a full agenda of relevant material. For travel consideration, two other Asian IBIS Summits follow this event: Taipei, Taiwan, Friday, November 12, Sherwood Hotel Tokyo, Japan, Monday, November 15, JEITA headquarters Bob Ross Teraspeed Consulting Group Lance Wang IO Methodology Inc. - ----------------------------------------------------------------------- ASIAN IBIS SUMMIT (CHINA) FIFTH CALL FOR PARTICIPATION AND PRESENTATIONS - ----------------------------------------------------------------------- http://www.eda.org/pub/ibis/summits/nov10a/announcement_chinese.pdf ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A S I A N I B I S S U M M I T ( C H I N A ) Time/Date: Tuesday, November 9, 2010, 8:00 AM to 5:30 PM Meeting starts at 9:00 AM Location: Four Points by Sheraton 5 Guihua Road Futian Free Trade Zone Shenzhen, Guangdong 518038 P. R. China http://www.starwoodhotels.com/fourpoints/property/overview/index.html?propertyID=1489& EM=VTY_FP_1489_shenzhen_overview or http://tinyurl.com/2s6esb Content: Presentations and Discussions Purpose: Solicit and exchange IBIS and interconnect model related information and ideas. Primary Sponsor: Huawei Technologies Co-sponsors (in alphabetical order): Agilent Technologies, Ansoft Corporation, Cadence Design Systems, Cybernet, Intel Corporation, IO Methodology, Mentor Graphics Corporation, Signal Integrity Software (SiSoft), Sigrity, Synopsys, and ZTE Corporation. Cost: FREE, including refreshments and buffet lunch Vendors: Some vendors will have information tables outside the meeting room Contact us for details regarding sponsorship. BACKGROUND We have held five successful meetings in Shenzhen, Shanghai and Beijing. This year we are meeting again in Shenzhen where many Chinese and foreign high technology companies operate. These events are archived along with all our other Summits: http://www.eda.org/pub/ibis/summits/ Our objective is to reach out internationally to communicate with the local experts and to learn of regional concerns. CONFERENCE LANGUAGE The conference language is English, but we will plan for technical translations in English and Chinese. So presenters can optionally deliver in Chinese as long as an English version of the material is available. IBIS SUMMIT This meeting will be conducted as a formal IBIS Summit Meeting. Presentations will be archived in an electronic format on our Summits site, and minutes of the meeting will be issued. However, no formal decisions requiring votes will be planned. CALL FOR PARTICIPANTS People involved in IBIS and interconnect model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register using the information below (in English): Name: E-mail address: Company: Top-level Web Link: Country: Telephone: Comments: (Such as assistance for the travel requirements at the end) Send to BOTH: Bob Ross, Teraspeed Consulting Group bob@teraspeed.com Lance Wang, IO Methology Inc. lwang@iometh.com SIGNUP DEADLINE: November 4, 2010 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS and interconnect modeling experiences or issues. If we have to select presentations for the number of time slots available, we will give preferential consideration to presentations from Asia. Presentation Format: LCD Projection from meeting laptop computer Time: 15-30 Minutes including questions Electronic Archival: All presentations will uploaded to our public IBIS Summit archives Electronic Format: Power Point or Acrobat Presentation Booklet: Available at the meeting for all attendees Presentation Deadline: October 12, 2010 to produce the presentation booklet for the meeting If you plan a presentation, please ADD to the above registration information: Title of Presentation: Estimated Time: (30 minutes or less) We will notify you of acceptance and may follow up with questions when we form the program agenda. Note: Vendor promotional or business information is prohibited. Submitted presentations must be in English, although the delivery can be in Mandarin. Submissions from Asia are encouraged along with other submissions world-wide. Topics may include behavioral modeling of buffers, interconnects or other system components. AGENDA 8:15 - 9:00 Vendor table setup and tables 8:30 - 9:00 Sign in 9:00 - 12:00 Presentations 12:00 - 13:30 Free buffet lunch, vendor tables 13:30 - 17:00 Presentations The specific agenda is being developed. We expect nine or ten presentations covering a range of issues from existing customer experiences, existing clarifications and some future technical directions in IBIS. Several major IBIS Committee presentations from IBIS officers or active members are planned. Several presentations on IBIS applications and behavioral modeling issues, including interconnects, and system components are expected from co-sponsor companies and/or their customers. Tentative Titles or Topics: Intel Corporation: IBIS Chair Introduction topic IBIS-ISS topic Agilent Technologies: "Automated AMI Model Generation & Validation" Huawei Technologies: "Modeling the Loop Inductance of High Frequency Capacitance and Analyzing Capacitance' Global Decouple Effect" IO Methodology: "Point Reduction Method for IBIS Curves" Cadence Design Systems and Sigrity: "Model Connection Protocol Extensions for Mixed Signal SiP" Flextronics and Cadence Design Systems: "Extending/Leveraging IBIS Constructs to Model High-Speed I/Os and Packages using AMI, Spice, and S-Parameters" Sigrity: BIRD95 Power Integrity Analysis Using IBIS topic ZTE Corporation: "IBIS-AMI Simulation for High-Speed System Design" OR/AND "Modeling Methods for Complex S-parameters in Touchstone 2.0" LIST OF NEARBY HOTELS AND TRAVEL RULES Hotels in all price ranges can be found through internet searches. Comply with your travel rules, such as indicated in the link below to China and Shenzhen. Work with your travel agent. Notify us as a sign-up comment if you need assistance. Visas, if needed, should fall in the visit/business category: http://travel.state.gov/travel/cis_pa_tw/cis/cis_1089.html - ----------------------------------------------------------------- - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 ------------------------------ End of ibis-users V1 #153 *************************