Re: Delayed Xaction and LOCK#

[Devendra K Tripathi <tripathi@Synopsys.COM>]

Hi Frank,

Thanks for your reply. Here are some comments on this:



> 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.
> 

It is true that all transactions need to be retried but it is not specified
(at least on PP 76) that an exclusive transaction is retried as exclusive only and
not as a normal transaction. May be it is understood but it is not obious.


> The target cannot consider itself locked until the successful completion
> of the first locked data transaction (a read). 

On Page 52 (PCI 2.1, 3.3.3.3.5), it says
 " .... . All the rules of LOCK# still apply except the target must consider itself
   locked when it enqueues the request even though no data has transferred. While in
   this state, the target enqueues no new request ..."

> 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.

Again, it does not look to be possible based on the above.

> 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? 

The deadlock I am mentioning is if an initiator does not retry the request 
as an exclusive access (because from its point of view lock was not established
so it may not be obliged to repeat the request in exclusive mode). Now since
target is looking for LOCK#, it will not honor the retry request. 

> I'm not sure if I've helped at all, or merely 
> stirred the pot. Hope its the former.
> 
> Frank
> 

> > 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
> 




Thanks again,
Tripathi.
‰
|i