[SI-LIST] IBIS Model VT Curve Length

  • From: "Moran, Brian P" <brian.p.moran@xxxxxxxxx>
  • To: <si-list@xxxxxxxxxxxxx>
  • Date: Wed, 16 Apr 2003 17:23:27 -0700

Hi Guys and Gals,

Just curious if any of you IBIS types out there have had to ponder the =
issue of trying to create IBIS models for buffers whose IBIS fixture =
generated VT curves do not fully switch in the minimum pulse width of =
your fastest intended stimulus, or more generally where the length of =
the VT curve is longer than Tp/2, where Tp=3D 1/Fmax. In such cases you =
can experience an issue some call "switching into an unfinished edge", =
which can create discontinuities in the output waveforms of some =
simulators. The right answer is probably to speed up the buffer, but in =
the mean time, I have 3 choices to weigh. 1) I can just leave the VT =
curves longer than the stimulus would normally dictate and let the =
simulator deal with it, 2) I could clip off the trailing edge of the VT =
curves, in which case they would not reach actual steady state level, or =
3) I can scale the VT curve's slope in order to fit the window. I guess =
I'm weighing 1 vs 3. I know scaling the VT will distort the model, which =
isn't good, but it is deterministic. The first option maintains the =
correctness of the model, but is less deterministic to my way of =
thinking, becasue I don't know how it effects various simulators. I'd be =
curious if anyone has been in this situation and done any type of =
analysis of the relative impact of either approach on simulation =
accuracy, or how various simulators react to the unfinished edge =
phenomenon.  This is probably a philosophical rat hole, but I was hoping =
someone might have a piece of insight I had not thought of, or a =
workaround I had not considered. =20

Brian P. Moran
Signal Integrity Engineer
Intel Corporation
brian.p.moran@xxxxxxxxx


-----Original Message-----
From: Aaron Helleman [mailto:aaron.helleman@xxxxxxxxxxx]
Sent: Wednesday, April 16, 2003 2:25 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Measuring Crosstalk



What's the standard way to measure crosstalk in the lab?  We have
experimentally determined that there is crosstalk on our PCB due
to traces being too close together for an xDSL system on the analog
side.   We want to characterize the amount of crosstalk between two
'bad' ports vs. two 'good' ports
to determine if our respin will work properly in simulation.

The frequency band of interest is between DC and 1100 KHz, which seems
like it should not be succeptable to crosstalk very much, but we have
experimentally determined
that if we re-route the tracks of interest using rework wire we can make
the crosstalk go away.

Would a spectrum analyzer and a signal generator be the way to go, or
perhaps a network analyzer to check the rejection ratio?

Could we do this via simulation as well?

--
Aaron


------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:    =20
                //www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages=20
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu
 =20
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:     
                //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
  

Other related posts: