[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adress/Data Stepping
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Re: Adress/Data Stepping
- From: Kai Harrekilde-Petersen <khp@dolphinics.no>
- Date: Wed, 11 Feb 1998 08:26:38 +0100 (MET)
- In-Reply-To: <199802110048.QAA01781@jazz.aureal.com> from Brian Sassone at "Feb 10, 98 04:47:59 pm"
- Resent-Date: Tue, 10 Feb 1998 23:37:17 -0800
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-ID: <"7odpM3.0.9f4.rBLuq"@electra.znyx.com>
- Resent-Sender: pci-sig-request@znyx.com
Brian Sassone writes:
> Does anyone have any experience with components using address/data stepping?
> Although this is permitted by the specification, it is also "discouraged"
> both for performance as well as timing reasons.
>
> Specifically, I'm looking for feedback on timing problems. e.g., If
> a component is using continuous stepping, other components may have
> problems when their input setup and hold is violated even though they should
> not be sampling the signals being stepped.
We have encountered one hostbridge (for the Alpha, IIRC), that used
data stepping on the config cycles. The only reason we noticed was
because the PCI bus model we had bought did not model data stepping in
a sane way (ie: it didn't drive X or Z on the bus during the stepping
cycles, but data), and this resulted in clocking data too early on our
parts side.
We haven't seen timing problems related to a/d stepping, but rather
logic bugs in the PCI model and the "Silicon proven" core we bought.
BTW, data stepping can actually be used to *increase* the system
performance in certain situations: Suppose you have a CPU bus which
has muxed address/data bus, and you receive the address several clock
cycles before you get the data (eg: the R4x00 bus, where you must
assert WrRdy# before you get the data) - in this case you can shave
off a cycle from the latency by starting the cycle on PCI before you
get the data.
Kai
--
Kai Harrekilde-Petersen <khp@dolphinics.no> #include <std/disclaimer.h>
http://www.dolphinics.no/~khp/