[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Mailing List Recipients <email@example.com>
- Subject: CLKRUN# Question
- From: brians@Aureal.com (Brian Sassone)
- Date: Thu, 19 Mar 1998 14:43:42 -0800 (PST)
- Resent-Date: Thu, 19 Mar 1998 14:52:43 -0800
- Resent-From: firstname.lastname@example.org
- Resent-Message-ID: <"QgyVw1.0.Qk6.7zP4r"@electra.znyx.com>
- Resent-Sender: email@example.com
Is the PCI Mobile Design Guide Revision 1.0 October 27, 1994 current?
Assuming that it is, my question is:
There seems to be a race condition between clock stop by the central
resource and clock start request by a device, such that the 2 clock assert
time required by the device cannot be guaranteed.
When the central resource indicates its intent to stop the clock, it
deasserts CLKRUN#. However, there is no guarantee as to when the clock will
actually be stopped and no easy way to detect actual clock stop. Thus, the
device may assert CLKRUN# just as the central resource stops the clock. The
device may then count these trailing clock edges as the ones required as the
minimum assert time and deassert CLKRUN#. This leaves the device thinking
it has made a succesful clock restart while the central resource has
transitioned to a clock stop state.
Is this a problem that has already been solved by current implementations
Comments, or suggestions?