Subject: standard loads on 66 MHz PCI

From: Gregory R Edlund <[email-masked]>
Date: Fri, 6 Nov 1998 18:44:27 -0500

A question came up here at IBM today that I could not answer.  Has anyone run
into this?

The 66 MHz PCI bus spec has a different standard load for rising and falling
edges.  (10 pF and 25 Ohms to gnd for rising OR 10 pF and 25 Ohms to Vcc for
falling.)  As I read version 3.1 of IBIS, it only allows one value of Vref per
[Model] keyword.  This seems to make the 66 MHz PCI driver unable to be
implemented in IBIS, at least if you want to do timing analysis.  I would think
someone else probably encountered this already.  How did you get around it?  Or
am I missing something?

Much thanks in advance.

Greg Edlund
Advisory Engineer, AS/400 System Timing
IBM
3650 Hwy. 52 N, Dept. HDC
Rochester, MN 55901
[email-masked]

---

From: Tay Ansari - Board Design Technology <[email-masked]>
Date: Mon, 9 Nov 1998 11:21:26 -0500 (EST)

Hi Greg,

I ran into this exact problem when I was trying to set up a simulation 
environment for the 66 MHz PCI bus.  Fortunately, the IBIS simulator I am using 
allows me to choose whether I want the buffer delays to come from a simulation 
into the standard load circuit from the IBIS model or from time values which I
directly give to the simulator.  So what I did was use Spice to measure the rise 
and fall delays into their respective standard load circuits; I then gave those 
Spice generated numbers to my IBIS simulator.  Not an ideal solution, but a 
workaround that worked good enough.

Unfortunately, this solution doesn't help you much if you can't directly give 
buffer delays to your simulator.  The ideal solution would be to enhance the 
IBIS spec to allow for a unique standard load circuit for both the rising and 
falling edges; that is, if this is a common problem.  Or is this pretty much an 
isolated case with the 66 MHz PCI spec?

Regards,

Tay Ansari
Sun Microsystems

>
> From: Gregory R Edlund <[email-masked]>
> To: <[email-masked]>
> Subject: standard loads on 66 MHz PCI
> 
> implemented in IBIS, at least if you want to do timing analysis.  I wouldthink

---

From: [email-masked] (Weston Beal)
Date: Mon, 9 Nov 98 10:02 CST

Greg,

This is a good question.  I've thought about it too.  I've seen
evidense that no one knows how to handle it.   I have yet to see an
IBIS file of a PCI component with the timing reference load specified.
There is one more problem.  There is another load for min time.  The
advice to uncomment the appropriate load and rerun simulation (from
Arpad) is about the only work around.  I wonder if we can change the
PCI spec or at least come up with a standard PCI test load to include
in IBIS.  Does anyone know WHY PCI has three different timing test
loads?  I think that is an important question before we can come up
with an appropriate test load for IBIS.

Regards,
Weston Beal

> Date: Fri, 6 Nov 1998 18:44:27 -0500
>

---

From: "Muranyi, Arpad" <[email-masked]>
Date: Mon, 9 Nov 1998 11:19:00 -0800

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.

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...

Arpad
============================================================================
==

Greg,

Regards,
Weston Beal

> someone else probably encountered this already.  How did you get around
it? 
Or

---

From: Andrew Ingraham <[email-masked]>
Date: Mon, 9 Nov 1998 15:21:02 -0500

Why does PCI have three different test loads?  To try to mimic some
aspect of actual operating conditions.

The minimum test load mimics the lightly loaded case: short bus wires,
minimum device capacitance.

The two maximum test loads model a driver sitting in the middle of a
long transmission line that has settled to the previous state's voltage.
Thus, when switching high-to-low, the bus is initially high, and looks
like a thevenin resistance of Zo/2 (both "halves" of the t-line in
parallel) to Vdd.  While an infinitely long t-line may not be completely
"realistic," its purpose as a test load is to extract how well the
buffer switches such a load, before the reflection has returned.

Are multiple test loads an isolated case with the 66MHz PCI spec?  Well,
33MHz PCI (at 3.3V signaling) uses it too.

Regards,
Andy Ingraham

---

From: "Muranyi, Arpad" <[email-masked]>
Date: Mon, 9 Nov 1998 15:49:00 -0800

The purpose of the test loads is to have a well defined load into which the 
semiconductor wendor can test their Tco (Tval) numbers.  So when we simulate

flight times, we start our flight time measurements from the point on the 
reference waveform where the Tco (Tval) number was measured to.  If we
didn't do
it that way, we would have a gap or overlap in our AC spreadhseets and our 
timings would be hosed...  (Remember, the actual driver has a totally
different 
waveform from the reference load waveform, so we can't use that as the
beginning
of the flight time).  Greg Edlund is absolutely correct, that for this
reason it
is very important to match the reference load in the simulation to the load
the 
manuafturer used to obtain the Tco (Tval) numbers.

Therefore I wold trun around Greg Edlund's question and ask:  Do the 
semiconductor vendors really use these different reference loads to obtain
their
min and max Tco (Tval) numbers for their chips?  In my opinion, these loads
were
not invented for the sake of PCI or the SIE engineer, they were invented for
the
IC manufacturer so that they can provide more meaningful Tco (Tval)
numbers(?). 
I only question whether it is really necessary to have different min/max
loads. 
The test load (and waveform) doesn't match the driver's real load (and
waveform)
anyway, so why bother making a separate test load for "minimum" and
"maximum" 
conditions?

Arpad

I wonder if this is really a non-issue?  Does the somewhat "unusual" passage
in 
the PCI spec about Tval loading necessarily mean that the vendor datasheet
for 
that component must use the same loads?  Couldn't the vendor specify a 
"traditional" standard load in the datasheet and still comply with PCI?

The real concern here is that the load used by the simulator to compute net 
delays be IDENTICAL to the one specified in the datasheet.  Now, if
component 
datasheets are really using the three new PCI loads, then we truly have a 
problem.  Beside the Motorola SRAM example, does anyone know of any PCI 
components that actually use all three loads in the datasheet?

How new are these Tval loads?  Version 2.2 (currently in draft, dated June 
1998)?

Greg Edlund

---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on
11/09/98 
04:44 PM ---------------------------

[email-masked] on 11/09/98 10:20:22 AM 
Please respond to [email-masked]
To: [email-masked]
cc:
Subject: Re: standard loads on 66 MHz PCI

We had a similar problem with a Motorola MPC750.  The L2 cache MAX timing 
numbers are specified to a 20pF load and the MIN numbers to a 5pF load.
We were using ICX to analyze timing.  We looked at the output under no load,

then at 20pF and 5pF.  The delta was measured to be 477ps.  We then adjusted

the timing sheets in ICX so that the minimum allowed routing distance was 
effectively increased by 477ps to compensate for the additional 'test' load.

This allowed us to use a single IBIS model with Cref set at 20pF.  You may 
be able to apply a similar 'trick' with the PCI driver and Vref.

David Haedge
Raytheon Systems Company

---

From: Andrew Ingraham <[email-masked]>
Date: Tue, 10 Nov 1998 07:57:14 -0500

