Accelerated Graphics Port Interface Specification

AGP3.0 Interface Specification

Rev. 1.0

107

4.1.11 Time Keeping

An AGP3.0 device must be aware of the isochronous time period (T) to ensure that it does not exceed

the agreed-upon maximum number of isochronous transaction requests. AGP3.0 bridges must also be

aware of the isochronous period for the same reason. Timekeeping is optional for AGP3.0 core-logics.

AGP3.0 Master devices must synchronize their isochronous periods to that of the bridge or core-logic by

issuing a time alignment transaction. The bridge forwards the transaction to the core-logic, which

responds with the time offset (in common clocks) between the initial data phase of the time alignment

data, and the beginning of the core-logic’s next isochronous period. The AGP3.0 Bridge shifts its

isochronous period by this amount, which brings it into time alignment with the core-logic. The AGP3.0

Bridge then responds to the AGP3.0 devices that shift its isochronous periods by this amount, which

then brings them into synchronization with the isochronous period of the AGP3.0 bridge and core-logic.

Isochronous alignment transactions resemble an isochronous read transaction except that the return

data contains the time offset, in AGP3.0 common clocks, between the initial data phase of the return

data and the beginning of the AGP3.0 core-logic’s next isochronous period. The value ranges between

0 and 65(decimal) or xxxxxx00 to xxxxxx41 (hexadecimal). An AGP3.0 core-logic may return the value

xxxxxxFF (hexadecimal) indicating it does not maintain on an internal isochronous period. Note that only

the lowest significant byte has any meaning. All other bytes in the 32-bit word must be ignored.

The bridge may shift the isochronous periods of the AGP3.0 Master devices relative to its own

isochronous period so the bridge can combine requests from two AGP3.0 Masters into a single

upstream isochronous period. The amount of this shift is an implementation detail left to the bridge

designer. Figure 4-4 illustrates the time offset introduced by a hypothetical AGP3.0 bridge.

AGP8X devices

AGP8X bridge

Cmd’s

Bridge inserts sufficient offset to

combine requests from two devices

Figure 4-4: Potential Fan-Out Bridge Delays of Isochronous Periods for AGP3.0 Devices

AGP3.0 bridges may also delay data transfers provided the total delay of requests and data does not

exceed one isochronous period. Isochronous delay experienced by an AGP3.0 Master device is the

sum of contributions from the core-logic and bridge. The AGP3.0 Master device is required to tolerate

the additional period of latency.

Future versions of this specification may require AGP3.0 core-logics to maintain an isochronous period

and participate in the time alignment process described above to support a more rigorous definition of

isochronous latency.