Re: Can't do T-LINE?

From: Stephen Peters <sjpeters@ichips.intel.com>
Date: Thu May 21 1998 - 08:26:58 PDT

Anders Ekholm wrote:

> Excuse me, but wouldn't that mean that you only will
> be able to use one T-line segment as a package
> modell ?
>
> That would imply that the package is uniform, and
> I would suppose that most packages are not. To get
> an accurate model you need multiple T-line segment
> models. Is that not possible in IBIS 3.0 ?

     Multiple T-line segments are possible in the package
     description of IBIS 3.0. They are also available in
     the electrical board description.

            Regards,
            Stephen Peters
            Intel Corp.

>
> Best Regards /Anders Ekholm
> Ericsson Telecom
>
>
>
> > From owner-ibis@server.vhdl.org Wed May 20 04:46 MET 1998
> > From: bobr@emicx.mentorg.com (Bob Ross)
> > Date: Tue, 19 May 98 19:03:38 PDT
> > To: crokusek@viewlogic.com, ibis@eda.org
> > Subject: Re: Can't do T-LINE?
> > Cc: bobr@emicx.mentorg.com
> > Mime-Version: 1.0
> > X-Status: $$$$
> > X-UID: 0000001041
> >
> > Chris:
> >
> > The L, C, and R parameters are given as CORRESPONDING per unit length values.
> > These are multiplied by Len to produce the total distributed values for the
> > exact length of T-line that you want.
> >
> > Whenever Len is not equal to zero, the section is interpreted as
> > a distributed section (not a lumped section).
> >
> > The T-line relationships still hold:
> >
> > Zo = sqrt(L/C)
> > TD = Len * sqrt(LC)
> >
> > So the electrical information is available for a T-line of whatever length
> > you want.
> >
> > Best Regards,
> > Bob Ross
> > Interconnectix/Mentor Graphics
> >
> >
> > > Sender: crokusek@qdt.com
> > > Date: Tue, 19 May 1998 17:56:15 -0700
> > > From: Chris Rokusek <crokusek@viewlogic.com>
> > > To: ibis@eda.org
> > > Subject: Can't do T-LINE?
> >
> > > ( I am reposting this question in hopes of a more helpful response )
> >
> > > Hi All,
> >
> > > Concerning [Path Description] section in Ver 3.x of .ibs...
> >
> > > The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not
> > > meters) such that a distributed T-LINE model cannot be built with the
> > > proper physical length.
> >
> > > ** I DO NOT WANT TO BUILD A LUMPED MODEL, I WANT TO BUILD A T-LINE MODEL
> > > **
> >
> > > Is this an oversight or am I not understanding the parameters?
> >
> > > Best Regards,
> >
> > > Chris Rokusek
> > > Viewlogic Systems
> >
> > >
> > >
> > > |=============================================================================
> > > | Keyword: [Path Description]
> > > | Required: Yes
> > > | Description: This keyword allows the user to describe the connection
> > > | between the user accessible pins of a part and the pins
> > > of the
> > > | ICs mounted on that part. Each pin to node connection
> > > is
> > > | divided into one or more cascaded "sections", where each
> > > | section is described in terms of it's L/R/C per unit
> > > length.
> > > | The Fork and Endfork subparameters allow the path to
> > > branch to
> > > | multiple nodes, or another pin. A path description is
> > > | required for each pin whose signal name is not "GND",
> > > "POWER"
> > > | or "NC".
> > > |
> > > | Board Description and IC Boundaries:
> > > |
> > > | In any system, each part interfaces with another part at
> > > some
> > > | boundary. Every part model must contain the components
> > > | necessary to represent the behavior of the part being
> > > modeled
> > > | within its boundaries. The boundary definition depends
> > > upon
> > > | the parts being represented by the model.
> > > |
> > > | For CARD EDGE CONNECTIONS such as a SIMM or a PC
> > > Daughter
> > > | Card plugged into a SIMM Socket or Edge Connector, the
> > > | boundary should be at the end of the board card edge
> > > pads as
> > > | they emerge from the connector.
> > > |
> > > | For any THROUGH-HOLE MOUNTED PART, the boundary will be
> > > at the
> > > | surface of the board on which the part is mounted.
> > > |
> > > | SURFACE MOUNTED PART models end at the outboard end of
> > > their
> > > | recommended surface mount pads.
> > > |
> > > | If the board level component contains an UNMATED
> > > CONNECTOR,
> > > | the unmated connector will be described in a separate
> > > file,
> > > | with its boundaries being as described above for the
> > > | through-hole or surface mounted part.
> > > |
> > > | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node
> > > | Usage Rules: Each individual connection path (user pin to node(s))
> > > | description begins with the [Path Description] keyword
> > > and a
> > > | path name, followed by the subparameters used to
> > > describe the
> > > | path topology and the electrical characteristics of each
> > > | section of the path. The path name must not exceed 40
> > > | characters, blanks are not allowed, and each occurrence
> > > of the
> > > | [Path Description] keyword must be followed by a unique
> > > path
> > > | name. Every signal pin (pins other than POWER, GND or
> > > NC)
> > > | must appear in one and only one path description per
> > > [Begin
> > > | Board Description]/[End Board Description] pair. Pin
> > > names do
> > > | not have to appear in the same order as listed in the
> > > [Pin
> > > | List] table. The individual subparameters are broken up
> > > into
> > > | those that describe the electrical properties of a
> > > section,
> > > | and those that describe the topology of a path.
> > > |
> > > | Section Description Subparameters:
> > > |
> > > | The Len, L, R, and C subparameters specify the length,
> > > the
> > > | series inductance and resistance and the capacitance to
> > > ground
> > > | of each section in a path description.
> > > |
> > > | Len The physical length of a section. Lengths are
> > > given
> > > | in terms of arbitrary 'units'. Any non-zero
> > > length
> > > | requires that the parameters that follow must be
> > > | interpreted as distributed elements by the
> > > simulator.
> > > | L The series inductance of a section, in terms of
> > > | 'inductance/unit length'. For example, if the
> > > total
> > > | inductance of a section is 3.0 nH and the length
> > > of
> > > | the section is 2 'units', the inductance would
> > > be
> > > | listed as L = 1.5 nH (i.e. 3.0 / 2).
> > > | C The capacitance to ground of a section, in terms
> > > of
> > > | capacitance per unit length.
> > > | R The series DC (ohmic) resistance of a section,
> > > in
> > > | terms of ohms per unit length.
> > > |
> > > | Topology Description Subparameters:
> > > |
> > > | The Fork and Endfork subparameters denote branches from
> > > the
> > > | main pin-to-node or pin-to-pin connection path. The
> > > Node
> > > | subparameter is used to reference the pin of a component
> > > or
> > > | board as defined in a .ibs or .ebd file. The Pin
> > > subparameter
> > > | is used to indicate the point at which a path connects
> > > to a
> > > | user visible pin.
> > > |
> > > | Fork This subparameter indicates that the sections
> > > | following (up to the Endfork subparameter) are
> > > part
> > > | of a branch off of the main connection path.
> > > This
> > > | subparameter has no arguments.
> > > | Endfork This subparameter indicates the end point of a
> > > branch.
> > > | For every Fork subparameter there must be a
> > > | corresponding Endfork subparameter. As with the
> > > Fork
> > > | subparameter, the Endfork subparameter has no
> > > | arguments.
> > > | Node reference_designator.pin
> > > | This subparameter is used when the connection
> > > path
> > > | connects to a pin of another, externally defined
> > > part.
> > > | The arguments of the Node subparameter indicate
> > > the
> > > | pin and reference designator of the external
> > > | component. The pin and reference designator
> > > portions
> > > | of the argument are separated by a period
> > > ("."). The
> > > | reference designator is mapped to an external
> > > | component description (another .ebd file or .ibs
> > > file)
> > > | by the [Reference Designator Map] Keyword. Note
> > > that
> > > | a Node MUST reference a model of a passive or
> > > active
> > > | component. A Node is not an arbitrary
> > > connection
> > > | point between two elements or paths.
> > > | Pin This subparameter is used to mark the point at
> > > which
> > > | a path description connects to a user accessible
> > > pin.
> > > | Every path description must contain at least one
> > > | occurrence of the Pin subparameter. It may also
> > > | contain the reserved word NC. The value of the
> > > Pin
> > > | subparameter must be one of the pin names listed
> > > in
> > > | the [Pin List] section.
> > > |
> > > | Using The Subparameters to Describe Paths:
> > > |
> > > | A section description begins with the Len subparameter
> > > and
> > > | ends with the slash (/) character. The value of the
> > > Len, L,
> > > | R, and C subparameters and the subparameter itself are
> > > | separated by an equals sign (=); whitespace around the
> > > equals
> > > | sign is optional. The Fork, Endfork, Node and Pin
> > > | subparameters are placed between section descriptions
> > > (i.e.,
> > > | between the concluding slash of one section and the
> > > 'Len'
> > > | parameters that starts another). The arguments of the
> > > Pin and
> > > | Node subparameter are separated by white space.
> > > |
> > > | Specifying a Len or L/R/C value of zero is allowed. If
> > > | Len = 0 is specified, then the L/R/C values are the
> > > total for
> > > | that section. If a non-zero length is specified, then
> > > the
> > > | total L/R/C for a section is calculated by multiplying
> > > the
> > > | value of the Len subparameter by the value of the L, R,
> > > or C
> > > | subparameter. However, as noted below, if a non-zero
> > > length
> > > | is specified, that section MUST be interpreted as
> > > distributed
> > > | elements.
> > > |
> > > | Legal Subparameter Combinations for Section
> > > Descriptions:
> > > |
> > > | A) Len, and one or more of the L, R and C
> > > subparameters. If
> > > | the Len subparameter is given as zero, then the L/R/C
> > > | subparameters represent lumped elements. If the Len
> > > | subparameter is non-zero, then the L/R/C subparameters
> > > | represent distributed elements and both L and C must be
> > > | specified, R is optional.
> > > |
> > > | B) The first subparameter following the [Path
> > > Description]
> > > | keyword must be 'Pin', followed by one or more section
> > > | descriptions. The path description can terminate in a
> > > Node,
> > > | another pin or the reserved word, NC.
> > > |
> > > | Dealing With Series Elements:
> > > |
> > > | A discrete series R or L component can be included in a
> > > path
> > > | description by defining a section with L=0 and the
> > > proper R or
> > > | L value. A discrete series component can also be
> > > included in
> > > | a path description by writing two back to back node
> > > statements
> > > | that reference the same component (see the example
> > > below).
> > > | Note that both ends of a discrete, two terminal
> > > component MUST
> > > | be contained in a single [Path Description]. Connecting
> > > two
> > > | separate [Path Description] with a series component is
> > > not
> > > | allowed.
> > > |-----------------------------------------------------------------------------
> > > |
> > > | An Example Path For a SIMM Module:
> > > |
> > > [Path Description] CAS_2
> > > Pin J25
> > > Len = 0.5 L=8.35n C=3.34p R=0.01 /
> > > Node u21.15
> > > Len = 0.5 L=8.35n C=3.34p R=0.01 /
> > > Node u22.15
> > > Len = 0.5 L=8.35n C=3.34p R=0.01 /
> > > Node u23.15
> > > |
> > > | A Description Using The Fork and Endfork Subparameters:
> > > |
> > > [Path Description] PassThru1
> > > Pin B5
> > > Len = 0 L=2.0n /
> > > Len = 2.1 L=6.0n C=2.0p /
> > > Fork
> > > Len = 1.0 L = 1.0n C= 2.0p /
> > > Node u23.15
> > > Endfork
> > > Len = 1.0 L = 6.0n C=2.0p /
> > > Pin A5
> > > |
> > > | A Description Including a Discrete Series Element:
> > > |
> > > [Path Description] sig1
> > > Pin B27
> > > Len = 0 L=1.6n /
> > > Len = 1.5 L=6.0n C=2.0p /
> > > Node R2.1
> > > Node R2.2
> > > Len = 0.25 L=6.0n C=2.0p /
> > > Node U25.6
> > > |
> > > |=============================================================================
> >
> >
> >
Received on Thu May 21 08:30:21 1998

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT