AMD has no plans to push BTX boards

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

http://www.theinquirer.net/?article=19969

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

ykhan wrote:
> http://www.theinquirer.net/?article=19969

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.

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Wed, 01 Dec 2004 06:36:20 -0800, ykhan wrote:

> Rob Stow <rob.stow.nospam@shaw.ca> wrote in message news:<bMcrd.383503$Pl.276907@pd7tw1no>...
>
>> 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.
>
> On-chip RAM controller is apparently not going to be ready till 2007,

I find this simply *amazing*!!

> last I read. Hell, it took AMD about two years to integrate the memory
> controller,

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*.

> 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.

I don't see HT as being a lynchpin. Indeed the only reason it's
interesting is because of the integrated memory controller.

--
Keith

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Thu, 02 Dec 2004 08:24:07 -0500, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:

>On 1 Dec 2004 06:36:20 -0800, yjkhan@gmail.com (ykhan) wrote:
>
>>Rob Stow <rob.stow.nospam@shaw.ca> wrote in message news:<bMcrd.383503$Pl.276907@pd7tw1no>...
>>
>>> 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.
>>
>>On-chip RAM controller is apparently not going to be ready till 2007,
>>last I read.
>
>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!

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??

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Tony Hill <hilla_nospam_20@yahoo.ca> wrote in message news:<kk4uq0tlvrf9to6b7v9puv2aobi3shvja2@4ax.com>...
> >On-chip RAM controller is apparently not going to be ready till 2007,
> >last I read.
>
> 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.

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).

> > Hell, it took AMD about two years to integrate the memory
> >controller, otherwise Opteron/Athlon 64 would've been out about two
> >years ago.
>
> Err, the Opteron was out more than a year and a half ago. Not quite
> two years yet, but it's getting pretty close.

I was talking about the amount of time that the design spent being
implemented prior to release.

> > 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.
>
> 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.

I was thinking not so much about I/O demands as I was for
multiprocessor cache-coherency.

Yousuf Khan

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

ykhan <yjkhan@gmail.com> wrote:
> Tony Hill <hilla_nospam_20@yahoo.ca> wrote in message news:<kk4uq0tlvrf9to6b7v9puv2aobi3shvja2@4ax.com>...
> > >On-chip RAM controller is apparently not going to be ready till 2007,
> > >last I read.
> >
> > 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.

> 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).


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.


--
davewang202(at)yahoo(dot)com

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

ykhan <yjkhan@gmail.com> wrote:
> David Wang <foo@bar.invalid> wrote in message news:<cootsr$a99$1@grapevine.wam.umd.edu>...
> > 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.

> 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.

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.

> > 2. Intel has integrated memory controllers into several of its
> > products. Take a look at the StrongArm-ne-XScale lines.

> 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.

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.

> > 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.

> 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.

> 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.

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.

> 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.

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.



--
davewang202(at)yahoo(dot)com

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

In article <bd84ed0c.0412030925.4fabb96e@posting.google.com>,
yjkhan@gmail.com says...
> keith <krw@att.bizzzz> wrote in message news:<pan.2004.12.03.03.40.14.833710@att.bizzzz>...
> > > 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).
> >
> > 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.
>
> 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.

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...

> 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.

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.

>
> > > I was talking about the amount of time that the design spent being
> > > implemented prior to release.
> >
> > So Intel sat on their thumbs until, err next July, before deciding that an
> > integrated memory controller was a good thing? Amazing.
>
> Maybe not July, they may have decided a /few/ months earlier than
> that. :-) Prior to that they were quite satisfied with a chipset-based
> 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.

> This is simply a situation with somebody being caught with their pants
> down, pure and simple.

And a blushing butt, apparently. Amazing!

> > > I was thinking not so much about I/O demands as I was for multiprocessor
> > > cache-coherency.
> >
> > There are other ways to skin that cat. INtel's shared bus isn't
> > necessarily the best one.
>
> Yes, exactly, that's why AMD came up with the HT bus.

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 ;-).

--
Keith

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Fri, 03 Dec 2004 15:13:15 -0500, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:

>On 2 Dec 2004 15:54:29 -0800, yjkhan@gmail.com (ykhan) wrote:
>
>>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?
>
>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