> How new are these Tval loads?  Version 2.2 (currently in draft, dated

Much older than that.  They became official at least as early as June
11, 1995, and were available in preliminary form a year before that.
See Version 2.1, note 2 under Table 4-6, on page 134; and Figures 7-6,
7-7, and 7-8 on pages 227-228.  Parts for the 5V PCI signaling
environment use the two simple "lumped" test loads (0pF and 50pF), as
these were already in place and in use for Version 2.0 (1993).

Arpad Myranyi said:

> The test load (and waveform) doesn't match the driver's real load
> (and waveform) ...

But I think they do!  They are more realistic than the conventional 50pF
lumped test load.

The minimum load represents the limiting case of two PCI devices on a
motherboard with no expansion slots and short etch; a strictly local
bus.

The maximum load represents that first nanosecond or so on a long bus,
before the incident edge bounces off the open ends and returns to the
driver.  The waveform you get is ... well ... it's what you really get!

Regards,
Andy Ingraham

---

From: Gregory R Edlund <[email-masked]>
Date: Tue, 10 Nov 1998 11:35:23 -0500

Is it a requirement to demonstrate compliance with the PCI Tval spec on the
component datasheet?  I'm already taking PCI compliance on faith because most
vendors do not include IV curves or rise/fall times on their datasheets.  In
the case of PCI drivers, my main interest as a system designer in the
clock-to-out spec is as an input to my static timing analyzer.

I agree with you that if vendors are specifying clock-to-out delays using the
PCI loads ONLY, then IBIS should be ammended to facilitate seamless timing
analysis.  However, my preference would be that vendors use a simple,
traditional standard load.  Simplicity reduces the probability of random
errors!  Corner analysis using a single standard load has always been possible
- as long as the vendor specifies min/typ/max clock-to-out delays.

Greg Edlund

[email-masked] on 11/10/98 10:10:01 AM
Please respond to [email-masked]
To: Gregory R Edlund/Rochester/IBM@IBMUS
cc: [email-masked], [email-masked]
Subject: Re: standard loads on 66 MHz PCI

in
> the PCI spec about Tval loading necessarily mean that the vendor datasheet for

How do you demonstrate compliance in all corner cases with a
single load datasheet? Especially if that single load is not
_any_ of those given in the design spec? Any device which
complies in one corner case may comply in the others, or it
may not. PCI takes the right approach in explicitly specifying
the corner cases. It's up to customers to demand appropriate
data sheets and models.

Is it feasible to expand the IBIS model spec and build enough
intelligence into the simulators so that together they can
automatically simulate all the corner cases in a given design?
That would be required to meet the logic designers' expectation
for a plug-and-chug solution. (Most SPICEs have monte carlo
capabilities for such work; they require manual intervention
to set parameter limits et cetera, but at least they don't
require a different model for each loading case. With a model
consisting of multiple sets of I-V and V-T curves, one per
loading case, there's more scope for error: knowing that the
set for one case is correct does not tell the user whether the
other sets are correct.)

---

From: Robert Haller <[email-masked]>
Date: Tue, 10 Nov 1998 11:46:42 -0500

Greg,
	As you may know, one of the ways we handle this (in our internal
simulator) is it by having a unique standard load entry for each corner
and for each rise/fall transistion. This way you do not need to make
multiple runs in order to obtain corner analysis for different standard
loads. I wonder if this idea could be extended for IBIS ? just my $.02
regards,
Bob Haller

	----------
	From: 	Gregory R Edlund[SMTP:[email-masked]]
	Sent: 	Tuesday, November 10, 1998 11:35 AM
	To: 	[email-masked]
	Subject: 	Re: standard loads on 66 MHz PCI

	Is it a requirement to demonstrate compliance with the PCI Tval
spec on the
	component datasheet?  I'm already taking PCI compliance on faith
because most
	vendors do not include IV curves or rise/fall times on their
datasheets.  In
	the case of PCI drivers, my main interest as a system designer
in the
	clock-to-out spec is as an input to my static timing analyzer.

	I agree with you that if vendors are specifying clock-to-out
delays using the
	PCI loads ONLY, then IBIS should be ammended to facilitate
seamless timing
	analysis.  However, my preference would be that vendors use a
simple,
	traditional standard load.  Simplicity reduces the probability
of random
	errors!  Corner analysis using a single standard load has always
been possible
	- as long as the vendor specifies min/typ/max clock-to-out
delays.

	Greg Edlund

	in