Data phases:
After the address phase (particularly, starting with the cycle that DEVSEL# goes low) comes a burst of one or more data phases. In all the cases, initiator drives active-low byte choose signals on the C/BE[3:0]# lines, however the data on the AD[31:0] may be driven by the initiator (on case of writes) or target (in case of reads).
During data phases, the C/BE [3:0] # lines are interpreted as active-low byte enables. In case of a write, the asserted signals indicate which of the four bytes on the AD bus are to be written to the addressed location. In the case of a read, they specify which bytes the initiator is interested in. For reads, it is always permissible to ignore the byte enable signals and simply return all 32 bits; cacheable memory resources are needed to always return 32 valid bits. The byte enables are chiefly useful for I/O space accesses where reads have side effects.
A data phase with all 4 C/BE# lines deserted is explicitly allowed by the PCI standard, and must have no effect on the target (other than to advance the address in the burst access in progress).
The data phase continues till both parties are ready to complete the transfer and continue to the next data phase. The initiator asserts the IRDY# (initiator is ready) when it no longer required to wait, whereas the target asserts TRDY# (target ready). Whichever side is providing the data have to drive it on the AD bus before asserting its ready signal.
Once one of the contributors asserts its ready signal, this cannot become un-ready or otherwise alter its control signals till the end of the data phase. The data recipient have to latch the AD bus each cycle till it sees IRDY# and TRDY# both asserted, which marks the end of the current data phase and mention that the just -latched data is the word to be transferred.
To maintain complete burst speed, the data sender then has half a clock cycle after seeing TRDY# and IRDY# both asserted to drive the next word onto the AD bus.
It continues the address cycle shown above, supposing a single address cycle having medium DEVSEL, so the target responds for clock 3in time. Though, at that time, neither side is ready to transfer data. For clock 4, initiator is ready to transfer, but the target is not ready. On clock 5, both are ready, and a data transfer takes place (as mention by the vertical lines). For clock 6, the target is ready to transfer, but the initiator is not ready. On clock 7, the initiator becomes ready, and then data is transferred. For clocks 8 and 9, both sides remain ready to transfer data and transferred it at the maximum possible rate (32 bits per clock cycle).
In particular case of a read, clock 2 is reserved for turning around the AD bus, so the target is not allowed to drive data on the bus even if it is capable of fast DEVSEL.
Fast DEVSEL# on reads
A target that supports fast DEVSEL could in theory start responding to a read the cycle after the address is existing. However, this particular cycle is reserved for AD bus turnaround. Therefore, a target may not drive the AD bus (and therefore may not assert TRDY#) on the second cycle of a transaction. Notice that most of the targets will not be this type of fast and will not require any special logic to enforce this condition.