FW: Target Initial/Subsequential Latency

["Taylor, Mike" <mike@buntypost.dundee.ncr.com>]

Latency timing for both Master and Target begins when IRDY and TRDY are   
both asserted, IRDY and TRDY can be asserted in any order, but worst case   
if both Master and Target each have a latency of 8 clocks then IRDY and   
TRDY are asserted together and data transfers occur every 8 clocks.
Mike.
   

>
> With implementing the target latency requirements of a company   
proprietary
> PCI design we from our point of view detected an inconsistency of the   
actual
> specification.
>
> A target that wants to fulfil the requirements of the actual spec has   
to
> transfer
> the data within 16 clocks starting with frame for the initial data   
phase
> and within 8 clocks starting at the end of the preceding data phase.
>
> But the target has to fulfil this requirements regardless of when the
> master is able to transfer the data indicated by asserting IRDY.
> The master has to assert IRDY no later than 8 clocks after asserting   
FRAME
> for the initial data phase and no later than 8 after the preceding data
> phase for a subsequential transaction.
>
> So for the initial transaction the target has a real chance to fulfil   
the
> requirements because there are 8 clocks left to transfer the data.
> But for a subsequential data phase the master might come at the
> 8. cycle and the target has to disconnect the transaction without
> having a real chance to make it.

Only a badly designed master would delay IRDY for 8 clocks (if at all).

Assuming such a master:

For reads there is no problem since the target does not have to wait for   
IRDY
asserted to begin reading the data internally. It can have the data ready   
when
the master does eventually assert IRDY and each data phase will still   
only take
8 clocks.

For writes the target should be designed to accept data with no wait   
states and
assert TRDY immediately, i.e. a posted write. This is in line with the
recommendation in 3.5.2, "Data transfers on PCI should be done as   
register to
register transfers to maximise performance". If the write post buffer is   
full
then the target can issue a retry or disconnect.

> Any comments? Are all of you content with this implementation   
possibility?
>
> sep
>


Andrew Crosland
Principal Engineer
PowerPC Product Group

* email: crosland@radstone.co.uk          Radstone Technology plc     *
* Tel: +44 (0)1327 359444                 Water Lane, Towcester       *
* Fax: +44 (0)1327 358113                 Northants, England NN12 6JN *
* Web: http://www.radstone.co.uk                                      *
*      http://www.radstone.com                                        *
*       _/_/_/_/                                 _/_/_/_/ _/_/_/_/    *
*      _/    _/                                 _/    _/ _/           *
*     _/    _/ _/_/_/ _/      _/ _/_/_/ _/_/_/ _/    _/ _/            *
*    _/_/_/_/ _/  _/ _/      _/ _/  _/ _/  _/ _/_/_/_/ _/             *
*   _/       _/  _/ _/  _/  _/ _/_/_/ _/     _/       _/              *
*  _/       _/  _/ _/  _/  _/ _/     _/     _/       _/               *
* _/       _/_/_/ _/_/_/_/_/ _/_/_/ _/     _/       _/_/_/_/  GROUP   *














jȸ