backtop


Print 42 comment(s) - last by boogle.. on Jun 21 at 8:01 AM


  (Source: HEXUS)
AMD has a new chip in the works to tackle the MID/netbook market

Intel and AMD have been fierce rivals for many years. Intel almost always had the upper hand over AMD until the launch of AMD's K8 architecture which saw the Sunnyvale, California-based company basking in the spotlight (and in enthusiast praise). Intel shoved AMD into the backseat with the launch of its Core architecture and AMD has been pretty much stuck in that position ever since.

While AMD may be having problems tackling Intel in the high-end desktop and notebook markets, the company is looking to go toe-to-toe with Intel in the emerging Mobile Internet Device (MID) and netbooks/nettop market. Intel is currently having a lot of success with its Atom processor which will be in short supply until the end of Q3 2008.

AMD is countering with a low-power AMD64-based CPU design of its own according to leaked slides obtained by Eee PC News. The unnamed processor features an integrated memory controller, 16-lane 800MHz HyperTransport link, 256KB of L2 cache, and a 1GHz core clock.

Considering that this new chip is to be used in low-power applications, power consumption is a critical talking point. Intel's Atom N270 -- the most popular Atom variant for netbooks -- features a 2.5W TDP at 1.6GHz. However, we can't forget the i945GSE Northbridge which adds another 4W -- more than the Atom processor itself.

AMD’s new processor, however, has an 8W TDP for the processor with its integrated Northbridge/memory controller at 1.0GHz. Although performance figures obviously aren't available at this time, it would be interesting to see how AMD's 1.0GHz processor would do against Intel's in-order 1.6GHz Atom N270.

Intel and AMD have both been in the news in recent weeks -- mostly for squabbles between the two companies. Intel recently got slapped with a $25M fine for anticompetitive practices in South Korea. Shortly after, the Federal Trade Commission opened up a formal investigation into allegations of anticompetitive behavior in the U.S. market.

Finally, AMD and NVIDIA have taken Intel to task over its refusal to release specifications on its open host controller for USB 3.0. Intel countered that it would provide the details once the spec is finished and that the company had invested “gazillions of dollars and bazillions of engineering man hours” in developing the open host controller.



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: I think we can see where this is going.
By System48 on 6/17/2008 1:41:04 PM , Rating: 3
The problem is with the way AMD has been performing lately. By the time they get this out the door they'll be competing against the next generation Atom, Lincroft, which will have an IMC and IGP.


RE: I think we can see where this is going.
By weskurtz0081 on 6/17/2008 1:43:51 PM , Rating: 2
This is yet to be seen. Since it seems like all they are doing is stripping K8, it might not take them too long. I guess we shall see.


RE: I think we can see where this is going.
By freaqie on 6/17/2008 2:15:53 PM , Rating: 2
amd already had the geode processors.
these were very energy efficient
and pretty fast ( basicly as fast as a 2100+ using ony a few watts) this is proably a relaunch with some added features


By Brandon Hill (blog) on 6/17/2008 2:34:26 PM , Rating: 3
IIRC, the Geode is derived from the original K7 architecture -- this appears to be K8-based.


By Regs on 6/17/2008 3:29:23 PM , Rating: 4
This is what I don't like. How AMD can develop something new, bring it to market, and some how before the product reaches the shelves it's branded a stripped down K8.

AMD comes out strong before a product launches, however when it launches or right before it launches, it's like the whole marketing team decides to take a vacation.

AMD has to sell these things like they have a actual purpose. Like true quad core and HT. What are their purpose? They sound sweet, but you forgot to sell me or show me the benifits. I can show people innovation all day long, like being able to brush me teeth with only one index finger, however I forgot to mention to them the purpose or even practicle sense of it.


RE: I think we can see where this is going.
By stryfe on 6/17/2008 4:46:47 PM , Rating: 1
The K8 is pretty much an optimized K7 plus IMC anyway.


RE: I think we can see where this is going.
By zpdixon on 6/18/2008 12:57:01 AM , Rating: 3
Are you kidding ? IMC, AMD64 (!), HyperTransport (!), SSE2, 3-way superscalar uarch, NX bit, etc. By far the biggest gap between the last 4 iterations (K6, K7, K8 and K10) is K7 -> K8.


RE: I think we can see where this is going.
By boogle on 6/18/08, Rating: 0
RE: I think we can see where this is going.
By zpdixon on 6/18/2008 7:07:03 AM , Rating: 3
Yes Intel did have problems efficiently implementing AMD64 in their CPUs. That's why the perf gap between Athlon 64/Opteron and P4/Xeon was even wider on 64-bit code than 32-bit. It took them 2 years to come up with a decent 64-bit microarch (Core).

HT is not "just a new transport protocol". HT + IMC forced AMD to add a XBAR, new cache coherency protocols, NUMA architecture, etc. Look at how many times Quickpath has been delayed. Even the mighty, big, rich Intel doesn't think it's easy to do.

SSE2: getting the specs is the easy part. Implementing the instructions efficiently is the hard part.

Nobody denies my basic point that K7-to-K8 was by far the biggest step in AMD's last 4 microarchs.


RE: I think we can see where this is going.
By boogle on 6/18/2008 8:10:55 AM , Rating: 2
No, the perf gap wasn't slightly wider because they had 'trouble', its because the arch was originally designed for 32bit. To put it in perspective AMD took years and years to make A64, Intel implemented EM64T in a matter of months. So the paths throughout the processor were all 32bit instead of 64bit (even now Phenom / Core 2 is still 32bit in places afaik). Even so the performance difference was relatively tiny, the bigger problem was P4 was just plain slower than A64.

