Re: Delayed Xaction and LOCK#

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

Thanks Monish for the reply. I missed the paragraph on PP51 where it said that retry 
should be exact and LOCK# is certainly part of that. The page 76 stuff does not 
contradict this (it does not say any thing about LOCK# during retry).

It seems to be possible to do locked transaction in delayed mode (3.3.3.3.5) and that
was origin of whole issue.

Thanks for clarification.

Tripathi.

> From pci-sig-request@znyx.com  Mon Aug 26 14:48:53 1996
> Resent-From: pci-sig-request@znyx.com
> Resent-Date: Mon, 26 Aug 1996 15:16:40 -0600
> From: "Monish Shah" <monish@mcsy2.fc.hp.com>
> Date: Mon, 26 Aug 1996 15:16:40 -0600
> X-Mailer: Z-Mail (3.2.1 10apr95)
> Subject: Re: Delayed Xaction and LOCK#
> Mime-Version: 1.0
> Content-Type> : > text/plain> ; > charset=us-ascii> 
> Resent-Message-Id: <"Q1tKR.0.1-5.bIX8o"@dart>
> X-Mailing-List: <pci-sig@znyx.com> archive/latest/3550
> X-Loop: pci-sig@znyx.com
> Resent-Sender: pci-sig-request@znyx.com
> To: Mailing List Recipients <pci-sig-request@znyx.com>
> Content-Length: 1672
> 
> On Aug 26, 12:37pm, Devendra K Tripathi wrote:
> > 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 don't see how you came to that conclusion.  On page 51, the last
> paragraph of 3.3.3.3.2 does say "The master must repeat the transaction
> exactly as the original request...".  That should include LOCK# as well.  I
> don't think there is anything on page 76 that contradicts that.  (Yes, you
> are required to release LOCK# if the transaction is retried, but when you
> attempt it again, you'd have to assert LOCK#.)
> 
> BTW, I don't think it is possible to do locked transactions as delayed
> transactions.  So, matching LOCK# merely makes it so that a locked
> transaction doesn't get serviced with a completion from a previous delayed
> transaction to the same address, which might have come from a different
> agent.  Is it important to protect against that case?  May be not.  The
> spec writers apparently thought otherwise.
> 
> > 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.
> 
> Monish Shah
> Hewlett Packard
> 
�
�
