From: owner-ibis-users@ (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #1 Reply-To: Sender: owner-ibis-users@ Errors-To: owner-ibis-users@ Precedence: bulk ibis-users Friday, October 19 2001 Volume 01 : Number 001 ---------------------------------------------------------------------- Date: Thu, 06 Sep 2001 18:13:40 +0300 From: yoked erlich Subject: Ibis_model This is a multi-part message in MIME format. - --------------EF07218DFAB6BDC3FDA80A4C Content-Type: multipart/alternative; boundary="------------CD917FB6AF485967046CAD24" - --------------CD917FB6AF485967046CAD24 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , I've got the next warning about [falling Waveform] simulation, WARNING - Model ipad6wd: The [Falling Waveform] with [R_fixture]=50 Ohms and [V_fixture_min]=3V has MIN column DC endpoints of 1.29V and 3.00v, but an equivalent load applied to the model's I-V tables yields different voltages ( 1.27V and 2.94V), a difference of 1.64% and 2.18%, respectively. I understood the first part of the warning , but I can't figure out how does the checker find the second voltage range (as it appear in the warning the range is yields from the I/V tables and I couldn't find any sign to this voltage in I/V tables) - -- With regards, Yoked. _____________________________________ E-mail: yokede@motorola.com Tel: 972-9-9522482 Fax: 972-9-9522888 WIRELESS CIRCUIT - IO GROUP MOTOROLA SEMICONDUCTOR ISRAEL - --------------CD917FB6AF485967046CAD24 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ,

I've got the next warning about [falling Waveform] simulation,

WARNING - Model ipad6wd: The [Falling Waveform]
      with [R_fixture]=50 Ohms and [V_fixture_min]=3V
      has MIN column DC endpoints of  1.29V and  3.00v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.27V and  2.94V),
      a difference of  1.64% and  2.18%, respectively.

