AGP Bus Issues


AGP Configuration Space Requirements

Some legacy operating systems require that the AGP capability registers be mapped at Bus 0, Device 0, and Function 0. Also, The AGP aperture base address configuration register must be at Bus 0, Device 0, Function 0, Offset 10h. In a legacy system, these registers are located within the Host to PCI bridge configuration space (Host to HT bridge in our example). See Figure 20-5.

Figure 20-5. Legacy Configuration Mapping for Host to HT Bridge with AGP and DRAM Controller

graphics/20fig05.jpg

For complete legacy software support, the specification recommends that the AGP subsystem be designed as follows :

  • AGP bridges are placed logically on HyperTransport chain 0 (Bus 0).

  • The AGP interface uses multiple UnitIDs due to AGP configuration being split between the Host to HT bridge and the Host to AGP bridge (i.e., virtual PCI to PCI bridge).

  • During initialization the base UnitID of an AGP device must be assigned a non-zero value to support configuration of chain 0. Following HT initialization the base UnitID should be changed to zero.

  • Device number zero, derived from the base UnitID register value, should contain the capabilities header and the AGP aperture base address register (at Offset 10h), as pictured in Figure 20-5 on page 470.

  • Device number 1, derived from the base UnitID+1, should be used for the Host to AGP bridge.

  • The UnitID that matches the base (0) is not used for any AGP-initiated I/O streams or responses so that there is no conflict with host-initiated I/O streams or responses. Only UnitIDs greater than the base may be used for I/O streams.

  • Legacy implementations place the AGP graphics address remapping table (GART) in the host. Thus, the AGP aperture base address register and any other registers that are located in the AGP device but required by the host are copied by software into implementation-specific host registers. These implementation-specific registers should be placed somewhere other than Device 0, to avoid conflicts with other predefined AGP registers. In a sharing double-hosted chain, this requires the hosts to implement the Device Number field so that the hosts may address each other after the AGP bridge has assumed Device 0. See "Case 3: Initializing A Double Hosted Chain" on page 320 for more information.

Note that if legacy OS support is not required, the AGP device's base UnitID register may be programmed to any permissible value.

AGP Ordering Requirements

Three categories of AGP transaction types lead to three separate sets of ordering rules. These categories can be thought of as three separate transaction channels. These three channels are completely independent of each other with respect to ordering, and should have their own UnitIDs. The transaction types are:

  • PCI-based

  • Low Priority

  • High Priority

The specification makes the following observation that leads to HT-based AGP ordering requirements being slightly less complex that PCI-based requirements:

The ordering rules presented here for reads are somewhat different from what appears in the AGP specification. That document defines ordering between reads in terms of the order that data is returned to the requesting device. We are concerned here with the order in which the reads are seen at the target ( generally , main memory). The I/O bridges can reorder returning read data if necessary. This leads to a slightly relaxed set of rules.

See MindShare's AGP System Architecture book for details regarding the AGP ordering rules.

PCI-Based Ordering

AGP transactions based on the PCI protocol follow the same rules as PCI. Therefore, the ordering rules discussed in Figure 20-1 on page 459 also apply to these types of AGP transactions.

Low Priority Ordering

Ordering rules for the low priority AGP transactions are:

  • Reads (including flushes) must not pass writes .

  • Writes must not pass writes.

  • Fences must not pass other transactions or be passed by other transactions.

High Priority Ordering

High priority transactions only carry graphics data using split transactions. Consequently, the Producer/Consumer model has no relevance and ordering requirements can be reduced to the following single rule:

  • Writes must not pass writes.

Transaction Translation

AGP is also allowed to generate requests with discontiguous byte masks, and require the same transaction handling as PCI. Refer to "PCI Burst Transactions" on page 466.

Command conversion from AGP-to-HT is listed in Table 20-7 on page 473. Note that the AGP graphics device is always the initiator of AGP transactions; therefore, HT-to-AGP conversion is not defined.

Table 20-7. AGP-to-HT Command Conversion

PCI -X Transaction Type

HyperTransport Packet Type

High Priority Write

WrSized, Posted, PassPW = 1 or 0 (alternate)

High Priority Read

RdSized, PassPW = 1 or 0 (alternate), RespPassPW = 1

Low Priority Write

WrSized, Nonposted, PassPW = 1

Low Priority Read

RdSized, PassPW = 1, RespPassPW = 1

Low Priority Flush

None (wait for all outstanding writes to complete)

Flush, PassPW = 0 (alternate)

Low Priority Fence

None Wait for all outstanding read responses (alternate)



HyperTransport System Architecture
HyperTransportв„ў System Architecture
ISBN: 0321168453
EAN: 2147483647
Year: 2003
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net