[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Target Termination Rules



> 
> 
> I don't see why I have to stick to target termination signaling 
> rule 3 (PCI Spec. v2.1, p.42), when I signal a disconnect and 
> the master has its IRDY# signal already asserted. The current
> data phase completes but according to rule 3 I have to keep
> STOP# asserted until the master completes the last data phase
> and the transaction by deasserting FRAME#. 
> 
> The reason I bother is that I must not rely on the master to
> deassert its FRAME# signal on the first clock of the last data
> phase. Therefore, if I don't want to violate rule 3, I must be
> able to react to a PCI signal within one clock cycle (deassertion
> of STOP# and DEVSEL# upon the deassertion of FRAME#). In all
> other transactions I want to support in my target design in a
> rather slow device I would not have to do that.
> 
> Question: Can anyone imagine any problems if I signal a disconnect,
> 	  when the master has its IRDY# already asserted, and 
> 	  blindly deassert STOP# and DEVSEL# on the second clock 
> 	  following the data phase terminated with a disconnect?  
>  	  
> Christian Huter
> 
> 
Christian, 

Yes, I can see a two problems.

1)  The last data phase will not complete.  A data phase completes with
IRDY# asserted and either TRDY# asserted or STOP# asserted.  The master
will wait until the target asserts either TRDY# or STOP#.  This is the
case you have to worry about.

2)  Deasserting DEVSEL# at the wrong time may cause some masters to see the
transaction as a master abort (ie DEVSEL# response has timed out).  This
is not as much of a problem as 1.

The handshake protocols are there for a reason.  If you don't follow
them, you may end up crashing the PCI bus or locking up a master.

Tom
--
Tom Hicks			Fore Systems
Design Engineer			174 Thorn Hill Rd
Adapter Group			Warrendale, PA 15086
thicks@fore.com	
GP=