Talk:Xenon (processor)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Video games (Rated Stub-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Video games, a collaborative effort to improve the coverage of video games on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Stub-Class article Stub  This article has been rated as Stub-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by the Xbox task force.
 

Laughable poor article[edit]

+stub, look at Cell (microprocessor) for comparison - laughable how poor this article is. --Col. Hauler 19:14, 5 May 2006 (UTC)

That's to be expected since Cell is a design which will be (or is already) avaliable for whomever want's to buy it, whereas Xenon is a custom built CPU specifically for Microsoft. There's really NO documation available if you're not under NDAs. -- Henriok 22:15, 22 June 2006 (UTC)
Also the Cell has a lot of industry hype behind it while the Xenon is just a gimped PPC chip. PPC isn't as "interesting" since it's a commodity chipset. It's even less interesting since the Xenons are missing a large portion of what other PPC chips have while the Cell is a whole new architecture. No slagging the Xenon as I'm sure people would rather program with a tri-core symmetric PPC rather then a asymmetric 1 PPC + 6 SPU vector engine. It's easier if not more powerful. —Preceding unsigned comment added by 206.75.33.118 (talk) 03:14, 9 October 2007 (UTC)

Mips Numbers?[edit]

Are there any mips numbers for this CPU yet? If there are they should be included. If Microsoft isn't releasing them, I suppose we'd have to take bogomips numbers from a linux distro running on it.

It'll be a while until anyone gets Linux running on an Xbox 360 (if ever), but we might extrapolate performace from published numbers of the PPE in Cell (Xenon is practically a tri-core PPE), or marketing babble of the expected performace of Xbox 360. Regarding "MIPS", we probably will have to do with "FLOPS" -- Henriok 00:52, 14 November 2006 (UTC)

VMX128 register file[edit]

The meaning of the sentence "2× (128×128 bit) register file for each VMX128 unit, 6 in total." is not clear, because it is not clear from the article context what a VMX128 unit is. I think that it's better to talk about the implemented register file in the context of "core" or "microarchitecture". -- 217.224.70.87 19:20, 11 August 2007 (UTC)

Better this way? -- Henriok 20:56, 11 August 2007 (UTC)
Why not "SIMD: VMX128 with 2× (128×128 bit) register files for each core." ? -- 217.224.103.3 12:36, 12 August 2007 (UTC)
Taken -- Henriok

Xenon and Xbox 360[edit]

May someone find relevant references about this issue? There are just two contradict claims. --millosh (talk (meta:)) 18:06, 8 September 2007 (UTC)

Err, umm, to which issue are you referring? The claim that Xenon "is using cores similar to the Power Processing Element (PPE) in the Cell microprocessor."? Guy Harris 18:51, 8 September 2007 (UTC)
Their both using PPC derived designs. Xenon is a tri-core semetric striped down PPC while the Cell is a 1 stripped down PPC + 7 specialty helper SPU's. 206.75.33.118 03:16, 9 October 2007 (UTC)
Also, the Xenon could not perform at 116 GFLOPS and although I understand that its theoretical, its not an accurate measure of it's performance. ~~ —Preceding unsigned comment added by Werner ghost (talkcontribs) 04:49, 7 October 2007 (UTC)

Xenon can't perform 116GFLOPS.Its a lie.Its peak peroformance is 76.8GF.Chaos Stein (talk) —Preceding comment was added at 13:36, 21 February 2008 (UTC)

Care to include any sources? 76.8 Gflops is the theoreticsl performance while only using the VMX units. Xenon can however theoretically use its FPUs in parallel, adding 38.4 Gflops, thus theoretically peaking at 115.2 Gflops. This is single precision floating point operations, but they are correct none the less. The 116 figure is probaly a miss spelling though. -- Henriok (talk) 14:40, 21 February 2008 (UTC)
Actually, 115.2 GFLOPS is inaccurate, and so is 76.8. The Xenon's PPE cores, while DERIVED from the POWER5/PPC 970, are not the same; as is covered in the the semi-official IBM paper linked in the article, each PPE has only 1 FPU, not 2. Hence, they only add a total of 19.2 GFLOPs to the total. Combined with the 76.8 GFLOPS from the VMX for single-precision math, that makes the total of a flat 96 GFLOPS. (57.6 GFLOPS for 64-bit double-precision) I am editing the article to reflect this. Nottheking (talk) 15:29, 17 April 2010 (UTC)

ROM[edit]

Is it really possible to have a processor with ROM? The ROM is probably just near the processor. Helpsloose 08:43, 1 December 2007 (UTC)

Of cource it's possible. "Read only memory". They have grafted some hard coded instructions regarding sequrity and DRM directly on the processor, making the console hard to hack. -- Henriok 10:01, 1 December 2007 (UTC)
Are you sure it is not jut in the same package/carrier or something? Helpsloose 15:15, 1 December 2007 (UTC)
Yes. Designing a ROM from a logic technology is quite straightforward. As it is a small portion of the overall chip size, density is not of supreme importance, so a DRC-correct implementation would be preferred. On-chip ROMs are often used to hold microcode routines, look-up tables, etc. So, use of a ROM to hold a small boot routine is not too surprising.Philhower (talk) 17:27, 2 July 2008 (UTC)


in the old days everything ran on roms, it's an easy way to secure an OS or toolkit as was the case with old-world Mac's. Markthemac (talk) 02:15, 24 May 2009 (UTC)

Fair use rationale for Image:IBMxenon.jpg[edit]

Nuvola apps important.svg

Image:IBMxenon.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 18:48, 2 January 2008 (UTC)

Xenon GFLOPS/operations-per-clock numbers[edit]

I just fixed the following inaccurate lines:

There were many things quite wrong in understanding of the above. Since there seems to be a lot of confusion, misunderstanding, and heated opinions over the subject, let me clear them up. The main source for specification information in the article comes right from IBM themselves; they were kind enough to publish a paper on the CPU's architecture. Reading through it, it tells us the following:

  • The Xenon has 3 CPU cores.
  • Each core has a single VMX128 unit, capable of acting as (among other things) a 4x32-bit or 2x64-bit floating-point array.
  • Each core has a single FPU unit, capable of handling operations up to 64 bits in size.
  • The cores run at 3.2 GHz.

Now, here's where the IP editor who inserted the above figures went wrong:

  • FPU units can't be arbitrarily cut apart to handle multiple parallel operations: that's what SIMD units like the VMX128 are for; it's the whole point of them existing. Hence, the FPU can handle a maximum of ONE operation set per clock cycle, regardless of the precision level; 32-bit operations won't be any faster in it than 64-bit ones.
  • All floating-point units, be they FPUs, SIMD, etc. are all capable of handling the multiply-accumulate instruction in a single clock cycle, which counts as TWO floating-point operations. Thus, you double all figures.

Taking all of the above into account, the math we have is the following:

  • 32-bit single-precision: ((4x SIMD + 1 FPU) * 3 cores * 2 ops-per-MAC) = 30 ops per clock cycle * 3.2 GHz = 96.0 GFLOPS
  • 64-bit double-precision: ((2x SIMD + 1 FPU) * 3 cores * 2 ops-per-MAC) = 18 ops per clock cycle * 3.2 GHz = 57.6 GFLOPS

Hopefully this clears up the confusion over this. It'd have been more helpful if IBM had directly provided the number in their article, but instead they merely provide all the elements needed to do the math to get it. The problem is that leaves too much room for people (and editors) to make honest mistakes with the math. Nottheking (talk) 08:32, 29 August 2010 (UTC)

Excellent! -- Henriok (talk)

XCGPU = SoC?[edit]

Is the new XCGPU considered a System-on-a-Chip? It sounds like everything is integreated onto the same chip. 98.114.237.231 (talk) 06:18, 13 October 2011 (UTC)

The XCGPU does not integrate the southbridge so most IO is handled by a separate chip outside the XCGPU. So No, it's not a SoC. -- Henriok (talk) 22:28, 13 October 2011 (UTC)

Name?[edit]

While doing research about this processor, I've come to the conclusion that we should rename the article "XCPU". "Xenon" seems to be the code name for the 90 nm version of it "Zephyr" another 90 nm version, "Falcon" being the name of the 65 nm version and "Vejle " for the 45 nm, combined version of the GPU and XCPU, named XCGPU on the devices. Looking at many pictures of XCPUs and the lettering on them, it might be that Xenon = XCPU-ES, Zephyr = XCPU, Falcon = XCPU (but more rectangular). And XCGPU is very distinct in its ow right. Waternoose is IBM's project name for the original processor, ie. Xenon and XCPU-ES. -- Henriok (talk) 11:33, 20 December 2012 (UTC)