Intel makes test chip based on 65nm process

bbot said:
They believe they will be the first to produce chip based on 65nm process. You heard that, Vince? Intel, NOT Sony/Toshiba.

Ok 'bbot', I heard that. I didn't realize that we're going to play this futile PR game akin to the nVidia/ATI paper launch game.

Sony and Toshiba 6 months ago announced that, has Intel's process surpassed it? I don't think so.

I say we dismiss this rhetoric and lets just compare the Sony/Toshiba (OTSS) product offering to Intel's in 2005/2006 and we'll see what's up. hah.
 
...

has Intel's process surpassed it? I don't think so.

Sony PSX2OAC@90nm

55 million transistors @ 300 Mhz @ 86 mm2

Intel Dothan@90 nm

170 million transistors @ 1.8 Ghz @ 88 mm2

Looks like Intel's fab capability is indeed far far superior to what SCEI and Toshiba can come up with.
 
Intel are moving to 90nm pretty aggresively from what I heard. AMD are having a good time with the process too (the recent delays were debunked).

And so what if Intel is first with 65nm? It wont affect Sony/Toshiba/IBM unless they experience delays in their own schedule.
 
Re: ...

DeadmeatGA said:
Sony PSX2OAC@90nm

55 million transistors @ 300 Mhz @ 86 mm2

Intel Dothan@90 nm

170 million transistors @ 1.8 Ghz @ 88 mm2

Looks like Intel's fab capability is indeed far far superior to what SCEI and Toshiba can come up with.


Dude, you're a joke. What you're doing is analogous to nVidia producing a TNT2 (from ~1999) at 90nm and clocking it at the same speeds for backwards compatability reasons and then wondering why it's not clocking as high or as complex in gates as a set-piece, new IC for that process stepping. And how many of those tranistsors are for Cache and not logic? :rolleyes: ^2


Lets try and use those neural pathways next time. Ohh, and AFAIK, Intel's eD/SRAM & Logic cell sizes are inferior to Sony/Toshiba's. Especially at 45nm, as Intel just can't compete with the PD-SOI eDRAM cell sans capacitor at this point.
 
There is absolutely no reason whatsoever for Sony to clock the PS2 SoC or whatever it is called beyond 300MHz. In fact clocking it higher would probably cause problems for games and the extra clockspeed will be for nothing.
 
Tahir said:
There is absolutely no reason whatsoever for Sony to clock the PS2 SoC or whatever it is called beyond 300MHz. In fact clocking it higher would probably cause problems for games and the extra clockspeed will be for nothing.
can you explain this a bit more. I dont really get it. Much appreciated.

later,
epic
 
epicstruggle said:
can you explain this a bit more. I dont really get it. Much appreciated.

Games for the chip are specifically programmed for certain timings, since the console realm doesn't yet need to bother with constant upgrades and differing components and variable scale, so in most cases you could pump the crap out of a chip and it still wouldn't do any good, because the games are not programmed to be able to take advantage of speed bumps. As I recall there's an Xbox mod out there with a "turbo" switch to access a chip twice the speed, but even it won't be able to apply to much. (Likely more than a PS bump would do, though, since there are more PC developers and similar programming in there, so certain parts might be able to use the excess speed.)

Basically, there's no real advantage in speed-bumping chips until the nature of console programming itself changes.
 
Is it me or do the slides design style remind you of how Sony makes their slides? A picture showing an areial photograph of the fab with the words "Worlds most advanced 300 mm fab" comes across as very Sony PRish. Maybe they've always done this and I've never seen the slides?

Not letting Sony get a free ride when it comes to PR claims is something Microsoft certainly needs to work at.
 
This topic is one gigantic joke.

In one corner you have bbot, which totally ignores replies targeted towards him. And has done this in posts past.

In the other corner you have Deadmeat, who is comparing two 5 year old chips (EE+GS at 90nm) transistor count to that of a new Intel 90nm CPU which was built for the specific process.

Pretty sad.
 
...

In the other corner you have Deadmeat, who is comparing two 5 year old chips (EE+GS at 90nm) transistor count to that of a new Intel 90nm CPU which was built for the specific process.
Dothan is based on the P6 core first released in 1995. Dothan design is actually far older than PSX2.
 
cthellis42 said:
Games for the chip are specifically programmed for certain timings, since the console realm doesn't yet need to bother with constant upgrades and differing components and variable scale
The timings games rely on are linked with display refresh frequency - and as such shouldn't have anything to do with chip speed.

You couldn't get improvements over whatever frequency games are locked to, but the games with non-constant framerate would run better.
 
Deadmeat said:
Dothan is based on the P6 core first released in 1995. Dothan design is actually far older than PSX2.
EE is based on MIPS Risc architecture, the first of which was released in 1986(R2000).
PS2 design is far older then Dothan.

:p
 
parodoxically

There are certain cases where speeding things up can slow games down....

If you have a looping physics solver that is terminated based on the frame rate then increasing the cpu clock speed could cause your solver to run an extra iteration, and slow the game loop down ( Something that you would avoid by decoupling the game engine and graphics on a PC, but may not bother with on a fixed spec console )
Also - certain classes of bugs related to cache can be exposed via a faster clock.. ( ever have those bugs that would only go away when you put in a printf or compiled with G0 Faf? )
 
Oh by all means, I wasn't trying to say bumping the speed would mean 100% compatibility with every game - just that it would have an effect.

If you have a looping physics solver that is terminated based on the frame rate then increasing the cpu clock speed could cause your solver to run an extra iteration, and slow the game loop down ( Something that you would avoid by decoupling the game engine and graphics on a PC, but may not bother with on a fixed spec console )
I would imagine these kind of practices are nearly obsolete nowadays though - or maybe I am just fooling myself?

Also - certain classes of bugs related to cache can be exposed via a faster clock.. ( ever have those bugs that would only go away when you put in a printf or compiled with G0 Faf? )
Yeah I've seen them, worst part is there are multiple reasons that exhibit this kind of behaviour so it's not always easy to trace.
Of course that kind of situation implies an app that had a bug to begin with :p
 
Fafalada said:
Also - certain classes of bugs related to cache can be exposed via a faster clock.. ( ever have those bugs that would only go away when you put in a printf or compiled with G0 Faf? )
Yeah I've seen them, worst part is there are multiple reasons that exhibit this kind of behaviour so it's not always easy to trace.
Of course that kind of situation implies an app that had a bug to begin with :p

that could be the cc just as well.
 
Quaz51 said:
Vince said:
Sony and Toshiba 6 months ago announced that, has Intel's process surpassed it? I don't think so.

1 years ago not 6 months

Intel now claims a SRAM cell-size of 0.57 um^2 for their 65 nm node, but no specifications were given beyond that.

The work I am most interested in is e-DRAM nowadays and Sony's and Toshiba's 0.11 um^2 cell size for the 65 nm node ( e-DRAM still uses bulk-CMOS, logic should use SOI CMOS: yes Toshiba has already talked quite a bit of the fact they can mix the two on a chip ) and capacitor-less e-DRAM cells ( they are implemented using a fully SOI based CMOS manufacturing process ).
 
Back
Top