Re: Fwd: AMD x2 chips

[Mark Hahn <hahn@xxxxxxxxxxxxxxxxxxx>]

> And you're over-simplifying.  The crossbar between the cores is
> _radically_different_ than between the "blocks."  The control unit of
> the cores do _not_ interface.  You're crossing the concepts of
> building peripherals around a core with having two _separate_ cores.

good god!  look, it's simple: you claimed that the two cores on an 
AMD DC chip were separate ICs.  this is just plain wrong, and an abuse
of the well-established concept of an IC.

> > I'd appreciate a reference to this 16-socket system; is it somehow 
> > using the new M2 opterons?  the Horus people clearly think they 
> > have something unique in their system, which exists precisely to 
> > do the extra bookkeeping to make HT think there are only 8 nodes,
> > but still "proxy" them into a single memory address space.
> 
> I'm talking about the modular 4-socket mainboards that can be
> combined into 16 (or greater) sockets.  The 4-socket uses 2
> HyperTransports between each CPU, and then 2-sockets have 1
> HyperTransport to the next board (ignoring the HyperTransport links
> used for I/O).  The common configuration I've seen is 4 x 4-socket
> mainboards.
> 
>   O---O+++O---O
>   |   |   |   |
>   O---O   O---O
>   +           +
>   +           +
>   O---O   O---O
>   |   |   |   |
>   O---O+++O---O 

I don't believe these exist in the AMD world - do you have a reference?

perhaps you're thinking of the Intel world, where this design could be
referring to IBM's X3 chipset, for instance, where quads are a common 
building block.

> Furthermore, how does even the _single_ core+L1+L2 talk to the
> on-board memory and HyperTransport?  Is that a Xbar too?  Possible an
> internal implementation of EV6?

sure, the diagram for a K8 is largely identical for all models,
and like a some EV6-based systems, it is xbar-based.

> Everything I've read suggests that there are _no_changes_ in the
> dual-core from the single-core.  Which suggests there is the same
> switch used inside.

you just aren't listening.  Bill and I said that: that DC simply adds another 
core onto the SRQ, which itself sits on the xbar.

> > an xbar is a device which can switch between any of its ports.
> > there's really no need to refer to Alpha architecture here.
> > (I have a whole room full of EV6's, and xbar is really a logical
> > construct, since not every possible connection can be made.)
> 
> Okay then, virtually up to a 16-node Xbar (even if not physical).

now you're conflating the HT fabric with the within-K8 xbar.
really, the whole point here is that they're necessarily different
because the HT fabric is limited to 8 nodes, which does not count
all the xbar ports, and in particular doesn't change with DC.

> The 40-bit address and other bus limitations of EV6 are readily
> apparent in A64/Opteron, which suggests that other than the 64-bit
> ALU, PAE 52-bit "Long Mode" and 8 new XMM registers, A64/Opteron is
> little changed at the core from Athlon and its EV6.

this is bizarre - who are you arguing with?

> Which suggests they moved the Xbar inside.
> Which is why going dual and even multicore is easy.

it's easy because it the cores simply talk to the SRQ.

> > you still didn't look at AMD's diagram?  the connection is 
> > core->SRQ->xbar->memctrl.
> 
> And what is the SRQ/Xbar?

System Request Queue is a unit that connects the core(s) to the xbar.  
the xbar is a switching network that permits all the  units (SRQ, 3xHT,
memctrl) to talk to each other.  the xbar can't be HT-based because it
connects more units in total than HT can address.

> > correct: another port on the srq.  they even brag about this, how
> > they had the foresight to design for DC in the original k8.
> 
> Which is what?  Is it just a new implementation of EV6 on-die?
> Everything I've read suggests so.

sigh.  I have no idea what you're pushing with all the EV6 comparisons.
the EV6 was a good CPU for its time.  the crossbar was actually in the
typhoon chipset (ES4x).  I have a roomfull of them still running.
they were NOT hypertransport.

-- 

amd64-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/amd64-list