[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PERR# and SERR#
It's a little of both of your reasons.
PERR# is associated with a particular cycle and therefore has to meet
single-cycle timing, just like data, TRDY, etc. Because it's only driven by
one agent at a time, it also has to meet the turnaround timing requirements
(which are really covered by the above).
In order to meet single-cycle timing on the deasserting (rising) edge, you'd
either need a really strong pullup which would hurt your asserting (falling)
edge timing (if it's even possible to meet deasserting timing with just a
pullup), or you have to drive it when deasserting and asserting. The second
is what we do, allowing a very weak pullup resistor to keep it deasserted.
SERR# does not have to meet single-cycle timing (along with some other
signals like PME# I think), and any agent can drive it at any time, so you
can't have anyone drive it high to deassert it. You must rely entirely on
the pullup, and the central resource that monitors SERR# must filter it to
deal with the slow rise time. I believe INTA-D# have the same behavior for
the same reasons.
Kuriakose, Anand wrote:
> Why are some signals in PCI like TRDY#, IRDY#, FRAME# etc categorised as
> Sustained tristate signals? What makes them different?
>
>
> Why is PERR# a STS (sustained tristate signal) signal, while SERR# an
> open-drain signal?
>
> Does the above difference arise due to the fact that
>
> 1) PERR# has always a transaction cycle associated with it and SERR#
> is only partially (for address parity errors and data parity errors
> in
> special cycle command and for system errors) and
> 2) SERR# can be asserted by more than one agent at any time while PERR#
> can be asserted by only one agent (involved in the current
> transaction) at
> any time.
--
_______
Paul C. Miranda (paul.miranda@amd.com) \ ___ |
"Failure is not an option!" - Gene Kranz /| | |
(Flight Director: Gemini, Apollo missions) | |___| |
#include <std.disclaimer> FNORD |____/ \|