Subject: ibis-users V1 #22
From: owner-ibis-users@ (ibis-users)
To: [email-masked]

ibis-users            Monday, May 12 2003            Volume 01 : Number 022

----------------------------------------------------------------------

Date: Thu, 8 May 2003 13:30:37 -0400
From: "Lynne Green" <[email-masked]>
Subject: [IBIS-Users] IBIS Summit First Call for Papers, DesignCon East

- -----------------------------------------------------------------------
               IBIS SUMMIT at DESIGNCON EAST
                     FIRST CALL FOR
               PARTICIPATION & PRESENTATIONS
- -----------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

              I B I S   S U M M I T   M E E T I N G

Time/Date:  Monday, June 23, 2003,  8:00 AM to 5:00 PM

Location:   Best Western Royal Plaza Hotel and Trade Center
                Marlboro, Massachusetts

Content:    Presentations and Discussions

Purpose:   Solicit and Exchange IBIS Model Related Information
                and Ideas.

Sponsors: DesignCon East, IBIS Open Forum, and
                Signal Integrity Software, Inc.

            If your company would be interested in being a sponsor,
            please contact Lynne Green <[email-masked]>.
            Sponsorships are needed for the teleconference phone
            line, lunch, and coffee breaks.

DesignCon East: June 23-25, 2003
            Best Western Royal Plaza Hotel and Trade Center
            Marlborough Massachusetts

            DesignCon offers a 30% discount for IBIS members who
            register for the technical program at
            http://www.iec.org/events/2003/designcon_east/ibis.html.

            See <http://www.iec.org/events/2003/designcon_east/>
            for  more information.

BACKGROUND

DesignCon is the premier annual Silicon Valley event for the electronic
design automation (EDA) and semiconductor industry.  Topics of current
interest to the EIA IBIS Open Forum are addressed at DesignCon.

This meeting will be conducted as a formal IBIS Summit Meeting.
Presentations are expected to be available and archived in an
electronic format, and minutes of the meeting will be issued.
Any pending formal decisions (votes) will be announced at least
two weeks prior to the meeting.

CALL FOR PARTICIPANTS

People involved in IBIS Model development, EDA tool development,
and digital circuit design are invited to participate to the
Summit meeting. If you plan to participate, please register with
the information below:

   Name:
   E-mail address:
   Company:
   Telephone:

Send to:

   Terry Roulic <[email-masked]>

CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have IBIS
experiences or issues.

Format of Presentation:  LCD Projection with Windows laptop.
Time:			15-30 Minutes
Electronic Archival: We request electronic versions so that the
	presentations can be archived and also made
	available to non-attendees.  Formats used in
	the past have been text, Power Point, Word,
	Postscript, and Acrobat.  Electronic
            presentations should be made available by
            June 18, 2003 for uploading and copying to
            the presentation laptop.

If you plan a presentation, please supply

   Title:
   Presenter:
   E-mail address:
   Company:
   Telephone:

   Estimate Time:

Send this to:

  Lynne Green ([email-masked])

AGENDA

The agenda includes presentations, discussions, breaks, and a
luncheon (which will be provided).  This will be developed as
presentation proposals are received.

The following individuals have signed up to present at the
summit (presentation titles are tentative).
* Barry Katz, IBIS Quality Report
* Arpad Muranyi, A behavioral VHDL-AMS I/O buffer model using
IBIS data

LIST OF NEARBY HOTELS

Please see
<http://www.iec.org/events/2003/designcon_east/attendee/hotel.html>
for travel directions, hotels and other information.
- -----------------------------------------------------------------
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 08 May 2003 15:31:31 -0400
From: Robert Haller <[email-masked]>
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination

Todd,
	Excellent detailed description of the problem and possible solutions ! 
Please see my responses in the body of your Mail. I propose a slightly 
modified solution.

regards,
bob

- -- 
Robert J. Haller ([email-masked])
Principal Consultant
Signal Integrity Software Inc.
6 Clock Tower Place, Suite 250
Maynard, MA 01754
Phone: (978) 461-0449, ext 15

Todd Westerhoff wrote:
> Hi all,
> 
> This one has been bugging us for a while ... the discussions that took place
> last week gave us the opportunity to take another look at this problem and
> its different components.  I have two solutions to propose, and would
> appreciate feedback from the group.
> 
> I apologize in advance for a lengthy email.  There's no other way I know to
> describe the different components of the problem and the way they interact.
> 
> To start - the problem is accurately modeling the effect of on-die input
> termination, most typically pulling the signal to a value of VDDQ/2, which
> would be common for HSTL and SSTL signalling.  The resistors in question (at
> least in our case) were not discrete components in the package - they were
> truly on-die.  Hence, the resistance varied with process and was non-linear
> over the operating range.  Thus, we needed a way to extract the actual input
> characteristics using the HSpice model and create the correct model in IBIS.
> 
> Simple enough, we thought - then it got deep.
> 
> To ended up breaking the problem down into three pieces -
> 
> 1) The IBIS Specification
> 2) The process of creating models
> 3) How IBIS simulators use the data in the IBIS models
> 
> 
> 1) The IBIS Specification
> -------------------------
> Please correct me if I'm wrong here, but I believe the IBIS Spec doesn't
> list any "standard" for the voltage range over which the behavior of the
> [GND Clamp] and [POWER Clamp] should be specified.  I took it as a given
> that [Pulldown] and [Pullup] curves would range from -VDDQ to 2*VDDQ, and,
> until last week, I would have expected to see the same range for the power
> and ground clamps.  That turned out not to be the case.
> 
The minimum range for the clamps is specified as;
The sweep for Power clamp must be at least made between +Vcc and +2Vcc 
(it is permitted to extend the range)
The sweep for Gnd-clamp should be made at least between -Vccmax and 
+Vccmax	(it is permitted to extend the range).

> I also suspect that the IBIS spec has no comment on just how the simulator
> is supposed to combine the data in the two clamp curves, should the points
> overlap.  That turned out to be a big sticking point.
> 
The IBIS specification is actually ambiguous (page 34 of ibis 3.2 spec). 
It states that the pullup be added to the the clamps (plural) and the 
pulldown be added to the clamps (plural).

So after many simulations and then discussions with 'IBIS and Tool 
experts' I concluded that the tools and IBIS spec require Both clamps be 
added to the pullup and Both clamps be added to the pulldown.

If there are not enough points they will exprapolate. If they overlap, 
you can get into trouble if they are inconsistent.

For a conventional CMOS push-pull driver it doesn't matter in this 
context, because it is zero outside the clamp sweep range. For ON die 
termination it is an important issues.
> 
> 2) The process of creating models
> ---------------------------------
> There are two classes of people who create IBIS models from HSpice
> simulations:
> 
> a) The gurus, who understand IBIS, HSpice and software well enough to
> develop their own tools for extracting and compiling IBIS model data, and
> 
I guess We fit into this category. We have a tool that does the 
extraction, math and model compiling automatically.

> b) The rest of us, who use some version of s2ibis2.  Usually, it's one we've
> compiled ourselves, with some collection of fixes implemented for problems
> we have found on our own.  I'm going to aim my comments squarely at s2ibis2,
> with the assumption that's what most of the IBIS-modelmakers are basing
> their efforts on.
> 
> When s2ibis2 was created, the developer noticed an interesting problem -
> there is really no good way to separate the ground clamp curve from the
> power clamp curve.  With the [Pullup] and [Pulldown] curves, you can isolate
> the behavior of transistor from the other by virtue of the output state.
> However, if you model the input buffer and sweep the voltage from -VDDQ to
> 2*VDDQ, there's really no good way to separate the one clamp curve from the
> other.
> 
Correct.
> (When I talk about voltage from this point on, I'm going to use ground as a
> reference, unless I specifically state that I'm using a power-based voltage
> reference "a la IBIS".  I'm also going to assume the ground clamp is active
> between -VDDQ and 0V, the "operating region" for the device is between 0V
> and VDDQ, and the power clamp is active between VDDQ and 2*VDDQ).
> 
> Of course, if you've got a normal input (without termination), the input
> current is zero (or essentially so) throughout the operating region, so
> there isn't really any problem.  It doesn't much matter where the ground
> clamp curve leaves off and the power clamp curve kicks in, because the
> currents at those points are always zero.
> 
> However, the presence of on-die termination to VDDQ/2 presents an
> interesting problem.  The "zero current" point is somewhere in the middle of
> the operating region, and it's only a single point.  The power and ground
> clamp curves, when added together, have to accurately represent the input's
> characteristic throughout the device's operating region (0 to VDDQ), if you
> want to input to behave properly.
> 
> So now the question becomes - where does one curve leave off, and the other
> begin?  Well, s2ibis2 simply implements the ground clamp curve from -VDDQ to
> VDDQ, and the power clamp curve from VDDQ to 2*VDDQ.  In theory, you should
> be able to just attach the two curves together and get the right result - or
> at least, that's the assumption s2ibis2 seems to be operating on.  Remember,
> because the power clamp curve in IBIS is rail-referenced, a sweep from VDDQ
> to 2*VDDQ shows up in the IBIS file as from 0 to -VDDQ.
> 
Yes In theory that is the right thing to do.

> There are a couple of interesting caveats here.  First, s2ibis2 ground clamp
> curves actually all end at the same point, which is the [typ] value of VDDQ.
> Let's assume that we have an HSTL 1.5 driver, whose power rail can vary by
> 10%.  Thus, the [min] power rail is 1.35V, while the [max] power rail is
> 1.65V.  In this case, the ground clamp data ends at 1.5V in all three cases.
> 
> The power clamp curves have the same issue, but in reverse.  They are
> supposed to sweep from VDDQ to 2*VDDQ.  That's 0 to -VDDQ in IBIS terms (the
> curves really go from -VDDQ to 0 in the IBIS data, because voltages are
> supposed to increase).  However, all three curves start at the same point,
> which is 2*VDDQ[typ] (-VDDQ[typ] in IBISese), and end at the same point,
> which is 0V.
> 
> But - and this is a big one - because the power clamp curves are
> rail-referenced, 0V means different things in the different cases.  It means
> 1.35V for [min], 1.5V for [typ] and 1.65V for [max].  So - if we adjust for
> the rail reference and talk about ground-referenced voltages, the voltage
> data points for the power clamp curves range from:
> 

> [min] 1.35V to 2.85V
> [typ] 1.5V to 3.0V
> [max] 1.65V to 3.15V
> 
> Let's set those side by side with the ground clamp curves and see what we
> get:
> 
>       Ground Clamp             Power Clamp
> [min] -1.5V to 1.5V            1.35V to 2.85V
> [typ] -1.5V to 1.5V            1.5V to 3.0V
> [max] -1.5V to 1.5V            1.65V to 3.15V
> 
> The [typ] curves complement each other just fine, but there is an overlap in
> the [min] data and a gap in the [max] data.  We're primarily concerned about
> capturing the behavior of the input termination across the entire operating
> region here, so this looks like it might be a problem.  Of course, that is
> determined by how the simulator handles the situation where the clamp V-I
> curves overlap or have a gap in them.  We didn't expect what we found,
> however.
> 
> 
> 3) How IBIS simulators use the data in the IBIS models
> ------------------------------------------------------
> Different simulators may well do different things, and I'm not trying to say
> I've tested all of them.  At least some of them, if not all of them, behave
> as I'm describing here.
> 
> We suspected an IBIS simulator might "double count" the current in the
> overlap region in the [min]case (between 1.35V and 1.5V), thereby making the
> termination appear twice as strong as it really was (in that region).  We
> didn't know what was going to happen in the [max] case, with a cap in the
> data between 1.5 and 1.65V.  So - we read the models in and tested them.
> 
> What we found, empirically, is that the simulator didn't add the curves
> together the way you might expect - taking the data from the ground clamp
> curve between -VDDQ and VDDQ, and the data from the power clamp curve
> between VDDQ and 2*VDDQ.  Instead, the simulator *extended each curve by
> extrapolation* to cover the entire region from -VDDQ to 2*VDDQ, and *THEN*
> added the currents together.  In other words, the power clamp curve (which,
> at the "IBIS 0V" point, corresponding to VDDQ, has a slope of roughly the
> termination value) got extended through the whole operating region with a
> slope roughly equal to the termination value.  Now, when the simulator added
> the contributions of the power and ground clamps in the operating region, it
> came up with roughly twice the correct current, making the termination
> appear twice as strong as it really was.  We started out thinking there
> might be a small problem in the gap/overlap regions of the [max/min] curves,
> and discovered instead that none of the simulation cases were working
> correctly, anywhere in the operating region.
> 
> This is a classic case of compartmentalization and assumptions - between
> IBIS, s2ibis2 and the IBIS simulators.  Bottom line, the basic assumption
> was that clamps don't kick in until you go beyond the rail, and the overall
> process falls apart in this case as a result.
> 
> 
> 4) What we can do about it
> --------------------------
> Again, I'm predicating this on the use of s2ibis2 to create IBIS models.
> The goal is simple: create an IBIS model that accurately reproduces the
> combined behavior of the clamps and input termination over the range
> from -VDDQ to 2*VDDQ.
> 
> Both proposals both rely on the same basis: having s2ibis2 perform a single
> input V-I sweep, over the voltage range from -VDDQ to 2*VDDQ.  That one
> simulation would capture all the behavior we're concerned about here.  From
> there, it's just a matter of how you format the data.
> 
> Proposal 1) Says that you put the whole kit & kaboodle into the [GND Clamp]
> curve and omit the [POWER Clamp] curve entirely.  There's really only one
> composite input characteristic, anyway; separating it into two sets of clamp
> curves is artificial.  Having two curves provides benefits in some cases,
> but it's hard to argue that those benefits apply here.  This is the easiest
> solution to implement, and provides the composite curve in one place.  The
> downside is that some users might object to having the power clamp data
> included in the [GND Clamp] curve, and that some simulation tools might also
> have a problem with this.  A simulation tool that used a different technique
> for combining the curve data might very well have a problem with this
> approach.
> 
This is the easiest to implement, but like you point out the models may 
not be portable.
> Proposal 2) ... which Arpad suggested, was to find the zero-current point in
> each of the min-typ-max cases, and assign all negative current to the ground
> clamp, and all positive current to the power clamp.  You need to make sure
> that each clamp curve has two consecutive voltage data points with zero
> current at the correct end of the curve (so that all further points are zero
> current by extrapolation).  You also need to do the proper voltage
> translations when assigning current to the power clamp curve.  The advantage
> of this technique is that you end up with two sets of clamp curves as most
> people expect, and they add together correctly.  This disadvantage is a
> slight increase in process complexity, and the fact that you probably won't
> be able to view the overall input behavior in one place.  Interestingly, the
> IBIS-viewer/model-editor tools seem to allow you to view the combined V-I
> characteristics of the output buffers, but don't provide for viewing the
> combined characteristics of the power and ground clamp curves on an input.
> 
Arpads approach is valid and portable.

> .... so there you have it - s2ibis2 and input termination modeling in IBIS,
> as I presently understand it.  Corrections to my reasoning, comments and
> thoughts on the subject are both welcome and greatly appreciated.
> 
proposal 3)
Sweep the entire IBIS range for all curves including clamps -Vcc to 2Vcc
Then like Arpad suggested, find the zero-current point in each case and 
assign all negative current to the ground clamp, and all positive 
current to the power clamp.

To view the IV curve run a IV sweep in your simulator. This is 
effectively an ibis2ibis process. Look at the resultant waveforms in the 
viewer of choice. The curves out better equal what you put in.

> 
> Todd.
> 
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:[email-masked]
> ph: 978-936-2149
> ============================================

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 8 May 2003 16:06:49 -0400 
From: Gustavo Blando <[email-masked]>
Subject: [IBIS-Users] SSO IBIS Modeling question

Hi IBIS experts.

This questions, is regarding to SSO simulation on a package.
If I want to model the following:

     |------(RLC1)----------(RLC1)-----------(RLC1) --|
     |                |                |              | 
     |              (drv)            (drv)            |     
   (RLC)            (RLC)            (RLC)          (RLC) 
     |                |                |              | 
 (PWRBALL)        (SIG-BALL)       (SIG-BALL)     (PWR-BALL)
   (A1)              (A2)             (A3)           (A4)

With a package model it seems pretty straight-forward to model all the
(RLC), now
It is not obvious to me how to model the (RLC1) ??????.

This is for the Package.(RLC) modeling
A1  Len=4.69838 L=0.284n C=0.1775p R=0.05 / Len=0 C=0.8p /  | PWR-BALL
A2  Len=4.69838 L=0.284n C=0.1775p R=0.05 / Len=0 C=0.8p /  | SIGNAL
A3  Len=4.69838 L=0.284n C=0.1775p R=0.05 / Len=0 C=0.8p /  | SIGNAL
A4  Len=4.69838 L=0.284n C=0.1775p R=0.05 / Len=0 C=0.8p /  | PWR-BALL

