Delayed transactions and LOCK#

[Thomas Dippon <thomasd@hpbidrd.bbn.hp.com>]

Dear PCI experts,

What information does a target that supports delayed transactions
need to latch and compare?  Obviously address, byte enables, command,
data (in case of a write) and REQ64#.  But: What about LOCK#?

Section 3.3.3.3.5 of PCI Spec 2.1 says: "LOCK# must be latched and
used in the compare to determine when the request is being repeated".

Consider the scenario where Master B starts a locked access to Target B
and keeps ownership of LOCK# after the initial transaction, thus keeping
LOCK# asserted. Now Master A starts a normal (i.e. non-locked) transaction
to Target A. Target A supports delayed transactions, latches the asserted
LOCK# signal (amongst all the other info) and terminates with a Retry.
Master B completes its locked transfer and deasserts LOCK#.  Master A
repeats its original non-locked request to Target A, but Target A will
not recognize it, because this time LOCK# is deasserted.

Is this in the sense of the PCI protocol or am I misinterpreting something?

IMHO, the target needs to implement the more complicated algorithm
described in the second paragraph on page 75 ("To allow a non-PCI agent...")
in order to find out whether it is *really* locked and latch/compare this
information.

I'd appreciate any comments  (particularly from the PCI SIG).

rgds,
Thomas Dippon

--

+--------------------------------------------------------------------------+
| Thomas Dippon                   | E-Mail:  thomas_dippon@bbn.hp.com      |
|   Hewlett-Packard GmbH, Germany | Phone:   +49 7031 14-3973,  Fax: -3883 |
+--------------------------------------------------------------------------+
v”ƒ