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

ibis-users          Friday, February 15 2002          Volume 01 : Number 003

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

Date: Mon, 4 Feb 2002 17:58:04 -0500
From: "Ingraham, Andrew" <[email-masked]>
Subject: RE: ibischk3 V3.2.8 [Warning]

I don't disagree that models CAN be made to cover the full range from
- -Vcc to +2*Vcc.

I just don't think that a model should ever be made that doesn't cover
this range.  I can think of no valid reason for any I-V curve to cover a
smaller range.

I'm not sure precisely what s2ibis* does (since I've not used it), but I
believe it does just the minimum required by the IBIS spec.  Since most
s2ibis* users probably don't know much about IBIS, this is bound to
cause problems.

Regards,
Andy

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

Date: Mon, 04 Feb 2002 15:55:48 -0800
From: "Ross, Bob" <[email-masked]>
Subject: Re: ibischk3 V3.2.8 [Warning]

Andy:

I agree with you and everyone else.  Both the [Gnd Clamp]
and [Power Clamp] tables should have been extended to cover
the whole range for consistency.  In fact, this is necessary
for correct representation when the buffer has internal
terminators that need to be isolated from the [Pullup]
and [Pulldown] tables.

When IBIS was originally formulated for 5 V CMOS technology,
the [Gnd Clamp] and [Power Clamp] tables had negligible
currents in the 0 to 5 V region.  These tables were both
truncated and joined at Vcc (5 V).  The fact that the currents
were nearly 0 ma AND the slope with respect to voltage
was approximately 0ma/V meant the extrapolation by slope
or by value both worked in EDA tools.  Several tools and ibischk3
do extrapolate the end-points, so this is a potential source
of waveform mismatch if the clamp tables do not have zero slope.  

Bob

"Ingraham, Andrew" wrote:
> 
> I don't disagree that models CAN be made to cover the full range from
> -Vcc to +2*Vcc.
> 
> I just don't think that a model should ever be made that doesn't cover
> this range.  I can think of no valid reason for any I-V curve to cover a
> smaller range.
> 
> I'm not sure precisely what s2ibis* does (since I've not used it), but I
> believe it does just the minimum required by the IBIS spec.  Since most
> s2ibis* users probably don't know much about IBIS, this is bound to
> cause problems.
> 
> Regards,
> Andy

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

Date: Mon, 04 Feb 2002 21:58:23 -0500
From: Mike LaBonte <[email-masked]>
Subject: Re: ibischk3 V3.2.8 [Warning]

Andy,

You may be assuming that s2ibis2 users mostly know SPICE, and IBIS
is a "second language" for them. But I am guessing that s2ibis is
used more by people that know IBIS well, or may even know both
quite well. Anyone who uses s2ibis2 and doesn't know IBIS fairly
well is probably not turning out useful models. OK, maybe I just
supported your premise :-)

But I think the majority of s2ibis2 users are IBIS model end users,
who have to fuss with it until they get a good IBIS model. That takes
IBIS knowledge. Also, I find that to use s2ibis2 you have to know
a 3rd language, "C".

Mike LaBonte

"Ingraham, Andrew" wrote:
> 
> I'm not sure precisely what s2ibis* does (since I've not used it), but I
> believe it does just the minimum required by the IBIS spec.  Since most
> s2ibis* users probably don't know much about IBIS, this is bound to
> cause problems.
> 
> Regards,
> Andy

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

Date: Tue, 05 Feb 2002 09:09:29 -0500
From: Shahab Ahmed <[email-masked]>
Subject: IBIS (.ebd) verification question.

Hello all:

I hope I am not posting this in the wrong group. I was just wondering, 
how do you create .ebd file for different pcb boards?
Do you do it manually or automatically using some tools?

Also, once you have a .ebd file, how do you verify the .ebd file (not 
just the syntax). Ideally, seems to me that you would want to look at 
the waveform on each pin from the pcb and also from .ebd and compare 
these two waveforms.

I would very much appreciate some advice/feedback on this.

Thank you and have a wonderful day.

Shahab

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

Date: Tue, 05 Feb 2002 16:58:03 -0800
From: "Ross, Bob" <[email-masked]>
Subject: European IBIS Summit - Third Announcement

To All:

This is the third announcement of the European IBIS Summit
meeting held during DATE 2002 in Paris for presentations and
participation.  Several interesting presentations have already
been proposed privately.

Bob Ross
Mentor Graphics

            E U R O P E A N   I B I S   S U M M I T   M E E T I N G
                      T H I R D   A N N O U N C E M E N T

Time/Date:     8:30 AM - 2 PM, Friday, March 8, 2002

Location:      Concorde-Lafayette Hotel (adjacent to Le Palais des 
               Congress de Paris Prote Mailot - site of the DATE2002
               Conference) in Paris, France

Rooms:         Salon Van Gogh/Pissarro

Content:       Presentations and Discussions

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

Sponsors:      EADS, Innoveda, Mentor Graphics

DATE2000:      March 4-8, 2002.  The IBIS meeting is scheduled the day
               following the trade show portion of the Conference

               See http://www.date-conference.com for more information.

BACKGROUND

For the last several years we have been holding very successful European IBIS
Summit Meetings.  We plan a combination of the following:

  Submitted Presentations on IBIS Topics (See below)
  Less formal Ad Hoc Presentations and Discussions
  IBIS Questions and Answers
  
Below is an invitation to register and also to submit presentations.

CALL FOR PARTICIPANTS

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

  Name:
  E-mail address:
  Company:
  Telephone:

Send to:

  Karine Loudet ([email-masked])

CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have IBIS experiences
or issues.  Some suggested subjects of interest are:

  IBIS Model Development Experiences
  Company IBIS Standards and Requirements
  Generating and Validating IBIS Models
  Future IBIS Requirements
  EMC/EMI IBIS Issues

Format of Presentation:  Overhead Projections
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.

Please plan to bring copies of your presentation to distribute at the meeting.

If you plan a presentation, please supply

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

  Estimate Time:

Send this to:

  Bob Ross ([email-masked])

AGENDA

The agenda includes presentations, discussions, and a free lunch.

FOR FURTHER INFORMATION:

Bob Ross,
Vice Chair, EIA/IBIS Open Forum
Mentor Graphics
8005 S.W. Boeckman Road
Wilsonville, Oregon 97070
USA

(503) 685-0732
[email-masked]

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

Date: Tue, 05 Feb 2002 17:49:19 -0800
From: "Ross, Bob" <[email-masked]>
Subject: Re: VT curves

Hello Sunil:

Several EDA Vendors use the V-T tables, but you need to contact
the vendors directly for the specific algorithms and limitations.

However, a common method is to use two (and possibly more) tables
and convert the tables into an intermediate internal format (such as
I-V table multipliers as a function of T.  The method to do this
is done in a manner that will reproduce the orignal V-T waveform
when loaded with the given V_fixture and R_fixture values.

Bob Ross
Mentor Graphics

Sunil Kumar wrote:
> 
> Hello,
> 
> Please tell me how a simulation tool uses VT (rising and falling) curves
> in the simulation.
> 
> Thanks
> 
> Sunil Kumar
> Senior Research Engineer
> ATM Group, Switching-B2
> Centre for Development of Telematics (C-DOT)
> 71/1 Millers Road
> Bangalore-52
> INDIA
> 
> Ph:  91-80-2263399 Ext. 217, 279
>      91-80-2282119 (Direct)
> Fax: 91-80-2282119
> Email: [email-masked]
>        [email-masked]
> 
> On Mon, 4 Feb 2002, Sunil Kumar wrote:
> 
> >
> >

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

Date: Tue, 05 Feb 2002 17:59:21 -0800
From: "Ross, Bob" <[email-masked]>
Subject: Re: differential buffer model

Hello Yueming:

A simplistic sample that really was demonstrating creating
a differential terminator out of [R Series] exists under:

  http://www.eda.org/pub/ibis/samples/ver3.2/

as diff_pecl_term.ibs.  It shows using [Diff_Pin] for PECL.

Bob Ross
Mentor Graphics

Yueming Jiang wrote:
> 
> Hi.
> 
> I'm trying to make some IBIS models for our ICs upon customer request.
> But I couldn't find much info as to how to deal with and differential
> PECL buffer. The examples in Cookbook can't really apply to differential
> signals. Can someone provide some information/example of differential
> PECL buffer modeling?
> 
> Thanks a lot,
> 
> Y. Jiang
> 
> Tality Corp

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

Date: Wed, 6 Feb 2002 18:59:26 -0800 
From: "Mohan, Prabhu" <[email-masked]>
Subject: removing non-monotonic points?!

Hi all,

I have a few questions regarding a paper that was presented at the last IBIS
Summit, that suggested various methods to remove non-monotonic points from
the IBIS model file.

http://www.eda.org/pub/ibis/summits/jan02/bell2.pdf

For example, on page11, the pulldown curve is just extrapolated in the -ve
region to remove non-monotonic behavior.

Question#1: Won't we double count the clamp current by doing this (since
simulation tools add the Pulldown/up curves with the clamp curves)?

Question#2: What do we do if the silicon really does behave like this? (true
in my case. i do get a similar -ve bump when i subtract the 'tristate' curve
from the 'ouput low' curve)

Question#3: Is it advisable to remove the non-monotonic points completely,
since they almost always seem to occur outside the normal operating range?
ie. flatten the -ve/+ve bumps?

There might not be a simple solution. But I'd really like to know what the
possibilities are.

Thanks in advance,
Prabhu/~

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

Date: Thu, 7 Feb 2002 08:06:30 -0800 
From: "Muranyi, Arpad" <[email-masked]>
Subject: RE: removing non-monotonic points?!

Prabhu,

You are correct, the recommendation in that presentation will result
in double counting the clamps.  What the author of that paper really
should have recommended is to check the monotonocity after summing
the pullup with the power clamp and the pulldown with the GND clamp
IV curves.  Unfortunately the IBIS checker doesn't do this, and in
my opinion it should be corrected.  It has mislead way too many 
people already.

When I brought this up in the meeting Scott's response was that your
signals will never go into that range at the driver anyway, so it
really doesn't matter.  Even though this maybe true in most cases,
the correct way for monotonocity check is after the summation.

Arpad Muranyi
Intel Corporation
====================================================================

- -----Original Message-----
From: Mohan, Prabhu [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 6:59 PM
To: [email-masked]
Subject: removing non-monotonic points?!

Hi all,

I have a few questions regarding a paper that was presented at the last IBIS
Summit, that suggested various methods to remove non-monotonic points from
the IBIS model file.

http://www.eda.org/pub/ibis/summits/jan02/bell2.pdf

For example, on page11, the pulldown curve is just extrapolated in the -ve
region to remove non-monotonic behavior.

Question#1: Won't we double count the clamp current by doing this (since
simulation tools add the Pulldown/up curves with the clamp curves)?

Question#2: What do we do if the silicon really does behave like this? (true
in my case. i do get a similar -ve bump when i subtract the 'tristate' curve
from the 'ouput low' curve)

Question#3: Is it advisable to remove the non-monotonic points completely,
since they almost always seem to occur outside the normal operating range?
ie. flatten the -ve/+ve bumps?

There might not be a simple solution. But I'd really like to know what the
possibilities are.

Thanks in advance,
Prabhu/~

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

Date: Thu, 07 Feb 2002 08:50:38 -0800
From: Scott McMorrow <[email-masked]>
Subject: Re: removing non-monotonic points?!

Arpad,

We are all in agreement that the ibis checker should be fixed to report 
non-monotonicity in the summed curves, also.

It is our experience that when these points come well below or above the 
voltage rails, say 800 mV above or below the rail, they just do not 
matter.  For an output to achieve an extreme voltage this far below the 
rail while operating would be quite extraordinary.  We have yet to see a 
real device in  a real system where the output is pulled this far below 
ground.  For normal device operation, this non-monotonic behavior (which 
also often does show up in the summation) will never be seen.  It is 
perfectly acceptable to smooth out the curves as we do.  

In our spice to ibis process, we perform this data smoothing in the 
non-monotonic output curves below and above the rails, and then perform 
a correlation to the original spice models in a real circuit with 
reflected waves, to be sure that under normal operating conditions the 
model is still faithful and accurate.

Theoretically, it does matter what the curves do 700 mV below the ground 
rail and above the power (or clamp) rail.  But as a practical matter, it 
does not alter real simulations one iota.  For my money, anything can be 
done to a simulation model, as long as the approximation  results in 
accuracy that is accurate enough for the work we are doing.
The easiest way to check this is to compare simulations with the 
original spice, or to compare the results to measurements.

best regards,

scott

- -- 
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com

Muranyi, Arpad wrote:

>Prabhu,
>
>You are correct, the recommendation in that presentation will result
>in double counting the clamps.  What the author of that paper really
>should have recommended is to check the monotonocity after summing
>the pullup with the power clamp and the pulldown with the GND clamp
>IV curves.  Unfortunately the IBIS checker doesn't do this, and in
>my opinion it should be corrected.  It has mislead way too many 
>people already.
>
>When I brought this up in the meeting Scott's response was that your
>signals will never go into that range at the driver anyway, so it
>really doesn't matter.  Even though this maybe true in most cases,
>the correct way for monotonocity check is after the summation.
>
>Arpad Muranyi
>Intel Corporation
>====================================================================
>
>
>-----Original Message-----
>From: Mohan, Prabhu [mailto:[email-masked]]
>Sent: Wednesday, February 06, 2002 6:59 PM
>To: [email-masked]
>Subject: removing non-monotonic points?!
>
>
>Hi all,
>
>I have a few questions regarding a paper that was presented at the last IBIS
>Summit, that suggested various methods to remove non-monotonic points from
>the IBIS model file.
>
>http://www.eda.org/pub/ibis/summits/jan02/bell2.pdf
>
>For example, on page11, the pulldown curve is just extrapolated in the -ve
>region to remove non-monotonic behavior.
>
>Question#1: Won't we double count the clamp current by doing this (since
>simulation tools add the Pulldown/up curves with the clamp curves)?
>
>Question#2: What do we do if the silicon really does behave like this? (true
>in my case. i do get a similar -ve bump when i subtract the 'tristate' curve
>from the 'ouput low' curve)
>
>Question#3: Is it advisable to remove the non-monotonic points completely,
>since they almost always seem to occur outside the normal operating range?
>ie. flatten the -ve/+ve bumps?
>
>There might not be a simple solution. But I'd really like to know what the
>possibilities are.
>
>Thanks in advance,
>Prabhu/~
>
>

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

Date: Thu, 7 Feb 2002 12:44:52 -0500 
From: Chris Rokusek <[email-masked]>
Subject: RE: removing non-monotonic points?!

Parser-Developers, 

It is true that the checker doesn't add VI curves together for the
monotonicity check but it does add VI curves together for the acdc
check.  So implementation-wise all the hard work has already been done.
Just the monotonicity check itself needs to be called from within
acdc.c:acdc_CheckModelProcess() using the summed curve structures
created within that routine.  Hoping this may speed the process a bit.

Chris Rokusek
Innoveda

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Muranyi, Arpad
> Sent: Thursday, February 07, 2002 8:07 AM
> To: [email-masked]
> Subject: RE: removing non-monotonic points?!
> 
> 
> Prabhu,
> 
> You are correct, the recommendation in that presentation will 
> result in double counting the clamps.  What the author of 
> that paper really should have recommended is to check the 
> monotonocity after summing the pullup with the power clamp 
> and the pulldown with the GND clamp IV curves.  Unfortunately 
> the IBIS checker doesn't do this, and in my opinion it should 
> be corrected.  It has mislead way too many 
> people already.
> 
> When I brought this up in the meeting Scott's response was 
> that your signals will never go into that range at the driver 
> anyway, so it really doesn't matter.  Even though this maybe 
> true in most cases, the correct way for monotonocity check is 
> after the summation.
> 
> Arpad Muranyi
> Intel Corporation 
> ====================================================================

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

Date: Thu, 7 Feb 2002 10:03:27 -0800 (PST)
From: Shahab Ahmed <[email-masked]>
Subject: Looking for Bill Heggins(sp?). 

Hi all:

I sincerely apologize for sending this email to
everyone. I have been in touch with Bill Heggins(sp?)
recently. I just got laid off today along with 10
others at our company. So, I don't have access to my
emails. 

Bill..if you get this email, please email me back
soon. Thanks.

Shahab
919.484.8373 
919.641.1084 (Cell).

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

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

Date: Thu, 7 Feb 2002 13:28:14 -0500
From: "Ingraham, Andrew" <[email-masked]>
Subject: RE: removing non-monotonic points?!

As I've spoken my mind about this recently, I figured I should throw my
two cents in.  I disagree that I-V points more than 800 mV beyond the
rails are meaningless.

Even though a simulator may not CONVERGE on a point that is 2V beyond
the rails (because of stiff clamping), that doesn't mean that the
simulator didn't TRY that point.  If the I-V data at that point in the
model is totally out to lunch, say zero, then you wouldn't expect the
simulator to figure out it needs to get back into a more normal
operating region.

That's one reason why I-V tables should never be truncated, even if you
can't measure the current that far out without frying the part.  The
data out there needs to be reasonable enough ... by extrapolation if
need be ... to guide the simulator back toward reality.  Otherwise it
might actually converge way out there, or may give up and abort the
simulation.

Also, there are plenty of duff SPICE models that have unusually stiff
clamps because they forgot to include any diode resistance.  With these
models you might never find a simulated result that is more than 800 mV
beyond the rails, no matter how hard you try; whereas the real devices
are not that ideal.  I have seen negative overshoot on a few devices go
as far as about -2.5V ... although this is at the package pin, not on
the die.  Suffice it to say that some parts clamp less well than most.

Regards,
Andy

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

Date: Thu, 7 Feb 2002 10:36:31 -0800
From: "Bill Hargin" <[email-masked]>
Subject: RE: Looking for Bill Heggins(sp?). 

Hello Shahab:

Sorry to hear that ... What a brutal time we're going through.

You were pretty close on the name ... 

Best Regards,
Bill Hargin
Direct: 425-702-0744
mailto:[email-masked]

Cognition Consulting
Electronic Design Software and Consulting
http://www.CognitionConsulting.com

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Shahab Ahmed
> Sent: Thursday, February 07, 2002 10:03 AM
> To: [email-masked]
> Subject: Looking for Bill Heggins(sp?). 
> 
> 
> Hi all:
> 
> I sincerely apologize for sending this email to
> everyone. I have been in touch with Bill Heggins(sp?)
> recently. I just got laid off today along with 10
> others at our company. So, I don't have access to my
> emails. 
> 
> Bill..if you get this email, please email me back
> soon. Thanks.
> 
> Shahab
> 919.484.8373 
> 919.641.1084 (Cell).
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
> 

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

Date: Thu, 07 Feb 2002 18:23:34 -0800
From: Scott McMorrow <[email-masked]>
Subject: Re: removing non-monotonic points?!

Andrew,

I was not talking about a hypothetical when I suggested that removal of 
and/or smoothing non-monotonic points in the output I/V curves is a 
practical method of modifying models.  I am talking about the actual 
reality in the simulators which we use.  We have removed points from 
IBIS models and correlated the results to the original HSPICE 
simulations with the following three IBIS simulatiors

HSPICE b-element
Mentor Interconnectix
Cadence SpectraQuest.

In all cases, the removal and smoothing of points which are 
non-monotonic ( generally below the ground rail, but sometimes above the 
power rail) have absolutely no effect whatsoever on the simulation 
results in these simulators. When we do this, for models which we 
produce, we do perform correlations with the IBIS accuracy metric.  We 
have data on nearly 500 buffers which we have created models for which 
illustrate this point.  If our correlation to HSPICE is not at least 97% 
into a reflected wave test  environment at both the driver output and at 
the end of the line,   we start over and refine the extraction process. 
 In nearly 80% of all buffers which we extract IBIS Models for, the 
correlation is generally more on the order of 99% or better, with only 
very slight visual differences in simulation waveforms.

There may be simulators where this smoothing of the data is a problem, 
but I've not found one so far.  There may also be some types of outputs 
where correlation mismatches could occur, however we have not seen one 
yet in all our years of experience in creating IBIS models from the 
original HSPICE.

Generally, the excessive undershoot which you see at the pins of a 
device are not occuring at the die.  Often what is measured at the pin 
has a huge offset due to SSO and SSI (Simulaneous Switching Inputs), 
which IBIS modeling does not account for accurately, anyway.  If the 
clamp is weak, then we often find that there are no non-monotonic 
regions (until device breakdown) in which case the full effect of the 
undershoot would be modeled correctly, in your case of  -2.5 V negative 
overshoot.  I'd argue strongly that for strong negative overshoot, the 
modeling of clamp diodes in IBIS and in most HSPICE models is not up to 
the task anyway.

regards,

scott

- -- 
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com

Ingraham, Andrew wrote:

>As I've spoken my mind about this recently, I figured I should throw my
>two cents in.  I disagree that I-V points more than 800 mV beyond the
>rails are meaningless.
>
>Even though a simulator may not CONVERGE on a point that is 2V beyond
>the rails (because of stiff clamping), that doesn't mean that the
>simulator didn't TRY that point.  If the I-V data at that point in the
>model is totally out to lunch, say zero, then you wouldn't expect the
>simulator to figure out it needs to get back into a more normal
>operating region.
>
>That's one reason why I-V tables should never be truncated, even if you
>can't measure the current that far out without frying the part.  The
>data out there needs to be reasonable enough ... by extrapolation if
>need be ... to guide the simulator back toward reality.  Otherwise it
>might actually converge way out there, or may give up and abort the
>simulation.
>
>Also, there are plenty of duff SPICE models that have unusually stiff
>clamps because they forgot to include any diode resistance.  With these
>models you might never find a simulated result that is more than 800 mV
>beyond the rails, no matter how hard you try; whereas the real devices
>are not that ideal.  I have seen negative overshoot on a few devices go
>as far as about -2.5V ... although this is at the package pin, not on
>the die.  Suffice it to say that some parts clamp less well than most.
>
>Regards,
>Andy
>
>
>

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

Date: Fri, 08 Feb 2002 11:31:50 -0500
From: Peter LaFlamme <[email-masked]>
Subject: Job Opportunity, Andover, MA

Hi All,
My group is looking for a qualified person for the following position. If interested please
contact me confidentially with resume...etc. I can't say enough about the company and the work
environment. If you are looking to work with highly motivated,
success oriented people this may be what you are looking for.

Thanks,
Peter

- -- 
Peter LaFlamme

Applied Micro Circuits Corp.
Staff System Applications Engineer
200 Minuteman Rd, 3rd Floor
Andover, MA 01810

978-247-8470 phone
978-623-0055 Fax

Systems Applications Engineer - Andover REQ#1394
Seeking experienced high speed engineer to work with the Systems
Engineering and Applications teams in the development of cutting edge
chipsets. Will be responsible for: High Speed (2.5Gig) I/O simulations;
Detailed timing and interface analysis; Assist with the development of
engineering design specifications; Signal Integrity Analysis;  Interface
compatibility analysis between various components; Creation of
application notes related to these activities.

Must have: 
·       Requires BSEE/BSCS/MSEE or equivalent. 
·       Experience in Signal Integrity Analysis, HSPICE, XTK, Spectraquest
(Innoveda, Cadence design tools, or other SI evaluation tools). 
·       System level experience with High-speed backplanes, chip-to-chip
interconnect analysis. 
·       ASIC experience with selecting I/O's and simulation/validation. 
·       Expertise with LVDS, LVPECL, CML and other high-performance I/O
Technologies 

Pluses: 
·       Optical interconnects, Clock design and distribution - (i.e. PLL
design and high-speed clock distribution). 
·       Should  have working knowledge of simulation with IBIS, and SPICE
models. 
Verilog knowledge and simulation with MTI, VCS is a plus

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

Date: Fri, 08 Feb 2002 13:14:17 -0500
From: Peter LaFlamme <[email-masked]>
Subject: Sorry

I appologize for this posting. I was unaware of the rules regarding job postings on the IBIS reflector. 

Regards,
Peter 

Peter LaFlamme wrote:
> 
> Hi All,
> My group is looking for a qualified person for the following position. If interested please
> contact me confidentially with resume...etc. I can't say enough about the company and the work
> environment. If you are looking to work with highly motivated,
> success oriented people this may be what you are looking for.
> 
> Thanks,
> Peter
> 
> --
> Peter LaFlamme
> 
> Applied Micro Circuits Corp.
> Staff System Applications Engineer
> 200 Minuteman Rd, 3rd Floor
> Andover, MA 01810
> 
> 978-247-8470 phone
> 978-623-0055 Fax
> 
> Systems Applications Engineer - Andover REQ#1394
> Seeking experienced high speed engineer to work with the Systems
> Engineering and Applications teams in the development of cutting edge
> chipsets. Will be responsible for: High Speed (2.5Gig) I/O simulations;
> Detailed timing and interface analysis; Assist with the development of
> engineering design specifications; Signal Integrity Analysis;  Interface
> compatibility analysis between various components; Creation of
> application notes related to these activities.
> 
> Must have:
> ·       Requires BSEE/BSCS/MSEE or equivalent.
> ·       Experience in Signal Integrity Analysis, HSPICE, XTK, Spectraquest
> (Innoveda, Cadence design tools, or other SI evaluation tools).
> ·       System level experience with High-speed backplanes, chip-to-chip
> interconnect analysis.
> ·       ASIC experience with selecting I/O's and simulation/validation.
> ·       Expertise with LVDS, LVPECL, CML and other high-performance I/O
> Technologies
> 
> Pluses:
> ·       Optical interconnects, Clock design and distribution - (i.e. PLL
> design and high-speed clock distribution).
> ·       Should  have working knowledge of simulation with IBIS, and SPICE
> models.
> Verilog knowledge and simulation with MTI, VCS is a plus

- -- 
Peter LaFlamme

Applied Micro Circuits Corp.
Staff System Applications Engineer
200 Minuteman Rd, 3rd Floor
Andover, MA 01810

978-247-8470 phone
978-623-0055 Fax

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

Date: Wed, 13 Feb 2002 12:13:50 +0900
From: Takanobu Ura <[email-masked]>
Subject: Re: ibischk3 V3.2.8 [Warning]

Dear all,

I appreciate for all advices.
But, How should I do after all?  Should I describe the current of all 
voltage to all model? 
Or,Is the model out of which this warning does not come what does not 
need to describe the current of all voltage?

How should any really right model be?  Would you teach?

Regards,
T.Ura

Takanobu Ura wrote:
> 
> Dear all:
> 
>  I have checked our model with ibisckk3.
> 
>  As for model of xxx,The following WARNING is reported.
> 
>      WARNING -
>         Model xxx: POWER Clamp : Typical value never becomes zero
> 
>      [Power Clamp]   <- model of xxx
>         0      4.957u  5.049u  4.825u
>      -76m       5.07u  5.376u  4.918u
>     -152m      5.348u  6.904u  5.053u
>     -227m      7.611u  15.19u  6.135u
> 
>   But,As for model of yyy, The above WARNING is not reported.
> 
>      [Power Clamp]   <- model of yyy
>         0      0.557u  0.949u  0.225u
>      -76m      0.567u  0.976u  0.229u
>     -152m      0.548u  0.984u  0.253u
>     -227m      0.611u  1.190u  0.335u
> 
>   What is the reason of this difference?
>   Therefore,I have any question.
>     a/ How did you decide the limitation value as like 1uA?
>     b/ I cannot understand what this WARNING warns to us.
>        Can I ignore this WARNING?
>        Because,I think that clamp current is not surely zero.

          .....

> Dear T.Ura,
> 
> The warning is meant to alert you that the data in your clamp table
> indicates
> that the clamp never turns off, regardless of voltage.
> 
> I know that you're probably thinking that if the data in the table is
> extrapolated, then the current will stop flowing at some voltage outside of
> the table.  That is a problem, because the simulator is forced to guess the
> behavior of the device outside of the boundaries of the table.  The
> simulator might use linear extrapolation, cubic-spline extrapolation,
> quadratic, etc.  In fact, the simulator may not extrapolate at all and may
> use the first and last currents in the table for all voltages beyond the
> table (since extrapolation can result in ridiculous currents like 1e+26A).
> 
> The I-V tables are supposed to include data for all of the "interesting"
> voltages of the buffer.  The voltage at which current stops flowing is
> certainly "interesting" and should be included in the table.
> 
> Since there may exist some technology for which current never stops or to
> allow for measurement/calculation inaccuracies, IBISCHK3 will not report a
> warning if the current get very close to zero.  Very close was arbitrarily
> chosen to be within 1uA.  It seemed reasonable.
> 
> Best regards,
> Matthew Flora

                        .
                        .
                        .
                        .
                        .

> Andy,
> 
> You may be assuming that s2ibis2 users mostly know SPICE, and IBIS
> is a "second language" for them. But I am guessing that s2ibis is
> used more by people that know IBIS well, or may even know both
> quite well. Anyone who uses s2ibis2 and doesn't know IBIS fairly
> well is probably not turning out useful models. OK, maybe I just
> supported your premise :-)
> 
> But I think the majority of s2ibis2 users are IBIS model end users,
> who have to fuss with it until they get a good IBIS model. That takes
> IBIS knowledge. Also, I find that to use s2ibis2 you have to know
> a 3rd language, "C".
> 
> Mike LaBonte
> 
> "Ingraham, Andrew" wrote:
> >
> > I'm not sure precisely what s2ibis* does (since I've not used it), but I
> > believe it does just the minimum required by the IBIS spec.  Since most
> > s2ibis* users probably don't know much about IBIS, this is bound to
> > cause problems.
> >
> > Regards,
> > Andy

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

Date: Fri, 15 Feb 2002 17:24:36 -0800
From: "Peters, Stephen" <[email-masked]>
Subject: Agenda, IBIS Open Forum Teleconference 2/22

		     IBIS Open Forum Meeting Agenda
			      for 2/22/02

		 Bridge Number    Reservation #   Passcode
                 1-916-356-2663   3               1911733
                 (International Dial-in the same)

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
     - Membership Update and Treasurers Report               Fleming/Ross
     - 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 JC-16 Modeling and Testing                      Sessions
     - T10, Project 1414-DT - SCSI Signal Modeling           Barnes

     IBIS Summit Meeting DesignCon 2002 Feedback             Peters/Ross

     IBIS Summit Meeting Plans DATE 2002                     Peters/Ross

     IBIS Qualification Committee                            Katz/Peters

     IBIS Model Review Committee                             Ross

     Majordomo Update                                        Angulo

     New Administrative Issues                               All

8:45 Technical Discussion

     IBIS Version 4.0 Review                                 Peters

     Connector Proposal Report                               Peters/Ross

     IBIS Futures Group Report                               Peters/Green

     ibischk3 Status                                         Ross

      - BUG66 - Improve Truncation of Long File Name
      - BUG67 - Phantom Warnings Use Wrong Line Numbers and 
                then Disappear

     New Technical Issues                                    All

9:50 Wrap Up and Next Meetings Plans                         Peters

9:55 Sign Off

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

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