R
Rob Stow
ykhan said:
No surprise there. BTX is Intel's answer to all the
heat their P4's produce. AMD's solution is simply
to not make so much heat in the first place. And the
differences are very large - about a 45 to 50 W
difference between a 2.2 GHz Athlon FX and a 3.4 GHz P4.
Can't quite understand why Intel wouldn't simply kill
off the P4 and use the Pentium M to compete with AMD.
Comparable clock-for-clock performance using 40% as much
power. Put an on-chip memory controller into Dothan
and give it the 64 bit x86-64 extensions and it would
probably be a real Opteron killer.
Y
ykhan
Rob Stow said:
On-chip RAM controller is apparently not going to be ready till 2007,
last I read. Hell, it took AMD about two years to integrate the memory
controller, otherwise Opteron/Athlon 64 would've been out about two
years ago. Even with the memory controller, P-M still wouldn't have
the Hypertransport, so no answer to Opteron yet, but it might be a
compelling competitor to Athlon 64.
Yousuf Khan
K
keith
I find this simply *amazing*!!
I highly doubt that took all of two years. Come on, Yousuf! It's a damned
*memory controller*! What? a few tens of thousand gates and a few I/O?
OTOH, I gotta admit that I have no clue why we haven't had this for
*years*. Bandwith is nice, but latency is *king*.
I don't see HT as being a lynchpin. Indeed the only reason it's
interesting is because of the integrated memory controller.
T
Tony Hill
If that is indeed the case, what in the hell is taking Intel so
long?!?! It's not like they don't know how to build a memory
controller! Certainly it seems that integrating the memory controller
on the CPU die has been proven to be the way forward. Intel is now
pretty much the only company that has not done so yet.
Err, the Opteron was out more than a year and a half ago. Not quite
two years yet, but it's getting pretty close.
Once Intel finally gets around to integrating a memory controller
on-die, it no longer makes sense to have a traditional processor bus,
so I would imagine that they'll have a hypertransport-like solution.
I'm guessing that they won't use Hypertransport itself, but probably
something that is very similar. They've already got their
"Accelerated Hub Architecture" bus and PCI-Express as potential
candidates to base such a design off of.
G
George Macdonald
Hmmm, could it be that the road-map has become more important than the err,
road? Of course it would also involve a generous helping of crow, I'd say.
It's certainly going to be interesting to see how they spin it? If this is
how they arrive at the unified Itanium/x86 system architecture, it seems a
bit flat to me.
Rgds, George Macdonald
"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Y
ykhan
keith said:
Let's face it, we totally forget how much headache AMD went through,
designing all of these things quietly in the wilderness. It took a lot
of PR lumps from Intel for not responding to every little Pentium 4
speed increment or feature with an equivalent Athlon XP feature or
increment. It's now AMD's turn to laugh -- it's built up a huge lead
on Intel.
Well, I'm sure the original design was done fairly quickly, but then
they probably had a lot of tweaking and retuning, testing and
validation to do. Testing it out on low-quality ram, etc.
Plus, this type of memory controller has never been done before,
something operating at the speed of the processor that is. All
chipset-based ram controllers were operating in the 100's of Mhz
range, this one has to operate at several Ghz.
Not so much on a single-processor Athlon 64, sure, but quite a
lynchpin in a multiprocessor Opteron setting.
Yousuf Khan
Y
ykhan
Tony Hill said:
Well, a memory controller operating out of a chipset only has to
operate at several hundred Mhz. One operating out of a CPU will be
operating at several Ghz (especially if it's inside a P4 which was
designed to do nothing but Ghz).
I was talking about the amount of time that the design spent being
implemented prior to release.
I was thinking not so much about I/O demands as I was for
multiprocessor cache-coherency.
Yousuf Khan
Y
ykhan
George Macdonald said:Hmmm, could it be that the road-map has become more important than the err,
road? Of course it would also involve a generous helping of crow, I'd say.
It's certainly going to be interesting to see how they spin it? If this is
how they arrive at the unified Itanium/x86 system architecture, it seems a
bit flat to me.
Isn't the Itanium bus supposed to be yet another shared bus too, just
like Pentium's bus? How exactly will it be able to compete against
Hypertransport?
Yousuf Khan
K
keith
I look at it entirely differently. Intel *has* DRAM controller expertise.
They *have* the tools they need. Where are they? Intel has more than
three engineers in a basement, eating mold, somehwere. Five years to port
a DRAM controller?
Oh, come on! They *have* that expertise. Thre is something fishy here
(likely, stinky pointy-haired fish). NIH is a bitch!
Oh crap, Yousuf! The FSB doesn't run at the core frequency either. I
don't seeee this as any issue at all. Processor technology is the
bleeding edge.
It would be a rather crappy connection without the integrated memory
controller. That is, a northbridge hanging off HT would be a disaster.
K
keith
Why? I don't understand your logic at all! The FSB of a 3+GHz
processor runs at the mid-hundreds of MHz sorts of rates.
So Intel sat on their thumbs until, err next July, before deciding that an
integrated memory controller was a good thing? Amazing.
There are other ways to skin that cat. INtel's shared bus isn't
necessarily the best one.
D
David Wang
1. Getting things to run slower isn't a problem. As long as
it's not orders of magnitude slower, to the point that dynamic
circuits stop working. Your thoughts about why Intel has not
integrated a memory controller into the P4 line does not have
a good basis in reality.
2. Intel has integrated memory controllers into several of its
products. Take a look at the StrongArm-ne-XScale lines.
3. Intel had previously designed an x86 processor with an integrated
controller, and not just a regular old SDRAM-variant memory
controller, but the nasty Rambus controller. Timna.
T
Tony Hill
My understanding is that the Itanium's bus is pretty much the same
thing as the P4's bus except 128-bits wide instead of 64-bits.
Definitely a shared bus.
I tend to agree with Keith's earlier statement though, Hypertransport
isn't anything to get too excited about performance-wise, it's the
integrated memory controller that makes Opteron interesting, HT is
just an off-shoot of this. Sure, it's a very nice little interconnect
that is very flexible and allows for very good performance for very
low cost, but there's nothing earth-shattering about it. The
integrated memory controller is where the magic is.
T
Tony Hill
While I'll agree that it wouldn't be a very smart idea, it actually
doesn't seem as bad in reality as I expected. If you've got a
dual-processor Opteron board where the memory is only connected to a
single processor (as is the case on most low-end 2P Opteron boards),
you essentially have just what you mentioned, a northbridge hanging
off hypertransport. While such a design does cost you a bit in
performance, it doesn't seem to cost nearly as much as I would have
previously thought, usually only a few percent here or there.
Similarly I recently saw some number of a chipset with integrated
video accessing local memory vs. accessing memory through the CPU and
over hypertransport. Here I figured the performance penalty would be
HUGE, but it actually turned out to be fairly small. Here's the info:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2269&p=17
Long story short, while I'll agree with you that the integrated memory
controller is the key concept that makes the Opteron tick,
hypertransport is a nice little interconnect. Perhaps not so much
because of the performance it offers (which, while respectable, is not
groundbreaking), but rather that it's a VERY flexible and low-cost
interconnect that can easily be worked into the pricing scheme of PCs.
Sure, IBM's Power5 has a processor interconnect that makes
Hypertransport look like a child's toy, but there's no way they could
get the economics of that to work in the PC world.
With hypertransport you get good performance for a great price point
and a very flexible design that seems to work well from the fairly
high-bandwidth Opteron connection right down to a the very low-end in
some embedded designs.
Y
ykhan
David Wang said:
Still requires a lot of field testing before it can be released. And
it would need to be able to work even on the cheapest no-name brand
DIMMs. With the tremendous speed differential between the memory
controller and the DIMMs that it controls, it's bound to find some
cheapo brands that don't quite live upto their advertised SPID
ratings, so getting to the appropriate conservative fudge factors
would take some empirical testing.
Processors that run in the Mhz ranges not the Ghz ranges. Plus they
aren't even from the same architecture family as x86 processors. In a
modern context metaphor, it's like saying Intel should be able to come
up with a dual-core P4 fast because they are almost ready to make
dual-core Itaniums -- no relationship whatsoever between them.
That processor was still-born, it was never released. For all we know
those engineers that worked on the project later became hdtv chip
designers or something.
Besides, it was based on a Pentium 3 core, when those things were just
barely entering the Ghz range. It's likely that Timna was still in the
Mhz ranges at that time. What I'm trying to say here is that Intel and
many other chipset manufacturers have years upon years of experience
creating memory controllers in the Mhz ranges, the increments in FSB
speeds have been kept under tight control for years, seeing doublings
only every two or three years at most, not every year like with the
CPUs themselves.
As for Rambus, wasn't that supposed to be one of easier controllers to
build? I could swear I heard rumblings that the reason Rambus was
being pushed by Intel was because it simplified the process of
designing the timings and interfaces to the RAM, since most of the
control was onboard the RIMM itself. Much like what FB-DIMMs are
supposed to do soon. The only thing nasty about the Rambus was when
they tried to create a chipset that could translate RAMBUS commands
into SDRAM commands.
Yousuf Khan
Y
ykhan
keith said:
Of course we mustn't forget about "turf expertise". The memory
controllers are mainly built by the chipset guys, they have complete
control and know exactly where to put the circuitry on their own
chipset designs, but are clueless where to put it inside a CPU, until
the CPU guys allocate some real estate on the die for them. Requires
some communication, i.e. too much work. Much easier to simply hire new
guys into the CPU side and have them create memory controllers from
scratch.
Well, the overall Opteron/Athlon 64 design took about two years. Don't
know how much of that was devoted to memory controllers,
Hypertransports, instruction sets, etc. From reports, the instruction
sets were little trouble at all, and if they were simply just adding a
new ISA and nothing else it would've been out in about a year after
initial design. They could've possibly even grafted it right onto an
Athlon XP possibly.
That really is my point. In the past, the chipsets were *not* running
at the CPU core frequency, but this integrated memory controller is.
It's simply a matter of creating a memory controller capable of adding
enough wait states to interface with the DIMMs properly.
Not referring to hanging a northbridge off of the HT, I'm talking
about multiprocessor communications really. That's the really the main
important use of HT, hanging peripherals off of it seems to be a
secondary purpose.
Yousuf Khan
D
David Wang
You do realize that Intel builds and sells tons of memory controllers
that interfaces with all sorts of memory devices? These issues are
well known and already taken care of by the folks that build the
system controllers.
Intel uses its N-1 generation capacity to build the system controllers
to amortize the costs of the fab line, not because there's any issues
in using the N th generation (the latest and greatest) process to
build memory/system controllers.
As I wrote above. The GHz/MHz thing is a red herring. I don't know
how you managed to convince yourself that such an explanation works,
but I doubt that it'll make sense to others. You can always operate
part of the chip at a lower frequency with a clock divider if that
makes you happy. Look at how AMD built the Opteron. The DMC is sitting
across a "northbridge" that's integrated into the die, and the DMC
is operating at a lower frequency.
In the x86 line, Intel used to sell a processor with an integrated
DMC, I think it was the 486SL or some such thing. It cost more
to build, but Intel wasn't able to sell it for more money, so it
was discontinued.
That processor was still-born, it was never released. For all we know
those engineers that worked on the project later became hdtv chip
designers or something.
Banias could be found in an HDTV device I suppose.
Please stop this line of argument. You're twisting yourself in a knot
arguing a viewpoint that makes no sense. The memory controllers won't
run at GHz ranges even if you integrate it into the processor. The
memory controllers must necessarily run at the frequency of the DRAM
devices they control. i.e. the Opteron's DDR SDRAM memory controller
runs at 200 MHz to control DDR400 SDRAM devices.
Seriously, building a memory controller into the CPU is not rocket
science. Now, building a high performance memory controller, that
requires some serious architecture/engineering work, especially
since DRAM systems are becoming ever more finicky for engineers to
move data in and out of them.
Intel built those D-RDRAM to SDRAM translation hubs with N-1 generation
silicon. It's not going to be difficult to naively integrate the
D-RDRAM to SDRAM translator onto the same piece of silicon and get
a "SDRAM controller" out of it.... Not that this is anyone's choice
of building an SDRAM controller.
Weren't you arguing about quality control/signaling problems with
"cheap" memory modules above? D RDRAM kind of requires you to
engineer some pretty clean signal paths. You can be sloppier with
SDRAM. Then again, DDR now gets to be pretty serious too.
Y
ykhan
keith said:
Yes, an external FSB would run in the mid-hundreds of Mhz. But in an
Opteron there is no traditional FSB, the memory links directly to the
CPU, not the chipset. The memory controller in the CPU would be
running at the speed of the CPU, and it would synchronize to the (much
slower) DIMM interfaces using wait states -- lots of wait states,
considering the huge difference in speed between the memory controller
and DIMM.
This is no different than what a traditional FSB-based memory
controller would need to do too if it were working with sub-optimal
RAM. For example a system with an 800 Mhz controller would have to add
a certain number wait states if it were working with 533Mhz RAM, and
even more wait states if it were working with 400Mhz RAM. But the
chipset has the advantage that it rarely ever changes its frequency
within a generation, it will stay at 800Mhz until it replaced by the
next generation which itself will stay at its designated original
frequency because of the FSB. The CPU however, could be going from
1.8Ghz to 2.6Ghz within a generation, and the internal memory
controller would have to take that into account.
Maybe not July, they may have decided a /few/ months earlier than
that.
Prior to that they were quite satisfied with a chipset-basedmemory controller, and saw no reason to change from that. They didn't
think the onboard controller was really that much of a threat.
This is simply a situation with somebody being caught with their pants
down, pure and simple.
Yes, exactly, that's why AMD came up with the HT bus.
Yousuf Khan
G
George Macdonald
I was just thinking the time frame for the "unified bus" corresponds with
the 2007 you mentioned for an on-chip memory controller, according to what
I've read. IOW the unified bus system framework would have be something
similar to Hypertransport's - no?... a processor network or cross-bar, with
a pipe to peripherals
Rgds, George Macdonald
"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
K
Keith R. Williams
No, you simply divide the clock down to the frequency you wish to run
the dram controller. This is *no* different than dividing the
frequency down to run the FSB. ...or caches, or...
No wait states are needed at all (other than for different speed
memory, perhaps). Simply divide the clock down to the desired
frequency. This sort of thing is done all the time.
Maybe not July, they may have decided a /few/ months earlier than
that.
memory controller, and saw no reason to change from that. They didn't
think the onboard controller was really that much of a threat.
I don't think their engineers are that dumb. Even I saw it as a GOOD
THING (TM) two years ago and wondered why it hadn't been done before.
The latency advantages are obvious. These days processor designs don't
last as long as DRAM technologies, so it makes sense to integrate the
DRAM controller. Moons ago this wasn't so true.
And a blushing butt, apparently. Amazing!
I'm a big fan of AMDs engineering here, no question. I don't believe
that Intel still hasn't gotten it (and is waiting until next July to
get it ;-).