Does SACK serve any useful purpose

A student writes:

	Dr Patt,

	You talked about two race conditions in the FSM of the device controller
	in class. I remember you mentioning that both the problems can be solved
	by  introducing the SACK signal. However, I do not see how SACK resolves
	the problem completely.

If I said SACK by itself solves these problems, I misspoke.  SACK *contributes*
to both solutions.

	Race cond'n #1 : Consider two devices D1 and D2, D1 having a higher
	priority than D2. Suppose D2 requests for the bus, and gets the BG. 
	Now, consider the case when PAU has not yet received the SACK signal 
	from D2 (probably due to interconnect delay, or delay in the 
	generation of SACK in D2) and D1 requests for the bus during this 
	time. Since PAU hasn't received the SACK signal yet, it will send 
	another BG signal to D1.  So, both D1 and D2 will try to use the bus 
	in the same cycle, leading to bus contention.

No, PAU will only grant the bus on the basis of BR signals available at the
start of the bus cycle.  The request from D1 will not be seen until the next
bus cycle.

	Therefore, SACK might not help get rid of the problem completely.
	Alternatively, we could introduce some logic in the PAU such that it
	evaluates the requests at the beginning of each bus cycle and sends 
	the BG output only once per bus cycle. 


	This eliminates the need of an extra
	signal(SACK), and also takes care of the above hazard.

How will the PAU know that it is time to grant the bus again.  The BBSY line
is asserted by all device controllers on the bus.  The time between BBSY being
negated by one device controller and asserted by another depends on where
the two controllers are, and in any case, the very short transient can not
be counted on to inform the PAU of this.  A much cleaner signal is the SACK
signal, which when negated, tells the PAU it is time to latch all BR signals
and do the logic ending with a BG.

	Race cond'n #2 : Consider D1 and D2 having the same priority. D1 is 
	closer to the PAU than D2, and D2 has requested for the bus. If D1 
	wants the bus after sending BGout to D2, there would be a bus 
	contention again. To solve this problem, we have to ensure the device 
	controller does not take over the bus after sending the BGout. SACK 
	does not help solve this pbm.

Actually, the simplest way to handle this is to add an additional state which
the controller goes to if (a) it receives a BG AND (b) it does not want the
bus.  In this state, the controller asserts BG, which passes on the BG signal.
If subsequently, this controller wants the bus (the device signals it), and
BGin is negated (in response to SACK -- which tells the PAU to stop granting
the bus), the controller goes to BR.  If the device does not want the bus,
then the controller goes to Idle when it receives BGin negated.  

SACK contributes to this by telling the PAU it can stop granting the bus,
since the BG has been accepted.

	Could you please tell me the rationale behind introducing the SACK 
	signal, considering the aforementioned cases?

SACK asserted tells the PAU to stop granting the bus.
SACK negated tells the PAU it is time to latch the BR signals and grant the bus.

Does this make sense?  If not, please ping me again.

Yale Patt

	<<name withheld to protect the student who does not appreciate SACK>>