I understood the first part of the warning , but I can't figure out how does the checker find the second voltage range
(as it appear in the warning the range is yields from the I/V tables and I couldn't find any sign to this voltage in I/V tables) 

-- 

With regards,

Yoked.

_____________________________________
E-mail:           yokede@motorola.com
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP                 
MOTOROLA     SEMICONDUCTOR     ISRAEL
  - --------------CD917FB6AF485967046CAD24-- - --------------EF07218DFAB6BDC3FDA80A4C Content-Type: text/x-vcard; charset=us-ascii; name="yokede.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for yoked erlich Content-Disposition: attachment; filename="yokede.vcf" begin:vcard n:Erlich;Yoked tel;cell:051-957314 tel;fax:09-9522888 tel;home:09-8985166 tel;work:09-9522482 x-mozilla-html:FALSE org:Motorola Semiconductor L.T.D;IO - WIRELESS adr:;;Hadolev 20a;Zuran;;;ISRAEL version:2.1 email;internet:yokede@msil.sps.mot.com x-mozilla-cpt:;-32248 fn:Yoked Erlich end:vcard - --------------EF07218DFAB6BDC3FDA80A4C-- ------------------------------ Date: Thu, 06 Sep 2001 12:17:05 -0400 From: Steve Grout Subject: test - please ignore This is a test of ibis-users@eda.org list - please ignore - --majordom@eda.org ------------------------------ Date: Thu, 6 Sep 2001 13:47:13 -0400 From: "Ross, Bob" Subject: IBIS SUMMIT MEETING AGENDA 9/13/01 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C136FC.49BF0B00 Content-Type: text/plain To IBIS Participants: Here is the Agenda for the IBIS Summit Meeting. We do expect interactive discussions and some possible Ad Hoc presentations to fill out the day. If you plan to come, but have not notified anyone, please let Kathy Breda know to help us plan the refreshment and free lunch participation. E-mail is breda@nesa.com. We am looking forward to seeing you in Worcester and having a productive meeting. Bob Ross Mentor Graphics ************************************************************ I B I S S U M M I T M E E T I N G A G E N D A Time/Date: 8:30 AM - 5:00 PM, Thursday, September 13, 2001 Location: The Crowne Plaza Hotel 10 Lincoln Square Worcester, Massachusetts Tel: (508) 791-1600 Fax: (508) 791-1796 Content: IBIS Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: Mentor Graphics North East Systems Associates, Inc. IBIS Open Forum IBIS Users Group PCB Conference: September 10-14, 2001 East Worcester's Centrum Centre Worcester, Massachusetts See http://www.pcbeast.com/ for more information. ************************************************************ IBIS SUMMIT AGENDA 8:30 AM MORNING REFRESHMENTS 9:00 AM Introductions and Business Stephen Peters, Intel 9:15 AM Keynote Remarks Ed Sayre, North East Systems Associates (NESA) 9:30 AM From Model Creator to Model User Bob Haller, Cereva Networks 10:00 AM A Proposal for s2ibis3 Paul Franzon, North Carolina State University 10:30 AM BREAK AND REFRESHMENTS 10:45 AM Modeling the Radiated Emission of Micro-controllers Etienne Sicard, National Institute of Applied Science (INSA) 11:30 AM Power/Ground Simulation with IBIS Models and Pin Mapping Issues Raj Raghuram, Sigrity, Inc. 12:00 PM LUNCH (Free to Attendees) 1:00 PM Progress and Update in the Connector Specification Stephen Peters, Intel Corporation 1:30 PM Progress and Issues in IBIS-X Stephen Peters, Intel Corporation 2:00 PM IBIS-X Primitives and Example Lynne Green, Cadence Design Systems 2:30 PM BREAK AND REFRESHMENTS 2:45 PM Unscheduled Ad Hoc Topics 3:15 PM Roundtable - Other Topics Stephen Peters, Intel, Ed Sayre, NESA 5:00 PM FINAL BUSINESS AND ADJOURN ************************************************************ - ------_=_NextPart_001_01C136FC.49BF0B00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable IBIS SUMMIT MEETING AGENDA 9/13/01

To IBIS Participants:

Here is the Agenda for the IBIS Summit Meeting.  = We do expect
interactive discussions and some possible Ad Hoc = presentations
to fill out the day.

If you plan to come, but have not notified anyone, = please let
Kathy Breda know to help us plan the refreshment and = free lunch
participation.  E-mail is = breda@nesa.com.

We am looking forward to seeing you in Worcester and = having a
productive meeting.

Bob Ross
Mentor Graphics

************************************************************

I B I S   S U M M I T   M E E T I = N G   A G E N D A

Time/Date:      8:30 AM - = 5:00 PM, Thursday, September 13, 2001

Location:       The = Crowne Plaza Hotel
          &nb= sp;     10 Lincoln Square
          &nb= sp;     Worcester, Massachusetts
          &nb= sp;     Tel:  (508) 791-1600
          &nb= sp;     Fax:  (508) 791-1796

Content:        = IBIS Presentations and Discussions

Purpose:        = Solicit and Exchange IBIS Model Related Information and
          &nb= sp;     Ideas.

Sponsors:       Mentor = Graphics
          &nb= sp;     North East Systems Associates, Inc.
          &nb= sp;     IBIS Open Forum
          &nb= sp;     IBIS Users Group

PCB Conference: September 10-14, 2001
East          = ;  Worcester's Centrum Centre
          &nb= sp;     Worcester, Massachusetts
          &nb= sp;     See http://www.pcbeast.com/ for more = information.

************************************************************

IBIS SUMMIT AGENDA

8:30 AM   MORNING REFRESHMENTS

9:00 AM   Introductions and Business
          Stephen = Peters, Intel

9:15 AM   Keynote Remarks
          Ed = Sayre, North East Systems Associates (NESA)

9:30 AM   From Model Creator to Model = User
          Bob = Haller, Cereva Networks

10:00 AM  A Proposal for s2ibis3
          Paul = Franzon, North Carolina State University

10:30 AM  BREAK AND REFRESHMENTS

10:45 AM  Modeling the Radiated Emission of = Micro-controllers
          Etienne = Sicard, National Institute of Applied Science (INSA)

11:30 AM  Power/Ground Simulation with IBIS = Models and Pin Mapping
          = Issues
          Raj = Raghuram, Sigrity, Inc. 

12:00 PM  LUNCH (Free to Attendees)

1:00 PM   Progress and Update in the = Connector Specification
          Stephen = Peters, Intel Corporation

1:30 PM   Progress and Issues in = IBIS-X
          Stephen = Peters, Intel Corporation

2:00 PM   IBIS-X Primitives and = Example
          Lynne = Green, Cadence Design Systems

2:30 PM   BREAK AND REFRESHMENTS

2:45 PM   Unscheduled Ad Hoc Topics

3:15 PM   Roundtable - Other Topics
          Stephen = Peters, Intel, Ed Sayre, NESA

5:00 PM   FINAL BUSINESS AND ADJOURN

************************************************************

- ------_=_NextPart_001_01C136FC.49BF0B00-- ------------------------------ Date: Thu, 6 Sep 2001 13:21:23 -0700 From: "Ross, Bob" Subject: IBIS SUMMIT MEETING AGENDA 9/13/01 (re-sent) To IBIS Participants: Here is the Agenda for the IBIS Summit Meeting. We do expect interactive discussions and some possible Ad Hoc presentations to fill out the day. If you plan to come, but have not notified anyone, please let Kathy Breda know to help us plan the refreshment and free lunch participation. E-mail is breda@nesa.com. We am looking forward to seeing you in Worcester and having a productive meeting. Bob Ross Mentor Graphics ************************************************************ I B I S S U M M I T M E E T I N G A G E N D A Time/Date: 8:30 AM - 5:00 PM, Thursday, September 13, 2001 Location: The Crowne Plaza Hotel 10 Lincoln Square Worcester, Massachusetts Tel: (508) 791-1600 Fax: (508) 791-1796 Content: IBIS Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: Mentor Graphics North East Systems Associates, Inc. IBIS Open Forum IBIS Users Group PCB Conference: September 10-14, 2001 East Worcester's Centrum Centre Worcester, Massachusetts See http://www.pcbeast.com/ for more information. ************************************************************ IBIS SUMMIT AGENDA 8:30 AM MORNING REFRESHMENTS 9:00 AM Introductions and Business Stephen Peters, Intel 9:15 AM Keynote Remarks Ed Sayre, North East Systems Associates (NESA) 9:30 AM From Model Creator to Model User Bob Haller, Cereva Networks 10:00 AM A Proposal for s2ibis3 Paul Franzon, North Carolina State University 10:30 AM BREAK AND REFRESHMENTS 10:45 AM Modeling the Radiated Emission of Micro-controllers Etienne Sicard, National Institute of Applied Science (INSA) 11:30 AM Power/Ground Simulation with IBIS Models and Pin Mapping Issues Raj Raghuram, Sigrity, Inc. 12:00 PM LUNCH (Free to Attendees) 1:00 PM Progress and Update in the Connector Specification Stephen Peters, Intel Corporation 1:30 PM Progress and Issues in IBIS-X Stephen Peters, Intel Corporation 2:00 PM IBIS-X Primitives and Example Lynne Green, Cadence Design Systems 2:30 PM BREAK AND REFRESHMENTS 2:45 PM Unscheduled Ad Hoc Topics 3:15 PM Roundtable - Other Topics Stephen Peters, Intel, Ed Sayre, NESA 5:00 PM FINAL BUSINESS AND ADJOURN ************************************************************ ------------------------------ Date: Mon, 10 Sep 2001 08:42:05 -0700 From: "Mirmak, Michael" Subject: IBIS techniques for Pre-emphasis ? All, A lot of buffer designs are beginning to include pre-emphasis to enhance the strength of drivers for certain types of data pattern (a notable older example is EIA/RS-485). [Driver Schedule] and [Submodel] keyword sections can be used to add "boosts" to driven signals, but not necessarily in any way related to a particular signal pattern. At present, are there any known techniques for including pre-emphasis in IBIS buffers? If not, are there plans to do so in IBIS 4.x/IBIS-X? Thanks! - - Michael Mirmak, Intel Corp. ------------------------------ Date: Mon, 10 Sep 2001 10:38:42 -0700 From: "Peters, Stephen" Subject: RE: IBIS techniques for Pre-emphasis ? Hi Michael: The issue of modeling a buffer with data stream pre-emphasis has been raised before with respect to modeling the latest SCSI buffers. It is possible to model a buffer with data stream dependent pre-emphasis, although there are limitations and caveats. For the details, refer to several presentations at the June IBIS summit. Click on http://www.eda.org/pub/ibis/summits/jun01/ then go to the readme for a list of the presentation. I believe you want the ones from Larry Barnes, Hegazy and Bob Ross. Regards, Stephen Peters Intel Corp. - -----Original Message----- From: Mirmak, Michael [mailto:michael.mirmak@intel.com] Sent: Monday, September 10, 2001 8:42 AM To: 'ibis-users@eda.org' Subject: IBIS techniques for Pre-emphasis ? All, A lot of buffer designs are beginning to include pre-emphasis to enhance the strength of drivers for certain types of data pattern (a notable older example is EIA/RS-485). [Driver Schedule] and [Submodel] keyword sections can be used to add "boosts" to driven signals, but not necessarily in any way related to a particular signal pattern. At present, are there any known techniques for including pre-emphasis in IBIS buffers? If not, are there plans to do so in IBIS 4.x/IBIS-X? Thanks! - - Michael Mirmak, Intel Corp. ------------------------------ Date: Tue, 11 Sep 2001 15:24:53 -0700 From: "Peters, Stephen" Subject: Changes to IBIS East Summit Greetings: Due to the disruption in air travel, many of the officers and presenters will not be able attend Thursday's IBIS East summit in person. Nevertheless, the IBIS Summit and Users Group meeting WILL be held, albeit in a scaled down fashion. Ed Sayer (NESA) has agreed to host a Users Group meeting with the attendees already at PCB East. As for the IBIS Summit itself, Intel has arranged for a teleconference connection to the Users Group meeting. The teleconference will be from 6:00am - 9:00am Pacific time (9:00am - 12:00pm Eastern). We will conduct whatever IBIS business required and then work thru the presentations, especially Paul Fanzon's S2IBIS3 presentation and Mr. Sicard's EMI work with IBIS. We can extend the teleconference if folks desire and there are topics to discuss. The dial in number, bridge number and passcode are as follows: Dial in number: 1-916-356-2663 Bridge number: Bridge 3 Passcode: 5127881 Presenters, if you have not already done so please mail your presentation (electronic format) to bob_ross@mentorg.com for placement on the IBIS web site. Thanks everyone for you patience and understanding. Regards, Stephen Peters Intel Corp. Chair, EIA/IBIS Open Forum ------------------------------ Date: Mon, 17 Sep 2001 16:11:34 -0700 (PDT) From: john austin Subject: ibis If I want to create a behavioral model out of a spec. Could you please let me know what I should watch for? Also, if there is any documents or paper out there that facilitate the task? Thanks __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ------------------------------ Date: Tue, 18 Sep 2001 08:20:29 -0400 From: Adam.Tambone@fairchildsemi.com Subject: Re: ibis John, could you be more specific? Adam john austin @eda.org on 09/17/2001 07:11:34 PM Sent by: owner-ibis-users@eda.org To: ibis-users@eda.org cc: Subject: ibis If I want to create a behavioral model out of a spec. Could you please let me know what I should watch for? Also, if there is any documents or paper out there that facilitate the task? Thanks __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ------------------------------ Date: Tue, 18 Sep 2001 08:58:23 -0700 (PDT) From: john austin Subject: Re: ibis I have spec which specify the AC, DC requirement. The specs contain V/I curves pullup & pulldown. Also, the references curves of the pullup and pulldown. I am looking to write an approximate behavioral model for it. So I want to know what equations or portions of the specs I need to pay attention to, to create V/I tables, rising & falling waveforms. I have some idea on how to proceed( based on other IBIS models) but still I wanted to see a methodology or guidelines already used by an expert. Thanks - --- Adam.Tambone@fairchildsemi.com wrote: > > John, could you be more specific? > > Adam > > > > > > > john austin @eda.org on > 09/17/2001 07:11:34 PM > > Sent by: owner-ibis-users@eda.org > > > To: ibis-users@eda.org > cc: > > Subject: ibis > > > If I want to create a behavioral model out of a > spec. > Could you please let me know what I should watch > for? > Also, if there is any documents or paper out there > that facilitate the task? > > Thanks > > __________________________________________________ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ------------------------------ Date: Tue, 18 Sep 2001 11:44:15 -0700 From: "Muranyi, Arpad" Subject: RE: ibis You could start with reading the documents on the IBIS web site. http://www.eigroup.org/ibis/ibis.htm Arpad Muranyi Intel Corporation =================================================== - -----Original Message----- From: Adam.Tambone@fairchildsemi.com [mailto:Adam.Tambone@fairchildsemi.com] Sent: Tuesday, September 18, 2001 5:20 AM To: john austin Cc: ibis-users@eda.org Subject: Re: ibis John, could you be more specific? Adam john austin @eda.org on 09/17/2001 07:11:34 PM Sent by: owner-ibis-users@eda.org To: ibis-users@eda.org cc: Subject: ibis If I want to create a behavioral model out of a spec. Could you please let me know what I should watch for? Also, if there is any documents or paper out there that facilitate the task? Thanks __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ------------------------------ Date: Tue, 18 Sep 2001 15:38:19 -0400 From: Adam.Tambone@fairchildsemi.com Subject: Re: ibis John, My apologies for the delay in this response. I am still not clear as to what you have or what you want to create. Perhaps some very general and simplified advice can get you started. First inspect the material available at the IBIS site mentioned by Arpad, especially the specification itself. IBIS models ( datasheets ) contain DC and Vt data in addition to other parameters associated with the buffer being modeled. The DC and Vt data can be gained via simulation ( SPICE to IBIS ) or through lab measurement. Most of the additional parameters can be gained from the device's datasheet such as Vinh and Vinl. Collectively this data comprises a IBIS datasheet which can be used by various simulators to perform limited SI simulation and analysis. These simulators read a IBIS datasheet and create their own behavioral model based on the information contained therein. Creating your own behavioral model from a IBIS datasheet is not a trivial task. Hope this helps, Adam Tambone john austin @eda.org on 09/18/2001 11:58:23 AM Sent by: owner-ibis-users@eda.org To: Adam Tambone/SouthPortland/Fairchild@Fairchild cc: ibis-users@eda.org Subject: Re: ibis I have spec which specify the AC, DC requirement. The specs contain V/I curves pullup & pulldown. Also, the references curves of the pullup and pulldown. I am looking to write an approximate behavioral model for it. So I want to know what equations or portions of the specs I need to pay attention to, to create V/I tables, rising & falling waveforms. I have some idea on how to proceed( based on other IBIS models) but still I wanted to see a methodology or guidelines already used by an expert. Thanks - --- Adam.Tambone@fairchildsemi.com wrote: > > John, could you be more specific? > > Adam > > > > > > > john austin @eda.org on > 09/17/2001 07:11:34 PM > > Sent by: owner-ibis-users@eda.org > > > To: ibis-users@eda.org > cc: > > Subject: ibis > > > If I want to create a behavioral model out of a > spec. > Could you please let me know what I should watch > for? > Also, if there is any documents or paper out there > that facilitate the task? > > Thanks > > __________________________________________________ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ------------------------------ Date: Tue, 18 Sep 2001 14:41:17 -0700 (PDT) From: john austin Subject: Re: ibis Thank you Adam and to all to those who responded. - --- Adam.Tambone@fairchildsemi.com wrote: > > John, > > My apologies for the delay in this response. > > I am still not clear as to what you have or what you > want to create. > Perhaps some very general and simplified advice can > get you started. > > First inspect the material available at the IBIS > site mentioned by Arpad, > especially the specification itself. IBIS models ( > datasheets ) contain DC > and Vt data in addition to other parameters > associated with the buffer > being modeled. The DC and Vt data can be gained via > simulation ( SPICE to > IBIS ) or through lab measurement. Most of the > additional parameters can > be gained from the device's datasheet such as Vinh > and Vinl. Collectively > this data comprises a IBIS datasheet which can be > used by various > simulators to perform limited SI simulation and > analysis. These simulators > read a IBIS datasheet and create their own > behavioral model based on the > information contained therein. Creating your own > behavioral model from a > IBIS datasheet is not a trivial task. > > Hope this helps, > Adam Tambone > > > > > > > john austin @eda.org on > 09/18/2001 11:58:23 AM > > Sent by: owner-ibis-users@eda.org > > > To: Adam Tambone/SouthPortland/Fairchild@Fairchild > cc: ibis-users@eda.org > > Subject: Re: ibis > > > I have spec which specify the AC, DC requirement. > The specs contain V/I curves pullup & pulldown. > Also, > the references curves of the pullup and pulldown. > > I am looking to write an approximate behavioral > model > for it. So I want to know what equations or > portions > of the specs I need to pay attention to, to create > V/I > tables, rising & falling waveforms. > > I have some idea on how to proceed( based on other > IBIS models) but still I wanted to see a methodology > or guidelines already used by an expert. > > Thanks > > --- Adam.Tambone@fairchildsemi.com wrote: > > > > John, could you be more specific? > > > > Adam > > > > > > > > > > > > > > john austin @eda.org on > > 09/17/2001 07:11:34 PM > > > > Sent by: owner-ibis-users@eda.org > > > > > > To: ibis-users@eda.org > > cc: > > > > Subject: ibis > > > > > > If I want to create a behavioral model out of a > > spec. > > Could you please let me know what I should watch > > for? > > Also, if there is any documents or paper out there > > that facilitate the task? > > > > Thanks > > > > __________________________________________________ > > Terrorist Attacks on U.S. - How can you help? > > Donate cash, emergency relief information > > > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > > > > > > > __________________________________________________ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ------------------------------ Date: Tue, 18 Sep 2001 15:58:02 -0700 From: "Dagostino, Tom" Subject: RE: ibis Going from a released spec, one that a semiconductor manufacturer will send out will lead you to a much weaker model than the actual silicon. For example a typical part will have a Vol of 0.4V at 8 mA. In reality that driver will be 3 to 5 times stronger, 24 to 40 mA at 0.4V. The same applies to Voh. Most semiconductor datasheets do not specify rise and fall times so you will have to guess a transition time. You cannot just look at the underlying process used and make a guess because there may be structures in the output that control the slew rate. If you have rise and fall time specs in the datasheet they are likely to be accurate. You will also need to know if there is a power clamp in the device. For inputs the major items are what clamps and Ccomp. The rest of the data can be pulled from the datasheet. Your best bet is to find another part from that manufacturer's process and copy that model assuming you can find one with the same output buffer used. If you have a sample you can make some measurements if you have power supplies, a high speed scope and some means of measuring the IV characteristics. Tom Dagostino Modeling Manager Mentor Graphics Corp. SAE tom_dagostino@mentor.com 503-685-1613 - -----Original Message----- From: john austin [mailto:john_austinus@yahoo.com] Sent: Tuesday, September 18, 2001 8:58 AM To: Adam.Tambone@fairchildsemi.com Cc: ibis-users@eda.org Subject: Re: ibis I have spec which specify the AC, DC requirement. The specs contain V/I curves pullup & pulldown. Also, the references curves of the pullup and pulldown. I am looking to write an approximate behavioral model for it. So I want to know what equations or portions of the specs I need to pay attention to, to create V/I tables, rising & falling waveforms. I have some idea on how to proceed( based on other IBIS models) but still I wanted to see a methodology or guidelines already used by an expert. Thanks - --- Adam.Tambone@fairchildsemi.com wrote: > > John, could you be more specific? > > Adam > > > > > > > john austin @eda.org on > 09/17/2001 07:11:34 PM > > Sent by: owner-ibis-users@eda.org > > > To: ibis-users@eda.org > cc: > > Subject: ibis > > > If I want to create a behavioral model out of a > spec. > Could you please let me know what I should watch > for? > Also, if there is any documents or paper out there > that facilitate the task? > > Thanks > > __________________________________________________ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ------------------------------ Date: Wed, 19 Sep 2001 13:48:13 -0700 From: gdeburgh@camarillo.innoveda.com (Guy de Burgh) Subject: EIA IBIS Open Forum Meeting Minutes 9/19/01 Due to technical problems with the ibis@eda.org reflector I am resending these minutes to the ibis-users@eda.org reflector address. Guy de Burgh Secretary. DATE: 9/18/01 SUBJECT: September 13, 2001 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 2001 PARTICIPANTS LIST: 3Com (& CommWorks) Roy Leventhal Ansoft Corporation (Eric Bracken) Apple Computer John Figueroa Applied Simulation Technology [Raj Raghuram], Norio Matsui, Fred Balistreri Avanti (Chen Hongyu) Cadence Design [Ian Dodd], Patrick Dos Santos, Heiko Dudek, Lynne Green*, Lance Wang* Cisco Systems Syed Huq, Lungfu Chen Cypress Semiconductor (Rajesh Manapat) EMC Corporation Brian Arsenault, Jinhua Chen Fairchild Semiconductor Adam Tambone Huawei Technologies Rachild Chen IBM Michael Cohen, Greg Edlund, Wes Martin, Yeon-Chang Hahm, Bill DeVey, Pravin Patel Innoveda (& HyperLynx) Guy de Burgh, John Angulo, Cary Mandel, Matthew Flora, Steve Kaufer Intel Corporation Stephen Peters**, Arpad Muranyi*, Dave Lorang, Michael Mirmak, Qinglun Chen, Will Hobbs, Wei-hsing Huang LSI Logic Larry Barnes Mentor Graphics Bob Ross**, Tom Dagostino, Chris Reid, Mike Donnelly, Hazem Hegazy, Tony Dunbar, Griff Derryberry, Dan Lake, Sherif Hammad, Mohammed Korany, Weston Beal, Chris Swaim*, Ali Samii, Eric Ronger, Karine Loudet, Daisaku Shiga, Kenji Kushima, Ian Dodd Micron Technology Randy Wolff, Yong Phan Mitsubishi Pat Hefferan Molex Incorporated Gus Panella, Brian O'Malley National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre* Philips Semiconductor Zack Ciccone, Rob Mataheroe Quantic EMC (Mike Ventham) Signal Integrity Software Douglas Burns, Barry Katz, Walter Katz Sigrity Raj Raghuram*, Winson Yu* SiQual Scott McMorrow*, Rob Hinz, Bernard Voss, Chris Brewster Texas Instruments Thomas Fisher, Stephen Nolan, Ramzi Ammar, Jean Claude Perrin, Moshiul Haque Time Domain Analysis Systems Dima Smolyansky, Steve Corey Tyco Electronics (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) John Berrie, Ralf Bruening OTHER PARTICIPANTS IN 2001: Actel Corporation Silvia Montoya Acuson Kim Helliwell AMCC Jeff Smith ASIS Ltd David Wright Brocade Communications Robert Badal BMW Friedrich Hasinger Cereva Networks Bob Haller* Compaq [Peter LaFlamme], Ron Bellomio, Quang Dam, Bill Ham EADS Airbus Industry Claude Huet (Aerospatiale) EFM Ekkehard Miersch, Horle Raines EIA Cecilia Fleming Ericsson Radio Systems Anders Ekholm FCI Sercu Stefaan Foundary Networks Bertram Chan Framatom Conectors Danny Morlion Fraunhofer Institute Mariusz Faferko, Peter Kralicek Reliability and Integration Fujitsu Ltd Tadashi Arai, Takeshi Murakami Heidelberger Druchmaschinen AG Wolfgang Kleinfeldt Hyundai Electronics Jongho Kang Idaho State University Al Davis Infineon Technologies Christian Sporrer Intrinsix Corporation Steven Chin KAW/USA Shinichi Maeda* Motorola (Rick Kingen) National Institute of Applied Etienne Sicard** Science (INSA) Nokia Tapani von Ravner, Mika Castren, Janne Uusitalo North Carolina State U. Paul Franzon** Nortel Networks Calvin Trowell Oak Technology Darmin Jin Plexus Technology Group Joseph Socha Siemens (& Automotive) AG Bernhard Unger, Helmut Katzier, Katja Koller, Wolfram Meyer, Eckhard Lenski, Gerald Bannert, Burkhard Muller, Christian Marot, Manfred Maurer, Amir Motamedi, Hans Pichlmaier Sintecs Hans Klos STMicroelectronics Peter Hirt, Fabrice Boissieres Sun Adrian Udenze Toshiba Corp. Hirokaza Kato, Yuichi Koga, Toshio Sudo Xilinx Susan Wu In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode October 5, 2001 1-888-316-5901 none 6159969 October 26, 2001 1-916-356-2663 3 0776283 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum, and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Stephen Peters and give the reservation number and passcode. Four people who attended by teleconference are designate by **. NOTE: "AR" = Action Required. - -------------------------------- MINUTES ----------------------------------- IBIS SUMMIT MEETING LOGISTICS NOTE The IBIS Summit meeting was held on Thursday, September 13, 2001 in the Crowne Plaza Hotel located in Worcester, Massachusetts at the same time as the PCB Conference East 2001. Because of the tragic attack on America on September 11, 2001, the arrangements needed to be adjusted. Several people were already attending the PCB Conference East, but others could not travel to the site. After some consultation, we decided to hold the meeting as a combined on-site/teleconference meeting. Intel provided the phone bridge. A total of 14 people representing 11 organizations participated and 4 of these people participated by telephone. Four of the presentations were delivered by telephone and copies were available on-site. INTRODUCTIONS AND BUSINESS Stephen Peters welcomed the participants and thanked the co-sponsors Mentor Graphics, North East Systems Associates, the IBIS Users Group and IBIS Open Forum. Stephen also thanked Kathy Breda and North East Systems Associates for the arrangements and for the last minute logistical adjustments. All of the meeting presentation slides were available at the meeting and had also been uploaded at the site: http://www.eda.org/pub/ibis/summits/sep01/ Stephen stated that there were no business issues. Stephen asked for any open topics. None were offered at that time, but at the end of the meeting Arpad Muranyi gave a brief presentation: Arpad Muranyi - Correlation Study for DDR Style Terminations with IBIS Models KEYNOTE REMARKS Stephen Peters introduced Ed Sayre, Chair of the IBIS Users Group for some keynote remarks. After thanking Intel for the bridge, Ed expressed concern that the IBIS specification was becoming too complex for the middle ground user and becoming too hard to use. A tutorial is needed to understand the specification, and a paper or presentation detailing the theoretical basis behind IBIS behavioral modeling would be helpful. He also felt that while the model developer needs to be concerned about the syntactical issues, the user needs more graphical information content. In short, the basic concepts need to be communicated better. Ed suggested that money and resources be set aside for IBIS training. The group commented and discussed Ed's remarks. Arpad Muranyi state that complexity was added in Version 3.2 to deal with new technologies beyond the original scope of IBIS. Bob Haller stated that the IBIS Cookbook (which needs to be updated) has some graphical representations. Lynne Green commented that users buy tools to do the work and engineers are more software literate, and the participants agreed that most IBIS models are created by junior level engineers. Raj Raghuram suggested that a university professor could write a book or produce more information on IBIS. Bob Ross noted that EDA Vendors and other commercial vendors often provide model training and model development support and also stated that Arpad Muranyi has a four hour Real-Time video IBIS tutorial that is available. Stephen Peters did acknowledge that the IBIS Specification could be clearer. PRESENTATIONS AND DISCUSSION TOPICS The rest of the meeting consisted of presentations and discussions. These notes capture some of the content and discussion. See the uploaded documents for more detail. FROM MODEL CREATOR TO MODEL USER Bob Haller, Cereva Networks Bob Haller started by showing that some public IBIS models still have a large number of errors. Bob showed an AC termination simulation where IBIS produced good results quickly. He also showed a simulation result where the Spice model was appropriate. Moving from model creator to model user, Bob now sees good and bad models. He commented that he can identify and fix models and provide some vendor feedback. Bob noted that given today's short design cycles one has to request models early. Market forces are generally driving model quality, but he still recommends verifying IBIS models in the lab. Bob then went on to give examples of typical model problems. He noted that the additional PCI loads will be handled in IBIS Version 4.0. However, there are improvements and vendors are more responsive. Bob stated that work is continuing on advances (Connector Specification, IBIS-X), and pointed to a number of resources. These includes Syed Huq's DesignCon 2000 paper as well as friends and colleagues. Bob Ross commented that some good models are produced by EDA and commercial vendors, and some of these vendor also help semiconductor vendors produce models. A PROPOSAL FOR s2ibis3 Paul Franzon and Michael Steer, North Carolina State University (NCSU) Paul Franzon via teleconference gave some background showing strong industrial connections and support for analog, RF and mixed mode research based on federal funding. Paul is proud of the earlier NCSU s2ibis and s2ibis2 contributions to IBIS and industry. A multi-university DARPA project covers a number of advanced modeling and simulation abstractions: Global Environment, Michael Steer, NCSU Digital Behavioral Modeling and SSN Macromodeling, Paul Franzon, NCSU Parasitic Extraction and Full Wave Modeling of Interconnect, Andreas Cangellaris, U. of Illinois Optoelectronic Modeling, Mark Neifeld, University of Arizona Paul gave an overview of the other activities. Regarding his topic, he planned a macromodeling tool for automatic accurate reduced-order SSN modeling of on-chip digital structures from full circuit descriptions. Its unique feature is a macromodel production tool similar to Spice2IBIS and a complete SSN macromodel conversion tool. Paul then covered point-by-point the s2ibis3 project requirements that were issued by the IBIS sub-committee. Some notable points include: C++ based, JAVA for graphics Flex and Bison and portability through GNU and Cygwin in MS Windows A separate IBIS parser may be developed Improved algorithms and configuration options. Improved Spice controls for improved convergence (e.g., Vdd ramping, more .options, fixing some clamping problems, data point and time, voltage step options, etc.) In addition, the goals are to support: GNU public license Class structures to support digital and analog macromodeling with IBIS as a subset Be applicable for board level modeling and modeling of segments of mixed signal chips The research agenda includes support of IBIS-X with SSN macromodeling, 3-D models, and testing and validating against Spice and measurement. Paul intends to have industrial collaborators. This 3-year DARPA effort will produce a spice2ibis3 and have strong industrial collaboration. Several questions and suggestions were discussed during the presentation. Ed Sayre and Lynne Green commented that the s2ibis3 utility should handle differential models and models with strong feedback (such as those having gate modulation). Numerical stability presents a challenge, and there was a long discussion regarding the utility of models and simulators supporting VDD ramping. Several people stated that they would investigate providing some industrial support. PROGRESS AND UPDATE ON THE CONNECTOR SPECIFICATION Stephen Peters, Intel Corporation Because of a conflicting meeting, Stephen Peters' two presentations were moved up to this position in the meeting. Stephen, via teleconference, stated that the IBIS Connector header and about three-fourths of the technical description have been reviewed. The Working Group plans to add the conductance matrix (G Matrix) for losses and also frequency dependent simulations. Both the LRGC and S-parameter formats are being considered. We expect a specification completion by the end of January 2002 if there are no unexpected technical issues. Stephen gave some more detail on changes including even_mode, odd_mode, and quiescent model types and Fork and Endfork under a [Path Description] keyword. Electrical matrix "row" order can be random, so a pin number to matrix map has been added. Stephen and others then discussed the advantages of using S-parameters versus RLGC matrices. S-parameters are more natural for frequency domain simulations while RLGC are more natural and familiar to engineers for time domain simulations. Ed asked if the inductance matrix was for partial or loop inductances. Bob Ross indicated that for full matrix the inductance is partial, however, there was some discussion on whether loop inductances are appropriate for single line models. After much discussion Stephen agreed to make sure that the connector specification fully documents partial vs. loop inductances and when each are used. PROGRESS AND ISSUES IN IBIS-X Stephen Peters, Intel Corporation Stephen Peters stated that a simpler path into IBIS is being pursued. Shortly after IBIS Version 4.0 is approved, the Working Group intends to issue a BIRD to add the [Define 'class name'] concept. The work is now focusing on the macro-language reference manual (IBIS-ML). This is being reviewed and should be available in January 2002. Stephen listed some technical milestones that have been met or are being tracked. Then Stephen described the [Define "class name"] keyword. He showed the syntax. It can be used in the IBIS file itself. Defines can be collected in a library file. Once an object is defined, it can be customized in the IBIS file. Ed Sayre asked about backward compatibility with IBIS Version 3.2, and Stephen said that IBIS Version 3.2 (and 4.0) will be supported by being defined in the macro language. MODELING THE RADIATED EMISSION OF MICRO-CONTROLLERS Christian Marot, Siemens, Andre Peyre Lavigne, Motorola, Claud Huet, Eads Airbus, Etienne Sicard, National Institute of Applied Science (INSA) After lunch, Etienne Sicard, via teleconference, introduced the need for EMC modeling of ICs. The industry is working with 0.12u, 6 metal technology with up to 200,000,000 devices and CPU frequencies of 1 GHz. The dI/dt switching speeds have become faster causing increased EMC problems. Etienne showed identical devices from different vendors. One device designed without considering radiation showed to be out of compliance by 20 to 40 dB compared to other chip. Currently EMC problems are found after the fact and require costly design iterations to correct. The IERSET (a European research institution for research in transportation) EMC project for ICs is co-sponsored by EADS Airbus, Siemens Automotive, Motorola, Alcatel, INSA, and IERSET. The objectives are to define and validate a model for PCB CAD tools to guarantee the EMC of electronic systems. Its focus is on a model from 1 MHz to 1 GHz for conducted and radiated emission. The French standards organization UTE has issued a draft Integrated Circuit Electromagnetic compatibility Model (ICEM) and forwarded it to IEC as a Committee Draft for Voting 62014-3. An ICEM Cookbook Version 1c is available. ICEM presentations and papers are planned at conferences, at company sites and at IBIS Summit meetings. Etienne described the core emission model and its basic parameters Cd and core noise generator Ib and advanced parameters for secondary resonance Rvdd, Lvdd, Rvss, Lvss and Cb. He gave typical values and showed some good measurement and simulation comparisons. In response to a question by Raj Raghuram, Etienne clarified that the measurements and simulations were for near field emissions. Scott McMorrow and others commented on the resonance terminology since the since all resonances including the "primary" resonance were many multiples above the 8 MHz fundamental clock frequency. In response to Lynne Green's question some typical values of all parameters were given (Cd - 300 pF to 20 nF, Cb - 1 nF, Lvdd and Lvss - 15 nH). The equivalent current generator was extracted through Verilog gate level simulation and simple statistical considerations. Spice and interpolated transistor level methods had either size or number of device limitations. The core emission model can be extended with an IBIS I/O model. An I/O buffer is added along with a Cio decoupling capacitor and a substrate resistance Zsub (typically 1 to 10 ohms). Etienne showed good simulation predictions with TEM cell measurements up to 300 MHz with the core emission model alone, and improved correlation up to 800 MHz when the I/O model was added. Etienne stressed that this is a relatively simple model that can be used for predicting parasitic emission of complex chips. Bob Ross added that a link to Etienne's work that includes several presentations and draft documents exists under: http://intrage.insa-tlse.fr/~etienne/Emc/index.html POWER/GND SIMULATION USING IBIS MODELS AND PIN MAPPING ISSUES Raj Raghuram, Sigrity, Inc. In introducing the subject Raj Raghuram stated that analysis based on ideal planes are no longer sufficient. Routing of traces through multiple layers and with vias is now common. Advanced signal and power integrity now combines the circuit along with trace transmission lines the pin RLC and non-ideal ground and power plane simulation. This can take care of power ground noise (SSN or Delta-I or ground bounce), effects of vias and return path discontinuity, effects of decoupling capacitors, and edge radiation from boards due to SSN. The approach he takes is to do combined circuit/transmission line/power/ ground simulation with IBIS models in the time domain (in contrast to a separate frequency domain power/ground analysis). He does need the [Pin Mapping] keyword for the IBIS models. Raj showed some topologies and some results. Full analysis distorts the signal, but well-placed decoupling capacitors can produce a nearly ideal response since return path and other discontinuities are bypassed. Raj provided plots illustrating the improvement provided by decoupling capacitors. Raj also illustrated some several types of devices with unique pin mapping requirements. These included separating different supplies and possible different clamp references from the buffer, core and I/O parts of the IC, and separating analog and digital ground pins. Raj stressed that [Pin Mapping] is essential and is a zeroth order effect in simulation that includes more accurate ground and power effects. Lynne Green asked if the decoupling capacitors had parasitic elements. Raj responded that they did not, but the RL information was available form the manufacturers and easy to add. IBIS-X PRIMITIVES AND EXAMPLE Lynne Green, Cadence Design Systems Lynne Green introduced IBIS Version 3.2 as having a fixed topology with some flexibility regarding values and allowable IBIS setups. She listed some usages of "model" in IBIS as a "circuit" model for a predefined topology, a "component" model for pins and packages and a "buffer" model for numbers, vectors, and data tables. IBIS-X retains the last two usages, but introduces a "behavioral" model where the model maker defines the topology. Lynne then used some examples to show some of the IBIS-X capability. The simple model under [Define Model] inherited an existing IBIS Version 3.2 buffer model as a "model_base", but added voltage and temperature dependent capacitor and resistor elements. Another example showed how resistor and capacitor tables could be specified. As second buffer had the same tables with different data. IBIS-X "behavioral" models add components that model effects (such as vsource), has symbolic values such as C_comp, has tables and equations for components, and can deal with other variables such as time and temperature. Lynne showed some primitives (resistor, capacitor, inductor, voltage and current sources, voltage controlled voltage and current sources, and transmission lines. She illustrated variations of the resistor primitive. The model maker provides the model behavior, the model data, and pin list. The users may provide pin lists (such as for FPGAs) and model selector information. Much discussion occurred during the presentation. Ed Sayre and others did feel that the syntax and terminology was confusing and did not relate to what engineers already know and use. We should use words with a common context. This should be raised as an issue for the Futures committee. It was not clear whether the set of primitives does or should include current and voltage controlled current sources. Engineers are already familiar with the set of four controlled sources. Options regarding coupled transmission line modeling were discussed. One suggestion was to have local temperature controlled resistors modeling thermal hot spots. IBIS-X will continue to support MKS units. There was some concern over how EDA vendors would support IBIS-X. Lynne concluded that IBIS-X should be regarded as an extension of IBIS. CORRELATION STUDY FOR DDR STYLE TERMINATIONS WITH IBIS MODELS (Unscheduled Presentation) Arpad Muranyi, Intel Corporation Arpad Muranyi investigated the accuracy of the recommended waveform loads with respect to the DDR style terminations such as 50 ohms to Vdd/2. He showed two sets of results: (1) V_fixture = 0, 5 V and R_fixture = 50 ohms (2) V_fixture = 2.5 V, R_fixture = 50 ohms Arpad's concern was that the results for (1) did not overlay for the DDR termination. Also the results for (2) overlayed for the DDR termination (same as the load), but gave bad results for 50 ohms to ground and Vdd for both the rising and falling edges. His results were based on the HSPICE B-element. Scott McMorrow suggested a larger load resistance such as 100 ohms for (1) because the voltages of the existing waveforms did not overlap center region. Bob Ross suggested exploring Vdd/2 and 2Vdd/3 voltages with 50 ohm loads to center the four waveform loads. Arpad plans to send the ibis model to EDA vendors to test in their own tools since they may have different algorithms. [Added note, the uploaded presentations show that Scott's and Bob's suggestions did not produce improved results] FINAL BUSINESS Bob Ross reported that the next IBIS Summit Meeting is scheduled on January 28, 2002 at DesignCon2002 in Santa Clara, California. We are also working on arrangements for an IBIS Summit Meeting on March 8, 2002 at Date 2002 in Paris, France. The weekly IBIS Working Groups on the Connector Specification and on IBIS-X will continue next week. Ed Sayre offered space at NESA to those who needed working facilities while waiting for their return trips. NEXT MEETING: The next teleconference meeting will be on Friday October 5, 2001 ============================================================================ NOTES IBIS CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-1831 stephen.peters@intel.com Senior Hardware Engineer, Intel Corporation M/S JF4-215 2111 NE 25th Ave. Hillsboro, OR 97124-5961 VICE CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Roy Leventhal (837) 797-2152, Fax: (847) 222-2799 roy_leventhal@3com.com Senior Engineer, CommWorks Corp. (a wholly owned 3Com subsidiary) 1800 W. Central Rd. Mt. Prospect, IL 60056-2293 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 jangulo@innoveda.com Development Engineer, Innoveda 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: majordomo@eda.org In the body, for the IBIS Open Forum Reflector: subscribe ibis In the body, for the IBIS Users' Group Reflector: subscribe ibis-users Help and other commands: help ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, and /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eigroup.org/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================ ------------------------------ Date: Thu, 20 Sep 2001 15:34:16 -0400 From: tcoyle Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Thu, 20 Sep 2001 16:34:26 -0700 From: "Lorang, David D" Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Thu, 20 Sep 2001 23:13:12 -0700 (PDT) From: Majordomo Account Subject: test - please ignore this is a test - please ignore. - --majordom@eda.org ------------------------------ Date: Fri, 21 Sep 2001 11:00:17 -0700 From: Frederic Giral Subject: ECL modeling - --------------A8AB4F56F4A95D722606C4A9 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Hello, I'm trying to built an IBIS model from a spice netlist using the s2ib2 software from the university of North Carolina. Would you have by chance an example of .s2i file to send me ? I would need a file including models for both differential ECL input and output. Regards, Frederic. - -- ********************************** Frederic GIRAL Tel:408-586-6891 Fax:408-586-4677 Pager:408-697-6195 Email:fgiral@san-jose.tt.slb.com SCHLUMBERGER ATE 150 Baytech Dr, San Jose, CA 95134 ********************************** - --------------A8AB4F56F4A95D722606C4A9 Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Hello,

I'm trying to built an IBIS model from a spice netlist using the s2ib2 software from the university of North Carolina.
Would you have by chance an example of .s2i file to send me ? I would need a file including models for both differential ECL input and output.

Regards, Frederic. 

-- 
**********************************
Frederic GIRAL                                    
                                  
Tel:408-586-6891
Fax:408-586-4677
Pager:408-697-6195                  
Email:fgiral@san-jose.tt.slb.com

SCHLUMBERGER ATE
150 Baytech Dr, San Jose, CA 95134  
**********************************
  - --------------A8AB4F56F4A95D722606C4A9-- ------------------------------ Date: Sat, 22 Sep 2001 09:01:24 -0700 From: "Jon Powell" Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Sat, 22 Sep 2001 09:09:33 -0700 From: "Jon Powell" Subject: RE: ECL modeling This is a multi-part message in MIME format. - ------=_NextPart_000_0027_01C14346.4BD449E0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Just a Note: I don't know how well s2ibis will work on ECL, because it is a current controled technology. On the other hand, it is also very linear and a thevinen equivalent model made by hand from from spice measurements would probably be very accurate. jon -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Frederic Giral Sent: Friday, September 21, 2001 11:00 AM To: ibis-users@eda.org Subject: ECL modeling Hello, I'm trying to built an IBIS model from a spice netlist using the s2ib2 software from the university of North Carolina. Would you have by chance an example of .s2i file to send me ? I would need a file including models for both differential ECL input and output. Regards, Frederic. - -- ********************************** Frederic GIRAL Tel:408-586-6891 Fax:408-586-4677 Pager:408-697-6195 Email:fgiral@san-jose.tt.slb.com SCHLUMBERGER ATE 150 Baytech Dr, San Jose, CA 95134 ********************************** - ------=_NextPart_000_0027_01C14346.4BD449E0 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable
Just a=20 Note:
I=20 don't know how well s2ibis will work on ECL, because it is a current = controled=20 technology.
On the=20 other hand, it is also very linear and a thevinen equivalent model made = by hand=20 from
from=20 spice measurements would probably be very accurate.
 
jon
 
-----Original Message-----
From: = owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org]On Behalf Of Frederic=20 Giral
Sent: Friday, September 21, 2001 11:00 = AM
To:=20 ibis-users@eda.org
Subject: ECL = modeling

