Hello A.D.:
I will respond only briefly to your question since
I am involved on some other issues right now.
While the TT parameter estimate might exist within
the Spice code, it still may only be an estimate.
Use it as a starting point, if available.
The process is to simulate the same model in your
simulator and see if it exhibits the same kickback
response starting around 6 nS without TTgnd. If
the response is already close, do nothing.
If not, try TTgnd of about 6 nS and see if that
causes about the same response. If the simulated
kickback is at a different location, then to
iterate on a value that matches the Spice (or
measured data) to get the effective TTgnd for
the purposes of simulation.
Note, the Intent of this addition is to give
a first order presentation of the kickback
effect only when it is a factor. Due to some
diode series R details, the simulation probably
will not correspond exactly with the Spice simulation.
Best Regards,
Bob Ross
Interconnectix/Mentor Graphics.
> Date: Wed, 25 Mar 1998 13:10:44 +0531 (IST)
> From: "A. D. Shirpadaraj" <ads@cadence.com>
> Message-Id: <199803250739.NAA05717@corona.cadence.com>
> To: ibis-users@eda.org
> Subject: Transit time extraction related issues for IBIS 3.0
> Cc: ads@corona.cadence.com
> Hi,
> Can anybody explain me the importance of Transit time information(with
> reference to IBIS 3.0 spec).
> I simulated an I/O buffer spice netlist(disabling the output so that I
> can get only clamp data), attaching the load(as specified in the section
> "Notes on Data derivation method" of IBIS 3.0 spec doc) and connecting
> a pulse generator with falling edge rate of 1ns.
> Input of I/O buffer is at Gnd level.
> _________ _______
> | | ______________ |PULSE |
> |I/O BUFF |--0-----|______________|-------\/\/\/\----|GEN | __
> | | ^ T LINE 10 OHM |_______| \
> --------- | \
> | \______
> |____ tdrv
> The simulation result is as follows,
> time voltage voltage
> (Pulse gen) tdrv
> 0. 3.3000 3.3000
> 400.00000p 1.9800 3.3000
> 800.00000p 660.0000m 3.3000
> 1.20000n 0. 2.7999
> 1.60000n 0. 1.1855
> 2.00000n 0. -745.8083m
> 2.40000n 0. -765.5829m
> 2.80000n 0. -764.9445m
> 3.20000n 0. -766.0098m
> 3.60000n 0. -743.5182m
> 4.00000n 0. -593.9329m
> 4.40000n 0. -480.4755m
> 4.80000n 0. -451.3177m
> 5.20000n 0. -454.4898m
> 5.60000n 0. -286.7090m
> 6.00000n 0. 152.1383m
> 6.40000n 0. 292.0734m
> 6.80000n 0. 307.6836m
> 7.20000n 0. 300.9822m
> 7.60000n 0. 323.2456m
> 8.00000n 0. 243.2512m
> 8.40000n 0. -10.6594m
> 8.80000n 0. -152.1871m
> 9.20000n 0. -193.6911m
> 9.60000n 0. -196.4707m
> 10.00000n 0. -222.0614m
> 10.40000n 0. -164.7043m
> 10.80000n 0. -24.4593m
> 11.20000n 0. 78.7876m
> 11.60000n 0. 115.6422m
> 12.00000n 0. 125.1014m
> 12.40000n 0. 145.4857m
> 12.80000n 0. 119.0935m
> 13.20000n 0. 35.9285m
> 13.60000n 0. -34.7450m
> 14.00000n 0. -69.3589m
> 14.40000n 0. -80.1839m
> 14.80000n 0. -96.5231m
> 15.00000n 0. -100.8460m
> The driver output is having both positive and negative glitches.
> How to find transit time (TT) from this data.
> What extra information does the TT keyword conveys to a
> signal integrity analyser? Whether all buffers have some finite amount
> of TT or only some with strong clamp.
> Thanks
> A.D. Shripadaraj
> Cadence Design Systems
> NOIDA, INDIA
> ads@cadence.com
Received on Fri Mar 27 16:52:15 1998
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:46 PDT