Do the Athlon 64's feature a shared memory bus? Can the north bridge in
Athlon 64 systems directly read/write system memory (without utilizing the
A64's built-in memory controller)? I'm guessing the north bridge can, but
I'm not sure.

--
Doug

On Sat, 18 Feb 2006 20:28:54 GMT, "pigdos" <(E-Mail Removed)> wrote:

>Do the Athlon 64's feature a shared memory bus? Can the north bridge in
>Athlon 64 systems directly read/write system memory (without utilizing the
>A64's built-in memory controller)? I'm guessing the north bridge can, but
>I'm not sure.

If by north bridge, you mean the I/O chip(s), no. The Athlon64 contains a
fair amount of the functionality of what was traditionally the "north
bridge". IOW all system DMA has to pass through Hypertransport links to
the CPU's crossbar and memory controller.

--
Rgds, George Macdonald

Are you sure about that? That would seem to me really inefficient and
contribute to propagation delays. The north bridge (which still exists)
would have to receive all the data and forward it to/from the A64 memory
controller, PCI/PCIe/AGP buses rather than handling all this itself? For
example, if we have an AGP access, say from the video card to system memory,
the AGP bus would xfer it's address request to the North Bridge, the North
Bridge would then have to forward this request to the A64 memory controller,
which would then fetch the AGP memory data, send it back to the North Bridge
and then the North Bridge sends it back to the video card. It would even be
worse if we experience a TLB miss in the North Bridge because then we have
to request the GART from the A64 memory controller. DMA access would
similarly be degraded. No matter how fast the bus between the A64 memory
controller and the North Bridge there would still be more latency than if
the North Bridge could handle it itself.

--
Doug
"George Macdonald" <fammacd=!SPAM^(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Sat, 18 Feb 2006 20:28:54 GMT, "pigdos" <(E-Mail Removed)> wrote:
>
>>Do the Athlon 64's feature a shared memory bus? Can the north bridge in
>>Athlon 64 systems directly read/write system memory (without utilizing the
>>A64's built-in memory controller)? I'm guessing the north bridge can, but
>>I'm not sure.
>
> If by north bridge, you mean the I/O chip(s), no. The Athlon64 contains a
> fair amount of the functionality of what was traditionally the "north
> bridge". IOW all system DMA has to pass through Hypertransport links to
> the CPU's crossbar and memory controller.
>
> --
> Rgds, George Macdonald

On Mon, 20 Feb 2006 05:43:14 GMT, "pigdos" <(E-Mail Removed)> wrote:

>Are you sure about that?

Yes.

> That would seem to me really inefficient and
>contribute to propagation delays. The north bridge (which still exists)
>would have to receive all the data and forward it to/from the A64 memory
>controller, PCI/PCIe/AGP buses rather than handling all this itself?

Call it a north bridge -- for convenience? -- if you wish but it really
isn't any longer and hasn't been for some time: Intel calls theirs a MCH
(Memory Controller Hub) which includes a memory controller, AGP/PCI-e x16
and bus to the I/O chip; for AMD64 systems, nVidia has a single chip which
includes the HT link and all I/O interfaces, including AGP/PCI-e x16...
IOW, no umm, south bridge!

> For
>example, if we have an AGP access, say from the video card to system memory,
>the AGP bus would xfer it's address request to the North Bridge, the North
>Bridge would then have to forward this request to the A64 memory controller,
>which would then fetch the AGP memory data, send it back to the North Bridge
>and then the North Bridge sends it back to the video card. It would even be
>worse if we experience a TLB miss in the North Bridge because then we have
>to request the GART from the A64 memory controller. DMA access would
>similarly be degraded. No matter how fast the bus between the A64 memory
>controller and the North Bridge there would still be more latency than if
>the North Bridge could handle it itself.

Compared with current FSB (Intel), and previous AMD, designs the only place
where there's a latency hit is on video card DMA since the memory
controller and video bus are obviously not on the same chip. In the
context of an I/O device, and the relative clock speeds, I believe the
effect is negligible. The current (1000MHz) HT peak bandwidth of 4GB/s in
both directions is sufficient to keep up with any current I/O device.

As I already noted, a fair portion of "north bridge" logic/activity --
address arbitration, MTRRs etc. -- is now on the CPU chip... including the
GART TLB. The system chip -- hub, north bridge, whatever -- just shuffles
and directs data to/from I/O devices.

Bottom line: the priority for latency in the system as a whole is
distributed where it is most beneficial, i.e. CPU<->memory transactions at
the top.

>--
>Doug
>"George Macdonald" <fammacd=!SPAM^(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>> On Sat, 18 Feb 2006 20:28:54 GMT, "pigdos" <(E-Mail Removed)> wrote:
>>
>>>Do the Athlon 64's feature a shared memory bus? Can the north bridge in
>>>Athlon 64 systems directly read/write system memory (without utilizing the
>>>A64's built-in memory controller)? I'm guessing the north bridge can, but
>>>I'm not sure.
>>
>> If by north bridge, you mean the I/O chip(s), no. The Athlon64 contains a
>> fair amount of the functionality of what was traditionally the "north
>> bridge". IOW all system DMA has to pass through Hypertransport links to
>> the CPU's crossbar and memory controller.
>>
>> --
>> Rgds, George Macdonald
>

--
Rgds, George Macdonald

George, I don't think this guy actually understands the K8 system
architecture...

DK

Duh, I never said I did... That's why I was asking a QUESTION. Dumb****...

--
Doug
"David Kanter" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> George, I don't think this guy actually understands the K8 system
> architecture...
>
> DK
>

So you BELEIVE it's negligible and then you go on to say EXACTLY what I was
saying regarding the latency hit. What happens if the AGP or DMA request
happens when the bus to the A64 memory controller is in use? Yeah, that's
right, we get a nice, big stall, whereas in a North Bridge setup this would
never be an issue. If there are dedicated resources on the A64 memory
controller for the GART TLB, how are these resources utilized in a PCIe-only
environment? PCIe dosn't feature DIME. AGP system memory access, while
similar to DMA, is not DMA BTW.
--
Doug
"George Macdonald" <fammacd=!SPAM^(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Mon, 20 Feb 2006 05:43:14 GMT, "pigdos" <(E-Mail Removed)> wrote:
>
> Compared with current FSB (Intel), and previous AMD, designs the only
> place
> where there's a latency hit is on video card DMA since the memory
> controller and video bus are obviously not on the same chip. In the
> context of an I/O device, and the relative clock speeds, I believe the
> effect is negligible. The current (1000MHz) HT peak bandwidth of 4GB/s in
> both directions is sufficient to keep up with any current I/O device.
>
> As I already noted, a fair portion of "north bridge" logic/activity --
> address arbitration, MTRRs etc. -- is now on the CPU chip... including the
> GART TLB. The system chip -- hub, north bridge, whatever -- just shuffles
> and directs data to/from I/O devices.
>
> Bottom line: the priority for latency in the system as a whole is
> distributed where it is most beneficial, i.e. CPU<->memory transactions at
> the top.
>
>>--
>>Doug
>>"George Macdonald" <fammacd=!SPAM^(E-Mail Removed)> wrote in message
>>news:(E-Mail Removed)...
>>> On Sat, 18 Feb 2006 20:28:54 GMT, "pigdos" <(E-Mail Removed)> wrote:
>>>
>>>>Do the Athlon 64's feature a shared memory bus? Can the north bridge in
>>>>Athlon 64 systems directly read/write system memory (without utilizing
>>>>the
>>>>A64's built-in memory controller)? I'm guessing the north bridge can,
>>>>but
>>>>I'm not sure.
>>>
>>> If by north bridge, you mean the I/O chip(s), no. The Athlon64 contains
>>> a
>>> fair amount of the functionality of what was traditionally the "north
>>> bridge". IOW all system DMA has to pass through Hypertransport links to
>>> the CPU's crossbar and memory controller.
>>>
>>> --
>>> Rgds, George Macdonald
>>
>
> --
> Rgds, George Macdonald

On Mon, 20 Feb 2006 05:43:14 GMT, "pigdos" <(E-Mail Removed)> wrote:

>Are you sure about that? That would seem to me really inefficient and
>contribute to propagation delays. The north bridge (which still exists)
>would have to receive all the data and forward it to/from the A64 memory
>controller, PCI/PCIe/AGP buses rather than handling all this itself? For
>example, if we have an AGP access, say from the video card to system memory,
>the AGP bus would xfer it's address request to the North Bridge, the North
>Bridge would then have to forward this request to the A64 memory controller,
>which would then fetch the AGP memory data, send it back to the North Bridge
>and then the North Bridge sends it back to the video card. It would even be
>worse if we experience a TLB miss in the North Bridge because then we have
>to request the GART from the A64 memory controller. DMA access would
>similarly be degraded. No matter how fast the bus between the A64 memory
>controller and the North Bridge there would still be more latency than if
>the North Bridge could handle it itself.

There will be a (very) small latency hit on DMA and AGP memory data
accesses when compared to using an external memory controller.
However that is *WAY* more than offset by the (comparatively large)
decrease in latency on CPU memory requests.

The high-bandwidth/low-latency design of hypertransport, used to link
the I/O chips (call them a "north bridge" if you like, it's not
particularly accurate though) means that you're adding only a few
nanoseconds of latency to forward the request on, usually on the order
of 20-40ns (maybe even less). Remember that this link was designed
with this sort of forwarding of memory requests in mind since that's
exactly what it does in a multiprocessor setup when accessing remote
memory. If we compare this to some common sources of DMA access the
latency becomes pretty negligible. For example, hard drives have a
latency up in the millisecond range, so an extra 30 nanoseconds or so
is totally invisible. Same goes for network cards.

The only place where this really comes into affect is video cards, and
in particular, shared memory video cards. AGP/PCI-Express cards with
built-in memory don't really need to worry much about transferring
data to main memory on the fly since *MOST* of the important data is
kept in local memory on the card itself. The difference in latency
and bandwidth between local memory and remote memory is HUGE, so an
extra 30ns of latency and virtually no hit to bandwidth doesn't end up
changing things much. When you're looking at "really slow" vs. "the
tiniest bit slower", usually you don't worry too much.

However with shared memory video, things get a bit trickier. Here
you're ALWAYS dealing with remote memory and you're always limited by
bandwidth and latency. However again this is a bit of a comparison
between "bad" and "just slightly worse", and the goal in designing
integrated video is ALWAYS to reduce the bandwidth needs and hide
latency, regardless of what platform you're using.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

pigdos wrote:

>Duh, I never said I did... That's why I was asking a QUESTION. Dumb****...

*plonk*

On Tue, 21 Feb 2006 00:06:31 GMT, "pigdos" <(E-Mail Removed)> wrote:

>So you BELEIVE it's negligible and then you go on to say EXACTLY what I was
>saying regarding the latency hit.

What do you not understand about "negligible"?

> What happens if the AGP or DMA request
>happens when the bus to the A64 memory controller is in use? Yeah, that's
>right, we get a nice, big stall, whereas in a North Bridge setup this would
>never be an issue.

For AGP or video PCI-e x16, there will be a non-noticeable increased delay
- "big stall" is not even close. In a MCH/IOCHx system (north bridge setup
?), all other DMA transactions, e.g. PCI, non-video PCI-e, come off an I/O
chip which is connected to the MCH by a serial link - no different from a
HT link in terms of conflicts and latency. Similarly, when the memory
controller is busy with another transaction, CPU or DMA to/from I/O device,
a simultaneous 2nd request is always going to have to wait its turn.

BTW the "bus to the A64" is HyperTransport and is bi-directional 4GB/s in
both directions simultaneously - the only additional delay vs. your err,
"north bridge" is the request flight time over this "bus".

> If there are dedicated resources on the A64 memory
>controller for the GART TLB, how are these resources utilized in a PCIe-only
>environment? PCIe dosn't feature DIME.

I'm no expert but I believe the GART aperture can be used for mappings to
do with DMA as well as DIME. What the hell does it matter anyway? You're
the one who brought up the GART TLB - WHY... if you now want to argue it's
not necessary? If GART is not needed you umm, disable it.

> AGP system memory access, while
>similar to DMA, is not DMA BTW.

Depends what you mean by DMA: in the sense of traditional PC ISA
architecture DMA, yes it's different; in the sense of generic Direct Memory
Access, yes it's a valid use of the term. IIIR it's called DMA Mode in the
AGP docs. What do *you* want to call it?

>--
>Doug
>"George Macdonald" <fammacd=!SPAM^(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>> On Mon, 20 Feb 2006 05:43:14 GMT, "pigdos" <(E-Mail Removed)> wrote:
>>
>> Compared with current FSB (Intel), and previous AMD, designs the only
>> place
>> where there's a latency hit is on video card DMA since the memory
>> controller and video bus are obviously not on the same chip. In the
>> context of an I/O device, and the relative clock speeds, I believe the
>> effect is negligible. The current (1000MHz) HT peak bandwidth of 4GB/s in
>> both directions is sufficient to keep up with any current I/O device.
>>
>> As I already noted, a fair portion of "north bridge" logic/activity --
>> address arbitration, MTRRs etc. -- is now on the CPU chip... including the
>> GART TLB. The system chip -- hub, north bridge, whatever -- just shuffles
>> and directs data to/from I/O devices.
>>
>> Bottom line: the priority for latency in the system as a whole is
>> distributed where it is most beneficial, i.e. CPU<->memory transactions at
>> the top.

--
Rgds, George Macdonald