This is for the Ring (The Driver of A2, is connected to RING and to VSS
- -----------------------------------------------------------------------
(Ground Balls, not shown in the above diagram)
B1      VSS    NC
B2      VSS    NC
- ------------------------------------------------------------------------
(Power Balls)
A1      NC     RING
A4      NC     RING
- -------------------------------------------------------------------------
(Signals drivers)
A2            VSS       RING
A3            VSS       RING 
- -------------------------------------------------------------------------

Anyway, it seems to me that I can do this creating an EBD model, but 
I was wondering, if there is some way to represent this with the 
[Package Model] directly?.

Thanks.

Gustavo Blando
Axiowave Networks
Tel:  (774) 348-4784 
Fax: (774) 348-4008
email: [email-masked]

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 8 May 2003 13:48:25 -0700
From: Kim Helliwell <[email-masked]>
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination

Great exposition; I hadn't thought about that, but it's
definitely an issue that affects me.

Your solutions are, I think, aimed at how to make better models.

I'd be more interested in at least 2 other angles:
1. How to massage models already supplied to me, when I
     don't have access to the HSPICE models.

2. How to get simulator makers to address this issue in the simulators
      proper, assuming that models won't be "perfect".

On Wednesday, May 7, 2003, at 10:44  PM, Todd Westerhoff wrote:

> Hi all,
>
> This one has been bugging us for a while ... the discussions that took 
> place
> last week gave us the opportunity to take another look at this problem 
> and
> its different components.  I have two solutions to propose, and would
> appreciate feedback from the group.
>
> I apologize in advance for a lengthy email.  There's no other way I 
> know to
> describe the different components of the problem and the way they 
> interact.
>
> To start - the problem is accurately modeling the effect of on-die 
> input
> termination, most typically pulling the signal to a value of VDDQ/2, 
> which
> would be common for HSTL and SSTL signalling.  The resistors in 
> question (at
> least in our case) were not discrete components in the package - they 
> were
> truly on-die.  Hence, the resistance varied with process and was 
> non-linear
> over the operating range.  Thus, we needed a way to extract the actual 
> input
> characteristics using the HSpice model and create the correct model in 
> IBIS.
>
> Simple enough, we thought - then it got deep.
>
> To ended up breaking the problem down into three pieces -
>
> 1) The IBIS Specification
> 2) The process of creating models
> 3) How IBIS simulators use the data in the IBIS models
>
>
> 1) The IBIS Specification
> -------------------------
> Please correct me if I'm wrong here, but I believe the IBIS Spec 
> doesn't
> list any "standard" for the voltage range over which the behavior of 
> the
> [GND Clamp] and [POWER Clamp] should be specified.  I took it as a 
> given
> that [Pulldown] and [Pullup] curves would range from -VDDQ to 2*VDDQ, 
> and,
> until last week, I would have expected to see the same range for the 
> power
> and ground clamps.  That turned out not to be the case.
>
> I also suspect that the IBIS spec has no comment on just how the 
> simulator
> is supposed to combine the data in the two clamp curves, should the 
> points
> overlap.  That turned out to be a big sticking point.
>
>
> 2) The process of creating models
> ---------------------------------
> There are two classes of people who create IBIS models from HSpice
> simulations:
>
> a) The gurus, who understand IBIS, HSpice and software well enough to
> develop their own tools for extracting and compiling IBIS model data, 
> and
>
> b) The rest of us, who use some version of s2ibis2.  Usually, it's one 
> we've
> compiled ourselves, with some collection of fixes implemented for 
> problems
> we have found on our own.  I'm going to aim my comments squarely at 
> s2ibis2,
> with the assumption that's what most of the IBIS-modelmakers are basing
> their efforts on.
>
> When s2ibis2 was created, the developer noticed an interesting problem 
> -
> there is really no good way to separate the ground clamp curve from the
> power clamp curve.  With the [Pullup] and [Pulldown] curves, you can 
> isolate
> the behavior of transistor from the other by virtue of the output 
> state.
> However, if you model the input buffer and sweep the voltage from 
> -VDDQ to
> 2*VDDQ, there's really no good way to separate the one clamp curve 
> from the
> other.
>
> (When I talk about voltage from this point on, I'm going to use ground 
> as a
> reference, unless I specifically state that I'm using a power-based 
> voltage
> reference "a la IBIS".  I'm also going to assume the ground clamp is 
> active
> between -VDDQ and 0V, the "operating region" for the device is between 
> 0V
> and VDDQ, and the power clamp is active between VDDQ and 2*VDDQ).
>
> Of course, if you've got a normal input (without termination), the 
> input
> current is zero (or essentially so) throughout the operating region, so
> there isn't really any problem.  It doesn't much matter where the 
> ground
> clamp curve leaves off and the power clamp curve kicks in, because the
> currents at those points are always zero.
>
> However, the presence of on-die termination to VDDQ/2 presents an
> interesting problem.  The "zero current" point is somewhere in the 
> middle of
> the operating region, and it's only a single point.  The power and 
> ground
> clamp curves, when added together, have to accurately represent the 
> input's
> characteristic throughout the device's operating region (0 to VDDQ), 
> if you
> want to input to behave properly.
>
> So now the question becomes - where does one curve leave off, and the 
> other
> begin?  Well, s2ibis2 simply implements the ground clamp curve from 
> -VDDQ to
> VDDQ, and the power clamp curve from VDDQ to 2*VDDQ.  In theory, you 
> should
> be able to just attach the two curves together and get the right 
> result - or
> at least, that's the assumption s2ibis2 seems to be operating on.  
> Remember,
> because the power clamp curve in IBIS is rail-referenced, a sweep from 
> VDDQ
> to 2*VDDQ shows up in the IBIS file as from 0 to -VDDQ.
>
> There are a couple of interesting caveats here.  First, s2ibis2 ground 
> clamp
> curves actually all end at the same point, which is the [typ] value of 
> VDDQ.
> Let's assume that we have an HSTL 1.5 driver, whose power rail can 
> vary by
> 10%.  Thus, the [min] power rail is 1.35V, while the [max] power rail 
> is
> 1.65V.  In this case, the ground clamp data ends at 1.5V in all three 
> cases.
>
> The power clamp curves have the same issue, but in reverse.  They are
> supposed to sweep from VDDQ to 2*VDDQ.  That's 0 to -VDDQ in IBIS 
> terms (the
> curves really go from -VDDQ to 0 in the IBIS data, because voltages are
> supposed to increase).  However, all three curves start at the same 
> point,
> which is 2*VDDQ[typ] (-VDDQ[typ] in IBISese), and end at the same 
> point,
> which is 0V.
>
> But - and this is a big one - because the power clamp curves are
> rail-referenced, 0V means different things in the different cases.  It 
> means
> 1.35V for [min], 1.5V for [typ] and 1.65V for [max].  So - if we 
> adjust for
> the rail reference and talk about ground-referenced voltages, the 
> voltage
> data points for the power clamp curves range from:
>
> [min] 1.35V to 2.85V
> [typ] 1.5V to 3.0V
> [max] 1.65V to 3.15V
>
> Let's set those side by side with the ground clamp curves and see what 
> we
> get:
>
>       Ground Clamp             Power Clamp
> [min] -1.5V to 1.5V            1.35V to 2.85V
> [typ] -1.5V to 1.5V            1.5V to 3.0V
> [max] -1.5V to 1.5V            1.65V to 3.15V
>
> The [typ] curves complement each other just fine, but there is an 
> overlap in
> the [min] data and a gap in the [max] data.  We're primarily concerned 
> about
> capturing the behavior of the input termination across the entire 
> operating
> region here, so this looks like it might be a problem.  Of course, 
> that is
> determined by how the simulator handles the situation where the clamp 
> V-I
> curves overlap or have a gap in them.  We didn't expect what we found,
> however.
>
>
> 3) How IBIS simulators use the data in the IBIS models
> ------------------------------------------------------
> Different simulators may well do different things, and I'm not trying 
> to say
> I've tested all of them.  At least some of them, if not all of them, 
> behave
> as I'm describing here.
>
> We suspected an IBIS simulator might "double count" the current in the
> overlap region in the [min]case (between 1.35V and 1.5V), thereby 
> making the
> termination appear twice as strong as it really was (in that region).  
> We
> didn't know what was going to happen in the [max] case, with a cap in 
> the
> data between 1.5 and 1.65V.  So - we read the models in and tested 
> them.
>
> What we found, empirically, is that the simulator didn't add the curves
> together the way you might expect - taking the data from the ground 
> clamp
> curve between -VDDQ and VDDQ, and the data from the power clamp curve
> between VDDQ and 2*VDDQ.  Instead, the simulator *extended each curve 
> by
> extrapolation* to cover the entire region from -VDDQ to 2*VDDQ, and 
> *THEN*
> added the currents together.  In other words, the power clamp curve 
> (which,
> at the "IBIS 0V" point, corresponding to VDDQ, has a slope of roughly 
> the
> termination value) got extended through the whole operating region 
> with a
> slope roughly equal to the termination value.  Now, when the simulator 
> added
> the contributions of the power and ground clamps in the operating 
> region, it
> came up with roughly twice the correct current, making the termination
> appear twice as strong as it really was.  We started out thinking there
> might be a small problem in the gap/overlap regions of the [max/min] 
> curves,
> and discovered instead that none of the simulation cases were working
> correctly, anywhere in the operating region.
>
> This is a classic case of compartmentalization and assumptions - 
> between
> IBIS, s2ibis2 and the IBIS simulators.  Bottom line, the basic 
> assumption
> was that clamps don't kick in until you go beyond the rail, and the 
> overall
> process falls apart in this case as a result.
>
>
> 4) What we can do about it
> --------------------------
> Again, I'm predicating this on the use of s2ibis2 to create IBIS 
> models.
> The goal is simple: create an IBIS model that accurately reproduces the
> combined behavior of the clamps and input termination over the range
> from -VDDQ to 2*VDDQ.
>
> Both proposals both rely on the same basis: having s2ibis2 perform a 
> single
> input V-I sweep, over the voltage range from -VDDQ to 2*VDDQ.  That one
> simulation would capture all the behavior we're concerned about here.  
> From
> there, it's just a matter of how you format the data.
>
> Proposal 1) Says that you put the whole kit & kaboodle into the [GND 
> Clamp]
> curve and omit the [POWER Clamp] curve entirely.  There's really only 
> one
> composite input characteristic, anyway; separating it into two sets of 
> clamp
> curves is artificial.  Having two curves provides benefits in some 
> cases,
> but it's hard to argue that those benefits apply here.  This is the 
> easiest
> solution to implement, and provides the composite curve in one place.  
> The
> downside is that some users might object to having the power clamp data
> included in the [GND Clamp] curve, and that some simulation tools 
> might also
> have a problem with this.  A simulation tool that used a different 
> technique
> for combining the curve data might very well have a problem with this
> approach.
>
> Proposal 2) ... which Arpad suggested, was to find the zero-current 
> point in
> each of the min-typ-max cases, and assign all negative current to the 
> ground
> clamp, and all positive current to the power clamp.  You need to make 
> sure
> that each clamp curve has two consecutive voltage data points with zero
> current at the correct end of the curve (so that all further points 
> are zero
> current by extrapolation).  You also need to do the proper voltage
> translations when assigning current to the power clamp curve.  The 
> advantage
> of this technique is that you end up with two sets of clamp curves as 
> most
> people expect, and they add together correctly.  This disadvantage is a
> slight increase in process complexity, and the fact that you probably 
> won't
> be able to view the overall input behavior in one place.  
> Interestingly, the
> IBIS-viewer/model-editor tools seem to allow you to view the combined 
> V-I
> characteristics of the output buffers, but don't provide for viewing 
> the
> combined characteristics of the power and ground clamp curves on an 
> input.
>
> .... so there you have it - s2ibis2 and input termination modeling in 
> IBIS,
> as I presently understand it.  Corrections to my reasoning, comments 
> and
> thoughts on the subject are both welcome and greatly appreciated.
>
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:[email-masked]
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake?
>  Life gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
>
Kim Helliwell
Apple Computer
[email-masked]
408 974 9936

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 8 May 2003 17:16:15 -0400
From: "Mike LaBonte" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

There is a way to deal with any uncertainty over how simulators will treat
the "missing" data in power clamp and gnd clamp curves - don't have any
missing data! If both curves extended from -VDD to 2VDD there would be no
guessing. Of course if you are going to go that far, why not just model both
clamps in one curve (Proposal 1). But even if you do Proposal 2, don't end
the curves at the zero current point. Take the zero current all the way to
the other end of the voltage range. Don't make the simulators guess what the
remaining data is.

An observation: characterizing both clamps in one V/I curve is more or less
a black-box approach, in that it does not assume any knowledge that the
buffer has separate diodes connected to power and ground. It just measures
how the buffer behaves when tristated. I like the simplicity of that. Now if
we measured the static behavior of the buffer in 2 other states and added
dynamic info on how to make the transitions from each state to the others we
would have a truly behavioral model, with no notion of structure. In our
attempt to model the behavior of buffers at 3 ports (pad, power, ground)
IBIS became complicated.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Todd Westerhoff
> Sent: Thursday, May 08, 2003 1:44 AM
> To: Ibis-Users (E-mail)
> Subject: [IBIS-Users] Modeling input receivers with on-die termination
>
>
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
...

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 08 May 2003 16:26:54 -0500
From: John Phillippe <[email-masked]>
Subject: [IBIS-Users] Using IBIS models for VDD droop & Ground Bounce

I'm curious as to how many people use IBIS models to simulate VDD Droop 
and Ground Bounce.  Is IBIS even a worthwhile format to try this with? 
Do current simulators do anything with regards to modeling the voltage 
drops across the powerbus on the chip?

- -- 
John Phillippe
SPS, 32 Bit Embedded Controller Division, IC Creation
Motorola      -  512-895-1835
Austin, TX    -  [email-masked]

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 8 May 2003 14:52:17 -0700
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Even though it may be somewhat more complicated to make a model that way,
it is better to separate the currents of the two clamps for the case when
you have power delivery network around the buffer's power and GND connections
and you are interested in the amount of noise in each.  If you combined
everything into just one curve, say the GND clamp curve, all of your noise
will show up in the GND pad, and nothing in the power pad when your signal
makes the clamps work.

I completely agree with Mike Labonte, that you should extend the tables
- -Vcc to 2 * Vcc, that way the tool will have everything defined.  That's
why I developed the algorithms which I have mentioned before.

The only problem that you cannot avoid is that when your buffer has a
double termination, i.e. both pullup and pulldown together then the
"going to zero and extending" algorithm will still not account for the
correct currents from the power and GND pads, because it is not able
to separate the upper and lower resistance values.  In order to do that,
you need to either be able to turn one or the other off, so you can
measure at least one of them separately, or you will need to start
separating things in the netlist (or on the die).

Arpad
===========================================================================

- -----Original Message-----
From: Mike LaBonte [mailto:[email-masked]]
Sent: Thursday, May 08, 2003 2:16 PM
To: Todd Westerhoff; Ibis-Users (E-mail)
Subject: RE: [IBIS-Users] Modeling input receivers with on-die
termination

There is a way to deal with any uncertainty over how simulators will treat
the "missing" data in power clamp and gnd clamp curves - don't have any
missing data! If both curves extended from -VDD to 2VDD there would be no
guessing. Of course if you are going to go that far, why not just model both
clamps in one curve (Proposal 1). But even if you do Proposal 2, don't end
the curves at the zero current point. Take the zero current all the way to
the other end of the voltage range. Don't make the simulators guess what the
remaining data is.

An observation: characterizing both clamps in one V/I curve is more or less
a black-box approach, in that it does not assume any knowledge that the
buffer has separate diodes connected to power and ground. It just measures
how the buffer behaves when tristated. I like the simplicity of that. Now if
we measured the static behavior of the buffer in 2 other states and added
dynamic info on how to make the transitions from each state to the others we
would have a truly behavioral model, with no notion of structure. In our
attempt to model the behavior of buffers at 3 ports (pad, power, ground)
IBIS became complicated.

Mike
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 09:18:58 +0900
From: "Hideya Sawada" <[email-masked]>
Subject: [IBIS-Users] Please Remove

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 8 May 2003 15:54:37 -0700 
From: "Peters, Stephen" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Hi Todd, all:

  I second Kims' comment: great exposition. I have just one comment - in the
"Notes on Data Derivation Method" section in the back of the IBIS spec (ver
3.2) there is a table that lists the expected voltage range for each curve.
Data for [GND Clamp] table is expected to cover the range GND - POWER to GND
+ POWER, while data for [POWER Clamp] table is expected to cover POWER to
POWER + POWER.  

Not sure though if this makes a difference in the problem with s2ibis
extraction (only using the typical VDDQ) or the subsequent simulator
extrapolation of the data.

 Regards,
 Stephen Peters
 Intel Corp.

  

- -----Original Message-----
From: Kim Helliwell [mailto:[email-masked]] 
Sent: Thursday, May 08, 2003 1:48 PM
To: Todd Westerhoff
Cc: Ibis-Users (E-mail)
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination

Great exposition; I hadn't thought about that, but it's definitely an issue
that affects me.

Your solutions are, I think, aimed at how to make better models.

I'd be more interested in at least 2 other angles:
1. How to massage models already supplied to me, when I
     don't have access to the HSPICE models.

2. How to get simulator makers to address this issue in the simulators
      proper, assuming that models won't be "perfect".

On Wednesday, May 7, 2003, at 10:44  PM, Todd Westerhoff wrote:

> Hi all,
>
> This one has been bugging us for a while ... the discussions that took
> place
> last week gave us the opportunity to take another look at this problem 
> and
> its different components.  I have two solutions to propose, and would
> appreciate feedback from the group.
>
> I apologize in advance for a lengthy email.  There's no other way I
> know to
> describe the different components of the problem and the way they 
> interact.
>
> To start - the problem is accurately modeling the effect of on-die
> input
> termination, most typically pulling the signal to a value of VDDQ/2, 
> which
> would be common for HSTL and SSTL signalling.  The resistors in 
> question (at
> least in our case) were not discrete components in the package - they 
> were
> truly on-die.  Hence, the resistance varied with process and was 
> non-linear
> over the operating range.  Thus, we needed a way to extract the actual 
> input
> characteristics using the HSpice model and create the correct model in 
> IBIS.
>
> Simple enough, we thought - then it got deep.
>
> To ended up breaking the problem down into three pieces -
>
> 1) The IBIS Specification
> 2) The process of creating models
> 3) How IBIS simulators use the data in the IBIS models
>
>
> 1) The IBIS Specification
> -------------------------
> Please correct me if I'm wrong here, but I believe the IBIS Spec
> doesn't
> list any "standard" for the voltage range over which the behavior of 
> the
> [GND Clamp] and [POWER Clamp] should be specified.  I took it as a 
> given
> that [Pulldown] and [Pullup] curves would range from -VDDQ to 2*VDDQ, 
> and,
> until last week, I would have expected to see the same range for the 
> power
> and ground clamps.  That turned out not to be the case.
>
> I also suspect that the IBIS spec has no comment on just how the
> simulator
> is supposed to combine the data in the two clamp curves, should the 
> points
> overlap.  That turned out to be a big sticking point.
>
>
> 2) The process of creating models
> ---------------------------------
> There are two classes of people who create IBIS models from HSpice
> simulations:
>
> a) The gurus, who understand IBIS, HSpice and software well enough to 
> develop their own tools for extracting and compiling IBIS model data, 
> and
>
> b) The rest of us, who use some version of s2ibis2.  Usually, it's one
> we've
> compiled ourselves, with some collection of fixes implemented for 
> problems
> we have found on our own.  I'm going to aim my comments squarely at 
> s2ibis2,
> with the assumption that's what most of the IBIS-modelmakers are basing
> their efforts on.
>
> When s2ibis2 was created, the developer noticed an interesting problem
> -
> there is really no good way to separate the ground clamp curve from the
> power clamp curve.  With the [Pullup] and [Pulldown] curves, you can 
> isolate
> the behavior of transistor from the other by virtue of the output 
> state.
> However, if you model the input buffer and sweep the voltage from 
> -VDDQ to
> 2*VDDQ, there's really no good way to separate the one clamp curve 
> from the
> other.
>
> (When I talk about voltage from this point on, I'm going to use ground
> as a
> reference, unless I specifically state that I'm using a power-based 
> voltage
> reference "a la IBIS".  I'm also going to assume the ground clamp is 
> active
> between -VDDQ and 0V, the "operating region" for the device is between 
> 0V
> and VDDQ, and the power clamp is active between VDDQ and 2*VDDQ).
>
> Of course, if you've got a normal input (without termination), the
> input
> current is zero (or essentially so) throughout the operating region, so
> there isn't really any problem.  It doesn't much matter where the 
> ground
> clamp curve leaves off and the power clamp curve kicks in, because the
> currents at those points are always zero.
>
> However, the presence of on-die termination to VDDQ/2 presents an 
> interesting problem.  The "zero current" point is somewhere in the 
> middle of the operating region, and it's only a single point.  The 
> power and ground
> clamp curves, when added together, have to accurately represent the 
> input's
> characteristic throughout the device's operating region (0 to VDDQ), 
> if you
> want to input to behave properly.
>
> So now the question becomes - where does one curve leave off, and the
> other
> begin?  Well, s2ibis2 simply implements the ground clamp curve from 
> -VDDQ to
> VDDQ, and the power clamp curve from VDDQ to 2*VDDQ.  In theory, you 
> should
> be able to just attach the two curves together and get the right 
> result - or
> at least, that's the assumption s2ibis2 seems to be operating on.  
> Remember,
> because the power clamp curve in IBIS is rail-referenced, a sweep from 
> VDDQ
> to 2*VDDQ shows up in the IBIS file as from 0 to -VDDQ.
>
> There are a couple of interesting caveats here.  First, s2ibis2 ground
> clamp
> curves actually all end at the same point, which is the [typ] value of 
> VDDQ.
> Let's assume that we have an HSTL 1.5 driver, whose power rail can 
> vary by
> 10%.  Thus, the [min] power rail is 1.35V, while the [max] power rail 
> is
> 1.65V.  In this case, the ground clamp data ends at 1.5V in all three 
> cases.
>
> The power clamp curves have the same issue, but in reverse.  They are 
> supposed to sweep from VDDQ to 2*VDDQ.  That's 0 to -VDDQ in IBIS 
> terms (the curves really go from -VDDQ to 0 in the IBIS data, because 
> voltages are supposed to increase).  However, all three curves start 
> at the same point,
> which is 2*VDDQ[typ] (-VDDQ[typ] in IBISese), and end at the same 
> point,
> which is 0V.
>
> But - and this is a big one - because the power clamp curves are 
> rail-referenced, 0V means different things in the different cases.  It 
> means 1.35V for [min], 1.5V for [typ] and 1.65V for [max].  So - if we
> adjust for
> the rail reference and talk about ground-referenced voltages, the 
> voltage
> data points for the power clamp curves range from:
>
> [min] 1.35V to 2.85V
> [typ] 1.5V to 3.0V
> [max] 1.65V to 3.15V
>
> Let's set those side by side with the ground clamp curves and see what
> we
> get:
>
>       Ground Clamp             Power Clamp
> [min] -1.5V to 1.5V            1.35V to 2.85V
> [typ] -1.5V to 1.5V            1.5V to 3.0V
> [max] -1.5V to 1.5V            1.65V to 3.15V
>
> The [typ] curves complement each other just fine, but there is an
> overlap in
> the [min] data and a gap in the [max] data.  We're primarily concerned 
> about
> capturing the behavior of the input termination across the entire 
> operating
> region here, so this looks like it might be a problem.  Of course, 
> that is
> determined by how the simulator handles the situation where the clamp 
> V-I
> curves overlap or have a gap in them.  We didn't expect what we found,
> however.
>
>
> 3) How IBIS simulators use the data in the IBIS models
> ------------------------------------------------------
> Different simulators may well do different things, and I'm not trying
> to say
> I've tested all of them.  At least some of them, if not all of them, 
> behave
> as I'm describing here.
>
> We suspected an IBIS simulator might "double count" the current in the 
> overlap region in the [min]case (between 1.35V and 1.5V), thereby 
> making the termination appear twice as strong as it really was (in 
> that region).
> We
> didn't know what was going to happen in the [max] case, with a cap in 
> the
> data between 1.5 and 1.65V.  So - we read the models in and tested 
> them.
>
> What we found, empirically, is that the simulator didn't add the 
> curves together the way you might expect - taking the data from the 
> ground clamp curve between -VDDQ and VDDQ, and the data from the power 
> clamp curve between VDDQ and 2*VDDQ.  Instead, the simulator *extended 
> each curve by
> extrapolation* to cover the entire region from -VDDQ to 2*VDDQ, and 
> *THEN*
> added the currents together.  In other words, the power clamp curve 
> (which,
> at the "IBIS 0V" point, corresponding to VDDQ, has a slope of roughly 
> the
> termination value) got extended through the whole operating region 
> with a
> slope roughly equal to the termination value.  Now, when the simulator 
> added
> the contributions of the power and ground clamps in the operating 
> region, it
> came up with roughly twice the correct current, making the termination
> appear twice as strong as it really was.  We started out thinking there
> might be a small problem in the gap/overlap regions of the [max/min] 
> curves,
> and discovered instead that none of the simulation cases were working
> correctly, anywhere in the operating region.
>
> This is a classic case of compartmentalization and assumptions -
> between
> IBIS, s2ibis2 and the IBIS simulators.  Bottom line, the basic 
> assumption
> was that clamps don't kick in until you go beyond the rail, and the 
> overall
> process falls apart in this case as a result.
>
>
> 4) What we can do about it
> --------------------------
> Again, I'm predicating this on the use of s2ibis2 to create IBIS
> models.
> The goal is simple: create an IBIS model that accurately reproduces the
> combined behavior of the clamps and input termination over the range
> from -VDDQ to 2*VDDQ.
>
> Both proposals both rely on the same basis: having s2ibis2 perform a
> single
> input V-I sweep, over the voltage range from -VDDQ to 2*VDDQ.  That one
> simulation would capture all the behavior we're concerned about here.  
> From
> there, it's just a matter of how you format the data.
>
> Proposal 1) Says that you put the whole kit & kaboodle into the [GND
> Clamp]
> curve and omit the [POWER Clamp] curve entirely.  There's really only 
> one
> composite input characteristic, anyway; separating it into two sets of 
> clamp
> curves is artificial.  Having two curves provides benefits in some 
> cases,
> but it's hard to argue that those benefits apply here.  This is the 
> easiest
> solution to implement, and provides the composite curve in one place.  
> The
> downside is that some users might object to having the power clamp data
> included in the [GND Clamp] curve, and that some simulation tools 
> might also
> have a problem with this.  A simulation tool that used a different 
> technique
> for combining the curve data might very well have a problem with this
> approach.
>
> Proposal 2) ... which Arpad suggested, was to find the zero-current
> point in
> each of the min-typ-max cases, and assign all negative current to the 
> ground
> clamp, and all positive current to the power clamp.  You need to make 
> sure
> that each clamp curve has two consecutive voltage data points with zero
> current at the correct end of the curve (so that all further points 
> are zero
> current by extrapolation).  You also need to do the proper voltage
> translations when assigning current to the power clamp curve.  The 
> advantage
> of this technique is that you end up with two sets of clamp curves as 
> most
> people expect, and they add together correctly.  This disadvantage is a
> slight increase in process complexity, and the fact that you probably 
> won't
> be able to view the overall input behavior in one place.  
> Interestingly, the
> IBIS-viewer/model-editor tools seem to allow you to view the combined 
> V-I
> characteristics of the output buffers, but don't provide for viewing 
> the
> combined characteristics of the power and ground clamp curves on an 
> input.
>
> .... so there you have it - s2ibis2 and input termination modeling in
> IBIS,
> as I presently understand it.  Corrections to my reasoning, comments 
> and
> thoughts on the subject are both welcome and greatly appreciated.
>
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719 email:[email-masked]
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake?  Life 
> gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked] with 
> |just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent  
> | http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
>
Kim Helliwell
Apple Computer
[email-masked]
408 974 9936

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked] with just 
|the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent  
| http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Thu, 8 May 2003 20:32:26 -0400
From: "Lynne Green" <[email-masked]>
Subject: RE: [IBIS-Users] hspice version for s2ibis2?

Hi, Eric,

s2ibis2 can also use other "spice" simulators (such as Spectre and
PSpice).

You should use whichever simulator uses the exact models provided by the
fab.  A fab provides different model parameters and parameter values,
depending on whether you intend to use HSpice, Spectre, or Eldo.  These
models are not portable between the simulators.

- - Lynne

Dr. Lynne Green
Senior Member of Consulting Staff
Cadence Design Systems, Inc.

"Digital is analog that you hope is in one of two states."

- -----Original Message-----
From: Syed Huq [mailto:[email-masked]] 
Sent: Monday, May 05, 2003 12:08 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [IBIS-Users] hspice version for s2ibis2?

I believe s2ibis2 is not dependent on a particular HSPICE version. It
calls HSPICE thur the [spice type] keyword..

It will pick up the HSPICE version pointed in your PATH variable.

Syed

>content-class: urn:content-classes:message
>MIME-Version: 1.0
>Subject: [IBIS-Users] hspice version for s2ibis2?
>X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
>Date: Mon, 5 May 2003 11:02:22 -0700
>Thread-Topic: hspice version for s2ibis2?
>Thread-Index: AcMTMHpbBtMfKG3pTNSTXCEkuquNAw==
>From: "Eric Hsu" <[email-masked]>
>To: <[email-masked]>
>Cc: "Frank Dunlap" <[email-masked]>
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org 
>id
h45I0o9a006058
>
>Hi,
>
>When generating ibis model by s2ibis2 and hspice engine, does any one 
>know
the hspice version information to be able to compatible with s2ibis2?
>
>Best Regards,
>
>Eric Hsu
>Interface Technologies
>NetLogic Microsystems, Inc.
>450 National Ave.
>Mountain View, CA 94043
>650-961-6676 x198
>This e-mail contains NetLogic Microsystems, Inc. Confidential 
>information
>
>
>|------------------------------------------------------------------
>|For help or to subscribe/unsubscribe, email [email-masked] with 
>|just the appropriate command message(s) in the body:
>|
>|  help
>|  subscribe   ibis       <optional e-mail address, if different>
>|  subscribe   ibis-users <optional e-mail address, if different>
>|  unsubscribe ibis       <optional e-mail address, if different>
>|  unsubscribe ibis-users <optional e-mail address, if different>
>|
>|or email a written request to [email-masked].
>|
>|IBIS reflector archives exist under:
>|
>|  http://www.eda.org/pub/ibis/email_archive/  Recent  
>| http://www.eda.org/pub/ibis/users_archive/  Recent
>|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked] with just

|the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent  
| http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 09 May 2003 09:09:42 +0530
From: Anshuli Goel <[email-masked]>
Subject: [IBIS-Users] Non - Monotonicity of the data

Hello Experts

I am trying to do IBIS model generation of one o/p tristate
buffer
susing s2ibis2.
Beyond the rail simulations I am getting follwoing error
"_____________________________
"* ERROR * [SIM:0] Current (5.12686e+38) of voltage source
VOUTS2I
exceeds CURMAX (1)
* ERROR * [SIM:1] Current (-5.12686e+38) of voltage source
VSS exceeds
 -CURMAX (-1)
_____________________________

Reson of this as far as I understand is that after one
particular
voltage the clamp diode start working and give these
errors.

Somewhere I read
"Semiconductor device models may not be well behaved over
these ranges,
so it is acceptable to lessen the actual sweep range and
then use linear
extrapolation to get to the required endpoints. However,
the simulation
sweep range must be enough to forward bias any
ESD/protection diodes or
the diodes intrinsic to the output transistor
structures."

I also want to do linear extrapolation for the buffer in
question. What
is the way to do the extrapolation ?

One more thing is that I get non-monotonic data in Power
clamp curve.
How can I get rid of this non-monotonicity ?

Regards
Anshuli Goel

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 09 May 2003 12:20:40 +0530
From: Ramesh Karmungi <[email-masked]>
Subject: [IBIS-Users] DC endpoint errors

Hello Experts,

I have used ibischk3 parser for my models and it has given following
errors and the file as failed.

What is the accuracy of my results in case I use this model.

Could anyone please suggest why these errors occur and how to overcome
these errors.

WARNING - Model IO: The [Rising Waveform]
      with [R_fixture]=70 Ohms and [V_fixture]=0V
      has TYP column DC endpoints of  0.01V and  2.03v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 0.02V and  2.07V),
      a difference of  0.58% and  2.10%, respectively.
ERROR - Model IO: The [Rising Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=0V
      has MIN column DC endpoints of  0.00V and  1.04v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 0.01V and  1.42V),
      a difference of  0.56% and 26.94%, respectively.
ERROR - Model IO: The [Falling Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=2.7V
      has MIN column DC endpoints of  1.71V and  2.70v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.59V and  2.70V),
      a difference of 10.89% and  0.00%, respectively.
ERROR - Model out: The [Rising Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=0V
      has MIN column DC endpoints of  0.00V and  1.05v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 0.00V and  1.41V),
      a difference of  0.00% and 25.47%, respectively.
ERROR - Model out: The [Falling Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=2.7V
      has MIN column DC endpoints of  1.70V and  2.70v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.58V and  2.70V),
      a difference of 10.70% and  0.00%, respectively.

Thanks in anticipation.

Ramesh

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 09:34:38 +0200
From: "Henrik G. Madsen" <[email-masked]>
Subject: RE: [IBIS-Users] DC endpoint errors

A guess

I seems like that the person, who made the IBIS model did not simulate long enough. The VT curves have not reached steady state.

If you did the models yourselves using s2ibis2, try to extend the simulation time by increasing [Sim time] parameter in the .s2i setup file.

Otherwise return to the model provider and ask for a better model.

Regards
/Henrik G Madsen

- -----Original Message-----
From: Ramesh Karmungi [mailto:[email-masked]]
Sent: 9. maj 2003 08:51
To: [email-masked]'
Subject: [IBIS-Users] DC endpoint errors

Hello Experts,

I have used ibischk3 parser for my models and it has given following
errors and the file as failed.

What is the accuracy of my results in case I use this model.

Could anyone please suggest why these errors occur and how to overcome
these errors.

WARNING - Model IO: The [Rising Waveform]
      with [R_fixture]=70 Ohms and [V_fixture]=0V
      has TYP column DC endpoints of  0.01V and  2.03v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 0.02V and  2.07V),
      a difference of  0.58% and  2.10%, respectively.
ERROR - Model IO: The [Rising Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=0V
      has MIN column DC endpoints of  0.00V and  1.04v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 0.01V and  1.42V),
      a difference of  0.56% and 26.94%, respectively.
