Re: Retry and Parity.

["Kevin Brace" <kevinbraceusenet@hotmail.com>]

         Based on what was discussed here and the PCI specification Rev. 
2.2, here are the ways how PERR# signal should be implemented.


1) The target is permitted to assert PERR# during a write cycle even before 
TRDY# is asserted.

2) Once PERR# is asserted by the target, TRDY# must be asserted eventually.

3) Once PERR# is asserted by the target, it must remain asserted two clock 
cycles following IRDY# and TRDY# assertion.

4) Once PERR# is asserted, the target is not permitted to end the 
transaction by signaling Retry, Disconnect without data, or Target Abort. 
(i.e., No TRDY# assertion allowed.)


        However, to implement PERR# "reasonably," here are the ways how I 
think it should be implemented.

1) Assuming the target is capable of signaling Retry, Disconnect without 
data, or Target Abort, the target should assert PERR# only when TRDY# is 
asserted. When the target is inserting wait states (TRDY# = 'H') and detects 
a parity error, the target should not assert PERR# and set Detected Parity 
Error bit (bit 15 of Status Register) (i.e., It should not modify Detected 
Parity Error bit.), because there is a chance that the backend logic of the 
target might not know that a parity error occurred, and might signal Retry, 
Disconnect without data, or Target Abort.

2) Assuming the target is not capable of signaling Retry, Disconnect without 
data, or Target Abort, it can go ahead and assert PERR# before TRDY# is 
asserted, since TRDY# is going to be asserted eventually, but such a device 
doesn't sound too practical. (I believe most PCI devices do signal Retry 
and/or Disconnect without data.)

3) Assuming the target is capable of signaling Retry, Disconnect
without data, or Target Abort, when it is inserting wait states (TRDY# = 
'H') and detects a parity error, the target will assert PERR#, but when it 
does so, it will no longer honor the target backend's request for signaling 
Retry, Disconnect without data, or Target Abort, and will only terminate the 
transaction with asserting TRDY#. I believe this implementation is a lot 
more complex to implement than the first implementation, and might cause 
confusion on the backend logic.



        Because the complexity of PERR# (i.e., Runs 2 clock cycles behind 
IRDY# and TRDY#.) protocol, it seems impractical (Too costly to implement.) 
to me to force the target to assert TRDY# if it once asserts PERR# and still 
hasn't made up its mind. (i.e., Inserting wait states.)
Therefore, I feel like ignoring the parity error occurring until TRDY# is 
asserted seems like a reasonable implementation, and still comply with the 
specification.
        Also, during a write cycle, I believe it is the initiator's 
responsibility to monitor PERR# when appropriate registers are set, but 
since the only valid assertion of PERR# is when IRDY# and TRDY# are both 
being asserted, should the master ignore all other cases of PERR# assertion? 
(i.e., PERR# is asserted, but IRDY# and TRDY# are not both asserted.)



Kevin Brace (In general, don't respond to me directly, and respond within 
the mailing list.)




>From: "Nagesh K Vishnumurthy" <vnagesh@in.ibm.com>
>To: pci-sig@znyx.com
>Subject: Retry and Parity.
>Date: Wed, 31 Jul 2002 09:16:14 +0530
>
>Hi Everybody,
>
>What should PERR# signal highlight in case of parity error for a Retry
>situation on the bus? Suppose A master were to issue request and it gets
>retried and the data never got transferred, but a parity error has occured
>is it valid for us to assert PERR#?
>
>Nagesh

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com