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

Re: How to complete a transaction caused by



On Nov 22,  5:01pm, Braun_Josef#Tel3805 wrote:
> Subject: How to complete a transaction caused by

Regarding the question below, the following rules will work:

If the device below your bridge has, or could have side-effects on reads,
then the following rules apply.  (In your example of a FIFO, you should
follow these rules.)

1.  If you retry the PCI master (i.e.  disconnect with no data transfer at
    any time in that transaction), you should read as much data from the
    secondary bus as was requested in the initial phase of the retried
    read.  You are guaranteed that this access will be repeated.  But, the
    spec does recommend that if the master doesn't repeat the transaction
    in 2^15 cycles, you should discard the read results.  This is mostly an
    insurance policy against deadlocks.

2.  If you disconnect the PCI master (i.e., some data had transferred), you
    must not "read ahead" to the next location.

Above rules will NOT give you good performance, but this is the best you
can do.

However, if you know that the device below your bridge does not have side
effects, you can get better performance by reading ahead more than what the
master initially asks for.  This is the well known concept of prefetching.
How much prefetching you do is a performance consideration and can only be
determined by examining the details of your design.

Monish Shah
Hewlett Packard

> Hi PCI-experts,
>
> I have a question concerning the disconnect with or without data and the
> repeat behaviour of the respective master. Imagine the following scenario:
>
> We have a PCI to a special local bus bridge device
> working only as a slave and we want to satisfy PCI specification 2.1. If a
> master
> wants to access memory on the special bus with a burst and for some reason
> the special bus is not able to fulfil the requirements of PCI 2.1 (i.e. 8
> cycles)
> for sequential transaction, the PCI device must disconnect the access
> without
> data.
>
> PCI specification (page 48) says, that
>
> a master which is target terminated with Retry must unconditionally repeat
> the
> same request until it completes; however, it is not required to repeat the
> transaction
> when terminated with Disconnect.
>
> For our device this means that in case of a read transaction the local bus
> state
> machine of our device already started a transaction on the local bus, but
> after
> the mentioned 8 clocks the state machine of the PCI side disconnects the
> master.
> It?s the only possibility to fulfil the PCI requirement for subsequential
> data phases
> because we are not able to foresee the transaction latency on the local bus
> side.
> And PCI spec says
> Once a request has been attempted on the destination bus, it must continue
> to
> be repeated until it completes on the destination bus and cannot be
> discarded
> (3.3.3.3.3, page 51)!
> So if the master comes back after a certain time to retry the transaction,
> the device could deliver the data. But if the master never comes back, what
> will we do?
>
> Concerning a read transaction on a prefetchable memory address region
> the target device could discard the data. This does not matter, at least the
>  PCI
> spec says so in Chapter 3.3.3.3.3.
>
> But if you think about a read access from a non prefetchable
> address region (for instance a FIFO) it?s a horrible scenario.
>
> Thinking about write accesses it even becomes more difficult. The data on
> the
> local bus side is already delivered but the master never comes back to
> terminate the transaction.
>
> So, is there anybody out there who can help me with this problem. Is it
> an inconsistency of the actual specification or am I misunterstanding the
> problematic. I think, in this case PCI isn?t prepared for the situation of
> other
> busses downstream, or at least of how to implement them.
> For me it?s a contradiction to say, the master doesn?t have to come back
> in case of a Target Disconnect and putting up the requirement of a
> subsequential data phase if your dealing with a local bus which transaction
> latency you cannot foresee.
>
> Perhaps it was very interesting to find out, how typical south bridges are
> dealing with this problem. The downstream  ISA-bus latency also cannot be
> foreseen, but all this bridges are PCI 2.1 compliant, aren?t they?
>
> Any help would be much appreciated!
>
>
> Best Regards,
> Josef Braun
> bj3805@nbg.scn.de
>
>-- End of excerpt from Braun_Josef#Tel3805

=