AGP SBA question

[pigdos]

I've been looking over the AGP 3.0 spec. and noticed there appear to be 8
pins dedicated to SBA and that SBA is a one way bus (from vid card to AGP
port). This is about all I was able to get out of the documentation though.

Is SBA merely the method by which a video card xfers addresses in the AGP
aperture range for which it will read/write? Are these addresses 32-bits in
length? If they are 32-bits how do the 8 SBA pins xfer these 32-bits? Is it
some sort of DDR scheme?

 

[George Macdonald]

I've been looking over the AGP 3.0 spec. and noticed there appear to be 8
pins dedicated to SBA and that SBA is a one way bus (from vid card to AGP
port). This is about all I was able to get out of the documentation though.

It's one-way because address requests to main memory only go in the one
direction, from the AGP device to the chipset.

Is SBA merely the method by which a video card xfers addresses in the AGP
aperture range for which it will read/write? Are these addresses 32-bits in
length? If they are 32-bits how do the 8 SBA pins xfer these 32-bits? Is it
some sort of DDR scheme?

SBA == Side Band Addressing. Note that AGP 3.0 dropped pipelined
addressing on the multiplexed Address/Data Bus. The AGP address
transactions are not just 32-bit addresses - since an AGP data transfer is
8 bytes min-length/aligned, the bottom 3 bits are used for transaction
length info. There's also command info which is transferred on the four
C/BE pins for the non-SBA multiplexed transactions on the Address/Data Bus.

When SBA is used, the C/BE pins are not used for the 4-bit command request
code which is folded into the SBA transaction request, which can handle a
36-bit memory address and also includes the length info and the SBA command
"type code", so that a full SBA transaction can be up to 48-bits in length
and require six SBA bus transfers... *BUT* there are also sticky bits for
addresses, which are held in the target (chipset) from a previous
transaction, so that if an address differs only in the bottom 15 bits from
that of the previous transaction, only 2 bus transfers are required.

There is also an optional extended mode SBA command type which allows for
48-bit memory addresses but I guess that's become kinda academic now with
PCI-E taking over.

The SBA Bus runs at the same 8x speed as the data bus, i.e. clocked at 4x
the base clock plus DDR.

The AGP 2.0 docs cover some of this better than the AGP 3.0, which is
written, in some places, as a comparison with the previous spec.

 

[pigdos]

Thanks George, interesting stuff, even if it is dead. Are there similar
mechanisms by which PCIe video cards can directly access system memory?

 

[George Macdonald]

Thanks George, interesting stuff, even if it is dead. Are there similar
mechanisms by which PCIe video cards can directly access system memory?

Though I don't have access to PCI-e specs, I have to assume it uses sticky
bits - a way to get a packetized or semi-packetized narrow bus like AGP/SBA
to work more efficiently. AIUI, the big difference with PCI-e is that all
addresses which come out of the video card are hardware addresses - IOW
GART translation is built into the video chip circuitry.

Doug

 

[pigdos]

George, since the minimum AGP data xfer is 8 bytes and always aligned on 8
bytes, wouldn't the 6 LSb's be unused for address information?

 

[George Macdonald]

George, since the minimum AGP data xfer is 8 bytes and always aligned on 8
bytes, wouldn't the 6 LSb's be unused for address information?

Here's a exercise for you: Find the next number in the series: 110, 20, 12,
11, 10, ?

;-)

 

[pigdos]

I understand part of this, three bits can encode 8 possible addresses, so
we're only interested in address bits 3 and greater?

Your exercise has me stumped.

 

[krw]

I understand part of this, three bits can encode 8 possible addresses, so
we're only interested in address bits 3 and greater?

Your exercise has me stumped.

George wrote a couple of posts above:
"Since an AGP data transfer is 8 bytes min-length/aligned"

I'd add that so are all memory transfers (8-byte aligned, now 16)
on P5 and later systems.

 

[George Macdonald]

I understand part of this, three bits can encode 8 possible addresses, so
we're only interested in address bits 3 and greater?
Right.

Your exercise has me stumped.

It's a good one.;-) Let's see who finds the answer... if anybody else is
reading this.

 

[The little lost angel]

22On Wed, 22 Nov 2006 21:12:54 -0500, George Macdona

Here's a exercise for you: Find the next number in the series: 110, 20, 12,
11, 10, ?

;-)

Hmm, 20 and 2?

 

[George Macdonald]

22On Wed, 22 Nov 2006 21:12:54 -0500, George Macdona


Hmm, 20 and 2?

Sorry. Why two numbers though? - I asked for just the next number in the
series.

 

[The little lost angel]

Sorry. Why two numbers though? - I asked for just the next number in the
series.

I figured I might get the first number correct by pure accident. So a
2nd number would determine if it was a fluke or I really got what I
think it is pPp

 

[pigdos]

What's confusing me is that the AGP 3.0 spec says that the data should be
aligned on 8 byte addresses but recommends you should always fetch/write at
least 64 bytes (so why not align data on 64 byte addresses)?
"When the AGP master needs to read a large amount of data from system
memory, it must split this up

into multiple 64 byte transaction requests. For optimum performance, these
requests should be

naturally aligned to 64 byte boundaries.

In some cases, the Core-Logic may have been optimized for data transfers
that are greater than 64

bytes. For instance, if the core-logic is designed for cache line accesses
of 128 bytes, it may perform

best with AGP request sizes that are some multiple of 128 bytes. A new 3-bit
field called ARQSZ in the

Core-Logic's AGPSTAT[15:13] register is used to provide the optimum transfer
size information to

software. The AGP Master should be programmed to group consecutively
addressed 64 byte requests

to effectively meet the Core-Logic's optimum transfer size expectations.
Note that this is only a

performance optimization and not a functional requirement."

 

[George Macdonald]

What's confusing me is that the AGP 3.0 spec says that the data should be
aligned on 8 byte addresses but recommends you should always fetch/write at
least 64 bytes (so why not align data on 64 byte addresses)?

Backwards Compatibility? I also don't see where, in the following it
recommends "at least" 64 byte transfers. The text you quote is in the
context of the fact that the 256 byte "long transfers" of AGP 2.0 was
dropped in AGP 3.0. Remember also that this is a spec which allows
implementation specific variations. E.g. though the pipelined multiplexed
addressing was dropped in the spec, a mfr can continue to offer it in an
"implementation", particularly given that the mfr usually wants to offer a
card which still works with AGP 2.0 core logic in the chipset.

"When the AGP master needs to read a large amount of data from system
memory, it must split this up

into multiple 64 byte transaction requests. For optimum performance, these
requests should be

naturally aligned to 64 byte boundaries.

In some cases, the Core-Logic may have been optimized for data transfers
that are greater than 64

bytes. For instance, if the core-logic is designed for cache line accesses
of 128 bytes, it may perform

best with AGP request sizes that are some multiple of 128 bytes. A new 3-bit
field called ARQSZ in the

Core-Logic's AGPSTAT[15:13] register is used to provide the optimum transfer
size information to

software. The AGP Master should be programmed to group consecutively
addressed 64 byte requests

to effectively meet the Core-Logic's optimum transfer size expectations.
Note that this is only a

performance optimization and not a functional requirement."