Hello,=20

I'm trying to built an IBIS model from a spice netlist using = the s2ib2=20 software from the university of North Carolina.
Would you have by = chance=20 an example of .s2i file to send me ? I would need a file including = models for=20 both differential ECL input and output.=20

Regards, Frederic. 

-- 
**********************************
Frederic =
GIRAL           &n=
bsp;           &nb=
sp;           &nbs=
p;
            &=
nbsp;           &n=
bsp;         
Tel:408-586-6891
Fax:408-586-4677
Pager:408-697-6195         &=
nbsp;        
Email:fgiral@san-jose.tt.slb.com

SCHLUMBERGER ATE
150 Baytech Dr, San Jose, CA 95134  
**********************************
  =
- ------=_NextPart_000_0027_01C14346.4BD449E0-- ------------------------------ Date: Sat, 22 Sep 2001 18:28:43 -0700 (PDT) From: john austin Subject: RE: ibis Thank You Tom. - --- "Dagostino, Tom" wrote: > Going from a released spec, one that a semiconductor > manufacturer will send out will lead you to a much > weaker model than the actual silicon. For example a > typical part will have a Vol of 0.4V at 8 mA. In > reality that driver will be 3 to 5 times stronger, > 24 to 40 mA at 0.4V. The same applies to Voh. Most > semiconductor datasheets do not specify rise and > fall times so you will have to guess a transition > time. You cannot just look at the underlying > process used and make a guess because there may be > structures in the output that control the slew rate. > If you have rise and fall time specs in the > datasheet they are likely to be accurate. > > You will also need to know if there is a power clamp > in the device. > > For inputs the major items are what clamps and > Ccomp. The rest of the data can be pulled from the > datasheet. > > Your best bet is to find another part from that > manufacturer's process and copy that model assuming > you can find one with the same output buffer used. > If you have a sample you can make some measurements > if you have power supplies, a high speed scope and > some means of measuring the IV characteristics. > > Tom Dagostino > Modeling Manager > Mentor Graphics Corp. > SAE > tom_dagostino@mentor.com > 503-685-1613 > > > -----Original Message----- > From: john austin [mailto:john_austinus@yahoo.com] > Sent: Tuesday, September 18, 2001 8:58 AM > To: Adam.Tambone@fairchildsemi.com > Cc: ibis-users@eda.org > Subject: Re: ibis > > > I have spec which specify the AC, DC requirement. > The specs contain V/I curves pullup & pulldown. > Also, > the references curves of the pullup and pulldown. > > I am looking to write an approximate behavioral > model > for it. So I want to know what equations or > portions > of the specs I need to pay attention to, to create > V/I > tables, rising & falling waveforms. > > I have some idea on how to proceed( based on other > IBIS models) but still I wanted to see a methodology > or guidelines already used by an expert. > > Thanks > > --- Adam.Tambone@fairchildsemi.com wrote: > > > > John, could you be more specific? > > > > Adam > > > > > > > > > > > > > > john austin @eda.org on > > 09/17/2001 07:11:34 PM > > > > Sent by: owner-ibis-users@eda.org > > > > > > To: ibis-users@eda.org > > cc: > > > > Subject: ibis > > > > > > If I want to create a behavioral model out of a > > spec. > > Could you please let me know what I should watch > > for? > > Also, if there is any documents or paper out there > > that facilitate the task? > > > > Thanks > > > > __________________________________________________ > > Terrorist Attacks on U.S. - How can you help? > > Donate cash, emergency relief information > > > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > > > > > > > __________________________________________________ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com ------------------------------ Date: Sat, 22 Sep 2001 18:34:20 -0700 (PDT) From: john austin Subject: Archives Is there archives for the questions and responses of this list? Thanks __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com ------------------------------ Date: Mon, 24 Sep 2001 09:54:21 -0400 From: Adam.Tambone@fairchildsemi.com Subject: RE: Duty Cycle hmmm... OK, here is another two cents, but I do not believe it disagrees with the previous remarks. I have found through experience that the raw rising and falling waveform data does not in itself represent correct duty cycle. Instead this data must be modified to 'fit' the devices actual duty cycle. One can modify the R/F V-t data in a number of ways including editing the delay region ( before the rising and falling edges occur ) to fit duty cycles at specific frequencies found thorough laboratory measurement. Since duty cycle can vary over frequency I have found it best to leave R/F V-t data in it's raw state, and with R and F relative to each other as David described. Here is an example with HSPICE that illustrates that the raw R/F V-t data itself does not represent correct duty cycle. One has R/F V-t data through HSPICE simulation and has included this data in an IBIS datasheet. Then this IBIS datasheet is used in HSPICE simulation comparing it to the original HSPICE sims used to generate the IBIS datasheet. I have found through experience that the duty cycles of the simulated IBIS datasheet will not be the same as the duty cycles of the HSPICE model of the device, especially as frequency varies. Like Jon said, simulator vendors have their own algorithms to process R/F V-t data in order to form a desired duty cycle. Adam Tambone "Jon Powell" @eda.org on 09/22/2001 12:01:24 PM Sent by: owner-ibis-users@eda.org To: "'Lorang, David D'" cc: Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Mon, 24 Sep 2001 08:33:36 -0700 From: "Ross, Bob" Subject: Re: Archives This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C1450E.A6009800 Content-Type: text/plain John: Current email archives are available under: http://www.eda.org/pub/ibis/users_archive and http://www.eda.org/pub/ibis/email_archive Older email archives since 1993 for the IBIS reflector and ibis-users reflectors are under: http://www.eda.org/pub/ibis/email/ Bob Ross Mentor Graphics john austin wrote: > > Is there archives for the questions and responses of > this list? > > Thanks > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com - ------_=_NextPart_001_01C1450E.A6009800 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: Archives

John:

Current email archives are available under:

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

and

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


Older email archives since 1993 for the IBIS
reflector and ibis-users reflectors are = under:

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

Bob Ross
Mentor Graphics

 


john austin wrote:
>
> Is there archives for the questions and = responses of
> this list?
>
> Thanks
>
> = __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant = messaging with Yahoo! Messenger. http://im.yahoo.com

- ------_=_NextPart_001_01C1450E.A6009800-- ------------------------------ Date: Mon, 24 Sep 2001 09:13:42 -0700 From: "Lorang, David D" Subject: RE: Duty Cycle Jon, I'm not sure I understand what you are disagreeing with, but let me take another shot an see if I can clear things up a little more. Please understand that although originally it wasn't clear in IBIS how the timing between rising and falling edges were related, BIRD 68.1 was written to clarify that some information could be conveyed in the IBIS file regarding the relationship between rising and falling edges (Rising vs. falling edge timing will affect the duty cycle of a periodic waveform.) So before BIRD 68.1, it was no surprise that simulation engines interpreted the waveform data in a variety of ways. Even now that BIRD 68.1 is approved, it is probably safe to say that simulation engines still interpret the waveform data in a variety of ways. Any changes that do happen won't occur overnight. Hence IBIS, even with BIRD 68.1 applied, cannot guarantee that, for example, the duty cycle of a waveform will come out as expected, (i.e. matching what is happening in the silicon.) It is likely that the waveform timings will often still need to be "manually" adjusted, and there are tools in at least some simulation engines to do that. What BIRD 68.1 does do is to specify that the relative timing information will be there in the IBIS file, so that simulation engine developers at least have a chance (in a specified, and perhaps more automated manner) to eventually maintain timing relationships between rising and falling edges. So now, at least, the hooks are there. Dave Lorang - -----Original Message----- From: Jon Powell [mailto:jpowell@innoveda.com] Sent: Saturday, September 22, 2001 9:01 AM To: 'Lorang, David D' Cc: ibis-users@eda.org Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Mon, 24 Sep 2001 09:38:29 -0700 (PDT) From: Syed Huq Subject: ibischk3 and Open Drain For ibischk3 ver 3.2.6, it looks for the Pullup table for a "I/O_open_drain" buffer. Why is that ? WARNING - [Model] GTL has no description of the buffer's high state DC drive characteristics (no [Pullup] table). This warning can be silenced by changing the Model_type or by adding a [Pullup] table. - -Syed ------------------------------ Date: Mon, 24 Sep 2001 12:45:43 -0400 From: "Todd Westerhoff" Subject: RE: Duty Cycle I agree with Jon. IBIS models are not meant, by default, to represent a device's duty cycle. You can get the model to produce the correct behavior if you're careful with your modeling - but the tools typically used to create IBIS models will not automatically produce a model that reflects the device's duty cycle. Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Adam.Tambone@fairchildsemi.com Sent: Monday, September 24, 2001 9:54 AM To: Jon Powell Cc: ibis-users@eda.org Subject: RE: Duty Cycle hmmm... OK, here is another two cents, but I do not believe it disagrees with the previous remarks. I have found through experience that the raw rising and falling waveform data does not in itself represent correct duty cycle. Instead this data must be modified to 'fit' the devices actual duty cycle. One can modify the R/F V-t data in a number of ways including editing the delay region ( before the rising and falling edges occur ) to fit duty cycles at specific frequencies found thorough laboratory measurement. Since duty cycle can vary over frequency I have found it best to leave R/F V-t data in it's raw state, and with R and F relative to each other as David described. Here is an example with HSPICE that illustrates that the raw R/F V-t data itself does not represent correct duty cycle. One has R/F V-t data through HSPICE simulation and has included this data in an IBIS datasheet. Then this IBIS datasheet is used in HSPICE simulation comparing it to the original HSPICE sims used to generate the IBIS datasheet. I have found through experience that the duty cycles of the simulated IBIS datasheet will not be the same as the duty cycles of the HSPICE model of the device, especially as frequency varies. Like Jon said, simulator vendors have their own algorithms to process R/F V-t data in order to form a desired duty cycle. Adam Tambone "Jon Powell" @eda.org on 09/22/2001 12:01:24 PM Sent by: owner-ibis-users@eda.org To: "'Lorang, David D'" cc: Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Mon, 24 Sep 2001 10:26:42 -0700 From: "Mirmak, Michael" Subject: RE: ibischk3 and Open Drain Syed, This was covered in Bug 53 (an amendment to Bug 34). It will most likely get fixed in the next IBISCHK3 release; Bob Ross can confirm when this will be available. - - Michael Mirmak, Intel Corp. - -----Original Message----- From: Syed Huq [mailto:shuq@cisco.com] Sent: Monday, September 24, 2001 9:38 AM To: ibis-users@eda.org Subject: ibischk3 and Open Drain For ibischk3 ver 3.2.6, it looks for the Pullup table for a "I/O_open_drain" buffer. Why is that ? WARNING - [Model] GTL has no description of the buffer's high state DC drive characteristics (no [Pullup] table). This warning can be silenced by changing the Model_type or by adding a [Pullup] table. - -Syed ------------------------------ Date: Mon, 24 Sep 2001 10:38:35 -0700 From: "Matthew Flora" Subject: Re: ibischk3 and Open Drain Hi Syed, That bug was fixed some time ago. Grab a copy of ibischk3 ver 3.2.7 from the EIA IBIS page and the problem should go away. Cheers, Matthew Flora - ----- Original Message ----- From: "Syed Huq" To: Sent: Monday, September 24, 2001 9:38 AM Subject: ibischk3 and Open Drain > For ibischk3 ver 3.2.6, it looks for the Pullup table for a "I/O_open_drain" > buffer. Why is that ? > > WARNING - [Model] GTL has no description of the buffer's high state > DC drive characteristics (no [Pullup] table). This warning > can be silenced by changing the Model_type or by adding a > [Pullup] table. > > -Syed > ------------------------------ Date: Mon, 24 Sep 2001 14:37:47 -0700 (PDT) From: john austin Subject: Re: Archives Thank You. - --- "Ross, Bob" wrote: > John: > > Current email archives are available under: > > http://www.eda.org/pub/ibis/users_archive > > and > > http://www.eda.org/pub/ibis/email_archive > > > Older email archives since 1993 for the IBIS > reflector and ibis-users reflectors are under: > > http://www.eda.org/pub/ibis/email/ > > Bob Ross > Mentor Graphics > > > > > john austin wrote: > > > > Is there archives for the questions and responses > of > > this list? > > > > Thanks > > > > __________________________________________________ > > Do You Yahoo!? > > Get email alerts & NEW webcam video instant > messaging with Yahoo! > Messenger. http://im.yahoo.com > __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com ------------------------------ Date: Tue, 25 Sep 2001 18:15:30 -0400 From: "Todd Westerhoff" Subject: RE: Duty Cycle Dave, et al., Well, now I realize my comment was out of context, as I was referring to IBIS as-is-in-current-practice, instead of IBIS as-it-would-be with BIRD 68.1. I can see that BIRD 68.1 would allow IBIS models to do a better job of predicting ISI caused by duty cycle assymetry in the driver. If I'm reading the BIRD correctly, this is a modeling issue, and not a tool issue, correct? It seems to me there are no tool changes required, providing the SI tools do not "alter" the V/T data in the IBIS waveforms prior to their use. If that were the case, it would seem to me that we could start producing models to the updated spec immediately. Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Monday, September 24, 2001 12:14 PM To: 'Jon Powell'; Lorang, David D Cc: ibis-users@eda.org Subject: RE: Duty Cycle Jon, I'm not sure I understand what you are disagreeing with, but let me take another shot an see if I can clear things up a little more. Please understand that although originally it wasn't clear in IBIS how the timing between rising and falling edges were related, BIRD 68.1 was written to clarify that some information could be conveyed in the IBIS file regarding the relationship between rising and falling edges (Rising vs. falling edge timing will affect the duty cycle of a periodic waveform.) So before BIRD 68.1, it was no surprise that simulation engines interpreted the waveform data in a variety of ways. Even now that BIRD 68.1 is approved, it is probably safe to say that simulation engines still interpret the waveform data in a variety of ways. Any changes that do happen won't occur overnight. Hence IBIS, even with BIRD 68.1 applied, cannot guarantee that, for example, the duty cycle of a waveform will come out as expected, (i.e. matching what is happening in the silicon.) It is likely that the waveform timings will often still need to be "manually" adjusted, and there are tools in at least some simulation engines to do that. What BIRD 68.1 does do is to specify that the relative timing information will be there in the IBIS file, so that simulation engine developers at least have a chance (in a specified, and perhaps more automated manner) to eventually maintain timing relationships between rising and falling edges. So now, at least, the hooks are there. Dave Lorang - -----Original Message----- From: Jon Powell [mailto:jpowell@innoveda.com] Sent: Saturday, September 22, 2001 9:01 AM To: 'Lorang, David D' Cc: ibis-users@eda.org Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Tue, 25 Sep 2001 16:07:40 -0700 From: "Jeremy Plunkett" Subject: RE: Duty Cycle Todd, I don't know the intentions of the authors of the IBIS spec, however there are some simple choices in the process of generating an IBIS model and using the data that will guarantee that duty cycle will be preserved. This has been the case with IBIS models that I have developed myself and compared to the original spice netlist using the hspice B element(barring other simulation errors and B-element bugs, that is). At the time the original IBIS spec was defined, Tco differences between rising and falling edges were a small fraction of the data bit cell width, so many tools may have been sloppy(relative to our current requirements) in their implementation and traded off accurate preservation of rise-fall timing in order to make the model smaller or simpler to process. Whatever the reason, these implementations cause problems today--if the duty cycle information is not accurately preserved in the IBIS model, then the user is required to manually adjust the duty cycle based on part specs in order to have the correct duty cycle in simulation(as you mention below). Since the duty cycle error if this is not done affects the waveforms and their accuracy with respect to ISI/crosstalk but does not cause any blatant timing violation (due to the use of time-to-Vm adjustment), it is likely to be missed by users unless it is visually obvious when looking at the waveforms. It would be a very good thing for makers of SI tools to see what they can do to preserve the rise-fall relationships present in the IBIS model Vt waveforms(per bird 68.1). Also, anyone generating IBIS models today should be sure to generate all Vt curves off of the same internal clock edge if they don't do so already, and if they remove any portion of the curves do it to all curves equally. regards, Jeremy Plunkett Signal Integrity Engineer ServerWorks Corporation jeremy@serverworks.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Todd Westerhoff Sent: Monday, September 24, 2001 9:46 AM To: ibis-users@eda.org Subject: RE: Duty Cycle I agree with Jon. IBIS models are not meant, by default, to represent a device's duty cycle. You can get the model to produce the correct behavior if you're careful with your modeling - but the tools typically used to create IBIS models will not automatically produce a model that reflects the device's duty cycle. Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Adam.Tambone@fairchildsemi.com Sent: Monday, September 24, 2001 9:54 AM To: Jon Powell Cc: ibis-users@eda.org Subject: RE: Duty Cycle hmmm... OK, here is another two cents, but I do not believe it disagrees with the previous remarks. I have found through experience that the raw rising and falling waveform data does not in itself represent correct duty cycle. Instead this data must be modified to 'fit' the devices actual duty cycle. One can modify the R/F V-t data in a number of ways including editing the delay region ( before the rising and falling edges occur ) to fit duty cycles at specific frequencies found thorough laboratory measurement. Since duty cycle can vary over frequency I have found it best to leave R/F V-t data in it's raw state, and with R and F relative to each other as David described. Here is an example with HSPICE that illustrates that the raw R/F V-t data itself does not represent correct duty cycle. One has R/F V-t data through HSPICE simulation and has included this data in an IBIS datasheet. Then this IBIS datasheet is used in HSPICE simulation comparing it to the original HSPICE sims used to generate the IBIS datasheet. I have found through experience that the duty cycles of the simulated IBIS datasheet will not be the same as the duty cycles of the HSPICE model of the device, especially as frequency varies. Like Jon said, simulator vendors have their own algorithms to process R/F V-t data in order to form a desired duty cycle. Adam Tambone "Jon Powell" @eda.org on 09/22/2001 12:01:24 PM Sent by: owner-ibis-users@eda.org To: "'Lorang, David D'" cc: Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Wed, 26 Sep 2001 14:21:17 -0700 From: "Jon Powell" Subject: RE: Duty Cycle Are we really talking "Duty Cycle" here or is this really a difference of internal delay between rising and falling signals. example: We have a simple clock buffer. The data takes longer go through the buffer on 0-1 than on 1-0 is that what we are talking about? (if not, please give real example) jon - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Jeremy Plunkett Sent: Tuesday, September 25, 2001 4:08 PM To: 'Todd Westerhoff'; ibis-users@eda.org Subject: RE: Duty Cycle Todd, I don't know the intentions of the authors of the IBIS spec, however there are some simple choices in the process of generating an IBIS model and using the data that will guarantee that duty cycle will be preserved. This has been the case with IBIS models that I have developed myself and compared to the original spice netlist using the hspice B element(barring other simulation errors and B-element bugs, that is). At the time the original IBIS spec was defined, Tco differences between rising and falling edges were a small fraction of the data bit cell width, so many tools may have been sloppy(relative to our current requirements) in their implementation and traded off accurate preservation of rise-fall timing in order to make the model smaller or simpler to process. Whatever the reason, these implementations cause problems today--if the duty cycle information is not accurately preserved in the IBIS model, then the user is required to manually adjust the duty cycle based on part specs in order to have the correct duty cycle in simulation(as you mention below). Since the duty cycle error if this is not done affects the waveforms and their accuracy with respect to ISI/crosstalk but does not cause any blatant timing violation (due to the use of time-to-Vm adjustment), it is likely to be missed by users unless it is visually obvious when looking at the waveforms. It would be a very good thing for makers of SI tools to see what they can do to preserve the rise-fall relationships present in the IBIS model Vt waveforms(per bird 68.1). Also, anyone generating IBIS models today should be sure to generate all Vt curves off of the same internal clock edge if they don't do so already, and if they remove any portion of the curves do it to all curves equally. regards, Jeremy Plunkett Signal Integrity Engineer ServerWorks Corporation jeremy@serverworks.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Todd Westerhoff Sent: Monday, September 24, 2001 9:46 AM To: ibis-users@eda.org Subject: RE: Duty Cycle I agree with Jon. IBIS models are not meant, by default, to represent a device's duty cycle. You can get the model to produce the correct behavior if you're careful with your modeling - but the tools typically used to create IBIS models will not automatically produce a model that reflects the device's duty cycle. Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Adam.Tambone@fairchildsemi.com Sent: Monday, September 24, 2001 9:54 AM To: Jon Powell Cc: ibis-users@eda.org Subject: RE: Duty Cycle hmmm... OK, here is another two cents, but I do not believe it disagrees with the previous remarks. I have found through experience that the raw rising and falling waveform data does not in itself represent correct duty cycle. Instead this data must be modified to 'fit' the devices actual duty cycle. One can modify the R/F V-t data in a number of ways including editing the delay region ( before the rising and falling edges occur ) to fit duty cycles at specific frequencies found thorough laboratory measurement. Since duty cycle can vary over frequency I have found it best to leave R/F V-t data in it's raw state, and with R and F relative to each other as David described. Here is an example with HSPICE that illustrates that the raw R/F V-t data itself does not represent correct duty cycle. One has R/F V-t data through HSPICE simulation and has included this data in an IBIS datasheet. Then this IBIS datasheet is used in HSPICE simulation comparing it to the original HSPICE sims used to generate the IBIS datasheet. I have found through experience that the duty cycles of the simulated IBIS datasheet will not be the same as the duty cycles of the HSPICE model of the device, especially as frequency varies. Like Jon said, simulator vendors have their own algorithms to process R/F V-t data in order to form a desired duty cycle. Adam Tambone "Jon Powell" @eda.org on 09/22/2001 12:01:24 PM Sent by: owner-ibis-users@eda.org To: "'Lorang, David D'" cc: Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Wed, 26 Sep 2001 15:51:03 -0400 From: "Todd Westerhoff" Subject: RE: Duty Cycle Jon, I think the answer here is: yes and no. Yes, because we want to model the effect of the differing prop delays on the output, and no, because we're not trying to be able to explicitly isolate the delay through the output buffer. The BIRD talks about being able to correctly predict ISI - and that's just what I took away from it. If the IBIS model won't correctly predict the percentages of time the signal spends high and low in a cycle - then doing any kind of random data / eye diagram analysis is pointless. We find that kind of analysis very useful, and want to be able to interchange IBIS and HSpice modeling with consistent results. If the model doesn't follow the points outlined in BIRD 68.1, then it seems unlikely that the two sets of results would correlate. Make sense? Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: Jon Powell [mailto:jpowell@innoveda.com] Sent: Wednesday, September 26, 2001 5:21 PM To: 'Jeremy Plunkett'; 'Todd Westerhoff'; ibis-users@eda.org Subject: RE: Duty Cycle Are we really talking "Duty Cycle" here or is this really a difference of internal delay between rising and falling signals. example: We have a simple clock buffer. The data takes longer go through the buffer on 0-1 than on 1-0 is that what we are talking about? (if not, please give real example) jon - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Jeremy Plunkett Sent: Tuesday, September 25, 2001 4:08 PM To: 'Todd Westerhoff'; ibis-users@eda.org Subject: RE: Duty Cycle Todd, I don't know the intentions of the authors of the IBIS spec, however there are some simple choices in the process of generating an IBIS model and using the data that will guarantee that duty cycle will be preserved. This has been the case with IBIS models that I have developed myself and compared to the original spice netlist using the hspice B element(barring other simulation errors and B-element bugs, that is). At the time the original IBIS spec was defined, Tco differences between rising and falling edges were a small fraction of the data bit cell width, so many tools may have been sloppy(relative to our current requirements) in their implementation and traded off accurate preservation of rise-fall timing in order to make the model smaller or simpler to process. Whatever the reason, these implementations cause problems today--if the duty cycle information is not accurately preserved in the IBIS model, then the user is required to manually adjust the duty cycle based on part specs in order to have the correct duty cycle in simulation(as you mention below). Since the duty cycle error if this is not done affects the waveforms and their accuracy with respect to ISI/crosstalk but does not cause any blatant timing violation (due to the use of time-to-Vm adjustment), it is likely to be missed by users unless it is visually obvious when looking at the waveforms. It would be a very good thing for makers of SI tools to see what they can do to preserve the rise-fall relationships present in the IBIS model Vt waveforms(per bird 68.1). Also, anyone generating IBIS models today should be sure to generate all Vt curves off of the same internal clock edge if they don't do so already, and if they remove any portion of the curves do it to all curves equally. regards, Jeremy Plunkett Signal Integrity Engineer ServerWorks Corporation jeremy@serverworks.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Todd Westerhoff Sent: Monday, September 24, 2001 9:46 AM To: ibis-users@eda.org Subject: RE: Duty Cycle I agree with Jon. IBIS models are not meant, by default, to represent a device's duty cycle. You can get the model to produce the correct behavior if you're careful with your modeling - but the tools typically used to create IBIS models will not automatically produce a model that reflects the device's duty cycle. Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Adam.Tambone@fairchildsemi.com Sent: Monday, September 24, 2001 9:54 AM To: Jon Powell Cc: ibis-users@eda.org Subject: RE: Duty Cycle hmmm... OK, here is another two cents, but I do not believe it disagrees with the previous remarks. I have found through experience that the raw rising and falling waveform data does not in itself represent correct duty cycle. Instead this data must be modified to 'fit' the devices actual duty cycle. One can modify the R/F V-t data in a number of ways including editing the delay region ( before the rising and falling edges occur ) to fit duty cycles at specific frequencies found thorough laboratory measurement. Since duty cycle can vary over frequency I have found it best to leave R/F V-t data in it's raw state, and with R and F relative to each other as David described. Here is an example with HSPICE that illustrates that the raw R/F V-t data itself does not represent correct duty cycle. One has R/F V-t data through HSPICE simulation and has included this data in an IBIS datasheet. Then this IBIS datasheet is used in HSPICE simulation comparing it to the original HSPICE sims used to generate the IBIS datasheet. I have found through experience that the duty cycles of the simulated IBIS datasheet will not be the same as the duty cycles of the HSPICE model of the device, especially as frequency varies. Like Jon said, simulator vendors have their own algorithms to process R/F V-t data in order to form a desired duty cycle. Adam Tambone "Jon Powell" @eda.org on 09/22/2001 12:01:24 PM Sent by: owner-ibis-users@eda.org To: "'Lorang, David D'" cc: Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Wed, 26 Sep 2001 11:13:34 -0700 From: "Muranyi, Arpad" Subject: Thank you messages? While it is a nice gesture to thank someone for the response they wrote, it is also annoying to have to open a bunch of meaningless messages on these reflectors (which are quite active already as it is). I would suggest that if someone really wants to say thanks for the answers they got they should ONLY send it to the person they got it from. This could reduce unnecessary network traffic and could save some time for the rest of us... Thanks, Arpad Muranyi Itel Corporation ================================================================ - -----Original Message----- From: john austin [mailto:john_austinus@yahoo.com] Sent: Monday, September 24, 2001 2:38 PM To: Ross, Bob Cc: ibis-users@eda.org; ibis@eda.org Subject: Re: Archives Thank You. - --- "Ross, Bob" wrote: > John: > > Current email archives are available under: > > http://www.eda.org/pub/ibis/users_archive > > and > > http://www.eda.org/pub/ibis/email_archive > > > Older email archives since 1993 for the IBIS > reflector and ibis-users reflectors are under: > > http://www.eda.org/pub/ibis/email/ > > Bob Ross > Mentor Graphics ------------------------------ Date: Wed, 26 Sep 2001 16:46:04 -0700 From: "Jeremy Plunkett" Subject: RE: Duty Cycle Well said, Todd. I would just like to add that even without bird 68.1, the default method of generating IBIS data from a spice netlist will in most cases produce Vt curves with accurate rising and falling Tco delays included. However, the person formatting the data into the model and the simulation tool using the model must both be conscientious in doing all editing/removal of time points on all curves together to maintain the rising/falling relationship. This has not been the case for many models and simulation tools to date, but it isn't difficult. In answer to Jon's original question, in the typical situations where I use IBIS models, it's the same thing--the duty cycle of the signal(at the driver output pad) is determined by the difference in output delay on rising and falling transitions. This is because the internal logic for most source-synchronous busses uses one edge of a clock at 2x the bus frequency to generate the output transitions. Regards, Jeremy - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Todd Westerhoff Sent: Wednesday, September 26, 2001 12:51 PM To: ibis-users@eda.org Subject: RE: Duty Cycle Jon, I think the answer here is: yes and no. Yes, because we want to model the effect of the differing prop delays on the output, and no, because we're not trying to be able to explicitly isolate the delay through the output buffer. The BIRD talks about being able to correctly predict ISI - and that's just what I took away from it. If the IBIS model won't correctly predict the percentages of time the signal spends high and low in a cycle - then doing any kind of random data / eye diagram analysis is pointless. We find that kind of analysis very useful, and want to be able to interchange IBIS and HSpice modeling with consistent results. If the model doesn't follow the points outlined in BIRD 68.1, then it seems unlikely that the two sets of results would correlate. Make sense? Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: Jon Powell [mailto:jpowell@innoveda.com] Sent: Wednesday, September 26, 2001 5:21 PM To: 'Jeremy Plunkett'; 'Todd Westerhoff'; ibis-users@eda.org Subject: RE: Duty Cycle Are we really talking "Duty Cycle" here or is this really a difference of internal delay between rising and falling signals. example: We have a simple clock buffer. The data takes longer go through the buffer on 0-1 than on 1-0 is that what we are talking about? (if not, please give real example) jon - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Jeremy Plunkett Sent: Tuesday, September 25, 2001 4:08 PM To: 'Todd Westerhoff'; ibis-users@eda.org Subject: RE: Duty Cycle Todd, I don't know the intentions of the authors of the IBIS spec, however there are some simple choices in the process of generating an IBIS model and using the data that will guarantee that duty cycle will be preserved. This has been the case with IBIS models that I have developed myself and compared to the original spice netlist using the hspice B element(barring other simulation errors and B-element bugs, that is). At the time the original IBIS spec was defined, Tco differences between rising and falling edges were a small fraction of the data bit cell width, so many tools may have been sloppy(relative to our current requirements) in their implementation and traded off accurate preservation of rise-fall timing in order to make the model smaller or simpler to process. Whatever the reason, these implementations cause problems today--if the duty cycle information is not accurately preserved in the IBIS model, then the user is required to manually adjust the duty cycle based on part specs in order to have the correct duty cycle in simulation(as you mention below). Since the duty cycle error if this is not done affects the waveforms and their accuracy with respect to ISI/crosstalk but does not cause any blatant timing violation (due to the use of time-to-Vm adjustment), it is likely to be missed by users unless it is visually obvious when looking at the waveforms. It would be a very good thing for makers of SI tools to see what they can do to preserve the rise-fall relationships present in the IBIS model Vt waveforms(per bird 68.1). Also, anyone generating IBIS models today should be sure to generate all Vt curves off of the same internal clock edge if they don't do so already, and if they remove any portion of the curves do it to all curves equally. regards, Jeremy Plunkett Signal Integrity Engineer ServerWorks Corporation jeremy@serverworks.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Todd Westerhoff Sent: Monday, September 24, 2001 9:46 AM To: ibis-users@eda.org Subject: RE: Duty Cycle I agree with Jon. IBIS models are not meant, by default, to represent a device's duty cycle. You can get the model to produce the correct behavior if you're careful with your modeling - but the tools typically used to create IBIS models will not automatically produce a model that reflects the device's duty cycle. Todd. Todd Westerhoff SI Engineer - Hammerhead Networks 5 Federal Street - Billerica, MA - 01821 email:twester@hhnetwk.com - ph: 978-671-5084 ============================================ "Oh, but ain't that America, for you and me Ain't that America, we're something to see Ain't that America, Home of the Free Little pink houses, for you and me" - - John Mellencamp - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Adam.Tambone@fairchildsemi.com Sent: Monday, September 24, 2001 9:54 AM To: Jon Powell Cc: ibis-users@eda.org Subject: RE: Duty Cycle hmmm... OK, here is another two cents, but I do not believe it disagrees with the previous remarks. I have found through experience that the raw rising and falling waveform data does not in itself represent correct duty cycle. Instead this data must be modified to 'fit' the devices actual duty cycle. One can modify the R/F V-t data in a number of ways including editing the delay region ( before the rising and falling edges occur ) to fit duty cycles at specific frequencies found thorough laboratory measurement. Since duty cycle can vary over frequency I have found it best to leave R/F V-t data in it's raw state, and with R and F relative to each other as David described. Here is an example with HSPICE that illustrates that the raw R/F V-t data itself does not represent correct duty cycle. One has R/F V-t data through HSPICE simulation and has included this data in an IBIS datasheet. Then this IBIS datasheet is used in HSPICE simulation comparing it to the original HSPICE sims used to generate the IBIS datasheet. I have found through experience that the duty cycles of the simulated IBIS datasheet will not be the same as the duty cycles of the HSPICE model of the device, especially as frequency varies. Like Jon said, simulator vendors have their own algorithms to process R/F V-t data in order to form a desired duty cycle. Adam Tambone "Jon Powell" @eda.org on 09/22/2001 12:01:24 PM Sent by: owner-ibis-users@eda.org To: "'Lorang, David D'" cc: Subject: RE: Duty Cycle I have to disagree. This isn't how IBIS is defined and speifically isn't how most simulation engines interpret the waveform data. The Waveform data cannot be used to specify duty cycle, however, this is an option in most native IBIS simulators and you should contact your simulator vendor for specifics on implementing different duty cycles for different clocks etc. regards, Jon Powell Innoveda Consulting Services - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lorang, David D Sent: Thursday, September 20, 2001 4:34 PM To: 'tcoyle' Cc: ibis-users@eda.org Subject: RE: Duty Cycle Tim, I think you have it right. Let's take the example of a clocked synchronous design where a chip has a some clock input and a data output. Suppose output data changes on every rising clock edge. You might have a specification for Tco delay of maybe 2ns, or whatever, for both rising edge and falling edge data. Then suppose you are using a SPICE simulation of some buffer to generate your voltage vs. time data to create an IBIS file. You would might run two simulations each where the rising edge of the input clock starts at time 0ns: one for rising data, one for falling data. The two simulations would generate two output V-T tables that would have their rising and falling edges correlated, because they both were timed from a clock starting at the same time (0 ns). From the tabular output files, for those two sims you could create two IBIS V-T tables. Where exactly the output edges occur is dependent on internal buffer delays, and that is not important, but where the two edges occur relative to each other is important. So you make sure you handle both tables in the same way when you import them into the IBIS file. You may decide to eliminate the internal buffer delay--commonly done to make sure that the tables contain mostly edge data--and if you took 1.5ns out of the front of one VT table, you would want to take the same amount out of the other. All of this is just to make sure that the IBIS file retains information concerning the timing relationship between the two edges. For this example so far I am assuming only one load configuration, perhaps, a 50 Ohm resistor to ground. For the other load configuration (resistor to supply), you would go through the same steps again and observe the same precautions. In the end you would have four V-T tables, with their waveforms all correlated. So, in summary, you need to correlate rising and falling edges in the same way you correlate the two load configurations. Have I answered your question? Dave Lorang - -----Original Message----- From: tcoyle [mailto:TCoyle@pdcme.fairchildsemi.com] Sent: Thursday, September 20, 2001 12:34 PM To: ibis-users@eda.org Subject: Duty Cycle Dear List, I have some questions regarding Bird 68.1 and duty cycle. I understand that IBIS does not guarantee propogation delays, but if the rising and falling waveform data is correlated then duty cycle can be maintained. I'm not sure I understand how you taking rising /falling data to ensure duty cycle? Is it a matter of doing the same transient analysis for rising/falling edges? Thank you for any information provided Tim ------------------------------ Date: Sat, 29 Sep 2001 13:29:00 -0700 (PDT) From: Mohanasankar Sivaprakasam Subject: Some clarifications reg IBIS3.2 Hello, I am Mohanasankar, student at North Carolina State University. Can some body help me with the following: 1.What is the difference between Vinl/Vinh in [Model] keyword and Vinl/Vinh in [Model Spec] keyword? What different purposes do they serve? 2.I got confused with [Add Submodel].. Is it a way of reusing models. that is using some charcteristics of a model into another?? 3.Are there any examples of models conforming to IBIS3.2 Specifications which would cover all the syntaxes?? Thanks for you cooperation. Mohanasankar. ===== "There are new problems to solve. Engineers who can solve these problems will define the future" Mohanasankar Sivaprakasam, Research Assistant, Electrical Engineering, North Carolina State University, Raleigh, NC,USA. __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ------------------------------ Date: Mon, 1 Oct 2001 17:08:43 -0700 From: tliu@semtech.com Subject: question about s2ibis2 Hi, I used free software v2.1 s2ibis2 which download from http://www.eigroup.org/ibis/ibis.htm. I create IBIS model for output_ECL. I cannot get the right model. I check the output list for pullup & pulldown, DC sweep is from -2.2V to 0, this is correct. But in side of IBIS model, DC sweep is from -0.14V to 0. Did anyone know what's wrong with it? Thanks Tina Liu Semtech Corp. 858-547-6615 ------------------------------ Date: Mon, 01 Oct 2001 17:50:56 -0700 From: Bob Ross Subject: Re: Some clarifications reg IBIS3.2 Hello: Some brief responses are in your text. Bob Ross Mentor Graphics Mohanasankar Sivaprakasam wrote: > > Hello, > I am Mohanasankar, student at North Carolina State > University. > Can some body help me with the following: > > 1.What is the difference between Vinl/Vinh in [Model] > keyword and Vinl/Vinh in [Model Spec] keyword?> > What different purposes do they serve? > The [Model Spec] Vinh/l subparamters allow you to specify min and max values that may change with [Voltage Range] or some other reference voltage. PECL technology is an example where this would be important. Vinh/l subparameter of [Model] only allows fixed values over the entire range. The [Model Spec] values always override the [Model] subparameter specification. > 2.I got confused with [Add Submodel].. > Is it a way of reusing models. that is using some > charcteristics of a model into another?? Some technologies add some functional details to the buffer. The [Add Submodel] and [Submodel] keywords provide a way to "add" on some detail that is of practical interest. > > 3.Are there any examples of models conforming to > IBIS3.2 Specifications which would cover all the > syntaxes?? There exists some examples that demonostrate some of the Version 3.2 syntax under http://www.eda.org/pub/ibis/samples/ for subdirectories ver3.0 and above. Bob Ross Mentor Graphics > > Thanks for you cooperation. > > Mohanasankar. > > ===== > "There are new problems to solve. > Engineers who can solve these problems will define the future" > Mohanasankar Sivaprakasam, > Research Assistant, > Electrical Engineering, > North Carolina State University, > Raleigh, NC,USA. > > __________________________________________________ > Do You Yahoo!? > Listen to your Yahoo! Mail messages from any phone. > http://phone.yahoo.com ------------------------------ Date: Tue, 02 Oct 2001 17:13:34 +0100 From: "Peter Rowe" Subject: request for info - --------------24BC98E783DF34BAE10CD6DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit HI, I'm looking to answer a basic question on IBIS models. Please can you tell me upto what frequencies IBIS models are useful? Peter Rowe - --------------24BC98E783DF34BAE10CD6DA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit HI,
    I'm looking to answer a basic question on IBIS  models. Please can you tell me upto what frequencies IBIS models are useful? 
Peter Rowe
  - --------------24BC98E783DF34BAE10CD6DA-- ------------------------------ Date: Tue, 2 Oct 2001 22:11:38 -0700 (PDT) From: suresh np Subject: Abt IBIS models........ Hi all Pls find the below questions (or my doubts). 1) For which all devices, IBIS models are valid? Is the IBIS model for a Analog to Digital converter valid? Is it applicable only for high speed IC's? 2)Suppose i have a SPICE model for an IC. How I can collect the datas for V/I and V/T curve? (i want to know the circuit to collect data [pull up] [pull down]....) .(in *.dsn or *.opj format. I have orcad in my system).(atleast a jpg file) 3) Can i simulate or test the IBIS model using Spectra Quest? Pls help out in these regards. Thanks Best Regards - --Suresh __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ------------------------------ Date: Wed, 3 Oct 2001 08:48:38 -0700 From: "Peters, Stephen" Subject: RE: Abt IBIS models........ Hi Suresh: My answers are below. Regards, Stephen Peters Intel Corp. - -----Original Message----- From: suresh np [mailto:suresh_np1@yahoo.com] Sent: Tuesday, October 02, 2001 10:12 PM To: ibis-users@eda.org Subject: Abt IBIS models........ Hi all Pls find the below questions (or my doubts). 1) For which all devices, IBIS models are valid? Is the IBIS model for a Analog to Digital converter valid? Is it applicable only for high speed IC's? The data in an IBIS model is intended for modeling digital output buffers (and digital input receivers). You can certainly build an IBIS model of an Analog to Digital converter, but the model would only represent the digital output portion of the device. 2)Suppose i have a SPICE model for an IC. How I can collect the datas for V/I and V/T curve? (i want to know the circuit to collect data [pull up] [pull down]....) .(in *.dsn or *.opj format. I have orcad in my system).(atleast a jpg file) The IBIS cookbook explains how to extract V/I and V/T curves from a spice model. The cookbook is available from the IBIS website in the tools area: http://www.eigroup.org/ibis/tools.htm The s2ibis (spice to ibis) program is also available. 3) Can i simulate or test the IBIS model using Spectra Quest? Yes. Contact your EDA vendor for more details. Pls help out in these regards. Thanks Best Regards - --Suresh __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ------------------------------ Date: Wed, 3 Oct 2001 12:56:32 -0700 From: tliu@semtech.com Subject: Did anyone familiar with s2ibis2? Hi All, Did anyone know how to use s2ibis2? I create .s2i file and .sp file. After ran s2ibis2, I got .spi, .msg and .out files. The data in .out files looked good, but model didn't show up the same DCsweep range on pullup & pulldown curves. s2ibis I used is free software download from web. Do we have any other updated version to help solve this problem? Thanks for any help Tina Liu ------------------------------ Date: Wed, 3 Oct 2001 14:09:22 -0700 (PDT) From: Syed Huq Subject: Re: Did anyone familiar with s2ibis2? Tina, You need to share your .out file and .ibs as well as our .spi files before any conclusion can be drawn. I am assuming you are using the s2ibis2_fix version. This is the most current version. I would be more than happy to provide some inputs.. Syed Cisco Systems, Inc > Subject: Did anyone familiar with s2ibis2? > To: ibis-users@eda.org > From: tliu@semtech.com > Date: Wed, 3 Oct 2001 12:56:32 -0700 > X-MIMETrack: Serialize by Router on Mail/SMTC(Release 5.0.6a |January 17, 2001) at 10/03/2001 01:01:04 PM > MIME-Version: 1.0 > > Hi All, > Did anyone know how to use s2ibis2? I create .s2i file and .sp file. After > ran s2ibis2, I got .spi, .msg and .out files. The data in .out files looked > good, but model didn't show up the same DCsweep range on pullup & pulldown > curves. s2ibis I used is free software download from web. Do we have any > other updated version to help solve this problem? > > Thanks for any help > > Tina Liu > > ------------------------------ Date: Sun, 7 Oct 2001 17:47:14 -0700 From: tliu@semtech.com Subject: Can anyone help me out those questions? Hi All, I got some replies regarding the questions I put to ibis-user last week. I tried them all, but I still have the following questions. The circuit I'm working on is Bipolar process, high voltage with power supply VCC and VEE. 1. After I ran s2ibis2, I got .spi, .out and IBIS model. But model didn't create the right table for pullup and pulldown curves. I checked puxx.out & pdxx.out, they looked good. Do you know why the table in the model is scrued up? 2. Sometimes I ran s2ibis2, I couldn't get model generated after all simulations were completed. It show me "BUS ERROR (core dumped)". Do you know what can cause this problem? I think it's not memory issue since I was runing the simulation in a machine with 1G memory. 3. How differential pin works? I defined [Diff Pin], but when I ran s2ibis2, I cannot see diff pin is set to any value, is it floating? Any reply will be appreciated. Tina Liu Semtech Corp. 858-547-6615 ------------------------------ Date: Thu, 11 Oct 2001 17:02:41 -0600 From: Yan Tang Subject: Non-monotonic IBIS data Hello, I am trying to figure out what the following warning message meant after I ran the IBIS validation check using HyperLynx visual IBIS editor. "WARNING (line 538) - Pulldown Minimum data is non-monotonic" Although the file passed, I am wondering if such a warning had any effect on the modeling result. Your help is greatly appreciated. Thanks in advance. Regards, Yanny ------------------------------ Date: Thu, 18 Oct 2001 15:09:52 -0500 From: Brian Young Subject: ibischk3 problems Hello, I am getting errors from ibischk3, but I can't figure out what the problem is. The IBIS file was generated by a methodology in development, so there are lots of little problems. Right now, there are also big problems: IBISCHK3 V3.2.7 Checking test.ibs for IBIS 2.1 Compatibility... ERROR - Model mod.A35_2.5V: The [Rising Waveform] with [R_fixture]=50 Ohms and [V_fixture]=2.5V has TYP column DC endpoints of 1.15V and 2.45v, but an equivalent load applied to the model's I-V tables yields different voltages ( 2.52V and 2.50V), a difference of 54.34% and 1.87%, respectively. ERROR - Model mod.A35_2.5V: The [Rising Waveform] with [R_fixture]=50 Ohms and [V_fixture]=0V has TYP column DC endpoints of 0.00V and 1.20v, but an equivalent load applied to the model's I-V tables yields different voltages ( 1.43V and 1.38V), a difference of 100.00% and 13.05%, respectively. ERROR - Model mod.A35_2.5V: The [Falling Waveform] with [R_fixture]=50 Ohms and [V_fixture]=2.5V has TYP column DC endpoints of 1.25V and 2.50v, but an equivalent load applied to the model's I-V tables yields different voltages ( 2.52V and 2.50V), a difference of 50.37% and 0.13%, respectively. ERROR - Model mod.A35_2.5V: The [Falling Waveform] with [R_fixture]=50 Ohms and [V_fixture]=0V has TYP column DC endpoints of 0.05V and 1.35v, but an equivalent load applied to the model's I-V tables yields different voltages ( 1.43V and 1.38V), a difference of 96.51% and 2.18%, respectively. Errors : 4 File Failed Take for example the first error. Before the start of the rising edge, the NFET is holding the voltage low. I can find the holding low voltage by finding the point on the PULLDOWN IV curve where 2.5V=V+50*I. Using the IV curve entry 1.10 27.69m, I find the voltage to be 1.1V. From the [Rising Waveform], R_fixture = 50, V_fixture = 2.500 curve, I get the starting voltage as 1.15V. That looks like a match to me, but ibischk3 comes up with an error and different numbers. Can someone ID the problem with these errors? Thanks, Brian - ------------------------------------- [ibiS ver] 2.1 [File Name] test.ibs [File Rev] 2.0 [Date] date [Source] rev x.x [Copyright] test [Component] test1 [Manufacturer] Motorola [Package] R_pkg 1m NA NA L_pkg 1p NA NA C_pkg 1f NA NA [Pin] signal_name model_name | D9 A35 mod.A35_2.5V [Model] mod.A35_2.5V Model_type I/O Polarity Non-Inverting Enable Active-High Vinh = 1.23V Vinl = 1.21V Cref = 0 Rref = 0 Vref = 0 C_comp 4p 3p 6p [Temperature Range] 27 NA NA [Pullup Reference] 2.5V NA NA [Pulldown Reference] 2.5V NA NA [Power Clamp Reference] 2.5V NA NA [GND Clamp Reference] 0.0V NA NA [Ramp] |variable typ min max dV/dt_r 0.75/0.24n NA NA dV/dt_f 0.75/0.09n NA NA [Rising Waveform] R_fixture = 50 V_fixture = 2.500 C_fixture = 0p L_fixture = 0n C_dut = 0p R_dut = 0m L_dut = 0n |Time V(typ) V(min) V(max) 1.45ns 1.15V NA NA 1.46ns 1.20V NA NA 1.47ns 1.95V NA NA 1.49ns 2.00V NA NA 1.51ns 2.05V NA NA 1.52ns 2.10V NA NA 1.54ns 2.15V NA NA 1.57ns 2.20V NA NA 1.60ns 2.25V NA NA 1.64ns 2.30V NA NA 1.75ns 2.35V NA NA 2.57ns 2.40V NA NA 8.05ns 2.45V NA NA [Falling Waveform] R_fixture = 50 V_fixture = 2.500 C_fixture = 0p L_fixture = 0n C_dut = 0p R_dut = 0m L_dut = 0n |Time V(typ) V(min) V(max) 1.54ns 2.50V NA NA 1.57ns 1.80V NA NA 1.67ns 1.75V NA NA 1.76ns 1.70V NA NA 1.84ns 1.65V NA NA 1.89ns 1.60V NA NA 1.92ns 1.55V NA NA 1.95ns 1.50V NA NA 1.98ns 1.45V NA NA 2.03ns 1.40V NA NA 2.07ns 1.35V NA NA 2.13ns 1.30V NA NA 2.22ns 1.25V NA NA [Rising Waveform] R_fixture = 50 V_fixture = 0 C_fixture = 0p L_fixture = 0n C_dut = 0p R_dut = 0m L_dut = 0n |Time V(typ) V(min) V(max) 1.47ns 0.00V NA NA 1.49ns 0.70V NA NA 1.51ns 0.75V NA NA 1.54ns 0.80V NA NA 1.56ns 0.85V NA NA 1.60ns 0.90V NA NA 1.64ns 0.95V NA NA 1.72ns 1.00V NA NA 1.85ns 1.05V NA NA 2.16ns 1.10V NA NA 2.38ns 1.15V NA NA 2.69ns 1.20V NA NA [Falling Waveform] R_fixture = 50 V_fixture = 0 C_fixture = 0p L_fixture = 0n C_dut = 0p R_dut = 0m L_dut = 0n |Time V(typ) V(min) V(max) 1.78ns 1.35V NA NA 1.79ns 0.80V NA NA 1.82ns 0.60V NA NA 1.86ns 0.55V NA NA 1.90ns 0.50V NA NA 1.93ns 0.45V NA NA 1.96ns 0.40V NA NA 2.00ns 0.35V NA NA 2.04ns 0.30V NA NA 2.10ns 0.25V NA NA 2.17ns 0.20V NA NA 2.30ns 0.15V NA NA 3.17ns 0.10V NA NA 8.77ns 0.05V NA NA [Pulldown] |Voltage I(typ) I(min) I(max) - -0.60V -17.34m NA NA - -0.55V -16.16m NA NA - -0.50V -14.83m NA NA - -0.45V -13.48m NA NA - -0.40V -12.14m NA NA - -0.35V -10.78m NA NA - -0.30V -9.38m NA NA - -0.25V -7.99m NA NA - -0.20V -6.55m NA NA - -0.15V -5.17m NA NA - -0.10V -3.74m NA NA - -0.05V -2.24m NA NA 0.00V -0.89m NA NA 0.05V 0.57m NA NA 0.10V 2.05m NA NA 0.15V 3.42m NA NA 0.20V 4.89m NA NA 0.25V 6.31m NA NA 0.30V 7.66m NA NA 0.35V 9.08m NA NA 0.40V 10.46m NA NA 0.45V 11.87m NA NA 0.50V 13.16m NA NA 0.55V 14.50m NA NA 0.60V 15.83m NA NA 0.65V 17.06m NA NA 0.70V 18.42m NA NA 0.75V 19.64m NA NA 0.80V 20.86m NA NA 0.85V 22.04m NA NA 0.90V 23.22m NA NA 0.95V 24.39m NA NA 1.00V 25.54m NA NA 1.05V 26.60m NA NA 1.10V 27.69m NA NA 1.15V 28.75m NA NA 1.20V 29.73m NA NA 1.25V 30.75m NA NA 1.30V 31.71m NA NA 1.35V 32.66m NA NA 1.40V 33.56m NA NA 1.45V 34.46m NA NA 1.50V 35.33m NA NA 1.55V 36.15m NA NA 1.60V 36.95m NA NA 1.65V 37.76m NA NA 1.70V 38.48m NA NA 1.75V 39.22m NA NA 1.80V 39.94m NA NA 1.85V 40.63m NA NA 1.90V 41.29m NA NA 1.95V 41.91m NA NA 2.00V 42.53m NA NA 2.05V 43.10m NA NA 2.10V 43.69m NA NA 2.15V 44.22m NA NA 2.20V 44.71m NA NA 2.25V 45.21m NA NA 2.30V 45.63m NA NA 2.35V 46.07m NA NA 2.40V 46.48m NA NA 2.45V 46.86m NA NA 2.50V 47.20m NA NA 2.55V 47.52m NA NA 2.60V 47.82m NA NA 2.65V 48.11m NA NA 2.70V 48.38m NA NA 2.75V 48.63m NA NA 2.80V 48.95m NA NA 2.85V 49.38m NA NA 2.90V 49.78m NA NA 2.95V 49.78m NA NA 3.00V 49.78m NA NA 3.05V 49.78m NA NA 3.10V 49.78m NA NA [Pullup] |Voltage I(typ) I(min) I(max) 3.10V -47.76m NA NA 3.05V -47.50m NA NA 3.00V -47.27m NA NA 2.95V -46.99m NA NA 2.90V -46.73m NA NA 2.85V -46.46m NA NA 2.80V -46.18m NA NA 2.75V -45.89m NA NA 2.70V -45.59m NA NA 2.65V -45.31m NA NA 2.60V -44.99m NA NA 2.55V -44.69m NA NA 2.50V -44.38m NA NA 2.45V -44.03m NA NA 2.40V -43.66m NA NA 2.35V -43.31m NA NA 2.30V -42.91m NA NA 2.25V -42.50m NA NA 2.20V -42.06m NA NA 2.15V -41.59m NA NA 2.10V -41.10m NA NA 2.05V -40.57m NA NA 2.00V -40.04m NA NA 1.95V -39.46m NA NA 1.90V -38.82m NA NA 1.85V -38.21m NA NA 1.80V -37.51m NA NA 1.75V -36.82m NA NA 1.70V -36.07m NA NA 1.65V -35.33m NA NA 1.60V -34.55m NA NA 1.55V -33.73m NA NA | 1.50V -32.88m NA NA 1.45V -32.08m NA NA | 1.40V -31.27m NA NA 1.35V -30.42m NA NA | 1.30V -30.80m NA NA 1.25V -29.87m NA NA | 1.20V -28.94m NA NA 1.15V -27.96m NA NA | 1.10V -26.99m NA NA 1.05V -25.92m NA NA | 1.00V -24.89m NA NA 0.95V -23.89m NA NA | 0.90V -22.83m NA NA 0.85V -21.66m NA NA | 0.80V -20.50m NA NA 0.75V -19.33m NA NA 0.70V -18.14m NA NA 0.65V -17.00m NA NA 0.60V -15.75m NA NA 0.55V -14.53m NA NA 0.50V -13.26m NA NA 0.45V -12.00m NA NA 0.40V -10.61m NA NA 0.35V -9.30m NA NA 0.30V -7.99m NA NA 0.25V -6.63m NA NA 0.20V -5.32m NA NA 0.15V -3.93m NA NA 0.10V -2.54m NA NA 0.05V -1.16m NA NA 0.00V 0.18m NA NA - -0.05V 1.58m NA NA - -0.10V 2.95m NA NA - -0.15V 4.38m NA NA - -0.20V 5.79m NA NA - -0.25V 7.12m NA NA - -0.30V 8.52m NA NA - -0.35V 10.01m NA NA - -0.40V 11.30m NA NA - -0.45V 12.67m NA NA - -0.50V 14.08m NA NA - -0.55V 15.49m NA NA - -0.60V 16.82m NA NA [GND Clamp] |Voltage I(typ) I(min) I(max) - -0.60V -5.08m NA NA - -0.55V -4.04m NA NA - -0.50V -3.04m NA NA - -0.45V -2.12m NA NA - -0.40V -1.33m NA NA - -0.35V -0.71m NA NA - -0.30V -0.29m NA NA - -0.25V -0.10m NA NA - -0.20V -0.02m NA NA - -0.15V -0.02m NA NA - -0.10V -0.01m NA NA - -0.05V -0.01m NA NA 0.00V -0.01m NA NA [POWER Clamp] |Voltage I(typ) I(min) I(max) 0.00V -0.02m NA NA - -0.05V -0.01m NA NA - -0.10V -0.01m NA NA - -0.15V 0.00m NA NA - -0.20V 0.03m NA NA - -0.25V 0.14m NA NA - -0.30V 0.43m NA NA - -0.35V 0.95m NA NA - -0.40V 1.61m NA NA - -0.45V 2.41m NA NA - -0.50V 3.39m NA NA - -0.55V 4.41m NA NA - -0.60V 5.50m NA NA [End] - -- *************************************************************** * Brian Young phone: (512) 996-6099 * * Somerset Design Center fax: (512) 996-7434 * * Motorola, Austin, TX brian.young@motorola.com * *************************************************************** ------------------------------ Date: Thu, 18 Oct 2001 15:04:53 -0700 From: Bob Ross Subject: Re: ibischk3 problems Brian: The problem is in the [Pulldown Reference] line. I believe you wanted it to be 0V. You will still get some Errors and Warnings, for smaller mismatches. One of the Warning messages has an incorrect percentage calculation, and I believe that problem needs to be filed as a BUG. Bob Ross Mentor Graphics Brian Young wrote: > > Hello, > > I am getting errors from ibischk3, but I can't figure out what > the problem is. The IBIS file was generated by a methodology in > development, so there are lots of little problems. Right now, > there are also big problems: > > IBISCHK3 V3.2.7 > > Checking test.ibs for IBIS 2.1 Compatibility... > > ERROR - Model mod.A35_2.5V: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=2.5V > has TYP column DC endpoints of 1.15V and 2.45v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 2.52V and 2.50V), > a difference of 54.34% and 1.87%, respectively. > ERROR - Model mod.A35_2.5V: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=0V > has TYP column DC endpoints of 0.00V and 1.20v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.43V and 1.38V), > a difference of 100.00% and 13.05%, respectively. > ERROR - Model mod.A35_2.5V: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=2.5V > has TYP column DC endpoints of 1.25V and 2.50v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 2.52V and 2.50V), > a difference of 50.37% and 0.13%, respectively. > ERROR - Model mod.A35_2.5V: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=0V > has TYP column DC endpoints of 0.05V and 1.35v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.43V and 1.38V), > a difference of 96.51% and 2.18%, respectively. > > Errors : 4 > > File Failed > > Take for example the first error. Before the start of the rising edge, > the NFET is holding the voltage low. I can find the holding low voltage > by finding the point on the PULLDOWN IV curve where 2.5V=V+50*I. Using > the IV curve entry 1.10 27.69m, I find the voltage to be 1.1V. From the > [Rising Waveform], R_fixture = 50, V_fixture = 2.500 curve, I get the > starting voltage as 1.15V. That looks like a match to me, but ibischk3 > comes up with an error and different numbers. > > Can someone ID the problem with these errors? > > Thanks, > Brian > - --- > [Model] mod.A35_2.5V > Model_type I/O > Polarity Non-Inverting > Enable Active-High > Vinh = 1.23V > Vinl = 1.21V > Cref = 0 > Rref = 0 > Vref = 0 > C_comp 4p 3p 6p > [Temperature Range] 27 NA NA > [Pullup Reference] 2.5V NA NA > [Pulldown Reference] 2.5V NA NA > [Power Clamp Reference] 2.5V NA NA > [GND Clamp Reference] 0.0V NA NA > ------------------------------ Date: Thu, 18 Oct 2001 18:19:34 -0400 From: Mike LaBonte Subject: Re: ibischk3 problems Brian, You probably are seeing an s2ibis2 function call bug. It depends on how s2ibis2 was compiled, and on which platform. Check all of the waveform test .spi files (like a00XXX.spi), and you may see a test fixture resistor RFIXS2I with both terminals attached to the same node. So the buffer is running open circuit and goes full swing. If you are willing to fix the code, the bug lines are in s2ispice.c, and looks like this: sprintf( dummyBuffer, resString[spiceType], "RFIXS2I", nodeList[nodeIndex], nodeList[++nodeIndex], currentWave_P->R_fixture ); The problem is that order of argument evaluation in C is indeterminate, and the ++nodeIndex may be evaluated first. Change it to: sprintf( dummyBuffer, resString[spiceType], "RFIXS2I", nodeList[nodeIndex], nodeList[nodeIndex+1], currentWave_P->R_fixture ); ++nodeIndex; The same bug appears at other places in that file. If your RFIXS2I terminals are not shorted, then I don't know what the problem is :-) Mike LaBonte Brian Young wrote: > > Hello, > > I am getting errors from ibischk3, but I can't figure out what > the problem is. The IBIS file was generated by a methodology in > development, so there are lots of little problems. Right now, > there are also big problems: > > IBISCHK3 V3.2.7 > > Checking test.ibs for IBIS 2.1 Compatibility... > > ERROR - Model mod.A35_2.5V: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=2.5V > has TYP column DC endpoints of 1.15V and 2.45v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 2.52V and 2.50V), > a difference of 54.34% and 1.87%, respectively. > ERROR - Model mod.A35_2.5V: The [Rising Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=0V > has TYP column DC endpoints of 0.00V and 1.20v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.43V and 1.38V), > a difference of 100.00% and 13.05%, respectively. > ERROR - Model mod.A35_2.5V: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=2.5V > has TYP column DC endpoints of 1.25V and 2.50v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 2.52V and 2.50V), > a difference of 50.37% and 0.13%, respectively. > ERROR - Model mod.A35_2.5V: The [Falling Waveform] > with [R_fixture]=50 Ohms and [V_fixture]=0V > has TYP column DC endpoints of 0.05V and 1.35v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.43V and 1.38V), > a difference of 96.51% and 2.18%, respectively. > > Errors : 4 > > File Failed > > Take for example the first error. Before the start of the rising edge, > the NFET is holding the voltage low. I can find the holding low voltage > by finding the point on the PULLDOWN IV curve where 2.5V=V+50*I. Using > the IV curve entry 1.10 27.69m, I find the voltage to be 1.1V. From the > [Rising Waveform], R_fixture = 50, V_fixture = 2.500 curve, I get the > starting voltage as 1.15V. That looks like a match to me, but ibischk3 > comes up with an error and different numbers. > > Can someone ID the problem with these errors? > > Thanks, > Brian > > ------------------------------------- > > [ibiS ver] 2.1 > [File Name] test.ibs > [File Rev] 2.0 > [Date] date > [Source] rev x.x > [Copyright] test > [Component] test1 > [Manufacturer] Motorola > [Package] > R_pkg 1m NA NA > L_pkg 1p NA NA > C_pkg 1f NA NA > [Pin] signal_name model_name > | > D9 A35 mod.A35_2.5V > > [Model] mod.A35_2.5V > Model_type I/O > Polarity Non-Inverting > Enable Active-High > Vinh = 1.23V > Vinl = 1.21V > Cref = 0 > Rref = 0 > Vref = 0 > C_comp 4p 3p 6p > [Temperature Range] 27 NA NA > [Pullup Reference] 2.5V NA NA > [Pulldown Reference] 2.5V NA NA > [Power Clamp Reference] 2.5V NA NA > [GND Clamp Reference] 0.0V NA NA > > [Ramp] > |variable typ min max > dV/dt_r 0.75/0.24n NA NA > dV/dt_f 0.75/0.09n NA NA > > [Rising Waveform] > R_fixture = 50 > V_fixture = 2.500 > C_fixture = 0p > L_fixture = 0n > C_dut = 0p > R_dut = 0m > L_dut = 0n > |Time V(typ) V(min) V(max) > 1.45ns 1.15V NA NA > 1.46ns 1.20V NA NA > 1.47ns 1.95V NA NA > 1.49ns 2.00V NA NA > 1.51ns 2.05V NA NA > 1.52ns 2.10V NA NA > 1.54ns 2.15V NA NA > 1.57ns 2.20V NA NA > 1.60ns 2.25V NA NA > 1.64ns 2.30V NA NA > 1.75ns 2.35V NA NA > 2.57ns 2.40V NA NA > 8.05ns 2.45V NA NA > > [Falling Waveform] > R_fixture = 50 > V_fixture = 2.500 > C_fixture = 0p > L_fixture = 0n > C_dut = 0p > R_dut = 0m > L_dut = 0n > |Time V(typ) V(min) V(max) > 1.54ns 2.50V NA NA > 1.57ns 1.80V NA NA > 1.67ns 1.75V NA NA > 1.76ns 1.70V NA NA > 1.84ns 1.65V NA NA > 1.89ns 1.60V NA NA > 1.92ns 1.55V NA NA > 1.95ns 1.50V NA NA > 1.98ns 1.45V NA NA > 2.03ns 1.40V NA NA > 2.07ns 1.35V NA NA > 2.13ns 1.30V NA NA > 2.22ns 1.25V NA NA > > [Rising Waveform] > R_fixture = 50 > V_fixture = 0 > C_fixture = 0p > L_fixture = 0n > C_dut = 0p > R_dut = 0m > L_dut = 0n > |Time V(typ) V(min) V(max) > 1.47ns 0.00V NA NA > 1.49ns 0.70V NA NA > 1.51ns 0.75V NA NA > 1.54ns 0.80V NA NA > 1.56ns 0.85V NA NA > 1.60ns 0.90V NA NA > 1.64ns 0.95V NA NA > 1.72ns 1.00V NA NA > 1.85ns 1.05V NA NA > 2.16ns 1.10V NA NA > 2.38ns 1.15V NA NA > 2.69ns 1.20V NA NA > > [Falling Waveform] > R_fixture = 50 > V_fixture = 0 > C_fixture = 0p > L_fixture = 0n > C_dut = 0p > R_dut = 0m > L_dut = 0n > |Time V(typ) V(min) V(max) > 1.78ns 1.35V NA NA > 1.79ns 0.80V NA NA > 1.82ns 0.60V NA NA > 1.86ns 0.55V NA NA > 1.90ns 0.50V NA NA > 1.93ns 0.45V NA NA > 1.96ns 0.40V NA NA > 2.00ns 0.35V NA NA > 2.04ns 0.30V NA NA > 2.10ns 0.25V NA NA > 2.17ns 0.20V NA NA > 2.30ns 0.15V NA NA > 3.17ns 0.10V NA NA > 8.77ns 0.05V NA NA > > [Pulldown] > |Voltage I(typ) I(min) I(max) > -0.60V -17.34m NA NA > -0.55V -16.16m NA NA > -0.50V -14.83m NA NA > -0.45V -13.48m NA NA > -0.40V -12.14m NA NA > -0.35V -10.78m NA NA > -0.30V -9.38m NA NA > -0.25V -7.99m NA NA > -0.20V -6.55m NA NA > -0.15V -5.17m NA NA > -0.10V -3.74m NA NA > -0.05V -2.24m NA NA > 0.00V -0.89m NA NA > 0.05V 0.57m NA NA > 0.10V 2.05m NA NA > 0.15V 3.42m NA NA > 0.20V 4.89m NA NA > 0.25V 6.31m NA NA > 0.30V 7.66m NA NA > 0.35V 9.08m NA NA > 0.40V 10.46m NA NA > 0.45V 11.87m NA NA > 0.50V 13.16m NA NA > 0.55V 14.50m NA NA > 0.60V 15.83m NA NA > 0.65V 17.06m NA NA > 0.70V 18.42m NA NA > 0.75V 19.64m NA NA > 0.80V 20.86m NA NA > 0.85V 22.04m NA NA > 0.90V 23.22m NA NA > 0.95V 24.39m NA NA > 1.00V 25.54m NA NA > 1.05V 26.60m NA NA > 1.10V 27.69m NA NA > 1.15V 28.75m NA NA > 1.20V 29.73m NA NA > 1.25V 30.75m NA NA > 1.30V 31.71m NA NA > 1.35V 32.66m NA NA > 1.40V 33.56m NA NA > 1.45V 34.46m NA NA > 1.50V 35.33m NA NA > 1.55V 36.15m NA NA > 1.60V 36.95m NA NA > 1.65V 37.76m NA NA > 1.70V 38.48m NA NA > 1.75V 39.22m NA NA > 1.80V 39.94m NA NA > 1.85V 40.63m NA NA > 1.90V 41.29m NA NA > 1.95V 41.91m NA NA > 2.00V 42.53m NA NA > 2.05V 43.10m NA NA > 2.10V 43.69m NA NA > 2.15V 44.22m NA NA > 2.20V 44.71m NA NA > 2.25V 45.21m NA NA > 2.30V 45.63m NA NA > 2.35V 46.07m NA NA > 2.40V 46.48m NA NA > 2.45V 46.86m NA NA > 2.50V 47.20m NA NA > 2.55V 47.52m NA NA > 2.60V 47.82m NA NA > 2.65V 48.11m NA NA > 2.70V 48.38m NA NA > 2.75V 48.63m NA NA > 2.80V 48.95m NA NA > 2.85V 49.38m NA NA > 2.90V 49.78m NA NA > 2.95V 49.78m NA NA > 3.00V 49.78m NA NA > 3.05V 49.78m NA NA > 3.10V 49.78m NA NA > > [Pullup] > |Voltage I(typ) I(min) I(max) > 3.10V -47.76m NA NA > 3.05V -47.50m NA NA > 3.00V -47.27m NA NA > 2.95V -46.99m NA NA > 2.90V -46.73m NA NA > 2.85V -46.46m NA NA > 2.80V -46.18m NA NA > 2.75V -45.89m NA NA > 2.70V -45.59m NA NA > 2.65V -45.31m NA NA > 2.60V -44.99m NA NA > 2.55V -44.69m NA NA > 2.50V -44.38m NA NA > 2.45V -44.03m NA NA > 2.40V -43.66m NA NA > 2.35V -43.31m NA NA > 2.30V -42.91m NA NA > 2.25V -42.50m NA NA > 2.20V -42.06m NA NA > 2.15V -41.59m NA NA > 2.10V -41.10m NA NA > 2.05V -40.57m NA NA > 2.00V -40.04m NA NA > 1.95V -39.46m NA NA > 1.90V -38.82m NA NA > 1.85V -38.21m NA NA > 1.80V -37.51m NA NA > 1.75V -36.82m NA NA > 1.70V -36.07m NA NA > 1.65V -35.33m NA NA > 1.60V -34.55m NA NA > 1.55V -33.73m NA NA > | 1.50V -32.88m NA NA > 1.45V -32.08m NA NA > | 1.40V -31.27m NA NA > 1.35V -30.42m NA NA > | 1.30V -30.80m NA NA > 1.25V -29.87m NA NA > | 1.20V -28.94m NA NA > 1.15V -27.96m NA NA > | 1.10V -26.99m NA NA > 1.05V -25.92m NA NA > | 1.00V -24.89m NA NA > 0.95V -23.89m NA NA > | 0.90V -22.83m NA NA > 0.85V -21.66m NA NA > | 0.80V -20.50m NA NA > 0.75V -19.33m NA NA > 0.70V -18.14m NA NA > 0.65V -17.00m NA NA > 0.60V -15.75m NA NA > 0.55V -14.53m NA NA > 0.50V -13.26m NA NA > 0.45V -12.00m NA NA > 0.40V -10.61m NA NA > 0.35V -9.30m NA NA > 0.30V -7.99m NA NA > 0.25V -6.63m NA NA > 0.20V -5.32m NA NA > 0.15V -3.93m NA NA > 0.10V -2.54m NA NA > 0.05V -1.16m NA NA > 0.00V 0.18m NA NA > -0.05V 1.58m NA NA > -0.10V 2.95m NA NA > -0.15V 4.38m NA NA > -0.20V 5.79m NA NA > -0.25V 7.12m NA NA > -0.30V 8.52m NA NA > -0.35V 10.01m NA NA > -0.40V 11.30m NA NA > -0.45V 12.67m NA NA > -0.50V 14.08m NA NA > -0.55V 15.49m NA NA > -0.60V 16.82m NA NA > > [GND Clamp] > |Voltage I(typ) I(min) I(max) > -0.60V -5.08m NA NA > -0.55V -4.04m NA NA > -0.50V -3.04m NA NA > -0.45V -2.12m NA NA > -0.40V -1.33m NA NA > -0.35V -0.71m NA NA > -0.30V -0.29m NA NA > -0.25V -0.10m NA NA > -0.20V -0.02m NA NA > -0.15V -0.02m NA NA > -0.10V -0.01m NA NA > -0.05V -0.01m NA NA > 0.00V -0.01m NA NA > > [POWER Clamp] > |Voltage I(typ) I(min) I(max) > 0.00V -0.02m NA NA > -0.05V -0.01m NA NA > -0.10V -0.01m NA NA > -0.15V 0.00m NA NA > -0.20V 0.03m NA NA > -0.25V 0.14m NA NA > -0.30V 0.43m NA NA > -0.35V 0.95m NA NA > -0.40V 1.61m NA NA > -0.45V 2.41m NA NA > -0.50V 3.39m NA NA > -0.55V 4.41m NA NA > -0.60V 5.50m NA NA > > [End] > > -- > *************************************************************** > * Brian Young phone: (512) 996-6099 * > * Somerset Design Center fax: (512) 996-7434 * > * Motorola, Austin, TX brian.young@motorola.com * > *************************************************************** ------------------------------ Date: Fri, 19 Oct 2001 15:40:41 -0400 From: "Chao Su" Subject: High frequency performance of IBIS model This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C158D5.EF661E90 Content-Type: text/plain; charset="iso-8859-1" Hi, I'm working in signal integrity of optical transceivers. I'm considering of using IBIS model for my simulation, our optical transciever is operated at 2.5Gb/s. Somebody told me that IBIS model is not good to predict high frequency behavior for the device. I would like you can give me advice about what issue I need to concern when I get my IBIS model from vendors and how I can make sure the model is good in high frequency simulations. Thanks Chao Su Optical Systems Design (Dept. QF11) Nortel Networks P. O. Box 3511 Station C, Ottawa, ON, K1Y 4H7 Canada - ---------------------------------------------------------------- *Phone: (613) 765-7688 (ESN 395-7688) *E-mail: csu@nortelnetworks.com *Mail Stop: 045/12/E06 - ------_=_NextPart_001_01C158D5.EF661E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable High frequency performance of IBIS model

