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/davewang202/misc/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