ERROR - Model IO: The [Falling Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=2.7V
      has MIN column DC endpoints of  1.71V and  2.70v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.59V and  2.70V),
      a difference of 10.89% and  0.00%, respectively.
ERROR - Model out: The [Rising Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=0V
      has MIN column DC endpoints of  0.00V and  1.05v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 0.00V and  1.41V),
      a difference of  0.00% and 25.47%, respectively.
ERROR - Model out: The [Falling Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_min]=2.7V
      has MIN column DC endpoints of  1.70V and  2.70v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.58V and  2.70V),
      a difference of 10.70% and  0.00%, respectively.

Thanks in anticipation.

Ramesh

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 09:40:58 +0200
From: [email-masked]
Subject: RE: [IBIS-Users] (lv)pecl

This is a multipart message in MIME format.
- --=_alternative 002A6325C1256D21_=
Content-Type: text/plain; charset="us-ascii"

Tom,

Thank you for your reply. I am starting with a Spectre netlist. I have 
tried s2ibis to make a model for LVPECL.
I noticed some differences. ECL has a supply of 0V (plus) and -5.2V (neg). 
My circuit has a supply of 3.3V (plus) and 0V (neg).
The pulldown table ranges from 1.1V to 3.3V (the pull down reference has 
been set to 3.3V, the pull-up reference as well), followed by ten lines of 
garbage. A collegue of mine has changed to pragram a bit so the pull down 
curve starts at 0V and ends at 2.2V (still followed by ten lines of 
garbage).
Is this a correct range?
What does the simulator that uses the IBIS model do with the information 
that it is an output-ECL model type? And how are the data tables 
interpreted in conjunction with the ECL_model type?

With kind regards,

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334

"Tom Dagostino" <[email-masked]>
05/08/03 07:16 PM
Please respond to tom

        To:     Erik van der Ven/NYM/SC/PHILIPS@EMEA2
        cc: 
        Subject:        RE: [IBIS-Users] (lv)pecl
        Classification: 

Erik
 
What are you starting with?  A SPICE description or are you going to make 
the model from measurements?  If you start with SPICE there is a spice to 
ibis program that you can download from the ibis home page.  If you are 
starting from measurements then you will need a lot of equipment to make 
the measurements.  You will have to manually convert the measurements to 
the ibis data.
 
Simulators use the output_ecl line to know how to handle ECL.  In IBIS ECL 
models are slightly different than standard CMOS or TTL drivers.  In CMOS 
or TTL the pulldown current is sunk into the ground plane and the pullup 
current is sourced from the supply.  With PECL both the pullup and 
pulldown are sourced from the supply.  So in PECL the pulldown is 
referenced to the supply, not ground.  The simulator needs to know this 
when it is using the IV tables.
 
Tom Dagostino
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
2926 SE Yamhill St.                Device Modeling Division
Portland, OR 97214                 13610 SW Harness Lane
                                   Beaverton, OR 97008
http://www.teraspeed.com           503-430-1065 
[email-masked] 
- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Thursday, May 08, 2003 12:04 AM
To: [email-masked]
Subject: [IBIS-Users] (lv)pecl

Dear all, 

I think I mailed my question too early since I subscribed to the user 
group at the same time. So I'll post it again, please see below. 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334 
- ----- Forwarded by Erik van der Ven/NYM/SC/PHILIPS on 05/08/03 09:03 AM 
- ----- 

Erik van der Ven 
05/06/03 02:01 PM 
        
        To:        [email-masked] 
        cc:         
        Subject:        (lv)pecl 
        Classification:        Unclassified 

1. How can I make an IBIS model of a (LV)PECL model? 
2. What does an IBIS simulator do with the model type information (like 
output_ECL)? 

Can anyone help me? 
Thanks. 

With kind regards, 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334 