Cache protocols have little to do with HT, and a LOT to do with multiple CPUs + cores. The Crossbar (XBAR) doesn't require HT either, that's another dualcore thing. NUMA *AGAIN* isn't to do with HT, its a multiple processor thing that happens to use HT because its the only communication method. HT is basically a link between the CPU and other CPUs, sound a bit like FSB?. The Crossbar means HT can be skipped entirely so direct core-core communication is possible. Incidentally NUMA is slower in desktop applications that not using NUMA at all, it benefits server apps almost exclusively.

Intel didn't need to worry about HT/QuickPath being out ASAP. Why? Because HT v1 is actually too slow on a multi-processor system using DDR2 memory, Intel's quad-FSB is actually faster. HT works at about 4GB/sec, DDR2 peaks at 10.6GB/sec (5.4GB practical): http://it.anandtech.com/IT/showdoc.aspx?i=3335&p=3

Implementing a more or less required feature (SSE2) from a 3rd party CPU shouldn't be considered a 'massive step', it should be called 'matching the competitor'.

quote:
Nobody denies my basic point that K7-to-K8 was by far the biggest step in AMD's last 4 microarchs.


Well, based on your lack of knowledge of AMD's actual internal architecture I would say you stumbled upon that 'fact' and luckily it pans out. But I would argue the first Athlon was the biggest jump AMD ever made. They went from making Intel clones / low performance CPUs to making their own CPUs that were faster & often cheaper than Intel's.


RE: I think we can see where this is going.
By zpdixon on 6/18/2008 3:56:58 PM , Rating: 2
"Intel implemented EM64T in a matter of months." Nope. June 2004: first x86-64 Intel CPUs. June 2006: first decent x86-64 implementation. As I said it took them 2 years to get it done correctly.

"The Crossbar (XBAR) doesn't require HT either, that's another dualcore thing.". Wrong. The XBAR was present even in single-core CPUs, like the first Opterons back in April 2003. The purpose of the XBAR is to link the core(s) to the IMC and HT links.

"Cache protocols have little to do with HT". Wrong. That's why there are 2 types of HT links: plain HT and HTcc specifically designed to run cache coherency protocols.

"Intel didn't need to worry about HT/QuickPath being out ASAP. Why? Because HT v1 is actually too slow on a multi-processor system using DDR2 memory". Wrong. It is common knowledge that FSB designs offer less combined bandwidth than socket-to-socket links. Even Intel implicitely admits it by the fact they have been forced to implement 4 independent FSBs on chipsets targetting the 4-socket market. Also FYI HT has long passed the 4 GB/s limit. CPUs have been shipping with HT links capable of 4.0 GT/s * 16 bits = 8 GB/s in both directions for at least 1.5+ years.

"Implementing a more or less required feature (SSE2) from a 3rd party CPU shouldn't be considered a 'massive step'". Yes it is ! No matter who invented SSE2, it was a massive step to implement it, both for Intel and AMD.

"Well, based on your lack of knowledge of AMD's actual internal architecture [...]". Based on the above factual errors, it sounds like you only have a vague understanding of K8...


By boogle on 6/21/2008 8:01:45 AM , Rating: 1
quote:
Nope. June 2004: first x86-64 Intel CPUs. June 2006: first decent x86-64 implementation. As I said it took them 2 years to get it done correctly.


All in your opinion. I can see no evidence that the implementation is different between P4 and Core2. Core2 is a lot faster sure, but the CPU itself is a lot faster. By your logic, because Core 2 is way faster than Phenom in 64bit apps, I could say the Phenom has a poor 64bit implementation.

quote:
"The Crossbar (XBAR) doesn't require HT either, that's another dualcore thing.". Wrong. The XBAR was present even in single-core CPUs, like the first Opterons back in April 2003. The purpose of the XBAR is to link the core(s) to the IMC and HT links.


So, still nothing to do with HT then, even in your own words. It avoids the HT link at all costs still, cores talk to each other, and the IMC needs a way of communicating with the CPU. Looks like a technical inevitability rather than a super-duper-amazing feature. I hook myself up to my keyboard, should I be considered an integral feature of computer design? Or is the keyboard just an interface?

quote:
"Cache protocols have little to do with HT". Wrong. That's why there are 2 types of HT links: plain HT and HTcc specifically designed to run cache coherency protocols.


I can't find a single reference to HTcc outside of this very post of yours. I would imagine AMD would have a strategy for managing cache coherency with multiple CPUs/cores, but that still doesn't require, or even need HTT. Intel would be stupid not to have their own strategy - and they're using FSB.

quote:
Yes it is ! No matter who invented SSE2, it was a massive step to implement it, both for Intel and AMD.


OK, I'll fall back to your x86-64 argument. Since Athlon64 didn't have 128bit FPUs, and took many more cycles to perform SSE2 instructions, A64's SSE2 implementation was so poor that they might as well have not bothered since standard 32bit instructions were barely any slower than grouping them up into 1 128bit vector.

I stand by my statement that HyperTransport is just an evolution of FSB, a strong optimisation of a bus that is required by any computer system in one shape or form. It's almost independent of the CPU and should be considered an advancement in platform design.


By stryfe on 6/18/2008 3:11:36 PM , Rating: 2
quote:
Nobody denies my basic point that K7-to-K8 was by far the biggest step in AMD's last 4 microarchs.
I would disagree. K6 -> K7 was the biggest jump. K7 was a brand new architecture from the ground up. As I said before K8 is an evolution of K7. Sure it has a bunch of new features but it's by no means a fresh architecture the way K7 was.


“Then they pop up and say ‘Hello, surprise! Give us your money or we will shut you down!' Screw them. Seriously, screw them. You can quote me on that.” -- Newegg Chief Legal Officer Lee Cheng referencing patent trolls














botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki