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

ibis             Thursday, August 2 2001             Volume 01 : Number 001

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

Date: Tue, 24 Jul 2001 13:51:51 -0400
From: Steve Grout <[email-masked]>
Subject: Test - Please ignore

This is a test of the new [email-masked] list. Please ignore.

- [email-masked]
- -- 
- --Steve Grout
  CAD Methodologist, Architect, Manager, Individual Contributor -
  CAD System, Database, Flows, Tools, Integration, and Support
  for both digital and Analog/Mixed-Signal.
  101 Kenneil Court
  Apex, NC 27502
  Phone: 919-303-5066
  email: [email-masked]
  http://www.flash.net/~sgrout/Personal/resume2001.txt (or doc,rtf,pdf)

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

Date: Tue, 24 Jul 2001 15:40:33 -0400
From: [email-masked]
Subject: Vod and Differential Models

- --0__=85256A930069883D8f9e8a93df938690918c85256A930069883D
Content-type: text/plain; charset=us-ascii

Hello IBIS Gurus,

I am attempting to understand the following problem.

Simulating the below differential network in HSPICE, with IBIS models for
driver and receiver, and lossless t-element t-lines, Vod is too small.
As opposed to this, simulating the same differential network in HSPICE,
with the HSPICE netlists of the driver and receiver, Vod is correct.
I am expecting to have a Vod of about 350mV.

Can anyone explain this discrepancy?

SIMULATION CONDITIONS

|\---------O=====O---------|---------------------|\
|  \            Zo = 50             \                             |  \
|    \                                      / Rterm = 100    |    \
|   /                                       \                            |
/
|/O-------O=====O---------|-------------------O|/
                Zo = 50

DRVR                                                        RCVR

SPICE TO IBIS CONDITIONS FOR OUTPUT BUFFER EXTRACTION

                    _________ + Vfix - __ GND
                    |
                   Rfix = 1MEG
                    |
|\-------------|
|  \              R1 = 50
|    \             |------------------ |  +
|   /             R2 = 50            Vos = 1.25V
|/O----------|                         |   -
                                            GND

DRVR

Thank You,
Adam Tambone

(See attached file: fin1017m.ibs)
- --0__=85256A930069883D8f9e8a93df938690918c85256A930069883D
Content-type: application/octet-stream; 
	name="fin1017m.ibs"
Content-Disposition: attachment; filename="fin1017m.ibs"
Content-transfer-encoding: base64

- --0__=85256A930069883D8f9e8a93df938690918c85256A930069883D--

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

Date: Tue, 24 Jul 2001 12:43:34 -0700
From: "Peters, Stephen" <[email-masked]>
Subject: Minutes, IBIS Teleconference Meeting 7/20

DATE: 7/24/01

SUBJECT: 7/20/01 EIA IBIS Open Forum Meeting Minutes

VOTING MEMBERS AND 2001 PARTICIPANTS LIST:
3Com (& CommWorks)             Roy Leventhal*
Ansoft Corporation             (Eric Bracken)
Apple Computer                 John Figueroa
Applied Simulation Technology  [Raj Raghuram], Norio Matsui, Fred Balistreri
Avanti                         (Chen Hongyu)
Cadence Design                 [Ian Dodd], Patrick Dos Santos, Heiko Dudek
                               Lynne Green, Lance Wang
Cisco Systems                  Syed Huq, Lungfu Chen
EMC Corporation                Brian Arsenault, Jinhua Chen
Fairchild Semiconductor        Adam Tambone
Huawei Technologies            Rachild Chen
IBM                            Michael Cohen, Greg Edlund*, Wes Martin,
                               Yeon-Chang Hahm, Bill DeVey, Pravin Patel*
Innoveda (& HyperLynx)         Guy de Burgh, John Angulo*, Cary Mandel, 
                               Matthew Flora, Steve Kaufer
Intel Corporation              Stephen Peters*, Arpad Muranyi*, Dave Lorang,
                               Michael Mirmak, Qinglun Chen, Will Hobbs,
                               Wei-hsing Huang
LSI Logic                      Larry Barnes
Mentor Graphics                Bob Ross*, Tom Dagostino, Chris Reid,
                               Mike Donnelly, Hazem Hegazy, Tony Dunbar,
                               Griff Derryberry, Dan Lake, Sherif Hammad,
                               Mohammed Korany, Weston Beal, Chris Swaim,
                               Ali Samii, Eric Ronger, Karine Loudet,
                               Daisaku Shiga, Kenji Kushima
Micron Technology              Randy Wolff*, Yong Phan*
Mitsubishi                     Pat Hefferan
Molex Incorporated             Gus Panella, Brian O'Malley
National Semiconductor         Milt Schwartz
North East Systems Associates  Edward Sayre
Philips Semiconductor          Zack Ciccone, Rob Mataheroe
Quantic EMC                    (Mike Ventham)
Signal Integrity Software      Douglas Burns, Barry Katz, Walter Katz
SiQual                         Scott McMorrow, Rob Hinz, Bernard Voss,
                               Chris Brewster
Texas Instruments              Thomas Fisher, Stephen Nolan, Ramzi Ammar,
                               Jean Claude Perrin, Moshiul Haque
Time Domain Analysis Systems   Dima Smolyansky, Steve Corey
Tyco Electronics               (Russell Moser)
Via Technologies               (Weber Chuang)
Zuken (& Incases)              John Berrie, Ralf Bruening

OTHER PARTICIPANTS IN 2001:
Actel Corporation              Silvia Montoya
Acuson                         Kim Helliwell
AMCC                           Jeff Smith
ASIS Ltd                       David Wright
Brocade Communications         Robert Badal
BMW                            Friedrich Hasinger
Cereva Networks                Bob Haller
Compaq                         [Peter LaFlamme], Ron Bellomio, Quang Dam,
                               Bill Ham
Cypress                        (Rajesh Manapat)
EADS Airbus Industry           Claude Huet
  (Aerospatiale)
EFM                            Ekkehard Miersch, Horle Raines
EIA                            Cecilia Fleming
Ericsson Radio Systems         Anders Ekholm
FCI                            Sercu Stefaan
Foundary Networks              Bertram Chan
Framatom Conectors             Danny Morlion
Fraunhofer Institute           Mariusz Faferko, Peter Kralicek
  Reliability and
  Integration
Fujitsu Ltd                    Tadashi Arai, Takeshi Murakami
Heidelberger Druchmaschinen AG Wolfgang Kleinfeldt
Hyundai Electronics            Jongho Kang
Idaho State University         Al Davis
Infineon Technologies          Christian Sporrer
Intrinsix Corporation          Steven Chin
Motorola                       (Rick Kingen)
National Institute of Applied  Etienne Sicard
  Science (INSA)
Nokia                          Tapani von Ravner, Mika Castren,
                               Janne Uusitalo
Nortel Networks                Calvin Trowell
Oak Technology                 Darmin Jin
Plexus Technology Group        Joseph Socha
Siemens (& Automotive) AG      Bernhard Unger, Helmut Katzier, Katja Koller,
                               Wolfram Meyer, Eckhard Lenski, Gerald
Bannert,
                               Burkhard Muller, Christian Marot,
                               Manfred Maurer, Amir Motamedi,
                               Hans Pichlmaier
Sigrity                        Raj Raghuram*
Sintecs                        Hans Klos
STMicroelectronics             Peter Hirt, Fabrice Boissieres
Sun                            Adrian Udenze
Toshiba Corp.                  Hirokaza Kato, Yuichi Koga, Toshio Sudo
Xilinx                         Susan Wu

In the list above, attendees at the meeting are indicated by *. Principal
members or other active members who have not attended are in parentheses.
Participants who no longer are in the organization are in square brackets.

Upcoming Meetings:  The bridge numbers for future IBIS teleconferences are
as
follows:

  Date                Bridge Number    Reservation #    Passcode
  August 10           (877) 299-1938   none             6350164    
  August 31           (916) 356-2663   2                4779396  
  Thursday, September 13, 2001 IBIS Summit Meeting, No Phone Bridge

All meetings are 8:00 AM to 9:55 AM Pacific Time.  We try to have agendas
out
7 days before each Open Forum, and meeting minutes out within 7 days after.
When you call into the meeting, ask for the IBIS Open Forum hosted by
Stephen
Peters and give the reservation number and passcode.

NOTE: "AR" = Action Required.

- -------------------------------- MINUTES
- -------------------------------------
INTRODUCTIONS AND MEETING QUORUM
Raj Raghuram, who has been involved for years with IBIS as a model developer
and as a tool developer joined Sigrity.  Sigrity is involved with power and
signal integrity simulations and uses IBIS models.  Raj stated that Sigrity
plans to become an EIA IBIS Open Forum member.

MEMBERSHIP UPDATE AND TREASURER'S REPORT
Stephen Peters reported about 28-29 members (down from 30) since there were
some payment issues.  These are being resolved.  Bob Ross reported there are
three potential members that are being processed (including Sigrity).  So we
expect about 32 members, ahead of the 30 member target from which our budget
is based.

REVIEW OF MINUTES AND AR'S
The June 01, 2001 IBIS Minutes were approved without change.

Bob Ross submitted a spelling correction for Ralf Bruening of Zuken in the
participants list for the June 21, 2001 IBIS Summit Meeting minutes.  The
Minutes were approved with this change.  Bob stated that the uploaded
minutes
have been corrected.

The ARs will be discussed during the meeting.

MISCELLANY/ANNOUNCEMENTS
Stephen Peters stated that several officers have been on vacation, but are
now
returning.  Guy de Burgh will return after July 27, 2001.

PRESS AND WEB PAGE UPDATES
Stephen Peters reported that Syed Huq made more Roster updates, did an FAQ
update (for ibischk3 source code license purchases), uploaded some IBIS
Summit
presentations, and updated the Upcoming Events link.

NEW MODELS AVAILABLE, LIBRARY UPDATE
Stephen Peters stated that Roy Leventhal provided more updates as of 6/26/01
on the IBIS Models link.

Bob Ross reported that Mindspeed Technologies (a Conexant Business) has IBIS

Models under (URL split into two lines to avoid mailer truncation):

 http://web2.mindspeed.com/default.sph/SaServletEngine.class/Web/products/
      documents.jsp?doc_type=27

OPENS FOR NEW ISSUES
None.

INTERNATIONAL/EXTERNAL PROGRESS
- - IEC 62014-1 (IBIS Version 3.2) - No report.  Bob Ross stated that the
  document is probably still in prepublication status.

- - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits
  (IMIC) - Bob Ross still cannot find the new link to the IMIC document.  

- - IEC 62014-3 (ICEM) Integrated Circuit Electromagnetic Model Proposal
  (formerly, IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross stated that 
  Etienne Sicard plans to present work at the September 13, 2001 IBIS Summit
  meeting.  This will be discussed later in the meeting.

- - JEDEC JC-16 - Modeling and Testing - No report.

- - T10, Project 1414-DT - SCSI Signal Modeling (a Technical Committee of the
  National Committee for Information Technology (NCITS)) - No report.

DESIGN AUTOMATION CONFERENCE 2001 IBIS SUMMIT MEETING FEEDBACK
Stephen Peters enjoyed the meeting.  However, he felt that we did not have
as
many questions and interactions as in some other meetings and is looking for
suggestions for more interactions.  He expected more questions on IBIS-X.
Arpad Muranyi reported that some people discussed things after the meeting, 
but he did not think there was an IBIS-X parser demonstration offered by Al
Davis.  Several people had to catch plane connections after the meeting.

Bob Ross stated that we had more presentations than expected and had to
limit
questions to keep the meeting going.  We did not have copies of all slides
available at the meeting.  The presentations are all now uploaded under:

  http://www.eda.org/pub/ibis/summits/jun01/

PCB CONFERENCE EAST 2001 IBIS SUMMIT MEETING PLANS
Bob Ross reported that an IBIS Summit Meeting is planned all day on
Thursday, 
September 13, 2001 in Worcester, Massachusetts at the Crowne Plaza Hotel
near
the PCB Conference East 2001 show.  The meeting follows on the next day the
trade show portion of the show.  The Upcoming events link of the IBIS Home
page already contains the sign-up information and hotel information.  A free
lunch and refreshments are included.

Kathy Breda of NESA has been handling the arrangements and signups.  She
will
also coordinate making copies of presentations for the meeting.  Bob stated
that we need to address the funding issue.  In the past the EDA vendors have
shared the meeting expenses.

So far Bob expects these presentations (titles may change):

  "Modeling the Radiated Emission of Micro-controllers", Etienne Sicard,
    National Institute of Applied Science (INSA) in France
  "A Proposal for s2ibis3", Michael Steer, North Carolina State University
  
  Plus IBIS Version 4.0, IBIS-X and IBIS Connector Specification Progress

Bob indicated that the IBIS Futures Working Group had discussed
demonstrating
the IBIS-X parser at the Summit meeting.  This follows up on Stephen Peters
comment to make the meeting have more interactive and promote more questions
and discussions.

Bob plans that the first announcement will be sent next week.

NORTH CAROLINA STATE UNIVERSITY S2IBIS3 PROJECT
Stephen Peters reported that he and Michael Steer of North Carolina State
University (NCSU) have made recent contact.  NCSU is working on a cell
design
project under a DARPA contract and is now interested in using IBIS.  Michael
is interested in developing s2ibis3 as part of this research.  His team
would
be interested in using the ibischk3 as a basis, but Stephen stated that NCSU
would have to pay for the source code.  NCSU will probably develop their
own parser independently.

Bob Ross mentioned that NCSU would release s2ibis3 source code and
executables
under a GPL (GNU public license).  Michael Steer is scheduled to discuss the
project at the September 13, 2001 IBIS Summit Meeting.

IBIS MODEL REVIEW COMMITTEE DISCUSSION
John Angulo sent out a model from STMicroelectronics for review.  John also
has two other models that are being processed prior to being distributed.

John stated that he cannot continue heading the IBIS Model Review Committee
because of work commitments.  He suggested several other people.  Stephen
Peters will work offline to find a replacement.

MAJORDOMO AND SPAM MAIL UPDATE
Stephen Peters reported that there seems to be more spam messages on the
IBIS
reflectors.  Possibly someone is harvesting names off the mailing list
(which
is protected) or off of e-mail correspondence.  One solution is to control
the
messages from a list server such as Majordomo.  Using Majordomo, only folks
that
have subscribed and have known valid e-mail addresses could post to the IBIS
reflectors, thus cutting down on SPAM to the list.

John Angulo is still working with the eda.org systems administrators on
using
Majordomo.  John would want to set up a test reflector before we actually
make the change.  There might be more restrictive access.  John also noted
that some of the spam messages have been sent to the ibis-request and
ibis-info addresses.

CONNECTOR PROPOSAL REVIEW
The Working Group has been meet on June 12, July 3, and July 10, 2001.  The
attendance was down because of vacations.  Stephen Peters summarized that
work
is continuing on reviewing the Connector Specification to align it with the
IBIS document and also with some IBIS-X conventions.  This work is
proceeding
more slowly than expected.

Some recent topics include uncoupled and coupled lines, the transmission
line
syntax and frequency dependent matrices.

Bob Ross stated that more people are now involved.  Some earlier decisions
are
subject to review.  The original choices included focusing on connector only
issues versus trying to make this a combined package/connector model
document,
and postponing lossy matrices.  Arpad Muranyi stated that it might not be
difficult to put in frequency dependent matrices.  Bob agreed and stated
that
the earlier consensus continues to implement losses based on matrices as a
function of frequency.  This is a superset of just assuming skin effect and
conductance matrix relationships.

Stephen stated that he preferred using the matrix approach as implemented in
the document and wanted to proceed in a rapid manner to get the Connector
Specification approved by the end of the year.  It has been under
development
for several years.

The next meeting is scheduled on July 24, 2001, and they should continue on
a
weekly basis.

IBIS FUTURES (IBIS-X, API, BIRDxx)
Stephen Peters summarized the progress based on meetings on June 12, July 3,
10 and 17, 2001.  The discussions included the basic elements, some
transmission line syntax (similar to the Connector Specification), LRC
matrix issues and the Laplace element.  John Angulo added that the syntax
for
controlled sources was discussed at the last meeting.

Stephen stated that Scott McMorrow has issued comments on the Connector 
Specification and now is providing good comments on the IBIS futures
documents.

Work is continuing and the next meeting is scheduled for July 24, 2001.
These
should continue on a weekly basis.

BIRD70.3 - GOLDEN WAVEFORMS
Greg Edlund indicated that he put out several messages on the IBIS reflector
in response to comments made at previous meetings.  He got one positive
comment back.

Bob Ross stated that vacations and other IBIS activities prevented him from
looking at BIRD70.3 and Greg's comments until now.  He summarized his
response
as follows:

  He agrees with Issue 1 that a new [Test Data] subparameter
Driver_model_inv
  should be added to support unsymmetrical differential drivers.

  He suggests that [Test Load] should add the subparamater
Receiver_model_inv
  for completeness and to support unsymmetrical receivers with internal 
  terminations.

  Bob noted that the [Test Load] subparameter Test_load_type was incorrectly
  entered as "Test_data_type" in some portions of BIRD70.3.

  Bob agreed with Greg's proposed Issue 2 restriction that only these
  combinations of Test_data_type and Test_load_type would be supported:

     Single_ended, Single_ended
     Differential, Differential

  While the combination Differential, Single_ended is also possible, it is
  not necessary since the Single_ended test load can be created with default
  large values of Rdiff*.  The rules need to be stated for the Single_ended
  case how to interpret the differential golden waveforms [Diff ...] and the
  Rdiff* and *_inv parameters.  Bob proposed that should be ignored.  The
  parser probably would accept the model, but issue an Warning message.

  Finally the single_ended golden waveforms given for Test_data_type
  Differential should be for the non-inverting side of the net when *-inv
  models are used.  The inverting golden waveform data can be obtained by a
  separate test, but with the inverting and non-inverting models
interchanged.
  If the differential network is symmetrical, this is not an issue since the
  inverting and non-inverting models are the same.

Bob plans to respond on the reflector to Greg's e-mail to capture these
points.  Greg should review this and issue BIRD70.4 in time for a vote at
the
next IBIS Meeting.  

AR - Bob Ross respond to Greg Edlunds comments.  Greg issue BIRD70.4 by July
27, 2001 so that it can be presented for a vote at the next IBIS Meeting.

BIRD71 - TIMING TEST LOADS IN [Model Spec] TO SUPPORT PCI & PCI-X
Stephen Peters stated that there have not been any reflector comments on
BIRD71.  BIRD71 completes the list of [Model Spec] subparameters in a manner
that supports PCI and PCI-X specifications.  There have been some concerns
on
how EDA tools should use the new information.

Bob Ross stated that he had questions because some of the new specification
subparameters interacted with the model data itself.  The loads, for example
may be different for the min and max corners.  This does not relate to how
a physical part is specified or measured since the measurement is set up
independent of the electrical characteristics of the component.  So there
may
be some ambiguity on how EDA tools are to process the new subparameters.

One suggestion is that the new subparameters is related to the actual model
corners and are used to set up best and worst cases.  Bob had suggested that
there might be some discussion about on this in BIRD71.  He did not have
specific suggestions.  Bob favors adding the subparameters per BIRD71 and
letting the EDA tools decide how to process the new information.  He will
communicate any new ideas, if any, by next week.

Stephen proposed that BIRD71 be scheduled for a vote at the next meeting.

OTHER PENDING BIRDS
Stephen Peters stated that he wanted IBIS Version 4.0 to be finished soon
and
voted by the end of the year.  Votes are planned for BIRD70.4 and BIRD71.
All
other pending BIRDs need to be issued or deferred until IBIS-X.

Bob stated that the SSO improvement proposal is pending, but might be
deferred
to IBIS-X where structural interactions could be programmed.  This
improvement
may not work in all cases and may open up some technical issues.  A fallback
submodel BIRD is needed for some existing technologies needs to be generated
if it is to be considered.  Bob also stated that a clarification BIRD for
Series Switch models is being developed by Tom Dagostino (following up on
the
Ad Hoc presentation at the June 21, 2001 IBIS Summit Meeting).  This pending
BIRD will make the discussion more general, but will not propose any syntax
change.

IBISCHK3 BUG TRACKING
- - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail
  Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or
  the [Pullup] table contains non-monotonic data in the clamping regions,
and
  there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an
  incorrect Error message.  

  The non-monotonic data itself causes ibischk3 to calculate the wrong
  endpoint values because the algorithm probably has numerical difficulties.
  It probably starts its convergence calculation at one end of the table
  rather than from the middle and gets numerically confused with the
  non-monotonic data.

  Even though the model is non-monotonic, it may represent real data.  Some
  EDA tools will correctly process the model.  However, the recently
  implemented Waveform endpoint tests now report an Error instead of a
  Warning, preventing the model to be processed in systems that uses
ibischk3
  for input model parsing.

  Bob suggested classifying BUG57 as Annoying, Low, and Open.

  The problem is how to resolve BUG57.  The choices are (1) fix the test,
(2)
  change the Error back to a Warning, or (3) ignore this problem and force
the
  user to modify the IBIS file.

  Bob suggested that we work on (1) as a low priority activity.  If the fix
is
  too difficult, then we might consider (3).  No one wanted (2).  Stephen
  Peters suggested that a note could be added to the Warning or Error
message
  to alert the user of a possible reason for the Error Message so that the
  user could modify the model.  Bob suggested that because this is a low
  priority bug, it should be investigated after all the other open bugs are
  fixed.  Then we can decide how to proceed.

END OF MEETING TOPIC
Roy Leventhal stated that he talked about signal integrity and IBIS at a 
recent IPC Design Learning Symposium meeting.  He will track their activity.

NEXT MEETING:
The next teleconference meeting will be on Friday, August 10, 2001, from 
8:00 AM to 10:00 AM.  BIRD70.4 and BIRD71 are scheduled for a vote.
============================================================================
==
                                      NOTES

IBIS CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-1831
            [email-masked]
            Senior Hardware Engineer, Intel Corporation
            M/S JF4-215
            2111 NE 25th Ave.
            Hillsboro, OR 97124-5961

VICE CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897
            [email-masked]
            Modeling Engineer, Mentor Graphics
            8005 S.W. Boeckman Road, Wilsonville, OR 97070

SECRETARY:  Guy de Burgh (805) 988-8250, Fax: (805) 988-8259
            [email-masked]
            Senior Manager, Innoveda
            1369 Del Norte Rd.
            Camarillo, CA 93010-8437

LIBRARIAN:  Roy Leventhal (837) 797-2152, Fax: (847) 222-2799
            [email-masked]
            Senior Engineer, CommWorks Corp. (a wholly owned 3Com
subsidiary)
            1800 W. Central Rd.
            Mt. Prospect, IL 60056-2293

WEBMASTER:  Syed Huq (408) 525-3399, Fax: (408) 526-5504
            [email-masked]
            Manager, Hardware Engineering, Cisco Systems
            170 West Tasman Drive
            San Jose, CA 95134-1706

POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008
            [email-masked]
            Development Engineer, Innoveda
            14715 N.E. 95th Street, Suite 200
            Redmond, WA 98052

This meeting was conducted in accordance with the EIA Legal Guides and EIA
Manual of Organization and Procedure.

The following e-mail addresses are used:

  [email-masked]
      To join, change, or drop from either the IBIS Open Forum Reflector
      ([email-masked]), the IBIS Users' Group Reflector ([email-masked])
      or both.  State your request.

  [email-masked]
      To obtain general information about IBIS, to ask specific questions
      for individual response, and to inquire about joining the EIA-IBIS
      Open Forum as a full Member.

  [email-masked]
      To send a message to the general IBIS Open Forum Reflector.  This
      is used mostly for IBIS Standardization business and future IBIS
      technical enhancements.  Job posting information is not permitted.

  [email-masked]
      To send a message to the IBIS Users' Group Reflector.  This is
      used mostly for IBIS clarification, current modeling issues, and
      general user concerns.  Job posting information is not permitted.

  [email-masked]
      To report ibischk2/3 parser bugs.  The Bug Report Form Resides on
      eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported
bugs.

      To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms
      which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt,
      /pub/ibis/bugs/s2ibis2/bugs2i2.txt, &
/pub/ibis/bugs/s2iplt/bugsplt.txt
      respectively.

Information on IBIS technical contents, IBIS participants, and actual
IBIS models are available on the IBIS Home page found by selecting the
Electronic Information Group under:

  http://www.eigroup.org/ibis/ibis.htm

Check the pub/ibis directory on eda.org for more information on previous
discussions and results.  You can get on via FTP anonymous.
============================================================================
==

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

Date: Wed, 25 Jul 2001 09:13:30 +0800
From: "LiuWeidong" <[email-masked]>
Subject: Re: Minutes, IBIS Teleconference Meeting 7/20

For the message bellow, 
" Even though the model is non-monotonic, it may represent real data"
" (3) ignore this problem and force  the   user to modify the IBIS file."
" Bob suggested that we work on (1) as a low priority activity.  If the fix  is   too difficult, then we might consider (3).  No one wanted (2).  "

I want to ask:
It seems that a  good model maybe is non-monotonic(right or wrong ?),Then how can we modefy the IBIS file ?

Thanks,
regards,
LiuWeidong

- ----- Original Message ----- > 
> 
> IBISCHK3 BUG TRACKING
> - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail
>   Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or
>   the [Pullup] table contains non-monotonic data in the clamping regions,
> and
>   there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an
>   incorrect Error message.  
> 
>   The non-monotonic data itself causes ibischk3 to calculate the wrong
>   endpoint values because the algorithm probably has numerical difficulties.
>   It probably starts its convergence calculation at one end of the table
>   rather than from the middle and gets numerically confused with the
>   non-monotonic data.
> 
>   Even though the model is non-monotonic, it may represent real data.  Some
>   EDA tools will correctly process the model.  However, the recently
>   implemented Waveform endpoint tests now report an Error instead of a
>   Warning, preventing the model to be processed in systems that uses
> ibischk3
>   for input model parsing.
> 
>   Bob suggested classifying BUG57 as Annoying, Low, and Open.
> 
>   The problem is how to resolve BUG57.  The choices are (1) fix the test,
> (2)
>   change the Error back to a Warning, or (3) ignore this problem and force
> the
>   user to modify the IBIS file.
> 
>   Bob suggested that we work on (1) as a low priority activity.  If the fix
> is
>   too difficult, then we might consider (3).  No one wanted (2).  Stephen
>   Peters suggested that a note could be added to the Warning or Error
> message
>   to alert the user of a possible reason for the Error Message so that the
>   user could modify the model.  Bob suggested that because this is a low
>   priority bug, it should be investigated after all the other open bugs are
>   fixed.  Then we can decide how to proceed.
> 
> 

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

Date: Wed, 25 Jul 2001 08:50:11 -0500
From: "Gregory R Edlund" <[email-masked]>
Subject: Re: about the IBIS "checklist.txt."

Dear LiuWeidong,

Please see my answers below your questions.  I hope this helps you.

Greg Edlund
Electrical Packaging
IBM Server Technology Development
3605 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
[email-masked]

"LiuWeidong" <[email-masked]> on 07/23/2001 08:38:09 PM

To:   Gregory R Edlund/Rochester/IBM@IBMUS
cc:   <[email-masked]>, <[email-masked]>
Subject:  about  the  IBIS  "checklist.txt."

Hello, Greg
I have some questions about your IBIS Datasheet Checklist :

"3. Has the modeling engineer performed a visual inspection of IV and  VT
curves to screen for non-monotonicity, discontinuities, and other obvious
errors?"
If a IV curves is non-monotonicity,How can  I deal with it ? Can the model
be used by the simulation tools?
There are so many  IBIS models provided by IC venders whose IV curves is
non-monotonicity  .

[GREG]  Non-monotonicity can be OK in some circumstances.  Page 20 of the
IBIS Cookbook shows an example of a pull-down curve that becomes
non-monotonic after you subtract out the ground clamp current (I believe
this is a numerical effect).  Once you add the two curves back together,
the composite becomes monotonic again, so this is OK.  In other
circumstances non-monotonicity may be indicative of a circuit feature such
as bus hold, which uses a feedback circuit.  This can make the simulator
fail, so I usually smooth out the non-monotonicity in the IV curve of a
circuit that has bus hold.  The point is that you need to know what's
causing the non-monotonicity.  Your IBIS vendor should do this for you.

"8. Does the output reach Vmeas under standard load conditions for   rising
and falling waveforms?"
For this item , I don't think it should be in the IBIS Datasheet Checklist
, Whether the output can reach Vmeas under standard load conditions for
rising   and falling waveforms mainly depend on the output buffer's driving
capability . If a  buffer's driving  capability is very weak, the output
maybe can't  reach Vmeas under standard load conditions for   rising   and
falling waveforms,but you can't think the IBIS model is wrong.

[GREG]  Vmeas comes from the component datasheet, and so the output better
be able to drive it's own standard load.  If it can't, there's something
seriously wrong with the circuit design.  If the behavioral simulations
using the IBIS file don't reach Vmeas with the standard load but the real
component DOES, then something went wrong during the creation of the IBIS
file.

Hope for your reply!
Thanks!
LiuWeidong

- ----- Original Message -----
From: Gregory R Edlund <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 24, 2001 8:53 PM
Subject: Re: Clarification needed.

>
> Anbazhagan,
>
> Looks like you're on the right track.  I would recommend your ASIC vendor
> read the "IBIS Cookbook," which can be found on the IBIS web page:
> http://www.eigroup.org/ibis/tools.htm
>
> As part of the "I/O Buffer Accuracy Handbook" (also available on the IBIS
> web page), we published a checklist that should help you.  This list was
> compiled from suggestions by members of the SI community who have
> experience with IBIS.  I am attaching the most recent version of this
list.
>
> Bob, Could you please post this list as an ASCII text file under
Accuracy?
> Pleas name it "checklist.txt."  Thanks.
>
>
> IBIS Datasheet Checklist                                  version 1.1,
> 05/07/01
> ------------------------
>
>
> IBIS datasheet:
> Component manufacturer:
> Component part number:
> Engineer verifying this component:
> Email address:
> Behavioral simulator and version:
> Date:
>
>
> Note:   If answer is N or N/A, provide explanation.
>         The user may verify items 1-9 but is unable to verify items 10-20
>         because the data involved are only available to the semiconductor
>         vendor.
>
>
> ___  1. Does the IBIS datasheet pass the IBIS syntax checker?
>         (Note: Some models generate warnings for non-monotonicities that
> are
>         actually part of the characteristics of the device. Other non-
>         monotonicities are so small as to be irrelevant.)
>
> ___  2. Is an "I/O Buffer Accuracy Report" available for this component?
>         (http://www.vhdl.org/pub/ibis/accuracy)
>
> ___  3. Has the modeling engineer performed a visual inspection of IV and
> VT
>         curves to screen for non-monotonicity, discontinuities, and other
>         obvious errors?
>
> ___  4. Has the modeling engineer tested the IBIS datasheet using a
> behavioral
>         simulator?
>
> ___  5. Do MIN and MAX data exist for all keywords and sub-parameters?
>
> ___  6. Does the IBIS datasheet include all four 50 Ohm VT tables as
> described
>         in the IBIS Cookbook?
>
> ___  7. Do the keywords Cref, Rref, Vref, and Vmeas match the values
> specified
>         in the component datasheet for all output and bidirectional
models?
>
> ___  8. Does the output reach Vmeas under standard load conditions for
> rising
>         and falling waveforms?
>
> ___  9. Does the pin table match the component datasheet?
>
>
> ___ 10. Do the keywords Vihl and Vinh represent the unity gain points
> derived
>         from the dc transfer characteristics for all inputs?
>
> ___ 11. Has the modeling engineer verified the accuracy of the C_comp
>         subparameter?
>
> ___ 12. Has the modeling engineer verified the accuracy of the R_pkg,
> L_pkg,
>         and C_pkg subparameters?
>
> ___ 13. For CMOS logic, do all MAX data represent maximum voltage,
minimum
>         temperature, and fast process?
>
> ___ 14. For CMOS logic, do all MIN data represent minimum voltage,
maximum
>         temperature, and slow process?
>
> ___ 15. For bipolar logic, do all MAX data represent maximum voltage,
> maximum
>         temperature, and fast process?
>
> ___ 16. For bipolar logic, do all MIN data represent minimum voltage,
> minimum
>         temperature, and slow process?
>
> ___ 17. Do the keywords dV/dt_r and dV/dt_f contain the correct 20%-80%
> edge
>         rate data measured using a 50 & load as specified in IBIS?
>
> ___ 18. If the I/O buffer employs dynamic clamping, does the IBIS
datasheet
>         contain the appropriate keywords and subparameters?
>
> ___ 19. If the I/O buffer employs a multi-stage driver, does the IBIS
> datasheet
>         contain the appropriate keywords and subparameters?
>
> ___ 20. If the I/O buffer design employs dynamic edge rate control,
dynamic
>         impedance control, or any form of feedback, has the modeling
> engineer
>         assessed the impact of this circuitry on behavioral model
accuracy?
>
>
> Greg Edlund
> Electrical Packaging
> IBM Server Technology Development
> 3605 Hwy. 52 N, Dept. HDC
> Rochester, MN 55901
> [email-masked]
>
>
> [email-masked] on 05/24/2001 01:48:13 AM
>
> To:   "[email-masked]":
> cc:
> Subject:  Clarification needed.
>
>
>
> Hello Users,
>
>         I am using XTK to simulate a PCBA. The board has a 100pin ASIC.
In
> order to model the ASIC properly I need the IBIS model of the ASIC which
I
> can convert it to XTK format. Now if I directly request for an IBIS model
> the vendor may hesistate. So I am requesting the following data from the
> vendor with which I can create a IBIS model. Below is the data I am
> requesting them. Is it OK. Does it cover everything necessary to create a
> proper IBIS model?. The ASIC does not have any clamp diodes. Please
reply.
> The following data whichever is applicable for each pin of the ASIC are
> needed
>  1. Package parasitics namely, the Resistance, capacitance and
Inductance.
> Typical, max, min values required.
>
> 2. Die capacitance as seen at the die pad. Typical, max, min values
> required
>
> 3. Output impedance of the I/O buffers. Typical, max, min values
required.
>
> 4. Rise time and fall time values (dv/dt typical, max, min) of buffers
> excluding the effect of packaging but including the effect of die
> capacitance. Load conditions required.
>
> 6. Rising edge and falling edge waveforms (Voltage vs. time curve with
the
> voltage values having typical, max, min values) of the driver along with
> the test conditions.
>
> 5. V/I characteristics of Pull up and Pull down resistor, if present,
when
> the buffer is driven high and low respectively. The voltage sweep must be
> from ?3.3V to +6.6V. Current measurement with typical, max, min values
are
> required.
>
> Thanks,
>
> Anbazhagan.
>
>
>
>
>
>

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

Date: Wed, 25 Jul 2001 09:07:10 -0700
From: Lynne Green <[email-masked]>
Subject: Re: Minutes, IBIS Teleconference Meeting 7/20

The EDA tools have to be able to use these models, which means the models
must pass the parser.

A smart user will send the model back to the person who made it, to verify
whether the non-monotonicity is "real", before proceeding with simulation.

- - Lynne

At 09:13 AM 7/25/2001 +0800, LiuWeidong wrote:
>For the message bellow,
>" Even though the model is non-monotonic, it may represent real data"
>" (3) ignore this problem and force  the   user to modify the IBIS file."
>" Bob suggested that we work on (1) as a low priority activity.  If the 
>fix  is   too difficult, then we might consider (3).  No one wanted (2).  "
>
>I want to ask:
>It seems that a  good model maybe is non-monotonic(right or wrong ?),Then 
>how can we modefy the IBIS file ?
>
>Thanks,
>regards,
>LiuWeidong
>
>----- Original Message ----- >
> >
> > IBISCHK3 BUG TRACKING
> > - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail
> >   Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or
> >   the [Pullup] table contains non-monotonic data in the clamping regions,
> > and
> >   there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an
> >   incorrect Error message.
> >
> >   The non-monotonic data itself causes ibischk3 to calculate the wrong
> >   endpoint values because the algorithm probably has numerical 
> difficulties.
> >   It probably starts its convergence calculation at one end of the table
> >   rather than from the middle and gets numerically confused with the
> >   non-monotonic data.
> >
> >   Even though the model is non-monotonic, it may represent real data.  Some
> >   EDA tools will correctly process the model.  However, the recently
> >   implemented Waveform endpoint tests now report an Error instead of a
> >   Warning, preventing the model to be processed in systems that uses
> > ibischk3
> >   for input model parsing.
> >
> >   Bob suggested classifying BUG57 as Annoying, Low, and Open.
> >
> >   The problem is how to resolve BUG57.  The choices are (1) fix the test,
> > (2)
> >   change the Error back to a Warning, or (3) ignore this problem and force
> > the
> >   user to modify the IBIS file.
> >
> >   Bob suggested that we work on (1) as a low priority activity.  If the fix
> > is
> >   too difficult, then we might consider (3).  No one wanted (2).  Stephen
> >   Peters suggested that a note could be added to the Warning or Error
> > message
> >   to alert the user of a possible reason for the Error Message so that the
> >   user could modify the model.  Bob suggested that because this is a low
> >   priority bug, it should be investigated after all the other open bugs are
> >   fixed.  Then we can decide how to proceed.
> >
> >

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

Date: Wed, 25 Jul 2001 13:55:24 -0700
From: Bob Ross <[email-masked]>
Subject: IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20

Hello LiuWeidong and Lynne:

Let me clarify that the problem in bug57 is
not the non-monotonic behavior itself.  The
issue is that the waveform endpoint test
incorrectly fails.  The waveform endpoints
are actually correct, the the non-monotonic
behavior described in bug57 causes the parser
itself to not find the correct endpoints.  This
causes the model to fail because we recently
changed the endpoint test (bug47) to issue
an Error when the mismatch is greater than 10%.

So a good model may be rejected because of
the ibischk3 bug.  The region where the
failure occurs however, is not critical
(e.g., in an extended clamping region where
no current could possibly flow anyway.  The
easy (3) fix is just to change the current in
that region to be monontonic.  This type of
change would be on a case-by-case basis
based on where the problem is.

I suspect that the parser problem is based
an algorithm that starts at one end of a
table to find a solution.  If the algorithm
started at the middle to find the solution,
this would be less of a problem.

See bug57 for a test case and more information:

  http://www.eda.org/pub/ibis/bugs/ibischk/bug57

Bob Ross
Mentor Graphics

Lynne Green wrote:
> 
> The EDA tools have to be able to use these models, which means the models
> must pass the parser.
> 
> A smart user will send the model back to the person who made it, to verify
> whether the non-monotonicity is "real", before proceeding with simulation.
> 
> - Lynne
> 
> At 09:13 AM 7/25/2001 +0800, LiuWeidong wrote:
> >For the message bellow,
> >" Even though the model is non-monotonic, it may represent real data"
> >" (3) ignore this problem and force  the   user to modify the IBIS file."
> >" Bob suggested that we work on (1) as a low priority activity.  If the
> >fix  is   too difficult, then we might consider (3).  No one wanted (2).  "
> >
> >I want to ask:
> >It seems that a  good model maybe is non-monotonic(right or wrong ?),Then
> >how can we modefy the IBIS file ?
> >
> >Thanks,
> >regards,
> >LiuWeidong
> >
> >----- Original Message ----- >
> > >
> > > IBISCHK3 BUG TRACKING
> > > - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail
> > >   Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or
> > >   the [Pullup] table contains non-monotonic data in the clamping regions,
> > > and
> > >   there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an
> > >   incorrect Error message.
> > >
> > >   The non-monotonic data itself causes ibischk3 to calculate the wrong
> > >   endpoint values because the algorithm probably has numerical
> > difficulties.
> > >   It probably starts its convergence calculation at one end of the table
> > >   rather than from the middle and gets numerically confused with the
> > >   non-monotonic data.
> > >
> > >   Even though the model is non-monotonic, it may represent real data.  Some
> > >   EDA tools will correctly process the model.  However, the recently
> > >   implemented Waveform endpoint tests now report an Error instead of a
> > >   Warning, preventing the model to be processed in systems that uses
> > > ibischk3
> > >   for input model parsing.
> > >
> > >   Bob suggested classifying BUG57 as Annoying, Low, and Open.
> > >
> > >   The problem is how to resolve BUG57.  The choices are (1) fix the test,
> > > (2)
> > >   change the Error back to a Warning, or (3) ignore this problem and force
> > > the
> > >   user to modify the IBIS file.
> > >
> > >   Bob suggested that we work on (1) as a low priority activity.  If the fix
> > > is
> > >   too difficult, then we might consider (3).  No one wanted (2).  Stephen
> > >   Peters suggested that a note could be added to the Warning or Error
> > > message
> > >   to alert the user of a possible reason for the Error Message so that the
> > >   user could modify the model.  Bob suggested that because this is a low
> > >   priority bug, it should be investigated after all the other open bugs are
> > >   fixed.  Then we can decide how to proceed.
> > >
> > >

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

Date: Thu, 26 Jul 2001 14:04:16 -0700
From: Bob Ross <[email-masked]>
Subject: IBIS Summit Meeting First Announcement 9/13/01

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- -------------------------------------------------------
IBIS SUMMIT 
	FIRST CALL FOR 
		PARTICIPATION, 
			PRESENTATIONS 
				& SPONSORSHIP!!!!
- -------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

Location:       The Crowne Plaza Hotel
                10 Lincoln Square
                Worcester, MA
                Tel:  (508) 791-1600
                Fax:  (508) 791-1796
               
Content:        Presentations and Discussions

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

Sponsors:       North East Systems Associates, Inc. (NESA),
                IBIS Users Group
                Others to be determined
                WE ARE LOOKING FOR ADDITIONAL SPONSORS!
                  (contact Kathy Breda, [email-masked]
                  or Bob Ross, [email-masked])

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

BACKGROUND

The IBIS Users Group (IBIS East) has been formed under the leadership of  
Dr. Edward Sayre from North East Systems Associates, Inc. (NESA) and has
been meeting to consider and forward IBIS model user concerns.  As a result
of East coast meetings, the group has developed an IBIS Accuracy Handbook
document and has initiated the project to format Connector Models.  These
topics plus others of current interest to the EIA IBIS Open Forum will be
discussed at this meeting.

This meeting will be conducted as a formal IBIS Summit Meeting.  Presentation
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:

  Kathy Breda ([email-masked])

CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have IBIS experiences
or 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.  Electronic presentations
                         should be made available by September 7, 2001.
                         Otherwise the presenter will be expected to provide
                         up to 50 copies for distribution.

If you plan a presentation, please supply

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

  Estimate Time:

Send this to:

  Kathy Breda ([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.  So far the following presentatation is planned:
  
  "A Proposal for s2ibis3", Michael Steer, North Carolina State University

  "Modeling the Radiated Emission of Micro-controllers", Etienne Sicard,
  National Institute of Applied Science (INSA/DEIG), France

  Plus IBIS Macro Language and demonstration, IBIS Connector Specification,
  and other IBIS issues.

LIST OF NEARBY HOTELS

See http://www.pcbeast.com for travel directions, hotels and other
information.

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

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

Date: Thu, 26 Jul 2001 17:42:21 -0700
From: Bob Ross <[email-masked]>
Subject: IBIS BIRD72 - Accommodating PMOS and NMOS//PMOS Series FET Models

This is a multi-part message in MIME format.
- --------------BE319BEDA54C34BC8D533340
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To IBIS Committee:

Attached is BIRD72 submitted by Tom Dagostino of Mentor Graphics.

Bob Ross
Mentor Graphics
- --------------BE319BEDA54C34BC8D533340
Content-Type: text/plain; charset=us-ascii;
 name="BIRD72.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="BIRD72.txt"

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

BIRD ID#:        72
ISSUE TITLE:     Accommodating PMOS and NMOS//PMOS Series FET Models
REQUESTER:       Tom Dagostino, Mentor Graphics
DATE SUBMITTED:  July 26, 2001
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

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

STATEMENT OF THE ISSUE:

The IBIS FET Bus Switch model assumes a series NMOS FET which has its gate
tied to Vdd.  We have come across two other topologies for the FET switches,
specifically: 

1. What appears to be a PMOS device with it's gate tied to ground 
2. Parallel NMOS and PMOS devices with gates respectively tied to Vdd and
   ground.

The IBIS Golden Parser produces warnings and errors with models that describe
this behavior.

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

These models cause issues with the IBIS Golden Parser and, depending on
assumptions in the simulator's implementations that support the bus switch,
analysis issues.  

For the single PMOS case:

The parser is set up to see increasing current as Vgs increase where Vgs is
defined as Vcc - Vsource.  Given this definition for Vgs the current Id will
decrease as 'Vgs' increases for the PMOS device with its gate to ground.  The
parser gives an error of decreasing current as 'Vgs' increases.

Simulators may make the assumption the FET is a NMOS device and may not handle
the characteristics properly if the model gets parsed in.

For the dual PMOS/NMOS case:

In the case of the dual PMOS/NMOS topology the currents through the parallel
FET's will sum and produce an Id curve that: 

- -- starts with significant current at 'Vgs' = 0 (current is flowing through
the PMOS device)

- -- decreases by 10 to 90% at about 40% of 'Vgs' range where both the PMOS and
NMOS devices are both on  

- -- increases to a larger value at 'Vgs' = Vdd than at 'Vgs" = 0.  This is
where the NMOS device is fully on

This characteristic has been observed in several devices.  This will cause a
non-monotonic warning from the parser.

It is not known how all simulators will handle this non-monotonic behavior.
 
In general the simulators should be able to handle these characteristics.
The IV curves define the device's characteristics and the simulator should
just work with that definition.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

The following changes are proposed:

The definition of Voltage in the IV table changes.  Vgs has been Vcc - Vsource
assuming the gate was tied to Vcc.  IBIS should now assume the voltage in the
IV table is really Vcc minus the FET's source voltage (Voltage = Vcc -
Vsource).  This makes old models compatible and no change in the model format
is required.

Decreasing current vs. Voltage are allowed.

Non-monotonic currents in the table are expected in the parallel case but
warnings can still be issued.  It may be useful to have the modeler note the
type of switch in the model so the user can better understand any
non-monotonic issues.  

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

Changes and additions to the IBIS Specification are shown by the |* lines

|=============================================================================
|     Keyword:  [Series MOSFET]
|    Required:  Yes, for series MOSFET switches
| Description:  The data points under this keyword define the I-V tables for
|               voltages measured at Pin 2 for a given Vds setting.  Currents 
|               are considered positive if they flow into Pin 1.  Pins 1 and 
|               2 are listed under the [Series Pin Mapping] keyword under
|               [Series Pin Mapping] and pin_2 columns, respectively.
|  Sub-Params:  Vds
| Usage Rules:  The first column contains the voltage value, and the three
|               remaining columns hold the typical, minimum, and maximum
|               current values.  The four entries, Voltage, I(typ), I(min),
|               and I(max) must be placed on a single line and must be
|               separated by at least one white space.
|
|               All four columns are required under these keywords.  However,
|               data is only required in the typical column.  If minimum 
|               and/or maximum current values are not available, the reserved
|               word "NA" must be used.  "NA" can be used for currents in the
|               typical column, but numeric values MUST be specified for the
|               first and last voltage points on any I-V table.  Each I-V 
|               table must have at least 2, but not more than 100, voltage
|               points.
|
| Other Notes:  There is no monotonicity requirement. However the model
|               supplier should realize that it may not be possible to derive
|               a behavioral model from non-monotonic data.
|
|* the old model is:
|*               The model is:
|*
|*                                Table Current
|*                                   ------->
|*                               +     Vds     -
|*                             Pin 1           Pin 2
|*                               <---|     |--->  +
|*                               d   |_____| - s
|*                                    --+-- Vgs   Vs
|*                                      | g  +
|*                                                -
|*                      Vg = [Voltage Range] = Vcc
|*                      Vgs = Table Voltage = Vtable = Vcc - Vs
|*                      Ids = Table Current for a given Vcc and Vds
|
|*The new model is:
|*
|*                                Table Current
|*                                   ------->  Ids
|*                               +     Vds     -
|*
|*                                     Vcc
|*                                      | g
|*                                  ----+----
|*                                   -------  NMOS
|*                             Pin 1 |     |    Pin 2
|*                               <---|     |--->  Voltage = Vcc - Vs
|*                       PMOS    d   |_____|  s
|*                                    --+-- 
|*                                      | g  
|*                                     GND 
|*
|* Either of the FET's could be removed (or have zero current
|* contribution.  Thus this model covers all four conditions, off,
|* single NMOS, single PMOS and parallel NMOS/PMOS.
|*         
|*                      Voltage = Table Voltage = Vtable = Vcc - Vs
|*                       Ids = Table Current for a given Vcc and Vds
|
|
|* old       Internal logic that is generally referenced to the power rail
|*             is used to set the MOSFET switch to its 'On' state.  Thus the
|*             [Voltage Range] settings provide the assumed gate voltages.
|*             If the [POWER Clamp Reference] exists, it overrides the
|*             [Voltage Range] value.  The table entries are actually the Vgs
|*             values referenced to the power rail.  The polarity conventions
|*
|* new      Internal Logic that is generally referenced to the power rail
|*              is used to set the NMOS MOSFET switch to its 'ON' state.
|*             Internal logic likewise referenced to ground is used to set the 
|*-             PMOS device to its 'ON' state if the PMOS device is present.
|*             Thus the [Voltage Range] settings provide the assumed 
|*             gate voltages.  If the [POWER Clamp Reference] exists, it 
|*             overrides the [Voltage Range] value.  The table entries are
|*             actually Vgs of the NMOS device and Vcc - Vgs of the PMOS
!*             device if present.  The polarity conventions

|               are identical with those used for other tables that are
|               referenced to power rails.  Thus the voltage column can be
|               viewed as a table defining the source voltages Vs according to
|               the convention:  Vtable = Vcc - Vs.
|
|               If the switch is used in an application such as interfacing
|               between 3.3 V and 5.0 V logic, the Vcc may be biased at a 
|               voltage (such as 4.3 V) that is different from a power rail
|               voltage (such as 5.0 V) used to create the model.  Just
|               readjust the [Voltage Range] entries (or [POWER Clamp
|               Reference] entries).
|
|               One fundamental assumption in the MOSFET switch model is that
|               it operates in a symmetrical manner.  The tables and
|               expressions are given assuming that Vd >= Vs.  If Vd < Vs,
|               then apply the same relationships under the assumption that
|               the source and drain nodes are interchanged.  A consequence of
|               this assumption is that the Vds subparameter is constrained to
|               values Vds > 0.  It is assumed that with Vds = 0 the currents
|               will be 0 mA.  A further consequence of this assumption that
|               would be embedded in the analysis process is that the voltage
|               table is based on the side of the model with the lowest
|               voltage (and that side is defined as the source).  Thus the
|               analysis must allow current to flow in both directions, as
|               would occur due to reflections when the switch is connected in
|               series with an unterminated transmission line.
|
|               The model data is used to create an On state relationship
|               between the actual drain to source current, ids, and the
|               actual drain to source voltage, vds:
|
|                                    ids = f(vds).
|
|               This functional relationship depends on the actual source
|               voltage Vs and can be expressed in terms of the corresponding
|               table currents associated with Vs (and expressed as a function
|               of Vgs).
|
|               If only one [Series MOSFET] table is supplied (as a first
|               order approximation), the functional relationship is assumed
|               to be linearly related to the table drain to source current,
|               Ids, for the given Vds subparameter value and located at the
|               existing gate to source voltage value Vgs.  This table current
|               is denoted as Ids(Vgs, Vds).  The functional relationship
|               becomes:
|
|* old                            ids = Ids(Vgs, Vds) * vds / Vds.  
|*
|* new     ids = Idsn(V, Vds) * vds/Vds + Idsp((Vcc - V), Vds) * vds/Vds
|
|               More than one [Series MOSFET] table is permitted, but it is
|               simulator dependent how the data will be used.  Each
|               successive [Series MOSFET] table must have a different
|               subparameter value for Vds.  The number of tables must not 
|               exceed 100.
|
|               C_comp values are ignored for [Series MOSFET] models.
|-----------------------------------------------------------------------------
[On]
[Series MOSFET]
Vds = 1.0  
|  Voltage   I(typ)    I(min)    I(max)
    5.0V    257.9m     153.3m    399.5m     | Defines the Ids current as a
    4.0V    203.0m     119.4m    317.3m     | function of Vgs, for Vds = 1.0
    3.0V    129.8m      74.7m    205.6m 
    2.0V     31.2m      16.6m     51.0m
    1.0V     52.7p      46.7p     56.7p
    0.0V      0.0p       0.0p      0.0p
|=============================================================================

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

ANY OTHER BACKGROUND INFORMATION:

An Ad Hoc presentation on this topic was initially presented at the IBIS
Summit Meeting on June 21, 2001.

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

- --------------BE319BEDA54C34BC8D533340--

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

Date: Fri, 27 Jul 2001 14:11:10 -0400
From: "Todd Westerhoff" <[email-masked]>
Subject: IBIS and device performance

Hi all,

This particular question is going to both the SI and IBIS reflectors, as the
issues touch both groups.

Question 1 (for the SI-listers)

How often are people seeing IBIS models that use the [Model Spec] keyword to
list min/typ/max values for parameters like Vinl, Vinh and Vmeas?  Are you
seeing this commonly, or was your response "what is he talking about"?

Question/Comment 2 (for the IBISians)

Is there any definitive, short, concise document that lists which
combinations of which IBIS parameters are meant to represent best, typical,
and worst-case component-level performance?  As an example, the [max]
section of a V/I curve would clearly indicate best-case device performance,
but you'd have to combine that with the [min] value of a parameter like
c_comp.  So - for best case conditions, the EDA tool and the model creator
both have to use the same set of conventions of combining parameters for
best, typical and worst case device performance.

Is there a table anywhere that defines this?

Todd.

Todd Westerhoff
SI Engineer
Hammerhead Networks
5 Federal Street
Billerica, MA  01821
[email-masked]
ph: 978-671-5084

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

Date: Mon, 30 Jul 2001 10:41:34 +0800
From: Hailong Wang <[email-masked]>
Subject: About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut

- --------------8426CC510388A44ED7A61FCC
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

Hi,
    I found that the R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut have the
very similar functions. But form the IBIS Specification V3.2, I found
they are different. So I am confused, and want to the relationship
between them.

Thanks in advance!

- --
Best Regards.
Hai-long Wang
Tel:021-62837026x228
Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
No.55, West Huaihai Road, Shanghai, 200030, P.R.China

- --------------8426CC510388A44ED7A61FCC
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>&nbsp;&nbsp;&nbsp; I found that the R_pkg,C_pkg,L_pkg and R_dut, C_dut,
L_dut have the very similar functions. But form the IBIS&nbsp;Specification&nbsp;V3.2,
I found they are different. So I am confused, and want to the relationship
between them.
<p>Thanks in advance!
<pre>--&nbsp;
Best Regards.
Hai-long Wang
Tel:021-62837026x228
Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
No.55, West Huaihai Road, Shanghai, 200030, P.R.China</pre>
&nbsp;</html>

- --------------8426CC510388A44ED7A61FCC--

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

Date: Tue, 31 Jul 2001 09:26:03 -0700
From: "Raj Raghuram" <[email-masked]>
Subject: Pin Mapping in IBIS models

The Pin Mapping section (optional) in IBIS 2.1 was introduced to associate
drivers with appropriate Power and Ground pins for simulation of ground and
power bounce. However, I am not able to locate any IBIS models which have
this section.

Can anybody point me to an IBIS model containing this section?

Raj Raghuram
Sigrity, Inc.
"Achieve what others can't"
[email-masked]
http://www.sigrity.com
4675 Stevens Creek Blvd. , Ste 130
Santa Clara, CA-95051
PH: 408-260-9344 x116
CELL: 408-390-9614
FAX: 408-260-9342

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

Date: Tue, 31 Jul 2001 15:33:11 -0700
From: "Howard Johnson" <[email-masked]>
Subject: removal from ibis list

Please remove Howard Johnson ([email-masked], [email-masked],
[email-masked], [email-masked]) from the IBIS email
list.

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

Date: Wed, 1 Aug 2001 08:48:34 +0800
From: "LiuWeidong" <[email-masked]>
Subject: Re: Pin Mapping in IBIS models

This is a multi-part message in MIME format.

- ------=_NextPart_000_0046_01C11A66.BF73ACA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

- ------=_NextPart_000_0046_01C11A66.BF73ACA0
Content-Type: application/octet-stream;
	name="LVT162244(pin_maping).ibs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="LVT162244(pin_maping).ibs"

|########################################################################=
##
|                     TEXAS INSTRUMENTS INCORPORATED
|                      Advanced Bus Interface Group
|                        IBIS Model of LVT162244
|            3.3V ABT 16-Bit BUFFERS/DRIVERS WITH 3-STATE OUTPUTS
|########################################################################=
##
|
[IBIS Ver]      1.1
[File Name]     LVT162244.ibs
|
|12/25/1999,[pin mapping] was added in this model by Jiang XiangZhong =
CAD group Huawei company.
|
[File Rev]      2.0
[Date]          11/29/95
[Source]        File originated at Texas Instruments, Inc.
[Notes]         The following is an IBIS list for the LVT162244.
|               - All test data contained in this file are derived from
|                 hspice(tm) simulations.
|               - File created by Tareq Shahwan, ABL Applications.
|               - Disclaimer modified by David Holmgreen, Launch =
Marketing
|
|************************************************************************=
**
[Disclaimer]    Property of Texas Instruments Incorporated.  =
Unauthorized=20
                reproduction and/or distribution is strictly prohibited.

                This product is protected under copyright law.
                Created 1995, (C) Copyright 1995, Texas Instruments =
Inc.,
                All Rights Reserved

                UNLESS THERE IS A SIGNED, WRITTEN AGREEMENT TO THE=20
                CONTRARY, TEXAS INSTRUMENTS ("TI") IS PROVIDING THE IBIS =

                MODELS "AS IS" AND WITHOUT ANY WARRANTY, EXPRESSED OR=20
                IMPLIED.  TI assumes no liability for:
                 1) the accuracy of the IBIS models provided to your=20
                    company;
                 2) the proper functioning of these IBIS models in your=20
                    design or for any resulting applications; or
                 3) infringement of patents, copyrights or intellectual=20
                    property rights resulting from your use of these =
IBIS=20
                    models.

                TI provides IBIS Models as a service to our customers.
                You and your company shall not distribute, sell or give=20
                these models to anyone else without prior written=20
                permission from TI.

                TI reserves the right to make changes to our products or =

                to discontinue any semiconductor product or service=20
                without notice, and advises our customers to obtain the=20
                latest version of relevant information to verify, before =

                placing orders, that the information being relied on is=20
                current.

                Please be aware that your receipt and use of the IBIS=20
                information provided shall serve as acceptance of these=20
                terms and conditions.  If you do not accept these terms,
                you should return or destroy the IBIS models and any=20
                other accompanying information immediately.
|
|************************************************************************=
**
|
[Component]     LVT162244=20
[Manufacturer]  Texas Instruments, Inc.
[Package]
|               typ        min         max
R_pkg           0.036      0.026       0.041
L_pkg           6.747nH    5.492nH     9.423nH
C_pkg           0.752pF    0.392pF     1.110pF
|
|************************************************************************=
**
|
[Pin]     signal_name     model_name        R_pin     L_pin       C_pin
|
1           ce1           LVT162244_IN      0.041     8.654nH     =
1.110pF
24          ce2           LVT162244_IN      0.041     8.654nH     =
1.110pF
25          ce3           LVT162244_IN      0.041     8.654nH     =
1.110pF
48          ce4           LVT162244_IN      0.041     8.654nH     =
1.110pF
47          1D1           LVT162244_IN      0.041     8.654nH     =
1.110pF
46          1D2           LVT162244_IN      0.041     8.654nH     =
1.110pF
44          1D3           LVT162244_IN      0.041     8.654nH     =
1.110pF
43          1D4           LVT162244_IN      0.041     8.654nH     =
1.110pF
41          1D5           LVT162244_IN      0.041     8.654nH     =
1.110pF
40          1D6           LVT162244_IN      0.041     8.654nH     =
1.110pF
38          1D7           LVT162244_IN      0.041     8.654nH     =
1.110pF
37          1D8           LVT162244_IN      0.041     8.654nH     =
1.110pF
36          2D1           LVT162244_IN      0.041     8.654nH     =
1.110pF
35          2D2           LVT162244_IN      0.041     8.654nH     =
1.110pF
33          2D3           LVT162244_IN      0.041     8.654nH     =
1.110pF
32          2D4           LVT162244_IN      0.041     8.654nH     =
1.110pF
30          2D5           LVT162244_IN      0.041     8.654nH     =
1.110pF
29          2D6           LVT162244_IN      0.041     8.654nH     =
1.110pF
27          2D7           LVT162244_IN      0.041     8.654nH     =
1.110pF
26          2D8           LVT162244_IN      0.041     8.654nH     =
1.110pF
2           1O1           LVT162244_OUT     0.041     8.654nH     =
1.110pF
3           1O2           LVT162244_OUT     0.041     8.654nH     =
1.110pF
5           1O3           LVT162244_OUT     0.041     8.654nH     =
1.110pF
6           1O4           LVT162244_OUT     0.041     8.654nH     =
1.110pF
8           1O5           LVT162244_OUT     0.041     8.654nH     =
1.110pF
9           1O6           LVT162244_OUT     0.041     8.654nH     =
1.110pF
11          1O7           LVT162244_OUT     0.041     8.654nH     =
1.110pF
12          1O8           LVT162244_OUT     0.041     8.654nH     =
1.110pF
13          2O1           LVT162244_OUT     0.041     8.654nH     =
1.110pF
14          2O2           LVT162244_OUT     0.041     8.654nH     =
1.110pF
16          2O3           LVT162244_OUT     0.041     8.654nH     =
1.110pF
17          2O4           LVT162244_OUT     0.041     8.654nH     =
1.110pF
19          2O5           LVT162244_OUT     0.041     8.654nH     =
1.110pF
20          2O6           LVT162244_OUT     0.041     8.654nH     =
1.110pF
22          2O7           LVT162244_OUT     0.041     8.654nH     =
1.110pF
23          2O8           LVT162244_OUT     0.041     8.654nH     =
1.110pF
4           GND           GND               0.041     7.469nH     =
0.899pF
10          GND           GND               0.041     7.469nH     =
0.899pF
15          GND           GND               0.041     7.469nH     =
0.899pF
21          GND           GND               0.041     7.469nH     =
0.899pF
28          GND           GND               0.041     7.469nH     =
0.899pF
34          GND           GND               0.041     7.469nH     =
0.899pF
39          GND           GND               0.041     7.469nH     =
0.899pF
45          GND           GND               0.041     7.469nH     =
0.899pF
7           VCC           POWER             0.035     6.006nH     =
0.748pF
18          VCC           POWER             0.035     6.006nH     =
0.748pF
31          VCC           POWER             0.035     6.006nH     =
0.748pF
42          VCC           POWER             0.035     6.006nH     =
0.748pF
|
[Pin Mapping]  pulldown_ref    pullup_ref      gnd_clamp_ref   =
power_clamp_ref
|
1             NC               NC              4                7
2             4                7               4                7
3             4                7               4                7
4             NC               NC              NC               NC
5             4                7               4                7
6             4                7               4                7
7             NC               NC              NC               NC
8             10               7               10               7
9             10               7               10               7
10            NC               NC              NC               NC
11            10               7               10               7
12            10               7               10               7
13            15               18              15               18
14            15               18              15               18
15            NC               NC              NC               NC
16            15               18              15               18
17            15               18              15               18
18            NC               NC              NC               NC
19            21               18              21               18
20            21               18              21               18
21            NC               NC              NC               NC
22            21               18              21               18
23            21               18              21               18
24            NC               NC              21               18
25            NC               NC              28               31
26            NC               NC              28               31
27            NC               NC              28               31
28            NC               NC              NC               NC
29            NC               NC              28               31
30            NC               NC              28               31
31            NC               NC              NC               NC
32            NC               NC              34               31  =20
33            NC               NC              34               31  =20
34            NC               NC              NC               NC
35            NC               NC              34               31  =20
36            NC               NC              34               31  =20
37            NC               NC              39               42
38            NC               NC              39               42
39            NC               NC              NC               NC
40            NC               NC              39               42
41            NC               NC              39               42
42            NC               NC              NC               NC
43            NC               NC              45               42
44            NC               NC              45               42
45            NC               NC              NC               NC
46            NC               NC              45               42
47            NC               NC              45               42
48            NC               NC              45               42
|
|************************************************************************=
**
|                          Model LVT162244_OUT
|************************************************************************=
**
|
[Model]            LVT162244_OUT
Model_type         3-state
Polarity           Inverting
Enable             Active-Low
|
|                      typ        min         max
C_comp                 9.25pF     NA          NA
|
|[Temperature Range]    25         -40         85
|
[Voltage range]        3.3        3.0         3.6
|
|************************************************************************=
**
|
[Pullup]
|
|Voltage          I(typ)          I(min)          I(max)
|
6.60E+00	-1.72E-01	-1.40E-01	-2.16E-01
6.50E+00	-1.70E-01	-1.38E-01	-2.12E-01
6.40E+00	-1.67E-01	-1.36E-01	-2.09E-01
6.30E+00	-1.65E-01	-1.34E-01	-2.06E-01
6.20E+00	-1.62E-01	-1.32E-01	-2.03E-01
6.10E+00	-1.59E-01	-1.29E-01	-2.00E-01
6.00E+00	-1.57E-01	-1.27E-01	-1.97E-01
5.90E+00	-1.54E-01	-1.25E-01	-1.94E-01
5.80E+00	-1.52E-01	-1.23E-01	-1.91E-01
5.70E+00	-1.49E-01	-1.20E-01	-1.88E-01
5.60E+00	-1.47E-01	-1.18E-01	-1.85E-01
5.50E+00	-1.44E-01	-1.16E-01	-1.82E-01
5.40E+00	-1.41E-01	-1.14E-01	-1.79E-01
5.30E+00	-1.39E-01	-1.11E-01	-1.76E-01
5.20E+00	-1.36E-01	-1.09E-01	-1.73E-01
5.10E+00	-1.33E-01	-1.07E-01	-1.70E-01
5.00E+00	-1.30E-01	-1.05E-01	-1.67E-01
4.90E+00	-1.27E-01	-1.02E-01	-1.63E-01
4.80E+00	-1.24E-01	-1.00E-01	-1.60E-01
4.70E+00	-1.21E-01	-9.78E-02	-1.57E-01
4.60E+00	-1.18E-01	-9.56E-02	-1.54E-01
4.50E+00	-1.15E-01	-9.33E-02	-1.51E-01
4.40E+00	-1.12E-01	-9.10E-02	-1.47E-01
4.30E+00	-1.09E-01	-8.87E-02	-1.44E-01
4.20E+00	-1.07E-01	-8.63E-02	-1.41E-01
4.10E+00	-1.04E-01	-8.39E-02	-1.38E-01
4.00E+00	-1.01E-01	-8.15E-02	-1.34E-01
3.90E+00	-9.83E-02	-7.91E-02	-1.31E-01
3.80E+00	-9.56E-02	-7.65E-02	-1.28E-01
3.70E+00	-9.30E-02	-7.38E-02	-1.25E-01
3.60E+00	-9.04E-02	-7.11E-02	-1.21E-01
3.50E+00	-8.80E-02	-6.84E-02	-1.18E-01
3.40E+00	-8.58E-02	-6.56E-02	-1.15E-01
3.30E+00	-8.37E-02	-6.29E-02	-1.11E-01
3.20E+00	-8.18E-02	-6.02E-02	-1.08E-01
3.10E+00	-7.98E-02	-5.75E-02	-1.05E-01
3.00E+00	-7.77E-02	-5.49E-02	-1.01E-01
2.90E+00	-7.56E-02	-5.23E-02	-9.79E-02
2.80E+00	-7.35E-02	-4.97E-02	-9.45E-02
2.70E+00	-7.12E-02	-4.72E-02	-9.11E-02
2.60E+00	-6.89E-02	-4.48E-02	-8.77E-02
2.50E+00	-6.66E-02	-4.25E-02	-8.44E-02
2.40E+00	-6.42E-02	-4.03E-02	-8.10E-02
2.30E+00	-6.18E-02	-3.83E-02	-7.76E-02
2.20E+00	-5.94E-02	-3.66E-02	-7.42E-02
2.10E+00	-5.69E-02	-3.53E-02	-7.08E-02
2.00E+00	-5.43E-02	-3.43E-02	-6.74E-02
1.90E+00	-5.18E-02	-3.34E-02	-6.40E-02
1.80E+00	-4.92E-02	-3.25E-02	-6.06E-02
1.70E+00	-4.66E-02	-3.14E-02	-5.72E-02
1.60E+00	-4.39E-02	-3.01E-02	-5.39E-02
1.50E+00	-4.13E-02	-2.88E-02	-5.05E-02
1.40E+00	-3.86E-02	-2.73E-02	-4.71E-02
1.30E+00	-3.59E-02	-2.58E-02	-4.37E-02
1.20E+00	-3.32E-02	-2.41E-02	-4.03E-02
1.10E+00	-3.05E-02	-2.24E-02	-3.69E-02
1.00E+00	-2.78E-02	-2.07E-02	-3.35E-02
9.00E-01	-2.50E-02	-1.88E-02	-3.01E-02
8.00E-01	-2.23E-02	-1.69E-02	-2.68E-02
7.00E-01	-1.95E-02	-1.49E-02	-2.34E-02
6.00E-01	-1.67E-02	-1.29E-02	-2.00E-02
5.00E-01	-1.40E-02	-1.09E-02	-1.67E-02
4.00E-01	-1.12E-02	-8.80E-03	-1.33E-02
3.00E-01	-8.40E-03	-6.67E-03	-1.00E-02
2.00E-01	-5.62E-03	-4.50E-03	-6.66E-03
1.00E-01	-2.82E-03	-2.29E-03	-3.34E-03
4.44E-16	7.84E-09	3.98E-08	1.52E-09
- -1.00E-01	2.84E-03	2.32E-03	3.34E-03
- -2.00E-01	5.69E-03	4.63E-03	6.69E-03
- -3.00E-01	8.55E-03	6.97E-03	1.01E-02
- -4.00E-01	1.15E-02	9.34E-03	1.35E-02
- -5.00E-01	1.44E-02	1.17E-02	1.69E-02
- -6.00E-01	1.73E-02	1.42E-02	2.03E-02
- -7.00E-01	2.03E-02	1.66E-02	2.38E-02
- -8.00E-01	2.33E-02	1.91E-02	2.72E-02
- -9.00E-01	2.63E-02	2.15E-02	3.07E-02
- -1.00E+00	2.94E-02	2.40E-02	3.42E-02
- -1.10E+00	3.24E-02	2.65E-02	3.77E-02
- -1.20E+00	3.55E-02	2.89E-02	4.13E-02
- -1.30E+00	3.86E-02	3.14E-02	4.48E-02
- -1.40E+00	4.16E-02	3.40E-02	4.84E-02
- -1.50E+00	4.47E-02	3.65E-02	5.19E-02
- -1.60E+00	4.78E-02	3.90E-02	5.55E-02
- -1.70E+00	5.09E-02	4.16E-02	5.90E-02
- -1.80E+00	5.40E-02	4.41E-02	6.25E-02
- -1.90E+00	5.72E-02	4.67E-02	6.60E-02
- -2.00E+00	6.03E-02	4.93E-02	6.95E-02
- -2.10E+00	6.35E-02	5.18E-02	7.30E-02
- -2.20E+00	6.66E-02	5.44E-02	7.65E-02
- -2.30E+00	6.98E-02	5.70E-02	8.01E-02
- -2.40E+00	7.28E-02	5.96E-02	8.37E-02
- -2.50E+00	7.58E-02	6.22E-02	8.73E-02
- -2.60E+00	7.88E-02	6.48E-02	9.09E-02
- -2.70E+00	8.19E-02	6.74E-02	9.45E-02
- -2.80E+00	8.51E-02	6.97E-02	9.81E-02
- -2.90E+00	8.83E-02	7.21E-02	1.02E-01
- -3.00E+00	9.15E-02	7.46E-02	1.05E-01
- -3.10E+00	9.47E-02	7.73E-02	1.09E-01
- -3.20E+00	9.79E-02	7.99E-02	1.13E-01
- -3.30E+00	1.01E-01	8.25E-02	1.16E-01
|
|
[Pulldown]
|
|Voltage          I(typ)          I(min)          I(max)
|
- -3.30E+00	-7.49E-02	-7.90E-02	-7.10E-02
- -3.20E+00	-7.12E-02	-7.53E-02	-6.76E-02
- -3.10E+00	-6.76E-02	-7.16E-02	-6.43E-02
- -3.00E+00	-6.41E-02	-6.80E-02	-6.12E-02
- -2.90E+00	-6.06E-02	-6.44E-02	-5.83E-02
- -2.80E+00	-5.73E-02	-6.09E-02	-5.56E-02
- -2.70E+00	-5.42E-02	-5.74E-02	-5.32E-02
- -2.60E+00	-5.11E-02	-5.40E-02	-5.09E-02
- -2.50E+00	-4.82E-02	-5.07E-02	-4.86E-02
- -2.40E+00	-4.54E-02	-4.75E-02	-4.65E-02
- -2.30E+00	-4.28E-02	-4.44E-02	-4.43E-02
- -2.20E+00	-4.04E-02	-4.15E-02	-4.22E-02
- -2.10E+00	-3.81E-02	-3.86E-02	-4.00E-02
- -2.00E+00	-3.59E-02	-3.59E-02	-3.79E-02
- -1.90E+00	-3.38E-02	-3.33E-02	-3.58E-02
- -1.80E+00	-3.18E-02	-3.08E-02	-3.37E-02
- -1.70E+00	-2.97E-02	-2.86E-02	-3.16E-02
- -1.60E+00	-2.77E-02	-2.64E-02	-2.95E-02
- -1.50E+00	-2.58E-02	-2.44E-02	-2.75E-02
- -1.40E+00	-2.38E-02	-2.24E-02	-2.54E-02
- -1.30E+00	-2.19E-02	-2.04E-02	-2.35E-02
- -1.20E+00	-2.00E-02	-1.85E-02	-2.17E-02
- -1.10E+00	-1.81E-02	-1.67E-02	-1.99E-02
- -1.00E+00	-1.64E-02	-1.49E-02	-1.81E-02
- -9.00E-01	-1.47E-02	-1.32E-02	-1.63E-02
- -8.00E-01	-1.31E-02	-1.16E-02	-1.45E-02
- -7.00E-01	-1.15E-02	-1.01E-02	-1.27E-02
- -6.00E-01	-9.84E-03	-8.65E-03	-1.09E-02
- -5.00E-01	-8.22E-03	-7.22E-03	-9.14E-03
- -4.00E-01	-6.60E-03	-5.79E-03	-7.35E-03
- -3.00E-01	-4.98E-03	-4.37E-03	-5.56E-03
- -2.00E-01	-3.36E-03	-2.94E-03	-3.77E-03
- -1.00E-01	-1.74E-03	-1.51E-03	-1.98E-03
0.00E+00	-1.04E-04	-6.51E-05	-1.87E-04
1.00E-01	1.52E-03	1.37E-03	1.61E-03
2.00E-01	3.14E-03	2.79E-03	3.47E-03
3.00E-01	4.76E-03	4.05E-03	5.86E-03
4.00E-01	6.78E-03	6.69E-03	9.05E-03
5.00E-01	1.07E-02	1.06E-02	1.26E-02
6.00E-01	1.49E-02	1.47E-02	1.63E-02
7.00E-01	1.93E-02	1.89E-02	1.99E-02
8.00E-01	2.36E-02	2.30E-02	2.38E-02
9.00E-01	2.80E-02	2.72E-02	2.81E-02
1.00E+00	3.24E-02	3.14E-02	3.26E-02
1.10E+00	3.68E-02	3.56E-02	3.70E-02
1.20E+00	4.12E-02	3.97E-02	4.14E-02
1.30E+00	4.57E-02	4.39E-02	4.59E-02
1.40E+00	5.01E-02	4.80E-02	5.03E-02
1.50E+00	5.45E-02	5.21E-02	5.48E-02
1.60E+00	5.89E-02	5.62E-02	5.93E-02
1.70E+00	6.33E-02	6.02E-02	6.37E-02
1.80E+00	6.77E-02	6.42E-02	6.82E-02
1.90E+00	7.22E-02	6.82E-02	7.27E-02
2.00E+00	7.66E-02	7.22E-02	7.71E-02
2.10E+00	8.09E-02	7.63E-02	8.16E-02
2.20E+00	8.53E-02	8.02E-02	8.61E-02
2.30E+00	8.97E-02	8.39E-02	9.05E-02
2.40E+00	9.40E-02	8.73E-02	9.49E-02
2.50E+00	9.84E-02	9.06E-02	9.93E-02
2.60E+00	1.03E-01	9.39E-02	1.04E-01
2.70E+00	1.07E-01	9.71E-02	1.08E-01
2.80E+00	1.11E-01	1.00E-01	1.13E-01
2.90E+00	1.16E-01	1.03E-01	1.17E-01
3.00E+00	1.20E-01	1.06E-01	1.21E-01
3.10E+00	1.24E-01	1.09E-01	1.25E-01
3.20E+00	1.28E-01	1.11E-01	1.30E-01
3.30E+00	1.33E-01	1.13E-01	1.34E-01
3.40E+00	1.37E-01	1.15E-01	1.38E-01
3.50E+00	1.41E-01	1.16E-01	1.42E-01
3.60E+00	1.45E-01	1.18E-01	1.47E-01
3.70E+00	1.49E-01	1.21E-01	1.51E-01
3.80E+00	1.53E-01	1.24E-01	1.55E-01
3.90E+00	1.58E-01	1.27E-01	1.59E-01
4.00E+00	1.62E-01	1.31E-01	1.64E-01
4.10E+00	1.66E-01	1.34E-01	1.68E-01
4.20E+00	1.70E-01	1.38E-01	1.72E-01
4.30E+00	1.74E-01	1.41E-01	1.76E-01
4.40E+00	1.78E-01	1.45E-01	1.80E-01
4.50E+00	1.83E-01	1.48E-01	1.84E-01
4.60E+00	1.87E-01	1.52E-01	1.89E-01
4.70E+00	1.91E-01	1.55E-01	1.93E-01
4.80E+00	1.95E-01	1.59E-01	1.97E-01
4.90E+00	1.99E-01	1.62E-01	2.01E-01
5.00E+00	2.03E-01	1.66E-01	2.05E-01
5.10E+00	2.08E-01	1.69E-01	2.10E-01
5.20E+00	2.12E-01	1.73E-01	2.14E-01
5.30E+00	2.16E-01	1.76E-01	2.18E-01
5.40E+00	2.20E-01	1.79E-01	2.22E-01
5.50E+00	2.24E-01	1.83E-01	2.26E-01
5.60E+00	2.28E-01	1.86E-01	2.30E-01
5.70E+00	2.32E-01	1.89E-01	2.34E-01
5.80E+00	2.36E-01	1.92E-01	2.39E-01
5.90E+00	2.41E-01	1.96E-01	2.43E-01
6.00E+00	2.45E-01	1.98E-01	2.47E-01
6.10E+00	2.49E-01	2.01E-01	2.51E-01
6.20E+00	2.53E-01	2.03E-01	2.55E-01
6.30E+00	2.57E-01	2.04E-01	2.59E-01
6.40E+00	2.61E-01	2.05E-01	2.64E-01
6.50E+00	2.65E-01	2.06E-01	2.68E-01
6.60E+00	2.69E-01	2.07E-01	2.72E-01
|
|
[Ramp]
|Variable         typ              min              max
|
dV/dt_r       1.142/0.356n     0.869/0.787n     1.347/0.203n
dV/dt_f       1.245/0.608n     1.124/1.169n     1.377/0.405n
|
|************************************************************************=
******
|                         Model LVT162244_IN
|************************************************************************=
******
|
[Model]             LVT162244_IN
Model_type          Input
Polarity            Inverting
Vinl =3D 0.8V
Vinh =3D 2.0V
|                   typ          min          max
C_comp              3.25pF       NA           NA
|
[Voltage Range]     3.3          3.0          3.6
|
|************************************************************************=
******
|
[POWER_Clamp]
|
|Voltage         I(typ)          I(min)          I(max)
|
0.00E+00	1.32E-09	1.19E-09	1.44E-09
- -3.33E-02	6.62E-09	4.81E-07	1.46E-09
- -6.66E-02	8.16E-09	6.81E-07	1.48E-09
- -1.00E-01	8.61E-09	7.57E-07	1.50E-09
- -1.33E-01	8.75E-09	7.84E-07	1.52E-09
- -1.67E-01	8.81E-09	7.94E-07	1.54E-09
- -2.00E-01	8.84E-09	7.98E-07	1.56E-09
- -2.33E-01	8.86E-09	7.99E-07	1.58E-09
- -2.67E-01	8.88E-09	7.99E-07	1.60E-09
- -3.00E-01	8.90E-09	8.00E-07	1.61E-09
- -3.33E-01	8.92E-09	8.00E-07	1.63E-09
- -3.67E-01	8.94E-09	8.00E-07	1.65E-09
- -4.00E-01	8.96E-09	8.00E-07	1.67E-09
- -4.33E-01	8.98E-09	8.00E-07	1.69E-09
- -4.67E-01	8.99E-09	8.00E-07	1.71E-09
- -5.00E-01	9.01E-09	8.00E-07	1.73E-09
- -5.33E-01	9.03E-09	8.00E-07	1.75E-09
- -5.67E-01	9.05E-09	8.00E-07	1.77E-09
- -6.00E-01	9.07E-09	8.00E-07	1.78E-09
- -6.33E-01	9.09E-09	8.00E-07	1.80E-09
- -6.67E-01	9.11E-09	8.00E-07	1.82E-09
- -7.00E-01	9.13E-09	8.00E-07	1.84E-09
- -7.33E-01	9.15E-09	8.00E-07	1.86E-09
- -7.67E-01	9.17E-09	8.00E-07	1.88E-09
- -8.00E-01	9.19E-09	8.00E-07	1.90E-09
- -8.33E-01	9.21E-09	8.00E-07	1.92E-09
- -8.67E-01	9.23E-09	8.00E-07	1.94E-09
- -9.00E-01	9.25E-09	8.00E-07	1.95E-09
- -9.33E-01	9.27E-09	8.00E-07	1.97E-09
- -9.67E-01	9.29E-09	8.00E-07	1.99E-09
- -1.00E+00	9.31E-09	8.00E-07	2.01E-09
- -1.03E+00	9.33E-09	8.00E-07	2.03E-09
- -1.07E+00	9.34E-09	8.00E-07	2.05E-09
- -1.10E+00	9.36E-09	8.00E-07	2.07E-09
- -1.13E+00	9.38E-09	8.00E-07	2.09E-09
- -1.17E+00	9.40E-09	8.00E-07	2.11E-09
- -1.20E+00	9.42E-09	8.00E-07	2.12E-09
- -1.23E+00	9.44E-09	8.00E-07	2.14E-09
- -1.27E+00	9.46E-09	8.00E-07	2.16E-09
- -1.30E+00	9.48E-09	8.00E-07	2.18E-09
- -1.33E+00	9.50E-09	8.00E-07	2.20E-09
- -1.37E+00	9.52E-09	8.00E-07	2.22E-09
- -1.40E+00	9.54E-09	8.00E-07	2.24E-09
- -1.43E+00	9.56E-09	8.00E-07	2.26E-09
- -1.47E+00	9.58E-09	8.00E-07	2.28E-09
- -1.50E+00	9.60E-09	8.00E-07	2.30E-09
- -1.53E+00	9.62E-09	8.00E-07	2.32E-09
- -1.57E+00	9.64E-09	8.00E-07	2.34E-09
- -1.60E+00	9.66E-09	8.00E-07	2.36E-09
- -1.63E+00	9.68E-09	8.01E-07	2.38E-09
- -1.67E+00	9.70E-09	8.01E-07	2.40E-09
- -1.70E+00	9.72E-09	8.01E-07	2.42E-09
- -1.73E+00	9.74E-09	8.01E-07	2.44E-09
- -1.77E+00	9.76E-09	8.01E-07	2.46E-09
- -1.80E+00	9.78E-09	8.01E-07	2.48E-09
- -1.83E+00	9.80E-09	8.01E-07	2.50E-09
- -1.87E+00	9.82E-09	8.01E-07	2.52E-09
- -1.90E+00	9.84E-09	8.01E-07	2.54E-09
- -1.93E+00	9.86E-09	8.01E-07	2.56E-09
- -1.97E+00	9.88E-09	8.01E-07	2.58E-09
- -2.00E+00	9.90E-09	8.01E-07	2.60E-09
- -2.03E+00	9.92E-09	8.01E-07	2.62E-09
- -2.07E+00	9.94E-09	8.01E-07	2.64E-09
- -2.10E+00	9.96E-09	8.01E-07	2.66E-09
- -2.13E+00	9.98E-09	8.01E-07	2.68E-09
- -2.17E+00	1.00E-08	8.01E-07	2.70E-09
- -2.20E+00	1.00E-08	8.01E-07	2.72E-09
- -2.23E+00	1.00E-08	8.01E-07	2.74E-09
- -2.27E+00	1.01E-08	8.01E-07	2.76E-09
- -2.30E+00	1.01E-08	8.01E-07	2.78E-09
- -2.33E+00	1.01E-08	8.01E-07	2.80E-09
- -2.37E+00	1.01E-08	8.01E-07	2.82E-09
- -2.40E+00	1.01E-08	8.01E-07	2.84E-09
- -2.43E+00	1.02E-08	8.01E-07	2.86E-09
- -2.47E+00	1.02E-08	8.01E-07	2.88E-09
- -2.50E+00	1.02E-08	8.01E-07	2.90E-09
- -2.53E+00	1.02E-08	8.01E-07	2.92E-09
- -2.57E+00	1.02E-08	8.01E-07	2.94E-09
- -2.60E+00	1.03E-08	8.01E-07	2.96E-09
- -2.63E+00	1.03E-08	8.01E-07	2.98E-09
- -2.67E+00	1.03E-08	8.01E-07	3.00E-09
- -2.70E+00	1.03E-08	8.01E-07	3.02E-09
- -2.73E+00	1.03E-08	8.01E-07	3.04E-09
- -2.77E+00	1.04E-08	8.01E-07	3.06E-09
- -2.80E+00	1.04E-08	8.01E-07	3.08E-09
- -2.83E+00	1.04E-08	8.01E-07	3.10E-09
- -2.87E+00	1.04E-08	8.01E-07	3.12E-09
- -2.90E+00	1.04E-08	8.01E-07	3.14E-09
- -2.93E+00	1.05E-08	8.01E-07	3.16E-09
- -2.97E+00	1.05E-08	8.01E-07	3.18E-09
- -3.00E+00	1.05E-08	8.01E-07	3.20E-09
- -3.03E+00	1.05E-08	8.01E-07	3.22E-09
- -3.07E+00	1.05E-08	8.01E-07	3.24E-09
- -3.10E+00	1.06E-08	8.01E-07	3.26E-09
- -3.13E+00	1.06E-08	8.01E-07	3.28E-09
- -3.17E+00	1.06E-08	8.01E-07	3.30E-09
- -3.20E+00	1.06E-08	8.01E-07	3.32E-09
- -3.23E+00	1.06E-08	8.01E-07	3.34E-09
- -3.27E+00	1.07E-08	8.01E-07	3.36E-09
- -3.30E+00	1.07E-08	8.01E-07	3.38E-09
|
|
[GND_Clamp]
|
|Voltage          I(typ)          I(min)          I(max)
|
- -3.30E+00	-5.19E-02	-5.27E-02	-5.17E-02
- -3.23E+00	-5.04E-02	-5.12E-02	-5.01E-02
- -3.17E+00	-4.89E-02	-4.98E-02	-4.86E-02
- -3.10E+00	-4.74E-02	-4.83E-02	-4.71E-02
- -3.03E+00	-4.60E-02	-4.69E-02	-4.56E-02
- -2.97E+00	-4.45E-02	-4.54E-02	-4.41E-02
- -2.90E+00	-4.30E-02	-4.40E-02	-4.26E-02
- -2.83E+00	-4.16E-02	-4.25E-02	-4.11E-02
- -2.77E+00	-4.01E-02	-4.11E-02	-3.96E-02
- -2.70E+00	-3.87E-02	-3.97E-02	-3.82E-02
- -2.63E+00	-3.73E-02	-3.83E-02	-3.67E-02
- -2.57E+00	-3.58E-02	-3.69E-02	-3.52E-02
- -2.50E+00	-3.44E-02	-3.55E-02	-3.38E-02
- -2.43E+00	-3.30E-02	-3.41E-02	-3.23E-02
- -2.37E+00	-3.16E-02	-3.27E-02	-3.09E-02
- -2.30E+00	-3.02E-02	-3.13E-02	-2.94E-02
- -2.23E+00	-2.88E-02	-2.99E-02	-2.80E-02
- -2.17E+00	-2.74E-02	-2.85E-02	-2.66E-02
- -2.10E+00	-2.60E-02	-2.71E-02	-2.51E-02
- -2.03E+00	-2.46E-02	-2.58E-02	-2.37E-02
- -1.97E+00	-2.32E-02	-2.44E-02	-2.23E-02
- -1.90E+00	-2.19E-02	-2.31E-02	-2.09E-02
- -1.83E+00	-2.05E-02	-2.17E-02	-1.95E-02
- -1.77E+00	-1.92E-02	-2.04E-02	-1.81E-02
- -1.70E+00	-1.78E-02	-1.91E-02	-1.67E-02
- -1.63E+00	-1.65E-02	-1.78E-02	-1.54E-02
- -1.57E+00	-1.52E-02	-1.64E-02	-1.40E-02
- -1.50E+00	-1.38E-02	-1.51E-02	-1.26E-02
- -1.43E+00	-1.25E-02	-1.39E-02	-1.13E-02
- -1.37E+00	-1.12E-02	-1.26E-02	-9.96E-03
- -1.30E+00	-9.95E-03	-1.13E-02	-8.64E-03
- -1.23E+00	-8.68E-03	-1.00E-02	-7.34E-03
- -1.17E+00	-7.42E-03	-8.79E-03	-6.06E-03
- -1.10E+00	-6.19E-03	-7.56E-03	-4.83E-03
- -1.03E+00	-4.98E-03	-6.35E-03	-3.64E-03
- -9.67E-01	-3.81E-03	-5.17E-03	-2.51E-03
- -9.00E-01	-2.69E-03	-4.02E-03	-1.48E-03
- -8.33E-01	-1.67E-03	-2.92E-03	-7.03E-04
- -7.67E-01	-8.18E-04	-1.90E-03	-4.19E-04
- -7.00E-01	-3.29E-04	-1.02E-03	-3.63E-04
- -6.33E-01	-2.00E-04	-4.08E-04	-3.25E-04
- -5.67E-01	-1.68E-04	-1.57E-04	-2.88E-04
- -5.00E-01	-1.46E-04	-9.74E-05	-2.52E-04
- -4.33E-01	-1.26E-04	-7.85E-05	-2.16E-04
- -3.67E-01	-1.05E-04	-6.51E-05	-1.81E-04
- -3.00E-01	-8.52E-05	-5.26E-05	-1.47E-04
- -2.33E-01	-6.56E-05	-4.05E-05	-1.13E-04
- -1.67E-01	-4.64E-05	-2.86E-05	-8.00E-05
- -1.00E-01	-2.77E-05	-1.71E-05	-4.76E-05
- -3.33E-02	-9.20E-06	-5.70E-06	-1.58E-05
3.33E-02	9.11E-06	5.62E-06	1.57E-05
1.00E-01	2.68E-05	1.64E-05	4.64E-05
1.67E-01	4.41E-05	2.67E-05	7.68E-05
2.33E-01	6.11E-05	3.67E-05	1.07E-04
3.00E-01	7.77E-05	4.64E-05	1.37E-04
3.67E-01	9.40E-05	5.57E-05	1.66E-04
4.33E-01	1.10E-04	6.46E-05	1.95E-04
5.00E-01	1.26E-04	7.32E-05	2.24E-04
5.67E-01	1.41E-04	8.15E-05	2.52E-04
6.33E-01	1.55E-04	8.94E-05	2.80E-04
7.00E-01	1.70E-04	9.68E-05	3.07E-04
7.67E-01	1.84E-04	1.04E-04	3.33E-04
8.33E-01	1.97E-04	1.11E-04	3.58E-04
9.00E-01	2.10E-04	1.17E-04	3.82E-04
9.67E-01	2.22E-04	1.23E-04	4.04E-04
1.03E+00	2.33E-04	1.28E-04	4.25E-04
1.10E+00	2.42E-04	1.33E-04	4.43E-04
1.17E+00	2.50E-04	1.36E-04	4.59E-04
1.23E+00	2.54E-04	1.38E-04	4.72E-04
1.30E+00	2.55E-04	1.34E-04	4.81E-04
1.37E+00	2.50E-04	-5.05E-05	4.85E-04
1.43E+00	2.29E-04	-1.01E-04	4.83E-04
1.50E+00	5.45E-05	-1.03E-04	4.71E-04
1.57E+00	-1.86E-04	-1.03E-04	4.36E-04
1.63E+00	-2.04E-04	-1.01E-04	2.73E-04
1.70E+00	-2.08E-04	-9.81E-05	-7.28E-05
1.77E+00	-2.06E-04	-9.49E-05	-3.53E-04
1.83E+00	-2.01E-04	-9.14E-05	-3.81E-04
1.90E+00	-1.95E-04	-8.75E-05	-3.85E-04
1.97E+00	-1.87E-04	-8.33E-05	-3.80E-04
2.03E+00	-1.78E-04	-7.89E-05	-3.70E-04
2.10E+00	-1.68E-04	-7.41E-05	-3.57E-04
2.17E+00	-1.58E-04	-6.91E-05	-3.42E-04
2.23E+00	-1.47E-04	-6.39E-05	-3.24E-04
2.30E+00	-1.36E-04	-5.84E-05	-3.06E-04
2.37E+00	-1.25E-04	-5.27E-05	-2.86E-04
2.43E+00	-1.14E-04	-4.68E-05	-2.65E-04
2.50E+00	-1.02E-04	-4.08E-05	-2.44E-04
2.57E+00	-9.07E-05	-3.46E-05	-2.23E-04
2.63E+00	-7.92E-05	-2.83E-05	-2.01E-04
2.70E+00	-6.76E-05	-2.21E-05	-1.79E-04
2.77E+00	-5.61E-05	-1.59E-05	-1.57E-04
2.83E+00	-4.48E-05	-9.93E-06	-1.35E-04
2.90E+00	-3.36E-05	-4.68E-06	-1.13E-04
2.97E+00	-2.29E-05	-9.72E-07	-9.19E-05
3.03E+00	-1.31E-05	4.81E-07	-7.12E-05
3.10E+00	-5.06E-06	7.57E-07	-5.12E-05
3.17E+00	-9.10E-07	7.94E-07	-3.23E-05
3.23E+00	-7.98E-08	7.99E-07	-1.54E-05
3.30E+00	1.32E-09	8.00E-07	-3.56E-06
[END]

- ------=_NextPart_000_0046_01C11A66.BF73ACA0--

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

Date: Wed, 1 Aug 2001 08:41:38 -0700 
From: "Peters, Stephen" <[email-masked]>
Subject: RE: About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_du t, L_dut

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_01C11AA0.73E128F0
Content-Type: text/plain;
	charset="gb2312"

Greetings:
 
  the R_pkg, C_pkg and L_pkg values are used to specify the minimum and
maximum values of the pin resistance, capacitance and inductance for the
entire package. These values appear under the [Package] keyword.  The R_dut,
C_dut and L_dut only represent the electrical characteristics of the pin
used when gathering data for the [Rising Waveform] and [Falling Waveform]
keywords.  The 'dut' in R_dut etc. means 'device under test'.
 
(Please note that it is recomended to gather the data in the waveform tables
with R_dut, C_dut and L_dut set to zero).
 
  Regards,
  Stephen Peters
  Intel Corp.

- -----Original Message-----
From: Hailong Wang [mailto:[email-masked]]
Sent: Sunday, July 29, 2001 7:42 PM
To: [email-masked]; [email-masked]
Subject: About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut,
L_dut

Hi, 
    I found that the R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut have the very
similar functions. But form the IBIS Specification V3.2, I found they are
different. So I am confused, and want to the relationship between them. 

Thanks in advance! 

- -- 

Best Regards.

Hai-long Wang

Tel:021-62837026x228

Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza

No.55, West Huaihai Road, Shanghai, 200030, P.R.China

- ------_=_NextPart_001_01C11AA0.73E128F0
Content-Type: text/html;
	charset="gb2312"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=gb2312">

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=896163515-01082001>Greetings:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=896163515-01082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=896163515-01082001>&nbsp; the R_pkg, C_pkg and L_pkg values are used to 
specify the minimum and maximum values of the pin resistance, </SPAN><SPAN 
class=896163515-01082001>capacitance and inductance for the entire 
package.&nbsp;These values appear under the [Package] keyword.&nbsp; The R_dut, 
C_dut and L_dut only represent the electrical characteristics of the pin used 
when gathering data for the [<SPAN class=570013915-01082001>Rising Waveform] and 
[Falling Waveform]&nbsp;keywords.&nbsp; The 'dut' in R_dut etc. means 'device 
under test'.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=896163515-01082001><SPAN 
class=570013915-01082001></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=896163515-01082001><SPAN class=570013915-01082001>(Please note that it is 
recomended to gather the data in the waveform tables &nbsp;with R_dut, C_dut and 
L_dut set to zero).</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=896163515-01082001><SPAN 
class=570013915-01082001></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=896163515-01082001><SPAN class=570013915-01082001>&nbsp; 
Regards,</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=896163515-01082001><SPAN class=570013915-01082001>&nbsp; Stephen 
Peters</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
class=896163515-01082001><SPAN class=570013915-01082001>&nbsp; Intel 
Corp.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hailong Wang 
  [mailto:[email-masked]]<BR><B>Sent:</B> Sunday, July 29, 2001 7:42 
  PM<BR><B>To:</B> [email-masked]; [email-masked]<BR><B>Subject:</B> About 
  relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, 
  L_dut<BR><BR></DIV></FONT>Hi, <BR>&nbsp;&nbsp;&nbsp; I found that the 
  R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut have the very similar functions. But 
  form the IBIS&nbsp;Specification&nbsp;V3.2, I found they are different. So I 
  am confused, and want to the relationship between them. 
  <P>Thanks in advance! <PRE>--&nbsp;
Best Regards.
Hai-long Wang
Tel:021-62837026x228
Avant! Shanghai R&amp;D Center,&nbsp; 16th Floor, SunTong InfoPort Plaza
No.55, West Huaihai Road, Shanghai, 200030, P.R.China</PRE>&nbsp; 
</BLOCKQUOTE></BODY></HTML>

- ------_=_NextPart_001_01C11AA0.73E128F0--

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

Date: Wed, 1 Aug 2001 14:59:00 -0500
From: [email-masked]
Subject: Re: [SI-LIST] IBIS and device performance

Todd,

I went back to IBIS 3.2 to recheck what it said about thesholds. Here is what I
found on page 23:

|
|               Vinh, Vinl rules:
|
|               The threshold subparameter lines provide additional min and
|               max column values, if needed.  The typ column values are still
|               required and would be expected to override the Vinh and Vinl
|               subparameter values specified elsewhere.  Note: the syntax
|               rule that require inserting Vinh and Vinl under models remains
|               unchanged even if the values are defined under the [Model
|               Spec] keyword.

I'm not sure what was originally intended since, Vinl & Vinh are supposed to be
the corners of the process under worst case environmental voltage
and temperature anyway. I'm sure you know all this. But, if others are listening
maybe it should be repeated for the record.

I've looked at over 600 IBIS files from a wide variety of sources and recollect
seeing, at most, two instances of min and max values of Vinl and Vinh
given in addition to typical.

However, your question is quite interesting in light of timing getting very
tight. Like on the Pentium III and beyond. Also, it isn't quite clear to me if
Vinl - Vinh indicates +/- 3 sigma, +/- 6 sigma, "worst case," or what.

Best Regards,

Roy

"Todd Westerhoff" <[email-masked]> on 07/27/2001 01:11:10 PM

Please respond to [email-masked]

Sent by:  "Todd Westerhoff" <[email-masked]>

To:   [email-masked], [email-masked]
cc:    (Roy Leventhal/MW/US/3Com)
Subject:  [SI-LIST] IBIS and device performance

Hi all,

This particular question is going to both the SI and IBIS reflectors, as the
issues touch both groups.

Question 1 (for the SI-listers)

How often are people seeing IBIS models that use the [Model Spec] keyword to
list min/typ/max values for parameters like Vinl, Vinh and Vmeas?  Are you
seeing this commonly, or was your response "what is he talking about"?

Question/Comment 2 (for the IBISians)

Is there any definitive, short, concise document that lists which
combinations of which IBIS parameters are meant to represent best, typical,
and worst-case component-level performance?  As an example, the [max]
section of a V/I curve would clearly indicate best-case device performance,
but you'd have to combine that with the [min] value of a parameter like
c_comp.  So - for best case conditions, the EDA tool and the model creator
both have to use the same set of conventions of combining parameters for
best, typical and worst case device performance.

Is there a table anywhere that defines this?

Todd.

Todd Westerhoff
SI Engineer
Hammerhead Networks
5 Federal Street
Billerica, MA  01821
[email-masked]
ph: 978-671-5084

- ------------------------------------------------------------------
To unsubscribe from si-list:
[email-masked] with 'unsubscribe' in the Subject field
For help:
[email-masked] with 'help' in the Subject field

List archives are viewable at:
          http://www.freelists.org/archives/si-list
or at our remote archives:
          http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
          http://www.qsl.net/wb6tpu

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

Date: Thu, 02 Aug 2001 19:59:29 -0700
From: Bob Ross <[email-masked]>
Subject: IBIS BIRD73 - Fall Back Submodel

To IBIS Committee:

BIRD73 proposes a new Submodel_type to handle the electrical
operation of techologies which have the driver strength
reduced during a transition.

Bob Ross
Mentor Graphics

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

BIRD ID#:        73
ISSUE TITLE:     Fall Back Submodel
REQUESTER:       Bob Ross, Mentor Graphics
DATE SUBMITTED:  8-2-2001
DATE ACCEPTED BY IBIS OPEN FORUM:  Pending

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

STATEMENT OF THE ISSUE:

Existing submodels have a trigger for turning on functions.  This works for
Bus_hold (and corresponding active terminators) and Dynamic_clamp functions.

However another mechanism to turn off the submodels is needed for AVC type
devices which have the overall driver strength reduced after the output
passes through a voltage threshold value.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

This BIRD proposes a new Submodel_type: Fall_back.  The new submodel operates
similar to the Bus_hold submodel, but with opposite action.  The trigger
turns off a submodel (presumed on) when the output die voltage passes
through a trigger threshold.

Additions are noted in the relevant sections below by |* lines:

Comments for a new section or for unchanged sections are shown using
**** lines.

|=============================================================================
|=============================================================================
|
|                                 Section 6a
|
|              A D D    S U B M O D E L    D E S C R I P T I O N
|
|=============================================================================
|=============================================================================
|
| The [Add Submodel] keyword can be used under a top-level [Model] keyword to
| to add special-purpose functionality to the existing top-level model.  This
| section describes the structure of the top-level model and the submodel.
|
| TOP-LEVEL MODEL:
|
| When special-purpose functional detail is needed, the top-level model can
| call one or more submodels.  The [Add Submodel] keyword is positioned 
| after the initial set of required and optional subparameters of the [Model] 
| keyword and among the keywords under [Model].
| 
| The [Add Submodel] keyword lists of name of each submodel and the permitted
| mode (Driving, Non-Driving or All) under which each added submodel is used.
|
| SUBMODEL:
|
| A submodel is defined using the [Submodel] keyword.  It contains a subset
| of keywords and subparameters used for the [Model] keyword along with other
| keywords and subparameters that are needed for the added functionality.
|
| The [Submodel] and [Submodel Spec] keywords are defined first since they
| are used for all submodels 
|
| The only required subparameter in [Submodel] is Submodel_type to define the
| list of submodel types.  No subparameters under [Model] are permitted under
| the [Submodel] keyword.
|
| The following set of keywords that are defined under the [Model] keyword are
| supported by the [Submodel] keyword:
|
| [Pulldown]
| [Pullup]
| [GND Clamp]
| [POWER Clamp]
| [Ramp]
| [Rising Waveform]
| [Falling Waveform]
|
| The [Voltage Range], [Pullup Reference], [Pulldown Reference], [GND Clamp
| Reference], and [POWER Clamp Reference] keywords are not permitted.  The
| voltage settings are inherited from the top-level model.
|
| These additional keywords are used only for the [Submodel] are documented
| in this section:
|
| [Submodel Spec]
| [GND Pulse Table]
| [POWER Pulse Table]
|
| The application of these keywords depends upon the Submodel_type entries
| listed below:
|
| Dynamic_clamp
| Bus_hold
|* Fall_back
|
| Permitted keywords that are not defined for any of these submodel types are
| ignored.  The rules for what set of keywords are required are found under
| the Dynamic Clamp and Bus Hold headings of this section.
|
|=============================================================================
|     Keyword:  [Submodel]
|    Required:  No
| Description:  Used to define a submodel, and its attributes.
|  Sub-Params:  Submodel_type        
| Usage Rules:  Each submodel must begin with the keyword [Submodel].  The
|               submodel name must match the one that is listed under an
|               [Add Submodel] keyword and must not contain more than 20
|               characters.  A .ibs file must contain enough [Submodel]
|               keywords to cover all of the model names specified under the
|               [Add Submodel] keyword.
|
|               Submodel_type subparameter is required and must be one of the
|               following:
|
|*               Dynamic_clamp, Bus_hold, Fall_back
|
|               The C_comp subparameter is not permitted under the [Submodel]
|               keyword.  The total effective die capacitance including the
|               submodel contributions are provided in the top-level model.
|
| Other Notes:  The following list of keywords that are defined under the 
|               [Model] keyword can be used under [Submodel]:  [Pulldown], 
|               [Pullup], [GND Clamp], [POWER Clamp], [Ramp], [Rising
|               Waveform], and [Falling Waveform].
|
|               The following list of additional keywords can be used:
|               [Submodel Spec], [GND Pulse Table], and [POWER Pulse Table].
|-----------------------------------------------------------------------------
[Submodel]      Dynamic_clamp1
Submodel_type   Dynamic_clamp
|

**** The next two sections are unchanged, but are shown for reference:

|============================================================================= 
|     Keyword:  [Submodel Spec]
|    Required:  No
| Description:  The [Submodel Spec] keyword defines four columns under which 
|               specification and information subparameters are defined for 
|               submodels.
|  Sub-Params:  V_trigger_r, V_trigger_f, Off_delay
| Usage Rules:  The [Submodel Spec] is to be used only with submodels.
|
|               The following subparameters are used:
|                 V_trigger_r           Rising edge trigger voltage 
|                 V_trigger_f           Falling edge trigger voltage 
|                 Off_delay             Turn-off delay from V_trigger_r or
|                                       V_trigger_f
|
|               For each subparameter contained in the first column, the
|               remaining three hold its typical, minimum and maximum values. 
|               The entries of typical, minimum and maximum be must be placed 
|               on a single line and must be separated by at least one white 
|               space.  All four columns are required under the [Submodel
|               Spec] keyword.  However, data is required only in the typical
|               column.  If minimum and/or maximum values are not available,
|               the reserved word "NA" must be used to indicate the typical
|               value by default. 
|
|               The values in the minimum and maximum columns usually
|               correspond to the values in the same columns for the inherited 
|               top-level voltage range or reference voltages in the top-level 
|               model.  The V_trigger_r and V_trigger_f subparameters should
|               hold values in the minimum and maximum columns that correspond
|               to the voltage range or reference voltages of the top-level
|               model.  The Off_delay subparameter, however, is an exception
|               to this rule because in some cases it may be completely or
|               or partially independent from supply voltages and/or
|               manufacturing process variations.  Therefore the minimum and
|               maximum entries for the Off_delay subparameter should be
|               ordered simply by their magnitude.
|
|               Unless noted, each [Submodel Spec] subparameter is independent 
|               of any other subparameter.
|
|               V_trigger_r, V_trigger_f rules: 
|
|               The voltage trigger values for the rising and falling edges 
|               provide the starting time when an action is initiated.
|
|               Off_delay rules: 
|
|               The functionality of the Off_delay subparameter is to provide
|               an additional time related mechanism to turn off circuit
|               elements.
|
|----------------------------------------------------------------------------- 
| Dynamic Clamp Example:
|
[Submodel Spec]
|   Subparameter          typ        min        max 
|
V_trigger_r               3.6        2.9        4.3 | Starts power pulse table 
V_trigger_f               1.4        1.2        1.6 | Starts gnd pulse table
|
| Bus Hold Example:
|
[Submodel Spec]
|   Subparameter          typ        min        max
V_trigger_r               3.1        2.4        3.7 | Starts low to high
                                                    | bus hold transition
V_trigger_f               1.8        1.6        2.0 | Starts high to low
                                                    | bus hold transition
|
| Bus_hold application with pullup structure triggered on and then clocked off: 
|
[Submodel Spec]
|   Subparameter          typ        min        max
V_trigger_r               3.1        2.4        3.7 | Low to high transition
                                                    | triggers the turn on 
                                                    | process of the pullup
V_trigger_f             -10.0      -10.0      -10.0 | Not used, so trigger
                                                    | voltages are set out 
                                                    | of range
Off_delay                 5n         6n         4n  | Time from rising edge
                                                    | trigger at which the
                                                    | pullup turned off
|
|=============================================================================
|=============================================================================
|
| Bus Hold:
|
| When the Submodel_type subparameter under the [Submodel] keyword is set to 
| Bus_hold, the added model describes the bus hold functionality.  However, 
| while described in terms of bus hold functionality, active terminators
| can also be modeled.
|
| Existing keywords and subparameters are used to describe bus hold models. 
| The [Pullup] and [Pulldown] tables both are used to define an internal
| buffer that is triggered switch to its opposite state.  This switching 
| transition is specified by a [Ramp] keyword or by the [Rising Waveform] and
| [Falling Waveform] keywords.  The usage rules for these keywords are the 
| same as under the [Model] keyword.  In particular, at least either the
| [Pullup] or [Pulldown] keyword is required.  Also, the [Ramp] keyword is
| required, even if the [Rising Waveform] and [Falling Waveform] tables exist. 
| However, the voltage ranges and reference voltages are inherited from the
| top-level model.
|
| For bus hold submodels, the [Submodel Spec] keyword, V_trigger_r, and
| V_trigger_f are required.  The Off_delay subparameter is optional, but can
| only be used if the submodel consists of a pullup or a pulldown structure
| only, and not both.  Devices which have both pullup and pulldown structures
| controlled in this fashion can be modeled using two submodels, one for each
| half of the circuit.
|
| The transition is triggered by action at the die using the [Submodel Spec] 
| V_trigger_r and V_trigger_f subparameters as follows:
|
| If the starting voltage is below V_trigger_f, then the bus hold model is set
| to the low state causing additional pulldown current.  If the starting 
| voltage is above V_trigger_r, the bus hold model is set to the high state
| for additional pullup current.  When the input passes though V_trigger_f
| during a high-to-low transition at the die, the bus hold output switches to
| the low state.  Similarly, when the input passes though V_trigger_r during
| a low-to-high transition at the die, the bus hold output switches to the
| high state.
|
| If the bus hold submodel has a pullup structure only, V_trigger_r provides
| the time when its pullup is turned on and V_trigger_f or Off_delay provides
| the time when it is turned off, whichever occurs first.  Similarly, if the
| submodel has a pulldown structure only, V_trigger_f provides the time when
| its pulldown is turned on and V_trigger_r or Off_delay provides the time
| when it is turned off, whichever occurs first.  The required V_trigger_r
| and V_trigger_f voltage entries can be set to values outside of the input
| signal range if the pullup or pulldown structures are to be held on until
| the Off_delay turns them off.
|
| The starting mode for each of the submodels which include the Off_delay
| subparameter of the [Submodel Spec] keyword is the off state.  Also, while
| two submodels provide the desired operation, either of the submodels may
| exist without the other to simulate turning on and off only a pullup or a
| pulldown current.
|
| No additional keywords are needed for this functionality. 
|----------------------------------------------------------------------------- 
|
| Complete Bus Hold Model Example:
|
[Submodel]       Bus_hold_1
Submodel_type    Bus_hold
|
[Submodel Spec]
|   Subparameter          typ        min        max 
|
V_trigger_f               1.3        1.2        1.4  | Falling edge trigger 
V_trigger_r               3.1        2.6        4.6  | Rising edge trigger 
|
|                         typ        min        max
| [Voltage Range]           5.0        4.5        5.5
| Note, the actual voltage range and reference voltages are inherited from 
| the top-level model.
|
[Pulldown]
|
- -5V     -100uA     -80uA     -120uA
- -1V     -30uA      -25uA     -40uA
0V       0           0         0
1V       30uA       25uA     40uA
3V       50uA       45uA     50uA
5V       100uA      80uA     120uA
10v      120uA      90uA     150uA
|
[Pullup]
|
- -5V      100uA      80uA     120uA
- -1V      30uA       25uA     40uA
0V       0           0         0
1V      -30uA      -25uA    -40uA
3V      -50uA      -45uA    -50uA
5V      -100uA     -80uA    -120uA
10v     -120uA     -90uA    -150uA
|
|----------------------------------------------------------------------------- 
|
[Ramp]
|                       typ             min             max 
dV/dt_r                 2.0/0.50n       2.0/0.75n       2.0/0.35n 
dV/dt_f                 2.0/0.50n       2.0/0.75n       2.0/0.35n 
R_load = 500
|
|----------------------------------------------------------------------------- 
|
| Complete Pullup Timed Latch Example: 
|
[Submodel]       Timed_pullup_latch
Submodel_type    Bus_hold
|
[Submodel Spec]
|   Subparameter          typ        min        max 
|
V_trigger_r               3.1        2.6        4.6  | Rising edge trigger 
                                                     | Values could be set out
                                                     | of range to disable the
                                                     | trigger
V_trigger_f               1.3        1.2        1.4  | Falling edge
trigger[Submodel]       Dynamic_Output_r
Submodel_type    Fall_back
|
[Submodel Spec]
|   Subparameter          typ        min        max 
|
V_trigger_f             -10.0      -10.0      -10.0  | Falling edge trigger
                                                     | set out of range to 
                                                     | disable trigger
V_trigger_r               3.1        2.6        4.6  | Rising edge trigger 
|
|                         typ        min        max
| [Voltage Range]           5.0        4.5        5.5
| Note, the actual voltage range and reference voltages are inherited from 
| the top-level model.
|
[Pullup]
|
- -5V      100mA      80mA      120mA
0V       0           0         0
10v     -200mA     -160mA    -240mA
|
| [Pulldown] table omitted to signify an Open_source Submodel.
|
|----------------------------------------------------------------------------- 
|
[Ramp]
|                       typ             min             max 
dV/dt_r                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
dV/dt_f                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
R_load = 50
|
|----------------------------------------------------------------------------- 
[Submodel]       Dynamic_Output_r
Submodel_type    Fall_back
|
[Submodel Spec]
|   Subparameter          typ        min        max 
|
V_trigger_f             -10.0      -10.0      -10.0  | Falling edge trigger
                                                     | set out of range to 
                                                     | disable trigger
V_trigger_r               3.1        2.6        4.6  | Rising edge trigger 
|
|                         typ        min        max
| [Voltage Range]           5.0        4.5        5.5
| Note, the actual voltage range and reference voltages are inherited from 
| the top-level model.
|
[Pullup]
|
- -5V      100mA      80mA      120mA
0V       0           0         0
10v     -200mA     -160mA    -240mA
|
| [Pulldown] table omitted to signify an Open_source Submodel.
|
|----------------------------------------------------------------------------- 
|
[Ramp]
|                       typ             min             max 
dV/dt_r                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
dV/dt_f                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
R_load = 50
|
|----------------------------------------------------------------------------- 

Off_delay                 3n         5n         2n   | Delay to turn off the
                                                     | pullup table
|
| Note that if the input signal goes above the V_trigger_r value, the
| pulldown structure will turn off even if the timer didn't expire yet.
|
|                         typ        min        max
| [Voltage Range]         5.0        4.5        5.5
| Note, the actual voltage range and reference voltages are inherited from 
| the top-level model.
|
[Pulldown]
|
- -5V     -100uA     -80uA     -120uA
- -1V      -30uA     -25uA     -40uA
0V       0           0         0
1V       30uA       25uA     40uA
3V       50uA       45uA     50uA
5V       100uA      80uA     120uA
10v      120uA      90uA    150uA
|
| [Pullup] table is omitted to signal Open_source functionality 
|
|----------------------------------------------------------------------------- 
|
[Ramp]
|                       typ             min             max 
dV/dt_r                 2.0/0.50n       2.0/0.75n       2.0/0.35n 
dV/dt_f                 2.0/0.50n       2.0/0.75n       2.0/0.35n 
R_load = 500
|
|=============================================================================

**** This section is added: 

|=============================================================================
|=============================================================================
|
| Fall Back:
|
| When the Submodel_type subparameter under the [Submodel] keyword is set to 
| Fall_back, the added model describes the fall back functionality.  This
| submodel can be used to model drivers that reduce their strengths and
| increase their output impedances during their transitions.  The fall back
| function can be considered opposite of the bus hold function, but there
| some details discussed below that are unique. 
|
| Existing keywords and subparameters are used to describe fall back models. 
| The [Pullup] and [Pulldown] tables both are used to define an internal
| buffer that is triggered switch to its opposite state.  This switching 
| transition is specified by a [Ramp] keyword or by the [Rising Waveform] and
| [Falling Waveform] keywords.  The usage rules for these keywords are the 
| same as under the [Model] keyword.  In particular, at least either the
| [Pullup] or [Pulldown] keyword is required.  Also, the [Ramp] keyword is
| required, even if the [Rising Waveform] and [Falling Waveform] tables exist. 
| However, the voltage ranges and reference voltages are inherited from the
| top-level model.
|
| For fallback submodels, the [Submodel Spec] keyword, V_trigger_r, and
| V_trigger_f are required.  Unlike the bus hold model, the Off_delay
| subparameter is not permitted.  Devices which have both pullup and pulldown
| structures can be modeled using two submodels, one for the rising cycle
| and one for the falling cycle.
|
| The transition is triggered by action at the die using the [Submodel Spec] 
| V_trigger_r and V_trigger_f subparameters as follows:
|
|   SIMULATOR RISING CYCLE:
|
|   Prior         Vdie            Rising Edge    Vdie > V_trigger_r
|   State                         Transition     Transition
|
|   low/none      <= V_trigger_r  low-to-high    high-to-low
|                 > V_trigger_r   Set/stays low  Stays low
|
|   high          <= V_trigger_r  Stays high     high-to-low
|                 > V_trigger_r   high-to-low    Stays low
|
|   SIMULATOR FALLING CYCLE:
|
|   Prior         Vdie            Falling Edge   Vdie < V_trigger_f
|   State                         Transition     Transition
|
|   high/none     => V_trigger_f  high-to-low    low-to-high
|                 < V_trigger_f   Set/stays high Stays high
|
|   low           <= V_trigger_f  Stays low      high-to-low
|                 > V_trigger_f   low-to-high    Stays high
|
|   The prior state of "none" describes the initial setting for the first
|   simulator edge encountered, either RISING or FALLING.  After that the
|   prior state is tracked.
|
| One application is to configure the submodel with one pullup structure only.
| At the beginning of the rising edge cycle, the pullup is turned on to the
| high state.  When the die voltage passes V_trigger_r, the pullup structure
| is turned off.  Because only the pullup structure is used, the off state is
| the same as a high-Z state.  During the falling transition, the pullup 
| remains in the high-Z state.  The V_trigger_f is set out of range, so no
| futher change of state occurs.  With this approach, the overall rising
| transition starts by turning the fall back submodel turned on.  This
| submodel is triggered to drop out after the output die voltage passes a
| trigger voltage, and it remains off until the next rising transition is
| initiated.
|
| A similar submodel consisting of only a pulldown structure could be
| constructed to provide added drive strength only at the beginning of the
| falling cycle.  The complete IBIS model would have both submodels to give
| added drive strength for both the start of the rising and the start of the
| falling cycles.
|
| No additional keywords are needed for this functionality. 
|----------------------------------------------------------------------------- 
|
| Complete Dynamic Output Model Example Using Two Submodels:
|
[Submodel]       Dynamic_Output_r
Submodel_type    Fall_back
|
[Submodel Spec]
|   Subparameter          typ        min        max 
|
V_trigger_f             -10.0      -10.0      -10.0  | Falling edge trigger
                                                     | set out of range to 
                                                     | disable trigger
V_trigger_r               3.1        2.6        4.6  | Rising edge trigger 
|
|                           typ        min        max
| [Voltage Range]           5.0        4.5        5.5
| Note, the actual voltage range and reference voltages are inherited from 
| the top-level model.
|
[Pullup]
|
- -5V      100mA      80mA      120mA
0V       0           0         0
10v     -200mA     -160mA    -240mA
|
| [Pulldown] table omitted to signify an Open_source Submodel.
|
|----------------------------------------------------------------------------- 
|
[Ramp]
|                       typ             min             max 
dV/dt_r                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
dV/dt_f                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
R_load = 50
|
|----------------------------------------------------------------------------- 
|
[Submodel]       Dynamic_Output_f
Submodel_type    Fall_back
|
[Submodel Spec]
|   Subparameter          typ        min        max 
|
V_trigger_r               10.0       10.0       10.0 | Rising edge trigger
                                                     | set out of range to 
                                                     | disable trigger
V_trigger_f               1.3        1.2        1.4  | Falling edge trigger
|
|                           typ        min        max
| [Voltage Range]           5.0        4.5        5.5
| Note, the actual voltage range and reference voltages are inherited from 
| the top-level model.
|
[Pulldown]
|
- -5V     -100mA     -80mA     -120mA
0V       0           0         0
10v      200mA      160mA     240mA
|
| [Pullup] table omitted to signify an Open_drain Submodel.
|
|----------------------------------------------------------------------------- 
|
[Ramp]
|                       typ             min             max 
dV/dt_r                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
dV/dt_f                 1.5/0.50n       1.43/0.75n      1.58/0.35n 
R_load = 50
|
|----------------------------------------------------------------------------- 

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

The AVC technology is structured using various trade marked terms such as
Dynamic Output Control(tm), Dynamic Control Output(tm), etc.  They are
designed to operate by starting at full strength, but finishing at a reduced
strength (higher impedance) when the output voltage passes through a trigger
voltage.  The final higher impedance usually matches better the load (such as
a transmission line equivalent circuit of the printed circuit board trace) to
produce better signal integrity matching conditions.

The operation is opposite of the Bus_hold submodel which is triggered to
turn on when the die voltage passes a threshold voltage.  So a bus hold
structure cannot be configured or modified to produce this "fall back"
effect.

BIRD73 proposes a new submodel which mimics the opposite effect.  The main
idea is that when the output voltage passes a trigger voltage, a rising
transition buffer changed to a falling transition, and a falling transition
buffer is changed to a rising transition.  The two existing [Submodel]
subparameters V_trigger_r and V_trigger_f are used for the fall back
operation.

Unlike the bus hold submodel, the rules for setting the initial state are
more complicated.  Furthermore, prior history or conditions could already
nullify some transitions.  Within a simulator rising edge cycle, 0, 1 or 2
transitions are possible.  One can be initiated at the start of the cycle,
and the other initiated when the output voltage passes V_trigger_r.  Several
initialization and switching conditions exist, and a table is used to
document the allowable fixed and transition states:

SIMULATOR RISING CYCLE:

  Prior         Vdie            Rising Edge    Vdie > V_trigger_r
  State                         Transition     Transition

  low/none      <= V_trigger_r  low-to-high    high-to-low
                > V_trigger_r   Set/stays low  Stays low

  high          <= V_trigger_r  Stays high     high-to-low
                > V_trigger_r   high-to-low    Stays low

SIMULATOR FALLING CYCLE:

  Prior         Vdie            Falling Edge   Vdie < V_trigger_f
  State                         Transition     Transition

  high/none     => V_trigger_f  high-to-low    low-to-high
                < V_trigger_f   Set/stays high Stays high

  low           <= V_trigger_f  Stays low      high-to-low
                > V_trigger_f   low-to-high    Stays high

The prior state of "none" describes the initial setting for the first
simulator edge encountered, either RISING or FALLING.  After that the
prior state is tracked.

The number of transitions for each simulator cycle is limited to two or less.
It might be possible to connect several fall back and bus hold submodels in
a manner and with different V_trigger_r and V_trigger_f values to work 
against each other to cause the Vdie to move above and below the V_trigger_*
values several times within a cycle.  There does not appear to be any
practical reason to make the above state and transition tables more
complicated to account for opposite direction movement (or oscillation)
around V_trigger_*.  So after the RISING or FALLLING transitions are
initiated, some states are simply held constant regardless of potential
oscillations.  Such fixed stated are defined by "Stays high" or "Stays low".

The rules are set to work in a manner consistent with the bus hold submodel.
However, Off_delay subparameter is not supported here.  Nor is the opposite
acting subparameter proposed that might be called "Off_delay" that might
add one more transition reversal after a V_trigger_* transition.  There does
not appear to be any practical need for such an extension which would add
complication to the state and transition conditions above.

While a complete set of states and transitions are defined, the most
practical implementation for AVC technology is intended to be done with
adding two submodels, one with only a [Pullup] table for rising edge
impedance control, and one with only a [Pulldown] table for falling edge
impedance control.  With this setup, the corresponding "off" states will
be high-Z making each submodel function independently for each edge only
to increase the impedance of the final state of the buffer.  As in other
submodels, letting the V_trigger_* values to be set out of range is used
to keep the off state of the submodel in the high-Z mode.  This is shown
in an example.

The need for providing the new functionality currently exists and is proposed
for IBIS Version 4.0 as a shorter term solution.  BIRD73 also provides the
basis for considering a more advanced solution that could be achieved using
a proposed IBIS-X Macro language.  This later solution could also provide more
detail and a superset of what is currently practical for Version 4.0.

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

ANY OTHER BACKGROUND INFORMATION:

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

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

End of ibis V1 #1
*****************