Re: standard loads on 66 MHz PCI

To All:

The IBIS Version 3.1 format could theoretically handle this
multiple test load situation by using the [Model Selector]
keyword to reference individual [Model] keywords containing
the same information except for the individually specified
test loads. However, it is likely that the user would to
manually manage the analysis for testing the design corners.

Bob Ross
Interconnectix/Mentor Graphics

> Date: Mon, 09 Nov 1998 13:01:02 -0700
> From: "D. C. Sessions" <dc.sessions@vlsi.com>
> Reply-To: IBIS Mailing list <ibis@eda.org>
> To: IBIS Mailing list <ibis@eda.org>
> Subject: Re: standard loads on 66 MHz PCI

> Muranyi, Arpad wrote:
> >
> > All,
> >
> > I guess it is not impossible to come up with a fix to the IBIS spec to
> > accommodate the various reference loads the PCI spec uses. But, to answer
> > someone's question, I have only seen this kind of multiple reference loads in
> > the PCI spec. so far. And, sorry, but I have no idea why it was done that
> > way.

> It actually maps into the requirements. Min has to be guaranteed at light
> load to avoid violating the zero hold time spec in the face of clock skew;
> the light load is possible in onboard point-to-point connections.

> The max is necessary to guarantee avoiding setup violation on a loaded bus.

> > To further complicate things, think about this. There is a separate min and max
> > reference (test) load. But what are you supposed to use if you want to run a
> > typical simulation? This makes me suggest that we should look into how to fix
> > the PCI spec...

> Fixing the PCI spec would be nice, (the 5v tolerant section has always
> been ugly) and the timing is right since Intel has announced its end-of-life.
> Less flippantly, it's probably too late. The fool thing has a life of
> its own now. To get an idea, see how many 3.3v PCI systems you can find,
> and then read the intro to the electricals where Intel announced that PCI
> is intended to be a 3.3v bus but 5v is supported only as a transisition
> path...

> --
> D. C. Sessions
> dc.sessions@vlsi.com
Received on Mon Nov 9 15:02:35 1998