<ding ding> I believe you've just given the winning answer to all of
this George! That would indeed make sense, integrate the memory
controller on both the Itanium and Xeon line and then just have some
sort of HT-like connection to the outside work that could quite easily
be common between the two.

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

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sat, 04 Dec 2004 11:48:33 -0500, Tony Hill wrote:

> On Fri, 3 Dec 2004 15:29:38 -0500, Keith R. Williams <krw@att.bizzzz>
> wrote:
>
>>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.
>
> Note that on the Opteron it's not even an issue for the different
> speeds of memory, the chip doesn't support such things. You can ONLY
> use whole integer dividers for the memory clock vs. the core
> frequency. This is why you sometimes end up with DDR266 or DDR333
> memory not running quite as fast as ideally it should. Eg. if you
> plug DDR333 memory into a 1.6GHz Opteron it will only run at 160MHz
> (10x divisor) instead of the 166MHz it is designed for.

I was thinking more along the lines of the memory timings
(precharge/RAS/CAS/whatever).
>
> Fortunately for DDR400 memory this is not an issue at any clock speed as
> all Opteron/Athlon64 chips run at a whole integer multiple of 200MHz.
>
> Astute readers among you though might notice that this could again
> become a potential issue with DDR2, eg. a 2.4GHz Athlon64 could not run
> DDR2-667 memory at it's rated clock speed, only at DDR2-640 speed (if I
> understand DDR2 correctly and am doing my math right)

Too much math for a weekend...

--
Keith

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

David Wang wrote:
> 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.

What relevance does manufacturing generation technology have to do with
it? It's not at issue, Intel could use any process generation they want.
The issue is about how to build a memory controller into a piece of
silicon that keeps changing its frequency within a generation. Chipsets
are stable in their frequency, CPUs are not.

>>>2. Intel has integrated memory controllers into several of its
>>> products. Take a look at the StrongArm-ne-XScale lines.
>
>
>>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.
>
>
> 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.

It's not as simple as you seem to make it sound either. What you
describe is fine in a chipset context, which has a fixed main frequency;
a chipset will run at 66Mhz, or 133Mhz, or 200Mhz or whatever for its
entire production lifetime/generation. A CPU, within a generation might
have several speed grades, each of which would require different clock
dividers and waitstates. And if somebody were to try to overclock the
processor, the memory controller would have to be able to compensate
dynamically. There is bound to be more variables to look at when testing
any component inside a CPU context. I'm not saying that the principles
of designing a memory controller are different inside a CPU vs. a
chipset, just that the testing required is much more extensive.

An Opteron running at 2.6 Ghz would probably require a different clock
divider than an Opteron running at 1.8 Ghz. If AMD was smart, it
probably made the divider dynamic and semi-intelligent inside the
Opteron, so that it wouldn't need to keep redesigning (or even simply
lasering) the Opteron everytime there was a different clock increment.
Plus there is no guarantee about what speed grade of RAM is going to be
used with an Opteron (eg. PC1600 to PC3200, or even higher), so each
memory controller would need to be able to compensate even further
depending on what type of memory people actually decide to stick onto
their own Opterons.

> 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.

I think that was an IBM design. Anyways, whoever made it, back in those
days CPU speed increments were also rare. The 486DX started at 25Mhz,
33Mhz, and then there was the DX2 versions at 50Mhz and 66Mhz; basically
two speed grades for that entire generation (not counting AMD versions).
I think the 486SL were even more fixed somewhere around 25Mhz and no
other choices.

>>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.
>
>
> 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.

The only thing I see is you twisting yourself in a knot trying to argue
against a point which any sane man would know is true: life inside a CPU
is much faster and more dynamic, than life inside a chipset. No chipset
approaches the speeds of CPUs, nor do they approach the speed
variations; therefore, slightly different measures have to be taken to
work with it. Are the overall principles different whether it's inside a
CPU or a chipset? No. But their implementation details are different
enough that you need to do a lot more initial testing for it. After
this, AMD will have all kinds of experience making memory controllers
running at multi-Ghz ranges, so it'll have an easier time next time.
It's not like as if AMD has no experience making memory controllers
itself, afterall it also does its own chipsets. Intel will now have to
walk the same path that AMD has already walked when it's time for it to
integrate its own memory controller, it's own chipset-based memory
controller experience will only help it slightly.

> 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.

Thank you for agreeing with me.

>>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.
>
>
> 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.

Again, I fail to see what relevence which manufacturing process they
used had? So Intel used an older manufacturing node for its chipsets --
great, good for it, it got to keep using its investment in older
manufacturing technology, but so what?

But as far as I can remember about the Intel i820 Pentium 3 RDRAM
chipset MCH fiasco, the RDRAM to SDRAM translator hub was not built into
the i820 northbridge, but it was a separate chip hanging off of the
northbridge. "Data integrity" issues, with SDRAM but not with RDRAM.
(However, there were separate "performance" issues with that chipset, as
the Pentium 3 could not in anyway take advantage of RDRAM to save its life.)

> 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.

No, I was arguing about the performance quality of the RAM modules
themselves, not their signal quality. However, signal quality would
obviously affect performance quality to some degree.

Yousuf Khan

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Yousuf Khan <bbbl67@ezrs.com> wrote:
> David Wang wrote:
> > 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.

> What relevance does manufacturing generation technology have to do with
> it? It's not at issue, Intel could use any process generation they want.
> The issue is about how to build a memory controller into a piece of
> silicon that keeps changing its frequency within a generation. Chipsets
> are stable in their frequency, CPUs are not.

Which is still not relevent.

You can easily have programmable clock dividers. How do you think that
the FSB stays at a "stable frequency" while the processor frequency
ramps? You can keep part of the CPU at a relatively constant frequency
while running the rest at a much higher frequency. You just have to
design the correct PLL and the (clock multiplied) interface logic.

> > 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.

> It's not as simple as you seem to make it sound either.

It is as "simple" as I make it sound. Though I don't think I made
it sound "simple".

Here's a breakdown of "memory latency" in an AMD Opteron.

Notice the part that says "clock domain crossing"? It's there for
a reason.

http://mywebpages.comcast.net/dave [...] c/K8-1.gif

> What you
> describe is fine in a chipset context, which has a fixed main frequency;
> a chipset will run at 66Mhz, or 133Mhz, or 200Mhz or whatever for its
> entire production lifetime/generation. A CPU, within a generation might
> have several speed grades, each of which would require different clock
> dividers and waitstates.

..... And all of the dividers and waitstates are programmable.

You can and should design the flexibility into the system controller
whether that system controller sits on the CPU or on a separate die.

> And if somebody were to try to overclock the
> processor, the memory controller would have to be able to compensate
> dynamically.

This is completely and utterly irrelevent.

As a processor design engineer, I would specify "bounds of operations"
and guarentee that the processor would operate correctly within those
bounds. If someone wants to "overclock", "overvoltage", "undervoltage"
or whatever they wish to do with the processor that are outside of the
operational boundaries that I have specified, then it is not my
responsibility to "compensate dynamically" for whatever utter
foolishness the end user wants to do with the processor once it
gets in his/her hands. I have no obligation to compensate for anything
that is outside of the bounds of specification of the processor.


> There is bound to be more variables to look at when testing
> any component inside a CPU context. I'm not saying that the principles
> of designing a memory controller are different inside a CPU vs. a
> chipset, just that the testing required is much more extensive.

And the "more extensive testing" is going to be a show stopper of
what sort?

> An Opteron running at 2.6 Ghz would probably require a different clock
> divider than an Opteron running at 1.8 Ghz. If AMD was smart, it
> probably made the divider dynamic and semi-intelligent inside the
> Opteron, so that it wouldn't need to keep redesigning (or even simply
> lasering) the Opteron everytime there was a different clock increment.

Amazing what programmability can do for you.

> Plus there is no guarantee about what speed grade of RAM is going to be
> used with an Opteron (eg. PC1600 to PC3200, or even higher), so each
> memory controller would need to be able to compensate even further
> depending on what type of memory people actually decide to stick onto
> their own Opterons.

You do realize that you can specify that you will only support a
limited subset of all available DRAM technologies right? It's not
a sin not to support all DRAM technologies under the sun.

> > 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.

> The only thing I see is you twisting yourself in a knot trying to argue
> against a point which any sane man would know is true: life inside a CPU
> is much faster and more dynamic, than life inside a chipset. No chipset
> approaches the speeds of CPUs, nor do they approach the speed
> variations; therefore, slightly different measures have to be taken to
> work with it. Are the overall principles different whether it's inside a
> CPU or a chipset? No. But their implementation details are different
> enough that you need to do a lot more initial testing for it. After
> this, AMD will have all kinds of experience making memory controllers
> running at multi-Ghz ranges, so it'll have an easier time next time.

No memory controller runs at multi-GHz ranges, regardless of whether
it's a separate piece of silicon or on the same piece of silicon as the
CPU. Even after integration, the DRAM controller will sit in a
different clock domain than the CPU processor clock domain. There
will be different clock distribution nets... Just as there are now...

> It's not like as if AMD has no experience making memory controllers
> itself, afterall it also does its own chipsets. Intel will now have to
> walk the same path that AMD has already walked when it's time for it to
> integrate its own memory controller, it's own chipset-based memory
> controller experience will only help it slightly.

Sigh. Intel has already integrated memory controllers into its
products. It has done so in the past (486Sl, Timna), is currently
doing so (XScale), and will likely do so in the future.

> > 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.

> Thank you for agreeing with me.

How have I agreed with you?

The problem is with the DRAM interaction and that the complexity of
the DRAM controller will have to grow. This is a given regardless of
whether the DRAM controller stays off die or moves on die.

> > 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.

> Again, I fail to see what relevence which manufacturing process they
> used had? So Intel used an older manufacturing node for its chipsets --
> great, good for it, it got to keep using its investment in older
> manufacturing technology, but so what?

So putting it on the same generation die is easier to do (faster),
not harder.

> > 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.

> No, I was arguing about the performance quality of the RAM modules
> themselves, not their signal quality. However, signal quality would
> obviously affect performance quality to some degree.

"performance quality of the RAM modules themselves" and

"not their signal quality". and

"signal quality would obviously affect performance quality to some degree."

So a contradiction followed by a limited qualification.

What exactly do you mean then?

What impacts the performance quality of RAM modules themselves, but
specifically excluding the signal quality aspect?

Who builds a memory module with good signal quality, but would have
difficulty interfacing with memory controllers? I'd surely like to
know what you are talking about here.







--
davewang202(at)yahoo(dot)com

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sat, 04 Dec 2004 17:34:15 -0500, George Macdonald wrote:

> On Fri, 3 Dec 2004 15:29:38 -0500, Keith R. Williams <krw@att.bizzzz>
> wrote:
>
>>In article <bd84ed0c.0412030925.4fabb96e@posting.google.com>,
>>yjkhan@gmail.com says...
>>> keith <krw@att.bizzzz> wrote in message news:<pan.2004.12.03.03.40.14.833710@att.bizzzz>...
>>> > > 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).
>>> >
>>> > 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.
>>>
>>> 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.
>>
>>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...
>
> Does anyone know for sure where Opteron does the frequency "division"? Why
> not keep the memory controller in the same clock domain as the rest of the
> chip and "wait" for a memory bus clock edge?

No. ...because that is a bad plan. When one widget needs service, simply
tell the other when it's needed then wait for the completion. It's far
easier to have each work in its own clock domain than forcing the issue on
another. Think of it this way, the logic in the slower clock domain
doesn' thave to be tweaked as much, or can have more levels of logic
between latches. Why complicate things with clocks that are faster than
need be?

> It would make sense for the
> rest of the "north bridge" logic on-board, i.e. memory address arbitration
> and routing, to be at the high clock rate, so as not to have dead cycles on
> the accesses destined for the 800/1000MHz HT. The folklore on some Web
> sites I've read has it that this is how it's done but... not err,
> convincingly.

Seems obvious to me. The stuff that has to be clocked fast is, that not,
not. Certaiunly the request/arbitration has to be done at the processor
speed, at least somewhere along the line. There is no reason to push that
constraint further down the pipe.

--
Keith

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sat, 04 Dec 2004 11:48:33 -0500, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:

>On Fri, 03 Dec 2004 15:13:15 -0500, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>>On 2 Dec 2004 15:54:29 -0800, yjkhan@gmail.com (ykhan) wrote:
>>
>>>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?
>>
>>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
>
><ding ding> I believe you've just given the winning answer to all of
>this George! That would indeed make sense, integrate the memory
>controller on both the Itanium and Xeon line and then just have some
>sort of HT-like connection to the outside work that could quite easily
>be common between the two.

Don't tell me - it'll be called err, 4GIO.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??