Re: Delayed Xaction and LOCK#

[frank.story@tempe.vlsi.com]

Tripathi,

I can't find where locked transactions are an exception to the delayed
transactions requirement that they be retried. I believe that a 2.1 
master must retry all retried transactions, even if they were locked.

The target cannot consider itself locked until the successful completion
of the first locked data transaction (a read). If the locking master is
retried due to the delayed transaction, and another master does a read of
the same target, the read can complete since the target is not yet locked.
The target won't lock until the locked cycle is retried and completed. To
differentiate requires the comparison of the LOCK# signal.

As an aside, an interesting case arises with locked cycles over PCI to
PCI bridges. If Master A's locked request is retried on the primary bus
due a delayed transaction that completed on the secondary bus, then prior
to Master A's retry of the locked request, the secondary bus is locked,
but the primary bus is not. This allows Master B on the primary bus to 
implement locked cycles whilst Master A is waiting for its lock request
to be completed on the secondary. Since Masters can only access a single
resource during their lock operation, livelocks between the two masters
are averted. The only downside is that the LOCK# resource is unavailable
to secondary masters while Master B finishes its lock operation.

You mentioned the possibility of a deadlock. Was that possibility related
to the requirement of comparing LOCK# during delayed transactions, or
was it more general? I'm not sure if I've helped at all, or merely 
stirred the pot. Hope its the former.

Frank

> Resent-Date: Mon, 26 Aug 1996 12:37:23 -0700
> From: Devendra K Tripathi <tripathi@Synopsys.COM>
> Subject: Delayed Xaction and LOCK#
> 
> Hi all,
> 
> There is possibility of deadlock, the way specification for delayed xaction for
> exclusive accesses has been specified  (PCI2.1 PP 52). It says that target needs to
> compare (latched) LOCK# signal to find if request is being repeated. On the other hand
> there is no requirement for initiator (PCI 2.1 PP 76) that it must retry
> an exclusive access as exculsive access only. I am not clear why matching of LOCK#
> is required on target side. I think it should be good enough that target consider 
> itself locked and do not allow any access other than the pending one. Once the
> pending request comes, it should honor irrespective of whether or not the access is
> exclusive one.
> 
> Any comments ?
> 
> Thanks,
> Tripathi.


Frank Story                    frank.story@tempe.vlsi.com
VLSI Technology                602-752-6098
Computing Products Group
‚
œ‹