Re: Differential pins in IBIS

Bob, D.C., et. al.,

To me, this seems to be a spec interpretation issue. It's an old story, and one that we are all familiar with: the user interprets the spec one way and the supplier interprets it another. In my case, it appears that the spec supports the way that I intend to use the IBIS file (and it would be nice if IBIS acually supported putting CORRECT data in about the part, and not some workaround). There is nothing in the spec that states that each pin of a diff pair must be unique and seperate from another diff pin pair. The golden parser, and apparently therefore the EDA tools interpret this differently.

These inputs are in fact differential, and to model them as single-ended is wrong. The Vinh and Vinl levels move around WRT Vref. Vref does NOT necessarily follow Vcc. It should follow Vddq of the transmitting device which can move around independantly of the typ/min/max case of the receiving device that I am modeling, especially when you consider the additive transmission line effects, xtalk, etc.

If I model the inputs as single-ended HOW do I spec correct Vinh and Vinl levels? IBIS is a DATA TRANSMISSION tool. If it does not adequately allow me to transmit the CORRECT factual information about my device then IBIS is BROKEN!

-- 
Regards,
Stephen M. Nolan
Bob Ross wrote:
> 
> Stephen, D. C., etc.:
> 
> All that I can add to this is that I believe BIRD62.6
> additions will provide additional detail for this
> technology.  The data input pins should be treated as
> single-ended inputs based on the function table of
> the SN74SSTL16857.
> 
> Bob Ross
> Mentor Graphics
> 
> "D. C. Sessions" wrote:
> >
> > Christian Klein wrote:
> > >
> > > DC, Stephen,
> > >
> > > What if you  created additional "virtual" Vref pins, and referenced each
> > > differential input to a different pin? I don't think this would be a problem, as
> > > long as they share the same POWER and GND busses.
> >
> > I talked about this with Bob Ross (Please chime in, Bob) and it seems
> > that this is one of those cases where Mr. Nolan's IBIS files are
> > within the letter of the specification but violate tool requirements.
> >
> > Arguably, we don't need to make any changes in IBIS to accomodate this
> > application, except maybe some comments to the effect that this is a
> > supported use.  The tool companies just need a nudge to get them to
> > support this.
> >
> > In the meantime, your proposed workaround might trick them into doing
> > what they Should Have In the First Place.
> >
> > > "D. C. Sessions" wrote:
> > >
> > > > Weston Beal wrote:
> > > > >
> > > > > Stephen,
> > > > >
> > > > > Although this receiver is implemented as a differential receiver, from the
> > > > > outside it looks more like a single ended receiver because the system really
> > > > > only feeds in one data signal.  Vref is held constant at 1.25V.  You can
> > > > > simply use the parameters Vinl and Vinh to specify the thresholds Vref -
> > > > > 350mV (0.9V) and Vref + 350mv (1.6V).
> > > > >
> > > > > Now, since Vref should follow Vcc, it changes for min and max cases.  For
> > > > > this we use Vinl and Vinh under the [Model_Spec] keyword.  They work the
> > > > > same but now have typ, min, and max values.
> > > >
> > > > Not good enough.  Vref and Vtt are related to Vddq, but there are both
> > > > tolerances and noise terms involved which don't track the simplistic
> > > > typ/min/max axis.  In particular, for the devices Mr. Nolan is discussing,
> > > > the common-mode rejection of the receivers is an issue.  Differential is
> > > > a must.
> > > >
> > > > For instance, right now there is a JC-42.3 task group dealing with the
> > > > impact of SSI noise on Vref.  Crosstalk analysis where is can make or
> > > > break standard technology.
> > > >
> > > > > The IBIS committee is still working on the AC thresholds vs. DC thresholds
> > > > > problem.
> > > >
> > > > One of the reasons that Mr. Nolan now represents TI on the IBIS committee.
> > > >
> > > > --
> > > > D. C. Sessions
> > > > dc.sessions@vlsi.com
> >
> > --
> > D. C. Sessions
> > dc.sessions@vlsi.com