- --=_alternative 002A6325C1256D21_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Tom,</font>
<br>
<br><font size=2 face="sans-serif">Thank you for your reply. I am starting with a Spectre netlist. I have tried s2ibis to make a model for LVPECL.</font>
<br><font size=2 face="sans-serif">I noticed some differences. ECL has a supply of 0V (plus) and -5.2V (neg). My circuit has a supply of 3.3V (plus) and 0V (neg).</font>
<br><font size=2 face="sans-serif">The pulldown table ranges from 1.1V to 3.3V (the pull down reference has been set to 3.3V, the pull-up reference as well), followed by ten lines of garbage. A collegue of mine has changed to pragram a bit so the pull down curve starts at 0V and ends at 2.2V (still followed by ten lines of garbage).</font>
<br><font size=2 face="sans-serif">Is this a correct range?</font>
<br><font size=2 face="sans-serif">What does the simulator that uses the IBIS model do with the information that it is an output-ECL model type? And how are the data tables interpreted in conjunction with the ECL_model type?</font>
<br>
<br><font size=2 face="sans-serif">With kind regards,</font>
<br><font size=2 face="sans-serif"><br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>&quot;Tom Dagostino&quot; &lt;[email-masked]&gt;</b></font>
<p><font size=1 face="sans-serif">05/08/03 07:16 PM</font>
<br><font size=1 face="sans-serif">Please respond to tom</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Erik van der Ven/NYM/SC/PHILIPS@EMEA2</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: [IBIS-Users] (lv)pecl</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Arial">Erik</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">What are you starting with? &nbsp;A SPICE description or are you going to make the model from measurements? &nbsp;If you start with SPICE there is a spice to ibis program that you can download from the ibis home page. &nbsp;If you are starting from measurements then you will need a lot of equipment to make the measurements. &nbsp;You will have to manually convert the measurements to the ibis data.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">Simulators use the output_ecl line to know how to handle ECL. &nbsp;In IBIS ECL models are slightly different than standard CMOS or TTL drivers. &nbsp;In CMOS or TTL the pulldown current is sunk into the ground plane and the pullup current is sourced from the supply. &nbsp;With PECL both the pullup and pulldown are sourced from the supply. &nbsp;So in PECL the pulldown is referenced to the supply, not ground. &nbsp;The simulator needs to know this when it is using the IV tables.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=3 face="Courier New">Tom Dagostino</font>
<br><font size=3 face="Courier New">Teraspeed Consulting Group LLC &nbsp; &nbsp; Teraspeed Consulting Group LLC</font>
<br><font size=3 face="Courier New">2926 SE Yamhill St. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Device Modeling Division</font>
<br><font size=3 face="Courier New">Portland, OR 97214 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 13610 SW Harness Lane</font>
<br><font size=3 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Beaverton, OR 97008</font>
<br><font size=3 face="Courier New">http://www.teraspeed.com &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 503-430-1065 </font>
<p><font size=3 face="Courier New">[email-masked]</font><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Tahoma">-----Original Message-----<b><br>
From:</b> [email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>[email-masked]<b><br>
Sent:</b> Thursday, May 08, 2003 12:04 AM<b><br>
To:</b> [email-masked]<b><br>
Subject:</b> [IBIS-Users] (lv)pecl<br>
</font>
<br><font size=2 face="sans-serif"><br>
Dear all,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
I think I mailed my question too early since I subscribed to the user group at the same time. So I'll post it again, please see below.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font><font size=3 face="Times New Roman"> </font><font size=1 color=#800080 face="sans-serif"><br>
- ----- Forwarded by Erik van der Ven/NYM/SC/PHILIPS on 05/08/03 09:03 AM -----</font><font size=3 face="Times New Roman"> </font>
<table width=100%>
<tr valign=top>
<td width=4%>
<td width=34%><font size=3 face="Times New Roman"><br>
<br>
<br>
<br>
</font><font size=1 face="sans-serif"><b><br>
Erik van der Ven</b></font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">05/06/03 02:01 PM</font><font size=3 face="Times New Roman"> </font>
<td width=60%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;(lv)pecl</font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;Unclassified</font><font size=3 face="Times New Roman"> </font></table>
<p><font size=3 face="Times New Roman"><br>
</font><font size=2 face="sans-serif"><br>
1. How can I make an IBIS model of a (LV)PECL model?</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
2. What does an IBIS simulator do with the model type information (like output_ECL)?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Can anyone help me?</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Thanks.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
With kind regards,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font><font size=3 face="Times New Roman"> </font>
<p>
<p>
- --=_alternative 002A6325C1256D21_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 08:05:20 -0700 
From: "Peters, Stephen" <[email-masked]>
Subject: RE: [IBIS-Users] Agenda, IBIS Open Forum Teleconference 5/9

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_01C3163C.68932B30
Content-Type: text/plain

The correct reservation number is 3

- -----Original Message-----
From: Peters, Stephen [mailto:[email-masked]] 
Sent: Friday, May 02, 2003 8:01 AM
To: [email-masked]'; [email-masked]'
Subject: [IBIS-Users] Agenda, IBIS Open Forum Teleconference 5/9

                    IBIS Open Forum Meeting Agenda
                            for 5/9/03
 
                 Bridge Number    Reservation #   Passcode
                 1-916-356-2663       1           8390090
                 (International Dial-In: 1-617-801-9781)
 
All meetings are 8:00 AM to 9:55 AM Pacific Time.  When you call into the 
meeting, ask for the IBIS Open Forum hosted by Stephen Peters and give the
Reservation Number and Passcode.
 
8:00 Check-In, Intros, Announcements                         Peters
 
     - Intros of New IBIS Participants, Meeting Quorum       Peters
     - Call for Patents                                      Peters
     - Membership Update and Treasurers Report               Peters
     - Review of Previous Meeting's Minutes (and ARs)        Peters
     - Miscellany/Announcements                              All
     - Press & Web Page Updates                              Huq, All
     - New Models Available, Library Update                  Leventhal, All
     - Opens for New Issues                                  All
 
8:15 Administrative and Project Discussions
 
     International/External Progress
     - IEC 62014-3 (ICEM) Integrated Circuits Electromagnetic 
       Model Proposal (IEC 93/67/NP IBIS and EMC Simulation) Perrin/Peters
     - JEDEC Committee Report                                Green
 
     DAC2003 Meeting Planning                                Peters
     - Election of Officers
 
     DesignCon2003 East Meeting Planning                     Peters
 
     IBIS Version 4.0 Parser Funding and Status              Peters
 
     IBIS Version 4.1 Discussion                             Peters/Ross
 
     IBIS Quality Committee                                  Katz
 
     IBIS Model Review Committee                             Green
 
     New Administrative Issues                               All
 
8:45 Technical Discussion
 
     IBIS Connector Group Report                             Peters/Green
 
     BIRD74.3 - EMI Parameters                               de Burgh
 
     IBISCHK3 Status                                         Ross
     - BUG71 - Monotonic Checking for Combined I-V Tables    Haller
 
     New Technical Issues                                    All
 
9:50 Wrap Up and Next Meetings Plans                         Peters
 
9:55 Sign Off

- ------_=_NextPart_001_01C3163C.68932B30
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><BR><SPAN class=3D720510615-09052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>The correct reservation number is 3</FONT></SPAN></DIV>
<DIV><SPAN class=3D720510615-09052003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D720510615-09052003></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Peters, Stephen=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Friday, May 02, =
2003 8:01=20
  AM<BR><B>To:</B> [email-masked]'; =
[email-masked]'<BR><B>Subject:</B>=20
  [IBIS-Users] Agenda, IBIS Open Forum Teleconference =
5/9<BR><BR></FONT></DIV>
  <DIV><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  =
class=3D297230115-02052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>IBIS Open Forum Meeting=20
  Agenda<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN =

  =
class=3D297230115-02052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>for 5/9/03</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
  =
class=3D297230115-02052003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>&nbsp;&nbsp; Bridge Number&nbsp;&nbsp;&nbsp; Reservation =
#&nbsp;&nbsp;=20
  =
Passcode<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  1-916-356-2663&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
8390090<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  (International Dial-In: 1-617-801-9781)</FONT></FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>All meetings are 8:00 AM to =
9:55 AM=20
  Pacific Time.&nbsp; When you call into the <BR>meeting, ask for the =
IBIS Open=20
  Forum hosted by Stephen Peters and give the Reservation Number and=20
  Passcode.</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>8:00 Check-In, Intros,=20
  =
Announcements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  Peters</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; - =
Intros of New=20
  IBIS Participants, Meeting Quorum&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  Peters<BR>&nbsp;&nbsp;&nbsp;&nbsp; - Call for=20
  =
Patents&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  Peters<BR>&nbsp;&nbsp;&nbsp;&nbsp; - Membership Update and Treasurers =

  =
Report&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
  Peters<BR>&nbsp;&nbsp;&nbsp;&nbsp; - Review of Previous Meeting's =
Minutes (and=20
  ARs)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Peters<BR>&nbsp;&nbsp;&nbsp;&nbsp; -=20
  =
Miscellany/Announcements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  All<BR>&nbsp;&nbsp;&nbsp;&nbsp; - Press &amp; Web Page=20
  =
Updates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Huq, All<BR>&nbsp;&nbsp;&nbsp;&nbsp; - New Models Available, Library=20
  =
Update&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Leventhal, All<BR>&nbsp;&nbsp;&nbsp;&nbsp; - Opens for New=20
  =
Issues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  All</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>8:15 Administrative and =
Project=20
  Discussions</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;=20
  International/External Progress<BR>&nbsp;&nbsp;&nbsp;&nbsp; - IEC =
62014-3=20
  (ICEM) Integrated Circuits Electromagnetic=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Model Proposal (IEC 93/67/NP =
IBIS and=20
  EMC Simulation) Perrin/Peters<BR>&nbsp;&nbsp;&nbsp;&nbsp; - JEDEC =
Committee=20
  =
Report&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Green</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
DAC2003 Meeting=20
  =
Planning&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Peters<BR>&nbsp;&nbsp;&nbsp;&nbsp; - Election of =
Officers</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
DesignCon2003=20
  East Meeting=20
  =
Planning&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Peters</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
IBIS Version 4.0=20
  Parser Funding and=20
  =
Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
  Peters</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
IBIS Version 4.1=20
  =
Discussion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Peters/Ross</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
IBIS Quality=20
  =
Committee&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Katz</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
IBIS Model=20
  Review=20
  =
Committee&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Green</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; New =

  Administrative=20
  =
Issues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  All</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>8:45 Technical =
Discussion</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
IBIS Connector=20
  Group=20
  =
Report&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Peters/Green</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
BIRD74.3 - EMI=20
  =
Parameters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  de Burgh<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp; IBISCHK3=20
  =
Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Ross<BR>&nbsp;&nbsp;&nbsp;&nbsp; - BUG71 - Monotonic Checking for =
Combined I-V=20
  Tables&nbsp;&nbsp;&nbsp; Haller</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; New =
Technical=20
  =
Issues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
  All</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>9:50 Wrap Up and Next =
Meetings=20
  =
Plans&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  Peters</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" size=3D2>9:55 Sign Off</FONT></DIV>
  <DIV><FONT face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

- ------_=_NextPart_001_01C3163C.68932B30--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 11:05:30 -0400
From: "Todd Westerhoff" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Kim, et al,

I'm a little surprised that none of the tool vendors have checked in by this
point.  I've had users tell me what the different tools do, but no word from
the tool-makers themselves.

It seems to me the rub is that s2ibis2 assumes the clamp curves will be
"added" one way (which is backed up, at least partially, by the IBIS spec,
as noted by Stephen) - and the simulators do something else by extrapolating
the power clamp curve.  Simply put, s2ibis2 assumes that clamp current
should be zero if voltage point is not specified in the particular clamp
curve - the simulators do not.

There is a different algorithm the simulators could use to avoid double
counting with the existing models:

1. Check the input voltage
2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
   Otherwise, look at the power clamp curve first.
3. If the voltage point exists in the curve you're looking at, use the
   corresponding entry for the current.  Done. (this takes care out
   double-counting and the overlap case)
4. If the voltage point does not exist in the first curve, check the second.
   If the voltage point exists, take the corresponding current value.  Done.
5. Only when the voltage point exists in neither curve (the gap case),
extend
   each curve by extrapolation to find the current at the point in question.
   This will provide two (potentially slightly different) current values -
   use the average of the two.

If the simulators worked this way, we wouldn't have to change s2ibis2 at all
(or, so it seems to me).  The proposal 1 technique from my original mail
would still work, but proposal 2 would need to be modified so that the
individual curves ended once they hit the zero current point.

Todd.

Todd Westerhoff
High Speed Design Specialist
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:[email-masked]
ph: 978-936-2149
============================================

"When did the choices get so hard, with so much more at stake?
 Life gets mighty precious when there's less of it to waste"

- - Bonnie Raitt, "Nick of Time"

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 10:19:50 -0700
From: "Tom Dagostino" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

This sounds like a band aid, not a solution.  Let's make the models correct
and not double count the currents.

Tom Dagostino
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
2926 SE Yamhill St.                Device Modeling Division
Portland, OR 97214                 13610 SW Harness Lane
                                   Beaverton, OR 97008
http://www.teraspeed.com           503-430-1065
[email-masked]

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Todd Westerhoff
Sent: Friday, May 09, 2003 8:06 AM
To: Ibis-Users (E-mail)
Subject: RE: [IBIS-Users] Modeling input receivers with on-die
termination

Kim, et al,

I'm a little surprised that none of the tool vendors have checked in by this
point.  I've had users tell me what the different tools do, but no word from
the tool-makers themselves.

It seems to me the rub is that s2ibis2 assumes the clamp curves will be
"added" one way (which is backed up, at least partially, by the IBIS spec,
as noted by Stephen) - and the simulators do something else by extrapolating
the power clamp curve.  Simply put, s2ibis2 assumes that clamp current
should be zero if voltage point is not specified in the particular clamp
curve - the simulators do not.

There is a different algorithm the simulators could use to avoid double
counting with the existing models:

1. Check the input voltage
2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
   Otherwise, look at the power clamp curve first.
3. If the voltage point exists in the curve you're looking at, use the
   corresponding entry for the current.  Done. (this takes care out
   double-counting and the overlap case)
4. If the voltage point does not exist in the first curve, check the second.
   If the voltage point exists, take the corresponding current value.  Done.
5. Only when the voltage point exists in neither curve (the gap case),
extend
   each curve by extrapolation to find the current at the point in question.
   This will provide two (potentially slightly different) current values -
   use the average of the two.

If the simulators worked this way, we wouldn't have to change s2ibis2 at all
(or, so it seems to me).  The proposal 1 technique from my original mail
would still work, but proposal 2 would need to be modified so that the
individual curves ended once they hit the zero current point.

Todd.

Todd Westerhoff
High Speed Design Specialist
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:[email-masked]
ph: 978-936-2149
============================================

"When did the choices get so hard, with so much more at stake?
 Life gets mighty precious when there's less of it to waste"

- - Bonnie Raitt, "Nick of Time"

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 18:59:40 +0200 
From: [email-masked]
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Hi Todd, All,

This is a very interesting dicussion. I have to admit that since I started IBIS modelling a few years ago I occasionally spent more time constructing input buffers than output buffers, even though the former only require 2 tables.... Below are my thoughts based on my limited understanding of the IBIS standard: 

Your proposal 1 is the simplest and should work with most simulators in my experience. I would use it when I have no information whatsoever about the internal structure of the buffer. A possible downside is that simulations in HSpice with the "power=off" option will become inaccurate since voltage fluctuations of the externally attached voltage source do not affect the buffer due to the missing Power clamp data.

Proposal 2 is my favourite approach, although I tend to use a modified version of it:
 - Find the zero-current (say at a voltage Vterm) and the slope Rterm (at Vterm).
 - Subtract the current (V-Vterm)/Rterm from the V-I data
 - If the resultant curve is still monotonous, I proceed as decribed below, if not I would most likely use proposal 2 without any modification
 - Therefore, IF the resultant V-I curve is monotonous, I split it into Power and Gnd Clamp (the current in the operating region is now ideally very small after the on-die termination has been subtracted)
 - I then work out the resistances R1 and R2 of the voltage divider that produces the right on-die termination characteristic:

    --- Power (VDDQ)
     |
     R1
     |
     ---------  input pad
     |
     R2
     |
   ------
    ---
     -

with Vterm = VDDQ*R2/(R1+R2) and Rterm = R1*R2/(R1+R2)

- - V-I data for R1 (connected to Power) is now added to the Power Clamp
- - and V-I data for R2 (connected to Gnd) is added to the Gnd Clamp data  

This modified approach should hopefully reflect the internal buffer structure fairly accurately. It looks complex, however, it can be implemented in a spreadsheet relatively easily. I usually extrapolate all data so that the whole voltage range between -VDDQ and 2*VDDQ is covered. I do not like to leave that to the simulation tools.....

Some months ago we actually discussed a 3rd approach. We wanted to create a clock-input buffer that had a voltage divider for biasing the input stage. We thought that we should be able to recreate the on-die circuit using the [Series Pin Mapping] keyword for mapping series resistors to Power and Gnd pins. However, in order to define the rail voltages for the Power pins, we also needed the [Pin Mapping] keyword to define Power and Gnd buses. The relevant parts of the model are attached below, it parses without errors. However, I am not so sure how this would behave in many IBIS simulators. A disadvantage is of course that with this approach you cannot tell the buffers characteristics from the V-I data.  

If I am completely on the wrong track here please let me know.....

Best Regards,

	Herbert.

|************************************************************
|
[IBIS Ver]        3.2
[File name]       ref_clk.ibs
[File Rev]        v1.0
[Date]            October 2002
[Source]          File originated at Agilent Technologies, Inc.
[Notes]           
[Disclaimer]      The usual....
|
[Copyright]       Agilent Technologies, Inc. Copyright 2002.
[Component]       HDMP-XXXX
[Manufacturer]    Agilent Technologies, Inc.
|
[Package]
| variable              typ           min           max
R_pkg                   0.00ohms      NA            NA
L_pkg                   0.00nH        NA            NA
C_pkg                   0.00pF        NA            NA
|
[Pin]     signal_name     model_name              R_pin   L_pin   C_pin
|
| Ref_clk receiver ports
APow      REFCLK_pwr      POWER
AGnd      REFCLK_gnd      GND
V25       REFCLK_P        PAD_REFCKIN
V26       REFCLK_N        PAD_REFCKIN
|
|
[Pin Mapping]  pulldown_ref  pullup_ref  gnd_clamp_ref  power_clamp_ref
|
APow           NC            RXPowBus1
AGnd           RXGndBus1     NC
V25            NC            NC          RXGndBus1      RXPowBus1
V26            NC            NC          RXGndBus1      RXPowBus1
|
|
[Diff Pin]  inv_pin  vdiff  tdelay_typ  tdelay_min  tdelay_max
|
| Input pins
V25      V26         275m   NA          NA          NA
|
|
[Series Pin Mapping]     pin_2     model_name
|
| DC-Biasing for Clock Inputs
V25            APow          R_AVDD_3k6
V25            AGnd          R_Gnd_4k2
|
V26            APow          R_AVDD_3k6
V26            AGnd          R_Gnd_4k2
|
|
|************************************************************
| DC-Biasing Clock Input Resistors
|************************************************************
|
[Model]                   R_AVDD_3k6
Model_type Series
|
|                       typ           min           max
C_comp                  0.00p         0.00p         0.00p
|
[Voltage Range]         1.80          1.62          1.98
|
| variable              R(typ)        R(min)        R(max)
[R series]              3887          3174          4579
|
| End of R_AVDD_3k6
|
|************************************************************
|
[Model]                   R_Gnd_4k2
Model_type Series
|
|                       typ           min           max
C_comp                  0.00p         0.00p         0.00p
|
[Voltage Range]         1.80          1.62          1.98
|
| variable              R(typ)        R(min)        R(max)
[R series]              4241          3475          4987
|
| End of R_Gnd_4k2
|
|
|************************************************************
|                 Model PAD_REFCKIN
|************************************************************
|
[Model]  PAD_REFCKIN
Model_type  Input
| REF_CLK Differential Receiver Pad
|
Vinl=0.80V
Vinh=1.20V
|
| Vinl and Vinh are overridden by Vdiff
|
|                       typ           min           max
C_comp                  1.08p         NA            NA
| C_comp: art-extracted value
|
|Condition             (typ)         (min)         (max)
|Process             nominal          slow          fast
[Temperature Range]       75           110             0
[Voltage Range]         1.80          1.62          1.98
|
|
[GND_clamp]
|
|    voltage             I(typ)        I(min)        I(max)
|
     -2.00             -4.57e-01     -4.81e-01     -4.07e-01
     -1.40             -2.17e-01     -2.34e-01     -1.78e-01
     -1.10             -9.70e-02     -1.11e-01     -6.30e-02
     -1.00             -5.50e-02     -7.00e-02     -2.60e-02
     -0.90             -1.49e-02     -3.00e-02     -1.23e-03
     -0.80             -1.10e-03     -3.34e-03     -1.00e-08
     -0.70             -7.50e-09     -3.01e-04     -7.56e-09
     -0.60             -6.89e-09     -6.05e-09     -6.35e-09
     -0.50             -5.19e-09     -5.19e-09     -5.15e-09
     -0.40             -4.58e-09     -4.54e-09     -4.53e-09
     -0.30             -3.52e-09     -3.53e-09     -3.54e-09
     -0.20             -2.57e-09     -2.54e-09     -2.54e-09
     -0.10             -1.54e-09     -1.51e-09     -1.59e-09
      0.00             -0.39e-09      0.31e-09     -0.32e-09
      0.10              0.54e-09      0.57e-09      0.59e-09
      0.20              1.55e-09      1.58e-09      1.57e-09
      0.30              2.54e-09      2.52e-09      2.56e-09
      0.40              3.54e-09      3.57e-09      3.54e-09
      0.50              4.52e-09      4.52e-09      4.52e-09
      0.60              5.50e-09      5.57e-09      5.59e-09
      0.70              7.08e-09      7.03e-09      7.07e-09
      0.80              8.05e-09      8.00e-09      8.04e-09
      0.90              8.51e-09      8.52e-09      8.51e-09
      1.00              1.01e-08      1.09e-08      1.02e-08
      1.10              1.03e-08      1.10e-08      1.04e-08
      1.20              1.15e-08      1.11e-08      1.11e-08
      1.30              1.20e-08      1.28e-08      1.23e-08
      1.40              1.35e-08      1.36e-08      1.39e-08
      1.50              1.45e-08      1.44e-08      1.40e-08
      1.60              1.55e-08      1.52e-08      1.52e-08
      1.70              1.64e-08      1.64e-08      1.64e-08
      1.80              1.75e-08      1.70e-08      1.76e-08
      1.90              1.82e-08      1.86e-08      1.88e-08
      2.00              1.93e-08      1.96e-08      1.90e-08
      2.10              2.05e-08      2.08e-08      2.01e-08
      2.20              2.12e-08      2.12e-08      2.12e-08
      2.30              2.24e-08      2.26e-08      2.23e-08
      2.40              2.38e-08      2.32e-08      2.37e-08
      2.50              2.49e-08      2.41e-08      2.40e-08
      2.60              2.56e-08      2.58e-08      2.50e-08
      2.70              2.67e-08      2.68e-08      2.62e-08
      2.80              2.71e-08      2.75e-08      2.70e-08
      2.90              2.81e-08      2.85e-08      2.81e-08
      3.00              2.94e-08      2.92e-08      2.94e-08
      3.10              3.06e-08      3.03e-08      3.09e-08
      3.20              3.13e-08      3.10e-08      3.19e-08
      3.30              3.21e-08      3.20e-08      3.21e-08
      3.40              3.35e-08      3.30e-08      3.30e-08
      3.50              3.40e-08      3.45e-08      3.43e-08
      3.60              3.55e-08      3.50e-08      3.51e-08
      3.70              3.60e-08      3.65e-08      3.67e-08
      3.80              3.75e-08      3.70e-08      3.75e-08
      3.90              3.85e-08      3.80e-08      3.85e-08
      4.00              3.90e-08      3.93e-08      3.90e-08
|
|
[POWER_clamp]          | Note: Vtable = Vcc - Voutput
|
|    voltage             I(typ)        I(min)        I(max)
|
     -2.00              3.25e-01      3.84e-01      1.83e-01
     -1.90              2.33e-01      2.95e-01      7.66e-02
     -1.80              1.39e-01      2.05e-01      1.39e-02
     -1.70              4.95e-02      1.20e-01      4.34e-03
     -1.60              1.25e-02      4.14e-02      2.50e-03
     -1.50              4.01e-03      1.17e-02      1.82e-03
     -1.40              1.83e-03      3.90e-03      1.30e-03
     -1.30              1.06e-03      1.67e-03      8.17e-04
     -1.20              6.34e-04      8.74e-04      3.93e-04
     -1.10              3.21e-04      4.68e-04      1.24e-04
     -1.00              1.21e-04      2.14e-04      5.07e-05
     -0.90              5.07e-05      8.05e-05      2.97e-05
     -0.80              2.96e-05      3.72e-05      1.42e-05
     -0.70              1.69e-05      2.18e-05      3.22e-06
     -0.60              6.98e-06      1.19e-05      1.76e-07
     -0.50              1.34e-06      4.55e-06      1.48e-08
     -0.40              1.22e-07      8.47e-07      7.04e-09
     -0.30              2.55e-08      9.03e-08      5.30e-09
     -0.20              3.53e-09      2.02e-08      3.57e-09
     -0.10              1.82e-09      1.05e-08      1.84e-09
      0.00              0.43e-09     -0.43e-09     -0.40e-09
      0.10             -1.74e-09     -1.76e-09     -1.77e-09
      0.20             -3.55e-09     -3.50e-09     -3.53e-09
      0.30             -5.35e-09     -5.35e-09     -5.39e-09
      0.40             -7.05e-09     -7.02e-09     -7.05e-09
      0.50             -8.70e-09     -8.70e-09     -8.70e-09
      1.00             -1.75e-08     -1.75e-08     -1.75e-08
      1.50             -2.64e-08     -2.65e-08     -2.69e-08
      2.00             -3.47e-08     -3.48e-08     -3.43e-08
      2.50             -4.39e-08     -4.38e-08     -4.30e-08
      3.00             -5.25e-08     -5.29e-08     -5.29e-08
      3.50             -6.18e-08     -6.19e-08     -6.16e-08
      4.00             -7.10e-08     -7.19e-08     -7.17e-08
|
| End of input model PAD_REFCKIN
|
[End]

- -----Original Message-----
From: Todd Westerhoff [mailto:[email-masked]]
Sent: 08 May 2003 07:44
To: Ibis-Users (E-mail)
Subject: [IBIS-Users] Modeling input receivers with on-die termination

Hi all,

This one has been bugging us for a while ... the discussions that took place
last week gave us the opportunity to take another look at this problem and
its different components.  I have two solutions to propose, and would
appreciate feedback from the group.

I apologize in advance for a lengthy email.  There's no other way I know to
describe the different components of the problem and the way they interact.

To start - the problem is accurately modeling the effect of on-die input
termination, most typically pulling the signal to a value of VDDQ/2, which
would be common for HSTL and SSTL signalling.  The resistors in question (at
least in our case) were not discrete components in the package - they were
truly on-die.  Hence, the resistance varied with process and was non-linear
over the operating range.  Thus, we needed a way to extract the actual input
characteristics using the HSpice model and create the correct model in IBIS.

Simple enough, we thought - then it got deep.

To ended up breaking the problem down into three pieces -

1) The IBIS Specification
2) The process of creating models
3) How IBIS simulators use the data in the IBIS models

1) The IBIS Specification
- -------------------------
Please correct me if I'm wrong here, but I believe the IBIS Spec doesn't
list any "standard" for the voltage range over which the behavior of the
[GND Clamp] and [POWER Clamp] should be specified.  I took it as a given
that [Pulldown] and [Pullup] curves would range from -VDDQ to 2*VDDQ, and,
until last week, I would have expected to see the same range for the power
and ground clamps.  That turned out not to be the case.

I also suspect that the IBIS spec has no comment on just how the simulator
is supposed to combine the data in the two clamp curves, should the points
overlap.  That turned out to be a big sticking point.

2) The process of creating models
- ---------------------------------
There are two classes of people who create IBIS models from HSpice
simulations:

a) The gurus, who understand IBIS, HSpice and software well enough to
develop their own tools for extracting and compiling IBIS model data, and

b) The rest of us, who use some version of s2ibis2.  Usually, it's one we've
compiled ourselves, with some collection of fixes implemented for problems
we have found on our own.  I'm going to aim my comments squarely at s2ibis2,
with the assumption that's what most of the IBIS-modelmakers are basing
their efforts on.

When s2ibis2 was created, the developer noticed an interesting problem -
there is really no good way to separate the ground clamp curve from the
power clamp curve.  With the [Pullup] and [Pulldown] curves, you can isolate
the behavior of transistor from the other by virtue of the output state.
However, if you model the input buffer and sweep the voltage from -VDDQ to
2*VDDQ, there's really no good way to separate the one clamp curve from the
other.

(When I talk about voltage from this point on, I'm going to use ground as a
reference, unless I specifically state that I'm using a power-based voltage
reference "a la IBIS".  I'm also going to assume the ground clamp is active
between -VDDQ and 0V, the "operating region" for the device is between 0V
and VDDQ, and the power clamp is active between VDDQ and 2*VDDQ).

Of course, if you've got a normal input (without termination), the input
current is zero (or essentially so) throughout the operating region, so
there isn't really any problem.  It doesn't much matter where the ground
clamp curve leaves off and the power clamp curve kicks in, because the
currents at those points are always zero.

However, the presence of on-die termination to VDDQ/2 presents an
interesting problem.  The "zero current" point is somewhere in the middle of
the operating region, and it's only a single point.  The power and ground
clamp curves, when added together, have to accurately represent the input's
characteristic throughout the device's operating region (0 to VDDQ), if you
want to input to behave properly.

So now the question becomes - where does one curve leave off, and the other
begin?  Well, s2ibis2 simply implements the ground clamp curve from -VDDQ to
VDDQ, and the power clamp curve from VDDQ to 2*VDDQ.  In theory, you should
be able to just attach the two curves together and get the right result - or
at least, that's the assumption s2ibis2 seems to be operating on.  Remember,
because the power clamp curve in IBIS is rail-referenced, a sweep from VDDQ
to 2*VDDQ shows up in the IBIS file as from 0 to -VDDQ.

There are a couple of interesting caveats here.  First, s2ibis2 ground clamp
curves actually all end at the same point, which is the [typ] value of VDDQ.
Let's assume that we have an HSTL 1.5 driver, whose power rail can vary by
10%.  Thus, the [min] power rail is 1.35V, while the [max] power rail is
1.65V.  In this case, the ground clamp data ends at 1.5V in all three cases.

The power clamp curves have the same issue, but in reverse.  They are
supposed to sweep from VDDQ to 2*VDDQ.  That's 0 to -VDDQ in IBIS terms (the
curves really go from -VDDQ to 0 in the IBIS data, because voltages are
supposed to increase).  However, all three curves start at the same point,
which is 2*VDDQ[typ] (-VDDQ[typ] in IBISese), and end at the same point,
which is 0V.

But - and this is a big one - because the power clamp curves are
rail-referenced, 0V means different things in the different cases.  It means
1.35V for [min], 1.5V for [typ] and 1.65V for [max].  So - if we adjust for
the rail reference and talk about ground-referenced voltages, the voltage
data points for the power clamp curves range from:

[min] 1.35V to 2.85V
[typ] 1.5V to 3.0V
[max] 1.65V to 3.15V

Let's set those side by side with the ground clamp curves and see what we
get:

      Ground Clamp             Power Clamp
[min] -1.5V to 1.5V            1.35V to 2.85V
[typ] -1.5V to 1.5V            1.5V to 3.0V
[max] -1.5V to 1.5V            1.65V to 3.15V

The [typ] curves complement each other just fine, but there is an overlap in
the [min] data and a gap in the [max] data.  We're primarily concerned about
capturing the behavior of the input termination across the entire operating
region here, so this looks like it might be a problem.  Of course, that is
determined by how the simulator handles the situation where the clamp V-I
curves overlap or have a gap in them.  We didn't expect what we found,
however.

3) How IBIS simulators use the data in the IBIS models
- ------------------------------------------------------
Different simulators may well do different things, and I'm not trying to say
I've tested all of them.  At least some of them, if not all of them, behave
as I'm describing here.

We suspected an IBIS simulator might "double count" the current in the
overlap region in the [min]case (between 1.35V and 1.5V), thereby making the
termination appear twice as strong as it really was (in that region).  We
didn't know what was going to happen in the [max] case, with a cap in the
data between 1.5 and 1.65V.  So - we read the models in and tested them.

What we found, empirically, is that the simulator didn't add the curves
together the way you might expect - taking the data from the ground clamp
curve between -VDDQ and VDDQ, and the data from the power clamp curve
between VDDQ and 2*VDDQ.  Instead, the simulator *extended each curve by
extrapolation* to cover the entire region from -VDDQ to 2*VDDQ, and *THEN*
added the currents together.  In other words, the power clamp curve (which,
at the "IBIS 0V" point, corresponding to VDDQ, has a slope of roughly the
termination value) got extended through the whole operating region with a
slope roughly equal to the termination value.  Now, when the simulator added
the contributions of the power and ground clamps in the operating region, it
came up with roughly twice the correct current, making the termination
appear twice as strong as it really was.  We started out thinking there
might be a small problem in the gap/overlap regions of the [max/min] curves,
and discovered instead that none of the simulation cases were working
correctly, anywhere in the operating region.

This is a classic case of compartmentalization and assumptions - between
IBIS, s2ibis2 and the IBIS simulators.  Bottom line, the basic assumption
was that clamps don't kick in until you go beyond the rail, and the overall
process falls apart in this case as a result.

4) What we can do about it
- --------------------------
Again, I'm predicating this on the use of s2ibis2 to create IBIS models.
The goal is simple: create an IBIS model that accurately reproduces the
combined behavior of the clamps and input termination over the range
from -VDDQ to 2*VDDQ.

Both proposals both rely on the same basis: having s2ibis2 perform a single
input V-I sweep, over the voltage range from -VDDQ to 2*VDDQ.  That one
simulation would capture all the behavior we're concerned about here.  From
there, it's just a matter of how you format the data.

Proposal 1) Says that you put the whole kit & kaboodle into the [GND Clamp]
curve and omit the [POWER Clamp] curve entirely.  There's really only one
composite input characteristic, anyway; separating it into two sets of clamp
curves is artificial.  Having two curves provides benefits in some cases,
but it's hard to argue that those benefits apply here.  This is the easiest
solution to implement, and provides the composite curve in one place.  The
downside is that some users might object to having the power clamp data
included in the [GND Clamp] curve, and that some simulation tools might also
have a problem with this.  A simulation tool that used a different technique
for combining the curve data might very well have a problem with this
approach.

Proposal 2) ... which Arpad suggested, was to find the zero-current point in
each of the min-typ-max cases, and assign all negative current to the ground
clamp, and all positive current to the power clamp.  You need to make sure
that each clamp curve has two consecutive voltage data points with zero
current at the correct end of the curve (so that all further points are zero
current by extrapolation).  You also need to do the proper voltage
translations when assigning current to the power clamp curve.  The advantage
of this technique is that you end up with two sets of clamp curves as most
people expect, and they add together correctly.  This disadvantage is a
slight increase in process complexity, and the fact that you probably won't
be able to view the overall input behavior in one place.  Interestingly, the
IBIS-viewer/model-editor tools seem to allow you to view the combined V-I
characteristics of the output buffers, but don't provide for viewing the
combined characteristics of the power and ground clamp curves on an input.

.... so there you have it - s2ibis2 and input termination modeling in IBIS,
as I presently understand it.  Corrections to my reasoning, comments and
thoughts on the subject are both welcome and greatly appreciated.

Todd.

Todd Westerhoff
High Speed Design Specialist
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:[email-masked]
ph: 978-936-2149
============================================

"When did the choices get so hard, with so much more at stake?
 Life gets mighty precious when there's less of it to waste"

- - Bonnie Raitt, "Nick of Time"

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 11:15:24 -0700
From: Kim Helliwell <[email-masked]>
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination

Tom:

I completely agree with making the models correct.
Todd was answering my earlier question of what to
do when a vendor supplied model is NOT correct.
For that case, a band aid is needed, particularly when
the vendor is recalcitrant about fixing the model...

On Friday, May 9, 2003, at 10:19  AM, Tom Dagostino wrote:

> This sounds like a band aid, not a solution.  Let's make the models 
> correct
> and not double count the currents.
>
> Tom Dagostino
> Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
> 2926 SE Yamhill St.                Device Modeling Division
> Portland, OR 97214                 13610 SW Harness Lane
>                                    Beaverton, OR 97008
> http://www.teraspeed.com           503-430-1065
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Todd Westerhoff
> Sent: Friday, May 09, 2003 8:06 AM
> To: Ibis-Users (E-mail)
> Subject: RE: [IBIS-Users] Modeling input receivers with on-die
> termination
>
>
> Kim, et al,
>
> I'm a little surprised that none of the tool vendors have checked in 
> by this
> point.  I've had users tell me what the different tools do, but no 
> word from
> the tool-makers themselves.
>
> It seems to me the rub is that s2ibis2 assumes the clamp curves will be
> "added" one way (which is backed up, at least partially, by the IBIS 
> spec,
> as noted by Stephen) - and the simulators do something else by 
> extrapolating
> the power clamp curve.  Simply put, s2ibis2 assumes that clamp current
> should be zero if voltage point is not specified in the particular 
> clamp
> curve - the simulators do not.
>
> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
>    Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
>    corresponding entry for the current.  Done. (this takes care out
>    double-counting and the overlap case)
> 4. If the voltage point does not exist in the first curve, check the 
> second.
>    If the voltage point exists, take the corresponding current value.  
> Done.
> 5. Only when the voltage point exists in neither curve (the gap case),
> extend
>    each curve by extrapolation to find the current at the point in 
> question.
>    This will provide two (potentially slightly different) current 
> values -
>    use the average of the two.
>
> If the simulators worked this way, we wouldn't have to change s2ibis2 
> at all
> (or, so it seems to me).  The proposal 1 technique from my original 
> mail
> would still work, but proposal 2 would need to be modified so that the
> individual curves ended once they hit the zero current point.
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:[email-masked]
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake?
>  Life gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
>
Kim Helliwell
Apple Computer
[email-masked]
408 974 9936

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 12:51:34 -0700
From: "Tom Dagostino" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Kim

My comment was directed towards having the simulator handle the data
differently:

> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
>    Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
>    corresponding entry for the current.  Done. (this takes care out
>    double-counting and the overlap case)
................

Getting the simulator companies to change their simulators would be harder
in my opinion than just fixing the model that is causing a user a problem.
What fix and how does it affect other models and does it cause additional
issues, etc.  Fix the model, the problem, not the simulator.

Tom Dagostino
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
2926 SE Yamhill St.                Device Modeling Division
Portland, OR 97214                 13610 SW Harness Lane
                                   Beaverton, OR 97008
http://www.teraspeed.com           503-430-1065
[email-masked]

- -----Original Message-----
From: Kim Helliwell [mailto:[email-masked]]
Sent: Friday, May 09, 2003 11:15 AM
To: [email-masked]
Cc: 'Todd Westerhoff'; 'Ibis-Users (E-mail)'
Subject: Re: [IBIS-Users] Modeling input receivers with on-die
termination

Tom:

I completely agree with making the models correct.
Todd was answering my earlier question of what to
do when a vendor supplied model is NOT correct.
For that case, a band aid is needed, particularly when
the vendor is recalcitrant about fixing the model...

On Friday, May 9, 2003, at 10:19  AM, Tom Dagostino wrote:

> This sounds like a band aid, not a solution.  Let's make the models
> correct
> and not double count the currents.
>
> Tom Dagostino
> Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
> 2926 SE Yamhill St.                Device Modeling Division
> Portland, OR 97214                 13610 SW Harness Lane
>                                    Beaverton, OR 97008
> http://www.teraspeed.com           503-430-1065
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Todd Westerhoff
> Sent: Friday, May 09, 2003 8:06 AM
> To: Ibis-Users (E-mail)
> Subject: RE: [IBIS-Users] Modeling input receivers with on-die
> termination
>
>
> Kim, et al,
>
> I'm a little surprised that none of the tool vendors have checked in
> by this
> point.  I've had users tell me what the different tools do, but no
> word from
> the tool-makers themselves.
>
> It seems to me the rub is that s2ibis2 assumes the clamp curves will be
> "added" one way (which is backed up, at least partially, by the IBIS
> spec,
> as noted by Stephen) - and the simulators do something else by
> extrapolating
> the power clamp curve.  Simply put, s2ibis2 assumes that clamp current
> should be zero if voltage point is not specified in the particular
> clamp
> curve - the simulators do not.
>
> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
>    Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
>    corresponding entry for the current.  Done. (this takes care out
>    double-counting and the overlap case)
> 4. If the voltage point does not exist in the first curve, check the
> second.
>    If the voltage point exists, take the corresponding current value.
> Done.
> 5. Only when the voltage point exists in neither curve (the gap case),
> extend
>    each curve by extrapolation to find the current at the point in
> question.
>    This will provide two (potentially slightly different) current
> values -
>    use the average of the two.
>
> If the simulators worked this way, we wouldn't have to change s2ibis2
> at all
> (or, so it seems to me).  The proposal 1 technique from my original
> mail
> would still work, but proposal 2 would need to be modified so that the
> individual curves ended once they hit the zero current point.
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:[email-masked]
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake?
>  Life gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
>
Kim Helliwell
Apple Computer
[email-masked]
408 974 9936

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 16:34:25 -0400
From: "Todd Westerhoff" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Tom,

I don't disagree with the comment "fix the model, not the simulator",
although we should recognize that there are models and tools (e.g. s2ibis2)
out there already, and getting all of them fixed isn't necessarily simple.
Easy if we have people of your caliber doing the work - but we don't.

I was actually proposing the simulation algorithm to see what response it
drew.  In theory, it solved both the problem of the existing models/tools,
and would work with corrected models - with the caveat about the curve
endings that I mentioned.

In actual fact, I am somewhat dubious about the wisdom of changing the
simulators, if no other reason than we'd go through a period where different
tools were doing different things, whereas they are (relatively) consistent
with regard to this issue at the moment.  Trying to understand how the
different tools work is hard enough already; I wasn't really anxious to make
it more complicated.

Todd.

Todd Westerhoff
High Speed Design Specialist
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:[email-masked]
ph: 978-936-2149
============================================

"When did the choices get so hard, with so much more at stake?
 Life gets mighty precious when there's less of it to waste"

- - Bonnie Raitt, "Nick of Time"

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Tom Dagostino
Sent: Friday, May 09, 2003 3:52 PM
To: 'Kim Helliwell'
Cc: 'Todd Westerhoff'; 'Ibis-Users (E-mail)'
Subject: RE: [IBIS-Users] Modeling input receivers with on-die
termination

Kim

My comment was directed towards having the simulator handle the data
differently:

> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
>    Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
>    corresponding entry for the current.  Done. (this takes care out
>    double-counting and the overlap case)
................

Getting the simulator companies to change their simulators would be harder
in my opinion than just fixing the model that is causing a user a problem.
What fix and how does it affect other models and does it cause additional
issues, etc.  Fix the model, the problem, not the simulator.

Tom Dagostino
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
2926 SE Yamhill St.                Device Modeling Division
Portland, OR 97214                 13610 SW Harness Lane
                                   Beaverton, OR 97008
http://www.teraspeed.com           503-430-1065
[email-masked]

- -----Original Message-----
From: Kim Helliwell [mailto:[email-masked]]
Sent: Friday, May 09, 2003 11:15 AM
To: [email-masked]
Cc: 'Todd Westerhoff'; 'Ibis-Users (E-mail)'
Subject: Re: [IBIS-Users] Modeling input receivers with on-die
termination

Tom:

I completely agree with making the models correct.
Todd was answering my earlier question of what to
do when a vendor supplied model is NOT correct.
For that case, a band aid is needed, particularly when
the vendor is recalcitrant about fixing the model...

On Friday, May 9, 2003, at 10:19  AM, Tom Dagostino wrote:

> This sounds like a band aid, not a solution.  Let's make the models
> correct
> and not double count the currents.
>
> Tom Dagostino
> Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
> 2926 SE Yamhill St.                Device Modeling Division
> Portland, OR 97214                 13610 SW Harness Lane
>                                    Beaverton, OR 97008
> http://www.teraspeed.com           503-430-1065
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Todd Westerhoff
> Sent: Friday, May 09, 2003 8:06 AM
> To: Ibis-Users (E-mail)
> Subject: RE: [IBIS-Users] Modeling input receivers with on-die
> termination
>
>
> Kim, et al,
>
> I'm a little surprised that none of the tool vendors have checked in
> by this
> point.  I've had users tell me what the different tools do, but no
> word from
> the tool-makers themselves.
>
> It seems to me the rub is that s2ibis2 assumes the clamp curves will be
> "added" one way (which is backed up, at least partially, by the IBIS
> spec,
> as noted by Stephen) - and the simulators do something else by
> extrapolating
> the power clamp curve.  Simply put, s2ibis2 assumes that clamp current
> should be zero if voltage point is not specified in the particular
> clamp
> curve - the simulators do not.
>
> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
>    Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
>    corresponding entry for the current.  Done. (this takes care out
>    double-counting and the overlap case)
> 4. If the voltage point does not exist in the first curve, check the
> second.
>    If the voltage point exists, take the corresponding current value.
> Done.
> 5. Only when the voltage point exists in neither curve (the gap case),
> extend
>    each curve by extrapolation to find the current at the point in
> question.
>    This will provide two (potentially slightly different) current
> values -
>    use the average of the two.
>
> If the simulators worked this way, we wouldn't have to change s2ibis2
> at all
> (or, so it seems to me).  The proposal 1 technique from my original
> mail
> would still work, but proposal 2 would need to be modified so that the
> individual curves ended once they hit the zero current point.
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:[email-masked]
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake?
>  Life gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
>
Kim Helliwell
Apple Computer
[email-masked]
408 974 9936

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 13:48:32 -0700 
From: "Angulo, John" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Kim, Todd et al.,

The predominant behavior you've found in simulators is based on the following idea: the [Pullup], [Pulldown], [POWER Clamp] and [GND Clamp] I-V tables provide characteristics for four independent elements, each connected between the buffer die pad and a supply rail.  Therefore, by KCL, the net I-V characteristic must be a superposition of all four (of course, you only worry about one of the [Pullup] and [Pulldown] curves at DC).

The IBIS parser follows this convention when it adds the I-V tables together in search of I-V/V-T data inconsistencies.

Treating the I-V tables as parameterizations of independent elements with definite power supply connections allows for ground bounce simulations.

s2ibis2, however, in dumping the DC sweep data from -VDDQ to VDDQ into the [GND Clamp] and VDDQ to 2*VDDQ into the [POWER Clamp], is treating the clamp tables as two halves of a single underlying element.  This disagrees with the IBIS parser and limits the potential for simulation of power effects.

So merging the clamp characteristics into one rather than adding them in parallel would not only mean changing multiple simulators, but also changing the IBIS parser and loosing some modeling capability.  In an effort to avoid leaving those on-die termination models which already follow the parser and work with existing simulators high and dry, we might try to examine the clamp curves and guess which convention they were meant to follow.  But this would probably be too much complexity.  Herbert's method for pulling out the pullup and pulldown resistors and placing them into the appropriate clamp curves as independent elements is a good "band-aid".  Fixing the spice2ibis process would be the ultimate solution.

John Angulo
Hyperlynx Products
Mentor Graphics Corp.
[email-masked]
425-869-2320

- -----Original Message-----
From: Kim Helliwell [mailto:[email-masked]]
Sent: Friday, May 09, 2003 11:15 AM
To: [email-masked]
Cc: 'Todd Westerhoff'; 'Ibis-Users (E-mail)'
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination

Tom:

I completely agree with making the models correct.
Todd was answering my earlier question of what to
do when a vendor supplied model is NOT correct.
For that case, a band aid is needed, particularly when
the vendor is recalcitrant about fixing the model...

On Friday, May 9, 2003, at 10:19  AM, Tom Dagostino wrote:

> This sounds like a band aid, not a solution.  Let's make the models 
> correct
> and not double count the currents.
>
> Tom Dagostino
> Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
> 2926 SE Yamhill St.                Device Modeling Division
> Portland, OR 97214                 13610 SW Harness Lane
>                                    Beaverton, OR 97008
> http://www.teraspeed.com           503-430-1065
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Todd Westerhoff
> Sent: Friday, May 09, 2003 8:06 AM
> To: Ibis-Users (E-mail)
> Subject: RE: [IBIS-Users] Modeling input receivers with on-die
> termination
>
>
> Kim, et al,
>
> I'm a little surprised that none of the tool vendors have checked in 
> by this
> point.  I've had users tell me what the different tools do, but no 
> word from
> the tool-makers themselves.
>
> It seems to me the rub is that s2ibis2 assumes the clamp curves will be
> "added" one way (which is backed up, at least partially, by the IBIS 
> spec,
> as noted by Stephen) - and the simulators do something else by 
> extrapolating
> the power clamp curve.  Simply put, s2ibis2 assumes that clamp current
> should be zero if voltage point is not specified in the particular 
> clamp
> curve - the simulators do not.
>
> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
>    Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
>    corresponding entry for the current.  Done. (this takes care out
>    double-counting and the overlap case)
> 4. If the voltage point does not exist in the first curve, check the 
> second.
>    If the voltage point exists, take the corresponding current value.  
> Done.
> 5. Only when the voltage point exists in neither curve (the gap case),
> extend
>    each curve by extrapolation to find the current at the point in 
> question.
>    This will provide two (potentially slightly different) current 
> values -
>    use the average of the two.
>
> If the simulators worked this way, we wouldn't have to change s2ibis2 
> at all
> (or, so it seems to me).  The proposal 1 technique from my original 
> mail
> would still work, but proposal 2 would need to be modified so that the
> individual curves ended once they hit the zero current point.
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:[email-masked]
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake?
>  Life gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
>
Kim Helliwell
Apple Computer
[email-masked]
408 974 9936

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 17:32:34 -0400
From: "Todd Westerhoff" <[email-masked]>
Subject: RE: [IBIS-Users] Modeling input receivers with on-die termination

Thanks, John!

Can I therefore assume Hyperlynx treats the power clamp curve the way I
described - by extrapolating the endpoint/slope across the operating region?

Todd.

Todd Westerhoff
High Speed Design Specialist
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:[email-masked]
ph: 978-936-2149
============================================

"When did the choices get so hard, with so much more at stake?
 Life gets mighty precious when there's less of it to waste"

- - Bonnie Raitt, "Nick of Time"

- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Angulo, John
Sent: Friday, May 09, 2003 4:49 PM
To: 'Ibis-Users (E-mail)'
Subject: RE: [IBIS-Users] Modeling input receivers with on-die
termination

Kim, Todd et al.,

The predominant behavior you've found in simulators is based on the
following idea: the [Pullup], [Pulldown], [POWER Clamp] and [GND Clamp] I-V
tables provide characteristics for four independent elements, each connected
between the buffer die pad and a supply rail.  Therefore, by KCL, the net
I-V characteristic must be a superposition of all four (of course, you only
worry about one of the [Pullup] and [Pulldown] curves at DC).

The IBIS parser follows this convention when it adds the I-V tables together
in search of I-V/V-T data inconsistencies.

Treating the I-V tables as parameterizations of independent elements with
definite power supply connections allows for ground bounce simulations.

s2ibis2, however, in dumping the DC sweep data from -VDDQ to VDDQ into the
[GND Clamp] and VDDQ to 2*VDDQ into the [POWER Clamp], is treating the clamp
tables as two halves of a single underlying element.  This disagrees with
the IBIS parser and limits the potential for simulation of power effects.

So merging the clamp characteristics into one rather than adding them in
parallel would not only mean changing multiple simulators, but also changing
the IBIS parser and loosing some modeling capability.  In an effort to avoid
leaving those on-die termination models which already follow the parser and
work with existing simulators high and dry, we might try to examine the
clamp curves and guess which convention they were meant to follow.  But this
would probably be too much complexity.  Herbert's method for pulling out the
pullup and pulldown resistors and placing them into the appropriate clamp
curves as independent elements is a good "band-aid".  Fixing the spice2ibis
process would be the ultimate solution.

John Angulo
Hyperlynx Products
Mentor Graphics Corp.
[email-masked]
425-869-2320

- -----Original Message-----
From: Kim Helliwell [mailto:[email-masked]]
Sent: Friday, May 09, 2003 11:15 AM
To: [email-masked]
Cc: 'Todd Westerhoff'; 'Ibis-Users (E-mail)'
Subject: Re: [IBIS-Users] Modeling input receivers with on-die termination

Tom:

I completely agree with making the models correct.
Todd was answering my earlier question of what to
do when a vendor supplied model is NOT correct.
For that case, a band aid is needed, particularly when
the vendor is recalcitrant about fixing the model...

On Friday, May 9, 2003, at 10:19  AM, Tom Dagostino wrote:

> This sounds like a band aid, not a solution.  Let's make the models
> correct
> and not double count the currents.
>
> Tom Dagostino
> Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
> 2926 SE Yamhill St.                Device Modeling Division
> Portland, OR 97214                 13610 SW Harness Lane
>                                    Beaverton, OR 97008
> http://www.teraspeed.com           503-430-1065
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Todd Westerhoff
> Sent: Friday, May 09, 2003 8:06 AM
> To: Ibis-Users (E-mail)
> Subject: RE: [IBIS-Users] Modeling input receivers with on-die
> termination
>
>
> Kim, et al,
>
> I'm a little surprised that none of the tool vendors have checked in
> by this
> point.  I've had users tell me what the different tools do, but no
> word from
> the tool-makers themselves.
>
> It seems to me the rub is that s2ibis2 assumes the clamp curves will be
> "added" one way (which is backed up, at least partially, by the IBIS
> spec,
> as noted by Stephen) - and the simulators do something else by
> extrapolating
> the power clamp curve.  Simply put, s2ibis2 assumes that clamp current
> should be zero if voltage point is not specified in the particular
> clamp
> curve - the simulators do not.
>
> There is a different algorithm the simulators could use to avoid double
> counting with the existing models:
>
> 1. Check the input voltage
> 2. If the input voltage, <=VDDQ, look at the ground clamp curve first.
>    Otherwise, look at the power clamp curve first.
> 3. If the voltage point exists in the curve you're looking at, use the
>    corresponding entry for the current.  Done. (this takes care out
>    double-counting and the overlap case)
> 4. If the voltage point does not exist in the first curve, check the
> second.
>    If the voltage point exists, take the corresponding current value.
> Done.
> 5. Only when the voltage point exists in neither curve (the gap case),
> extend
>    each curve by extrapolation to find the current at the point in
> question.
>    This will provide two (potentially slightly different) current
> values -
>    use the average of the two.
>
> If the simulators worked this way, we wouldn't have to change s2ibis2
> at all
> (or, so it seems to me).  The proposal 1 technique from my original
> mail
> would still work, but proposal 2 would need to be modified so that the
> individual curves ended once they hit the zero current point.
>
> Todd.
>
> Todd Westerhoff
> High Speed Design Specialist
> Cisco Systems
> 1414 Massachusetts Ave - Boxboro, MA - 01719
> email:[email-masked]
> ph: 978-936-2149
> ============================================
>
> "When did the choices get so hard, with so much more at stake?
>  Life gets mighty precious when there's less of it to waste"
>
> - Bonnie Raitt, "Nick of Time"
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with just the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a written request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
>
>
Kim Helliwell
Apple Computer
[email-masked]
408 974 9936

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Fri, 9 May 2003 18:51:21 -0700
From: "Eric Hsu" <[email-masked]>
Subject: [IBIS-Users] RE: [IBIS] Ibis generation problem

Hi Wil and Syed,

I would like to compile the "s2ibis2" by the *.z file had been downloaded yesterday from the web site( www.eda.org/pub/ibis/s2ibis/s2ibis2_v1.1 ). Unfortunately, I can not get the working s2ibis2 to be able to generate ibis model with my current control file (*.s2i), however, this s2i file can work with my current s2ibis2, which is compiled from my last time about half year ago.
My question is: The *.z files are just downloaded recently for your working case? If true, do you just follow the instruction from the readme file, and then just get "s2ibis2" directly after complete compiling? Or, is there any file need to be modified after I downloaded?

Best Regards,

Eric Hsu
Interface Technologies
NetLogic Microsystems, Inc.
450 National Ave.
Mountain View, CA 94043
650-961-6676 x198
This e-mail contains NetLogic Microsystems, Inc. Confidential information

- -----Original Message-----
From: Wil Ngan [mailto:[email-masked]]
Sent: Tuesday, April 15, 2003 5:18 PM
To: Syed Huq
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [IBIS] Ibis generation problem

FYI, using the new _fix program I was able to generate the *ibs file.
For a moment there I thought I had to manually parse all the data...
Thanks so much for your help, Syed!
- - Wil

** FYI: the s2ibis fix program is located at:
www.eda.org/pub/ibis/s2ibis/s2ibis2_v1.1
There are two *.Z files. Get the one with _fix.

Syed Huq wrote:

> Wil,
>
> Are you translating multiple buffers at the same time ? Try running the
> s2ibis2 only on an Input model or only on an Output model. There is an
> issue of creating too many .spi and .out files..
>
> Next, you should be using s2ibis2_fix version. Your data shows you are
> using an older version..
>
> Syed
>
> >Date: Mon, 14 Apr 2003 16:50:15 -0700
> >From: Wil Ngan <[email-masked]>
> >X-Accept-Language: en
> >MIME-Version: 1.0
> >CC: [email-masked], [email-masked], [email-masked]
> >Subject: [IBIS] Ibis generation problem
> >
> >Hi,
> >
> >I'm having problem generating an ibis file, and was wondering
> >if I can get ideas in how to approach this.
> >
> >1) The problem:
> >
> >I get the following error when running  spice to ibis:
> >% s2ibis2.11 gold_7xxx.s2i
> >s2ibis2.11_real v1.1 -- North Carolina State University
> >s2ibis2.11_real: Reading input file gold_7xxx..done
> >s2ibis2.11_real: Analyzing component idt7xxx .
> >s2ibis2.11_real: Starting HSpice job with input put7.spi.
> >:
> >etc
> >:
> >s2ibis2.11_real: Starting HSpice job with input y017.spi.
> >s2ibis2.11_real: Starting HSpice job with input z017.spi.
> >s2ibis2.11_real: Opening file gold_7xxx.ibs for writing...Bus error
> >
> >-----
> >
> >2) My attempt at solving this:
> >
> >And so  I examine the  gold_7xxx .ibs file, and  I see the following:
> >:
> >etc
> >:
> >[Pulldown]
> >| voltage     I(typ)              I(min)              I(max)
> >|
> >  -3.30      -9.001A             -9.160A             -8.914A
> >  -3.10      -8.255A             -8.415A             -8.168A
> >:
> >etc
> >:
> >   3.50       0.178A              0.117A              0.241A
> >   3.60       0.179A              0.117A              0.242A
> >   3.70       0.179A
> >
> >(The ibis file ends here, which is far from being complete.)
> >
> >I have examined all the *out files (especially the pdt.out, pdx.out,
> >pdn.out files)
> >in detail and see that all hspice data has been generated and dumped
> >into  the
> >*out files with  no problem whatsoever. And yet s2ibis is apparently
> >having
> >problem extracting  the data from the  *out files to place in the *ibs
> >file.
> >
> >Any idea how to approach or solve this problem?
> >Has anyone ever encountered this?
> >Any help or hints would be appreciated.  Thanks so much,
> >
> >- Wil
> >IDT  sram design
> >(408) 330-1623
> >
> >

- -----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: 10 May 2003 21:32:01 -0700
From: Syed Huq <[email-masked]>
Subject: [IBIS-Users] RE: [IBIS] Ibis generation problem

Eric,

The .Z is a compressed file. After you uncompress, you will get a .tar
file. Un'tar this file and you will get several sub-dir.

If you wish to re-compile(usually that is not necessary), look at the
/src sub-dir and the README and Makefile has all the info you need.

You can pick up the binary based on your OS, under the /bin sub-dir.

If you are downloding the s2ibis2_fix.tar.Z(highly recommended), then
there is a solaris binary in that dir already.

Once the binary is downloaded, make sure your 'x bit is set to make the
file executable(solaris/UNIX)..

So basically, you download and use without any modifications.

What was your error ?

Syed

On Fri, 2003-05-09 at 18:51, Eric Hsu wrote:
> Hi Wil and Syed,
> 
> I would like to compile the "s2ibis2" by the *.z file had been downloaded yesterday from the web site( www.eda.org/pub/ibis/s2ibis/s2ibis2_v1.1 ). Unfortunately, I can not get the working s2ibis2 to be able to generate ibis model with my current control file (*.s2i), however, this s2i file can work with my current s2ibis2, which is compiled from my last time about half year ago.
> My question is: The *.z files are just downloaded recently for your working case? If true, do you just follow the instruction from the readme file, and then just get "s2ibis2" directly after complete compiling? Or, is there any file need to be modified after I downloaded?
> 
> Best Regards,
> 
> Eric Hsu
> Interface Technologies
> NetLogic Microsystems, Inc.
> 450 National Ave.
> Mountain View, CA 94043
> 650-961-6676 x198
> This e-mail contains NetLogic Microsystems, Inc. Confidential information
> 
> 
> 
> -----Original Message-----
> From: Wil Ngan [mailto:[email-masked]]
> Sent: Tuesday, April 15, 2003 5:18 PM
> To: Syed Huq
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [IBIS] Ibis generation problem
> 
> 
> FYI, using the new _fix program I was able to generate the *ibs file.
> For a moment there I thought I had to manually parse all the data...
> Thanks so much for your help, Syed!
> - Wil
> 
> ** FYI: the s2ibis fix program is located at:
> www.eda.org/pub/ibis/s2ibis/s2ibis2_v1.1
> There are two *.Z files. Get the one with _fix.
> 
> 
> Syed Huq wrote:
> 
> > Wil,
> >
> > Are you translating multiple buffers at the same time ? Try running the
> > s2ibis2 only on an Input model or only on an Output model. There is an
> > issue of creating too many .spi and .out files..
> >
> > Next, you should be using s2ibis2_fix version. Your data shows you are
> > using an older version..
> >
> > Syed
> >
> > >Date: Mon, 14 Apr 2003 16:50:15 -0700
> > >From: Wil Ngan <[email-masked]>
> > >X-Accept-Language: en
> > >MIME-Version: 1.0
> > >CC: [email-masked], [email-masked], [email-masked]
> > >Subject: [IBIS] Ibis generation problem
> > >
> > >Hi,
> > >
> > >I'm having problem generating an ibis file, and was wondering
> > >if I can get ideas in how to approach this.
> > >
> > >1) The problem:
> > >
> > >I get the following error when running  spice to ibis:
> > >% s2ibis2.11 gold_7xxx.s2i
> > >s2ibis2.11_real v1.1 -- North Carolina State University
> > >s2ibis2.11_real: Reading input file gold_7xxx..done
> > >s2ibis2.11_real: Analyzing component idt7xxx .
> > >s2ibis2.11_real: Starting HSpice job with input put7.spi.
> > >:
> > >etc
> > >:
> > >s2ibis2.11_real: Starting HSpice job with input y017.spi.
> > >s2ibis2.11_real: Starting HSpice job with input z017.spi.
> > >s2ibis2.11_real: Opening file gold_7xxx.ibs for writing...Bus error
> > >
> > >-----
> > >
> > >2) My attempt at solving this:
> > >
> > >And so  I examine the  gold_7xxx .ibs file, and  I see the following:
> > >:
> > >etc
> > >:
> > >[Pulldown]
> > >| voltage     I(typ)              I(min)              I(max)
> > >|
> > >  -3.30      -9.001A             -9.160A             -8.914A
> > >  -3.10      -8.255A             -8.415A             -8.168A
> > >:
> > >etc
> > >:
> > >   3.50       0.178A              0.117A              0.241A
> > >   3.60       0.179A              0.117A              0.242A
> > >   3.70       0.179A
> > >
> > >(The ibis file ends here, which is far from being complete.)
> > >
> > >I have examined all the *out files (especially the pdt.out, pdx.out,
> > >pdn.out files)
> > >in detail and see that all hspice data has been generated and dumped
> > >into  the
> > >*out files with  no problem whatsoever. And yet s2ibis is apparently
> > >having
> > >problem extracting  the data from the  *out files to place in the *ibs
> > >file.
> > >
> > >Any idea how to approach or solve this problem?
> > >Has anyone ever encountered this?
> > >Any help or hints would be appreciated.  Thanks so much,
> > >
> > >- Wil
> > >IDT  sram design
> > >(408) 330-1623
> > >
> > >
> 
> -----------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email [email-masked]
> |with the appropriate command message(s) in the body:
> |
> |  help
> |  subscribe   ibis       <optional e-mail address, if different>
> |  subscribe   ibis-users <optional e-mail address, if different>
> |  unsubscribe ibis       <optional e-mail address, if different>
> |  unsubscribe ibis-users <optional e-mail address, if different>
> |
> |or email a request to [email-masked].
> |
> |IBIS reflector archives exist under:
> |
> |  http://www.eda.org/pub/ibis/email_archive/  Recent
> |  http://www.eda.org/pub/ibis/users_archive/  Recent
> |  http://www.eda.org/pub/ibis/email/          E-mail since 1993
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Mon, 12 May 2003 09:36:49 +0200
From: [email-masked]
Subject: RE: [IBIS-Users] (lv)pecl

