LOSTCIRCUITS

Why AGP 8X?

Real time performance expectations are increasing with every design cycle. The issues at hand are no longer limited to just gaming experience but increasingly include real time rendering of incoming video streams. Naturally, also games are evolving to bring cinematic levels of detail to the desktop. Moreover, the host platform's capabilities are increasing at an incredible rate courtesy of the fierce competition between Intel and AMD. Last not least, the improvements in graphics processor technology and capabilities are dwarfing the enhancements made in any other area of personal computing.

* We will have the details below
** Note that AGP 3.0 and AGP 8X are not synonymous since AGP 3.0 also supports AGP 4X mode.

Signalling to clock relation in AGP 8X. For every clock cycle (CL), there are eigth transactions (A). The important part of the graph is hi-lighted. The other traces are strobes for synchronization (source synchronous clocking, clock forwarding). Figure adapted from Intel white paper.

Changes from AGP 2.0 to AGP 3.0

From an electrical and signalling standpoint, the most significant change from AGP 2.0 to AGP 3.0 is the migration from 1.5V to 0.8V signalling voltage swing. Only because of the reduced signalling amplitude is it possible to funnel eight transactions per pin and clock cycle meaning that the AGP 8X interface employs octal data rate (ODR). Eight transactions / clock at a 66 MHz clock result in the above mentioned 533 mega transactions/sec and, by extension, on a 32 bit or 4 Byte wide interface will give a total of 2112 MB sec bandwidth.

The high signalling frequency requires some additional hardware changes to warrant signal integrity, that is:

• Parallel signal termination
• Removal of the 3.3V signalling support.
• Signal calibration during a calibration cycle.
• Dynamic bus inversion to reduce simultaneously switching output noise.
• Flow Control Change on Fast Writes. The buffer depth has increased to a minimum of 128 Bytes (64 bytes in AGP 2.0).

• Removal of PIPE (pipelining) mode addresses: AGP 1.0 and 2.0 supported both side band addressing (SBA) and PIPE, that is, the address and command bus was using the same 32 bit bidirectional bus used for receiving data in a pipelined, time muxed fashion. The AGP interface also specifies eight separate lines for side band addressing, that is, a physically separate command and address bus. In PIPE mode, the standard 32 bit interface is used to create requests and receive the data meaning that data receipt has to be completed before the next request can be issued. AGP3.0 commands and requests are transfered exclusively via the SBA lines. As a result, requests can be issued before completion of a data transfer.
• Removal of support for Long Transactions: Long transactions are transactions over 64 Bytes. In AGP 3.0, if the GPU needs a string of more than 64 Bytes, it will split up the requests into several 64Byte blocks. Naturally, the individual blocks should be alingned to the 64Byte boundaries for best bus utilization and performance. Because of the removal of PIPE, there is no bus contention, that is, using SBA, the next request can be issued already before the end of the ongoing incoming data transfer to allow streaming transfers.
• Removal of high priority transaction support: All transactions now have the same "low" priority.
• Addition of isochronous support.

Next Page:    => Changes in Pinout =>