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

Re: target termination




So you are asking us to break MOST of the PCI-mastering chips on the
market so that your "slow" device can save 1 clock cycle.  It would make
more sense for you to save the 2-3 clock cycles by allowing your target
device to accept 8 transfers instead of only 4, and it would improve the
performance of your PCI bus by more than your proposed change, and it
wouldn't break any other devices on the market (and it wouldn't involve a
spec change).

On Wed, 6 May 1998, Michael Tresidder wrote:

> Date: Wed, 06 May 1998 10:58:49 -0400
> From: Michael Tresidder <tresidd@vcubed.com>
> To: Mailing List Recipients <pci-sig-request@znyx.com>
> Subject: target termination
> Resent-Date: Thu, 7 May 1998 02:53:08 -0700
> Resent-From: pci-sig-request@znyx.com
> 
> Hello everyone, here's a question on industry support (or should I say
> tolerance) -- but first a little spec. background.
> 
> In the PCI Spec. Rev. 2.1, section 3.3.3.2.1 "Target Termination
> Signalling Rules":
> 
> Under the verbiage for Rule 1:
> 
> When both FRAME# and IRDY# are asserted, the master has committed to
> complete two data phases. The master is unable to deassert FRAME# until
> the current data phase completes because IRDY# is asserted. Because a
> data phase is allowed to complete when STOP# and IRDY# are asserted, the
> master is allowed to start the final data phase by deasserting FRAME#
> and keeping IRDY# asserted. The master must deassert IRDY# the clock
> after the completion of the last data phase.
> 
> Under the verbiage for Rule 3:
> 
> When both STOP# and TRDY# are asserted in the same data phase, the
> target will transfer data in that data phase. In this case, TRDY# must
> be deasserted when the data phase completes. As before, STOP# must
> remain asserted until the transaction ends whereupon it is deasserted.
> 
> Now, consider the following waveforms (please infer STS and high-Z where
> appropriate):
> 
>                             Figure 1:
>            |  0  |  1  |  2  |  3  |  4  |  5  |  6  |
> 
> CLK     ___/--\__/--\__/--\__/--\__/--\__/--\__/--\__
> 
> FRAME#  -----\_______________________/---------------
> IRDY#   -----------\_______________________/---------
> TRDY#   -----------\_______________________/---------
> DEVSEL# -----------\_______________________/---------
> STOP#   ------------------------\__________/---------
> 
>                             Figure 2:
>            |  0  |  1  |  2  |  3  |  4  |  5  |  6  |
> 
> CLK     ___/--\__/--\__/--\__/--\__/--\__/--\__/--\__
> 
> FRAME#  -----\_____________________________/---------
> IRDY#   -----------\_____________________________/---
> TRDY#   -----------\_______________________/---------
> DEVSEL# -----------\_____________________________/---
> STOP#   ------------------------------\__________/---
> 
> 
> With respect to Fig. 1, the first snippit of verbiage indicates that
> this could be a legal cycle on PCI from the master's point-of-view
> (during cycle 3 the master has committed to two more transfers).
> However, the second snippit of verbiage indicates that the target *must*
> deassert TRDY# in cycle 4 and not in cycle 5 as shown. According to the
> spec. a target that limits the transfer to four words would exhibit the
> behaviour shown in Fig. 2.
> 
> In reality, the waveform of Fig. 1 is just as simple to support as that
> of Fig. 2 (comparable cost), and has better performance because it
> occupies the PCI bus for one less cycle.
> 
> Has anyone else considered this case before? Personally, I think this
> should have been permitted from the beginning since it can be easily
> supported.
> 
> 
> So, here are my questions.....
> 
> Q1.    Are there any targets out there that already support/exhibit the
> behaviour in Fig. 1?
> Q2.    Are there any initiators (or other bus trackers) out there that
> *cannot* support/tolerate the behaviour in Fig. 1? (ie. either they
> break, or ignore the IRDY# / TRDY# assertions in cycle 5)
> Q3.    Would anyone else like to see support for the mode of Fig. 1
> supported by the spec.?
> 
> Clearly there are compatibility issues to consider before such an item
> could even hope to be sanctioned by the spec. However, existing designs
> with an eye to simplicity would probably tolerate the operation of
> Figure 1. For future designs, I would suggest at least that the
> operation of Fig 1. not be precluded.
> 
> For instance, the initiator might ignore STOP# in determining whether
> data was transferred in a given clock-cycle. In general I would expect
> that this is generally true since it is a simpler decision, and the
> initiator would then be able to tolerate the signalling of Fig. 1. In
> particular, WRT Figure 1, had STOP# not even been asserted, the cycle
> would be perfectly valid. The only contentious point I see here is that
> the master state-machine would have to be in a state (after first seeing
> FRAME#, IRDY# and STOP# asserted) in which the subsequent assertion of
> IRDY# and TRDY# would effect a transfer.
> 
> Additionally, for bus trackers, once STOP# has been seen they only need
> to be concerned with the state of IRDY#. In particular the termination
> of a data phase can be indicated by IRDY and [TRDY or STOP] (in positive
> logic). In this type of implementation, the simultaneous assertion of
> TRDY# and STOP# in Fig 1. would be irrelavent -- and thus Fig. 1 would
> be tolerated by such bus trackers.
> 
> Does anyone else have any other thoughts on this?
> 
> Michael Tresidder
> V3 Semiconductor
> 
> 

+-------------------------+
| Neal Palmer             |
| neal@dinigroup.com      |
| www.dinigroup.com       |
| (619) 454-3419          |
| (619) 454-1728 (fax)    |
+-------------------------+