This is a multipart message in MIME format.
- --=_alternative 002A0214C1256D24_=
Content-Type: text/plain; charset="us-ascii"

Tom, 

About the garbage lines:
I use s2ibis for model type output_ECL.
Voltage range has been  left out (since this created a voltage source of 
1.9V to the ground node in the spectre simulation files).
Pull-up and pull-down references have been set to 3.3V.

The result is an IBIS file that contains a pulldown-curve starting at 1.1V 
and continuing up to 3.3V.
Then the next voltages are: 2.05, 9 times 0V and 3.3V. Most currents are 
equal to the 3.3V current except for the max current, which is increasing 
for every line (note that I filled in the typical values for the the min 
and max cases).

The pull-up curve ranges from 0V to 2.2V and is then followed by 10 times 
0V and 2.2V. The current for the 0V lines is always 0.000A, except for the 
first one.

So I get some strange values and the range is from 0-2.2V instead of -3.3 
to 6.6V.

With kind regards,

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334

"Tom Dagostino" <[email-masked]>
05/09/03 07:11 PM
Please respond to tom

        To:     Erik van der Ven/NYM/SC/PHILIPS@EMEA2
        cc: 
        Subject:        RE: [IBIS-Users] (lv)pecl
        Classification: 

Erik
 
In the old days (in the 60s) when Motorola first developed ECL They found 
that running ECL from 0 to -5.2 volts worked better because the ground 
planes on boards at the time was cleaner.  ECL is referenced to the most 
positive supply, thus a clean reference was important.  In those days the 
ground could have been a complete plane of the board but power was in many 
cases distributed via traces on one of the layer.  In today's modern 
circuit boards both the power and ground are distributed in planes so this 
is not an issue. 
 
The voltage difference you see is not important.  When you are running the 
SPICE simulation you just need to connect the Vcc to 3.3 and the Vee to 
ground to get the PECL model.  Remember the 50 Ohm termination needs to be 
connected to Vcc - 2 volts or 1.3 for the typical case when running the AC 
simulations.
 
I do have concerns about the table range you are seeing.  It should be 
between -3.3 and +6.6 Volts for all the IV tables.
 
The simulator does several things with the data.  First of all it will 
check the data to ensure it is at least consistent, has not syntax issues, 
etc.  Then, for outputs, it builds a set of coefficients that describes 
how the buffer transitions from pullup to pulldown and from pulldown to 
pullup.  This table is based on the VT waveforms and the IV curves.
 
The output impedance of the buffer is composed of the sum of the pullup or 
pulldown IV table plus the power and ground clamps plus the component of 
C_comp.
 
If the buffer is an input the the power and ground clamps are summed and 
put in parallel with C_comp.
 
Because the model is designated ECL, the simulator makes one different 
calculation for the pulldown table than it does for CMOS, see below.
 
What is the 10 lines of garbage you are seeing?
 
Hope that helps.
 
Tom Dagostino
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC
2926 SE Yamhill St.                Device Modeling Division
Portland, OR 97214                 13610 SW Harness Lane
                                   Beaverton, OR 97008
http://www.teraspeed.com           503-430-1065 
[email-masked] 
- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Friday, May 09, 2003 12:41 AM
To: [email-masked]
Subject: RE: [IBIS-Users] (lv)pecl

Tom, 

Thank you for your reply. I am starting with a Spectre netlist. I have 
tried s2ibis to make a model for LVPECL. 
I noticed some differences. ECL has a supply of 0V (plus) and -5.2V (neg). 
My circuit has a supply of 3.3V (plus) and 0V (neg). 
The pulldown table ranges from 1.1V to 3.3V (the pull down reference has 
been set to 3.3V, the pull-up reference as well), followed by ten lines of 
garbage. A collegue of mine has changed to pragram a bit so the pull down 
curve starts at 0V and ends at 2.2V (still followed by ten lines of 
garbage). 
Is this a correct range? 
What does the simulator that uses the IBIS model do with the information 
that it is an output-ECL model type? And how are the data tables 
interpreted in conjunction with the ECL_model type? 

With kind regards, 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334 

"Tom Dagostino" <[email-masked]> 
05/08/03 07:16 PM 
Please respond to tom 
        
        To:        Erik van der Ven/NYM/SC/PHILIPS@EMEA2 
        cc:         
        Subject:        RE: [IBIS-Users] (lv)pecl 
        Classification:         

Erik 
  
What are you starting with?  A SPICE description or are you going to make 
the model from measurements?  If you start with SPICE there is a spice to 
ibis program that you can download from the ibis home page.  If you are 
starting from measurements then you will need a lot of equipment to make 
the measurements.  You will have to manually convert the measurements to 
the ibis data. 
  
Simulators use the output_ecl line to know how to handle ECL.  In IBIS ECL 
models are slightly different than standard CMOS or TTL drivers.  In CMOS 
or TTL the pulldown current is sunk into the ground plane and the pullup 
current is sourced from the supply.  With PECL both the pullup and 
pulldown are sourced from the supply.  So in PECL the pulldown is 
referenced to the supply, not ground.  The simulator needs to know this 
when it is using the IV tables. 
  
Tom Dagostino 
Teraspeed Consulting Group LLC     Teraspeed Consulting Group LLC 
2926 SE Yamhill St.                Device Modeling Division 
Portland, OR 97214                 13610 SW Harness Lane 
                                   Beaverton, OR 97008 
http://www.teraspeed.com           503-430-1065 
[email-masked] 
- -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Thursday, May 08, 2003 12:04 AM
To: [email-masked]
Subject: [IBIS-Users] (lv)pecl

Dear all, 

I think I mailed my question too early since I subscribed to the user 
group at the same time. So I'll post it again, please see below. 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334 
- ----- Forwarded by Erik van der Ven/NYM/SC/PHILIPS on 05/08/03 09:03 AM 
- ----- 

Erik van der Ven 
05/06/03 02:01 PM 
        
       To:        [email-masked] 
       cc:         
       Subject:        (lv)pecl 
        Classification:        Unclassified 

1. How can I make an IBIS model of a (LV)PECL model? 
2. What does an IBIS simulator do with the model type information (like 
output_ECL)? 

Can anyone help me? 
Thanks. 

With kind regards, 

Ir. Erik van der Ven
Room DB1032
Business Line Networking Infrastructure
Philips Semiconductors BV
Gerstweg 2
6534 AE Nijmegen
The Netherlands
Phone: +31-24-3534334 

- --=_alternative 002A0214C1256D24_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Tom, </font>
<br>
<br><font size=2 face="sans-serif">About the garbage lines:</font>
<br><font size=2 face="sans-serif">I use s2ibis for model type output_ECL.</font>
<br><font size=2 face="sans-serif">Voltage range has been &nbsp;left out (since this created a voltage source of 1.9V to the ground node in the spectre simulation files).</font>
<br><font size=2 face="sans-serif">Pull-up and pull-down references have been set to 3.3V.</font>
<br>
<br><font size=2 face="sans-serif">The result is an IBIS file that contains a pulldown-curve starting at 1.1V and continuing up to 3.3V.</font>
<br><font size=2 face="sans-serif">Then the next voltages are: 2.05, 9 times 0V and 3.3V. Most currents are equal to the 3.3V current except for the max current, which is increasing for every line (note that I filled in the typical values for the the min and max cases).</font>
<br>
<br><font size=2 face="sans-serif">The pull-up curve ranges from 0V to 2.2V and is then followed by 10 times 0V and 2.2V. The current for the 0V lines is always 0.000A, except for the first one.</font>
<br>
<br><font size=2 face="sans-serif">So I get some strange values and the range is from 0-2.2V instead of -3.3 to 6.6V.</font>
<br>
<br><font size=2 face="sans-serif">With kind regards,</font>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>&quot;Tom Dagostino&quot; &lt;[email-masked]&gt;</b></font>
<p><font size=1 face="sans-serif">05/09/03 07:11 PM</font>
<br><font size=1 face="sans-serif">Please respond to tom</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Erik van der Ven/NYM/SC/PHILIPS@EMEA2</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: [IBIS-Users] (lv)pecl</font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Arial">Erik</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">In the old days (in the 60s) when Motorola first developed ECL They found that running ECL from 0 to -5.2 volts worked better because the ground planes on boards at the time was cleaner. &nbsp;ECL is referenced to the most positive supply, thus a clean reference was important. &nbsp;In those days the ground could have been a complete plane of the board but power was in many cases distributed via traces on one of the layer. &nbsp;In today's modern circuit boards both the power and ground are distributed in planes so this is not an issue. &nbsp;</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">The voltage difference you see is not important. &nbsp;When you are running the SPICE simulation you just need to connect the Vcc to 3.3 and the Vee to ground to get the PECL model. &nbsp;Remember the 50 Ohm termination needs to be connected to Vcc - 2 volts or 1.3 for the typical case when running the AC simulations.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">I do have concerns about the table range you are seeing. &nbsp;It should be between -3.3 and +6.6 Volts for all the IV tables.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">The simulator does several things with the data. &nbsp;First of all it will check the data to ensure it is at least consistent, has not syntax issues, etc. &nbsp;Then, for outputs, it builds a set of coefficients that describes how the buffer transitions from pullup to pulldown and from pulldown to pullup. &nbsp;This table is based on the VT waveforms and the IV curves.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">The output impedance of the buffer is composed of the sum of the pullup or pulldown IV table plus the power and ground clamps plus the component of C_comp.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">If the buffer is an input the the power and ground clamps are summed and put in parallel with C_comp.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">Because the model is designated ECL, the simulator makes one different calculation for the pulldown table than it does for CMOS, see below.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">What is the 10 lines of garbage you are seeing?</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 color=blue face="Arial">Hope that helps.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=3 face="Courier New">Tom Dagostino</font>
<br><font size=3 face="Courier New">Teraspeed Consulting Group LLC &nbsp; &nbsp; Teraspeed Consulting Group LLC</font>
<br><font size=3 face="Courier New">2926 SE Yamhill St. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Device Modeling Division</font>
<br><font size=3 face="Courier New">Portland, OR 97214 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 13610 SW Harness Lane</font>
<br><font size=3 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Beaverton, OR 97008</font>
<br><font size=3 face="Courier New">http://www.teraspeed.com &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 503-430-1065 </font>
<p><font size=3 face="Courier New">[email-masked]</font><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Tahoma">-----Original Message-----<b><br>
From:</b> [email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>[email-masked]<b><br>
Sent:</b> Friday, May 09, 2003 12:41 AM<b><br>
To:</b> [email-masked]<b><br>
Subject:</b> RE: [IBIS-Users] (lv)pecl<br>
</font>
<br><font size=2 face="sans-serif"><br>
Tom,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Thank you for your reply. I am starting with a Spectre netlist. I have tried s2ibis to make a model for LVPECL.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
I noticed some differences. ECL has a supply of 0V (plus) and -5.2V (neg). My circuit has a supply of 3.3V (plus) and 0V (neg).</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
The pulldown table ranges from 1.1V to 3.3V (the pull down reference has been set to 3.3V, the pull-up reference as well), followed by ten lines of garbage. A collegue of mine has changed to pragram a bit so the pull down curve starts at 0V and ends at 2.2V (still followed by ten lines of garbage).</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Is this a correct range?</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
What does the simulator that uses the IBIS model do with the information that it is an output-ECL model type? And how are the data tables interpreted in conjunction with the ECL_model type?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
With kind regards,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure</font>
<br><font size=2 face="sans-serif">Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font><font size=3 face="Times New Roman"> <br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=2%>
<td width=43%><font size=3 face="Times New Roman"><br>
<br>
<br>
<br>
</font><font size=1 face="sans-serif"><b><br>
&quot;Tom Dagostino&quot; &lt;[email-masked]&gt;</b></font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">05/08/03 07:16 PM</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
Please respond to tom</font><font size=3 face="Times New Roman"> </font>
<td width=53%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;Erik van der Ven/NYM/SC/PHILIPS@EMEA2</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: [IBIS-Users] (lv)pecl</font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3 face="Times New Roman"> </font></table>
<p><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 color=blue face="Arial"><br>
Erik</font><font size=3 face="Times New Roman"> <br>
 &nbsp;</font><font size=2 color=blue face="Arial"><br>
What are you starting with? &nbsp;A SPICE description or are you going to make the model from measurements? &nbsp;If you start with SPICE there is a spice to ibis program that you can download from the ibis home page. &nbsp;If you are starting from measurements then you will need a lot of equipment to make the measurements. &nbsp;You will have to manually convert the measurements to the ibis data.</font><font size=3 face="Times New Roman"> <br>
 &nbsp;</font><font size=2 color=blue face="Arial"><br>
Simulators use the output_ecl line to know how to handle ECL. &nbsp;In IBIS ECL models are slightly different than standard CMOS or TTL drivers. &nbsp;In CMOS or TTL the pulldown current is sunk into the ground plane and the pullup current is sourced from the supply. &nbsp;With PECL both the pullup and pulldown are sourced from the supply. &nbsp;So in PECL the pulldown is referenced to the supply, not ground. &nbsp;The simulator needs to know this when it is using the IV tables.</font><font size=3 face="Times New Roman"> <br>
 &nbsp;</font><font size=3 face="Courier New"><br>
Tom Dagostino</font><font size=3 face="Times New Roman"> </font><font size=3 face="Courier New"><br>
Teraspeed Consulting Group LLC &nbsp; &nbsp; Teraspeed Consulting Group LLC</font><font size=3 face="Times New Roman"> </font><font size=3 face="Courier New"><br>
2926 SE Yamhill St. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Device Modeling Division</font><font size=3 face="Times New Roman"> </font><font size=3 face="Courier New"><br>
Portland, OR 97214 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 13610 SW Harness Lane</font><font size=3 face="Times New Roman"> </font><font size=3 face="Courier New"><br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Beaverton, OR 97008</font><font size=3 face="Times New Roman"> </font><font size=3 face="Courier New"><br>
http://www.teraspeed.com &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 503-430-1065 </font>
<p><font size=3 face="Courier New">[email-masked]</font><font size=3 face="Times New Roman"> </font><font size=2 face="Tahoma"><br>
- -----Original Message-----<b><br>
From:</b> [email-masked] [mailto:[email-masked]]<b>On Behalf Of </b>[email-masked]<b><br>
Sent:</b> Thursday, May 08, 2003 12:04 AM<b><br>
To:</b> [email-masked]<b><br>
Subject:</b> [IBIS-Users] (lv)pecl</font><font size=3 face="Times New Roman"><br>
</font><font size=2 face="sans-serif"><br>
<br>
Dear all,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
I think I mailed my question too early since I subscribed to the user group at the same time. So I'll post it again, please see below.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font><font size=3 face="Times New Roman"> </font><font size=1 color=#800080 face="sans-serif"><br>
- ----- Forwarded by Erik van der Ven/NYM/SC/PHILIPS on 05/08/03 09:03 AM -----</font><font size=3 face="Times New Roman"> </font>
<table width=100%>
<tr valign=top>
<td width=4%>
<td width=34%><font size=3 face="Times New Roman"><br>
<br>
<br>
</font><font size=1 face="sans-serif"><b><br>
<br>
Erik van der Ven</b></font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">05/06/03 02:01 PM</font><font size=3 face="Times New Roman"> </font>
<td width=60%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3 face="Times New Roman"> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;(lv)pecl</font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Classification: &nbsp; &nbsp; &nbsp; &nbsp;Unclassified</font><font size=3 face="Times New Roman"> </font></table>
<p><font size=2 face="sans-serif"><br>
<br>
1. How can I make an IBIS model of a (LV)PECL model?</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
2. What does an IBIS simulator do with the model type information (like output_ECL)?</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Can anyone help me?</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Thanks.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
With kind regards,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Ir. Erik van der Ven<br>
Room DB1032<br>
Business Line Networking Infrastructure<br>
Philips Semiconductors BV<br>
Gerstweg 2<br>
6534 AE Nijmegen<br>
The Netherlands<br>
Phone: +31-24-3534334</font><font size=3 face="Times New Roman"> </font>
<p>
<p>
- --=_alternative 002A0214C1256D24_=--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email [email-masked]
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to [email-masked].
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

End of ibis-users V1 #22
************************