Hi,

I'm working in signal integrity of = optical transceivers. I'm considering of using IBIS model for my = simulation, our optical transciever is operated at 2.5Gb/s. Somebody = told me that IBIS model is not good to predict high frequency behavior = for the device. I would like you can give me advice about what issue I = need to concern when I get my IBIS model from vendors and how I can = make sure the model is good in high frequency simulations.

Thanks

Chao = Su
Optical = Systems Design (Dept. QF11)
Nortel = Networks
P. O. Box = 3511
Station C, Ottawa, = ON, K1Y 4H7
Canada
---------------------------------------------------------= - -------
(Phone: (613) 765-7688 (ESN = 395-7688)
*E-mail:        = csu@nortelnetworks.com
+Mail = Stop:     045/12/E06


- ------_=_NextPart_001_01C158D5.EF661E90-- ------------------------------ Date: Fri, 19 Oct 2001 12:52:41 -0700 From: "Muranyi, Arpad" Subject: RE: High frequency performance of IBIS model This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C158D7.9D1497F0 Content-Type: text/plain; charset="iso-8859-1" IBIS models have only a constant capacitance to account for the die capacitance, which means that there is no frequency dependency in their impedance. If the value is correct at your frequency I think you could still use it, but if you need frequency dependency you may need to find other ways. I don't know if you are also planning to using the IBIS file for describing the package for your device, but the IBIS package parameters only use RLC (no G) and none of these are frequency dependent either. Arpad Muranyi Intel Corporation ============================================================ - -----Original Message----- From: Chao Su [mailto:csu@nortelnetworks.com] Sent: Friday, October 19, 2001 12:41 PM To: ibis-users@eda.org Subject: High frequency performance of IBIS model Hi, I'm working in signal integrity of optical transceivers. I'm considering of using IBIS model for my simulation, our optical transciever is operated at 2.5Gb/s. Somebody told me that IBIS model is not good to predict high frequency behavior for the device. I would like you can give me advice about what issue I need to concern when I get my IBIS model from vendors and how I can make sure the model is good in high frequency simulations. Thanks Chao Su Optical Systems Design (Dept. QF11) Nortel Networks P. O. Box 3511 Station C, Ottawa, ON, K1Y 4H7 Canada - ---------------------------------------------------------------- *Phone: (613) 765-7688 (ESN 395-7688) *E-mail: csu@nortelnetworks.com *Mail Stop: 045/12/E06 - ------_=_NextPart_001_01C158D7.9D1497F0 Content-Type: text/html; charset="iso-8859-1" High frequency performance of IBIS model
IBIS models have only a constant capacitance to account for
the die capacitance, which means that there is no frequency
dependency in their impedance.  If the value is correct at
your frequency I think you could still use it, but if you
need frequency dependency you may need to find other ways.
 
I don't know if you are also planning to using the IBIS file
for describing the package for your device, but the IBIS
package parameters only use RLC (no G) and none of these are
frequency dependent either.
 
Arpad Muranyi
Intel Corporation
============================================================
 
 
-----Original Message-----
From: Chao Su [mailto:csu@nortelnetworks.com]
Sent: Friday, October 19, 2001 12:41 PM
To: ibis-users@eda.org
Subject: High frequency performance of IBIS model

Hi,

I'm working in signal integrity of optical transceivers. I'm considering of using IBIS model for my simulation, our optical transciever is operated at 2.5Gb/s. Somebody told me that IBIS model is not good to predict high frequency behavior for the device. I would like you can give me advice about what issue I need to concern when I get my IBIS model from vendors and how I can make sure the model is good in high frequency simulations.

Thanks

Chao Su
Optical Systems Design (Dept. QF11)
Nortel Networks
P. O. Box 3511
Station C, Ottawa, ON, K1Y 4H7
Canada
----------------------------------------------------------------
(Phone: (613) 765-7688 (ESN 395-7688)
*E-mail:        csu@nortelnetworks.com
+Mail Stop:     045/12/E06


- ------_=_NextPart_001_01C158D7.9D1497F0-- ------------------------------ Date: Fri, 19 Oct 2001 13:57:25 -0700 From: "Mellitz, Richard" Subject: RE: High frequency performance of IBIS model This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C158E0.A7F9D050 Content-Type: text/plain; charset="iso-8859-1" When the return loss of the buffer over the required frequency range is relatively flat, db-log(f) linear (3-6 db/octave) , or small IBIS will be suffucient. ...Rich - -----Original Message----- From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com] Sent: Friday, October 19, 2001 3:53 PM To: ibis-users@eda.org Subject: RE: High frequency performance of IBIS model IBIS models have only a constant capacitance to account for the die capacitance, which means that there is no frequency dependency in their impedance. If the value is correct at your frequency I think you could still use it, but if you need frequency dependency you may need to find other ways. I don't know if you are also planning to using the IBIS file for describing the package for your device, but the IBIS package parameters only use RLC (no G) and none of these are frequency dependent either. Arpad Muranyi Intel Corporation ============================================================ - -----Original Message----- From: Chao Su [mailto:csu@nortelnetworks.com] Sent: Friday, October 19, 2001 12:41 PM To: ibis-users@eda.org Subject: High frequency performance of IBIS model Hi, I'm working in signal integrity of optical transceivers. I'm considering of using IBIS model for my simulation, our optical transciever is operated at 2.5Gb/s. Somebody told me that IBIS model is not good to predict high frequency behavior for the device. I would like you can give me advice about what issue I need to concern when I get my IBIS model from vendors and how I can make sure the model is good in high frequency simulations. Thanks Chao Su Optical Systems Design (Dept. QF11) Nortel Networks P. O. Box 3511 Station C, Ottawa, ON, K1Y 4H7 Canada - ---------------------------------------------------------------- *Phone: (613) 765-7688 (ESN 395-7688) *E-mail: csu@nortelnetworks.com *Mail Stop: 045/12/E06 - ------_=_NextPart_001_01C158E0.A7F9D050 Content-Type: text/html; charset="iso-8859-1" High frequency performance of IBIS model
When the return loss of the buffer over the required frequency range is relatively flat, db-log(f) linear (3-6 db/octave) , or small IBIS will be suffucient.
 
...Rich
-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Friday, October 19, 2001 3:53 PM
To: ibis-users@eda.org
Subject: RE: High frequency performance of IBIS model

IBIS models have only a constant capacitance to account for
the die capacitance, which means that there is no frequency
dependency in their impedance.  If the value is correct at
your frequency I think you could still use it, but if you
need frequency dependency you may need to find other ways.
 
I don't know if you are also planning to using the IBIS file
for describing the package for your device, but the IBIS
package parameters only use RLC (no G) and none of these are
frequency dependent either.
 
Arpad Muranyi
Intel Corporation
============================================================
 
 
-----Original Message-----
From: Chao Su [mailto:csu@nortelnetworks.com]
Sent: Friday, October 19, 2001 12:41 PM
To: ibis-users@eda.org
Subject: High frequency performance of IBIS model

Hi,

I'm working in signal integrity of optical transceivers. I'm considering of using IBIS model for my simulation, our optical transciever is operated at 2.5Gb/s. Somebody told me that IBIS model is not good to predict high frequency behavior for the device. I would like you can give me advice about what issue I need to concern when I get my IBIS model from vendors and how I can make sure the model is good in high frequency simulations.

Thanks

Chao Su
Optical Systems Design (Dept. QF11)
Nortel Networks
P. O. Box 3511
Station C, Ottawa, ON, K1Y 4H7
Canada
----------------------------------------------------------------
(Phone: (613) 765-7688 (ESN 395-7688)
*E-mail:        csu@nortelnetworks.com
+Mail Stop:     045/12/E06


- ------_=_NextPart_001_01C158E0.A7F9D050-- ------------------------------ End of ibis-users V1 #1 ***********************