I'm afraid I don't follow. My thinking is that it isn't assymetric at all in terms of performance. It is in terms of logic, because all the 'intelligence' is at the issue side.
What's puzzling me is the data routing.
Write data, from a ROP, goes via the central MC (or at least a central crossbar) to the requisite ring stop. This data doesn't travel around the ring. Now, that might be because the ring is busy enough with read data, or that to make the ring big enough would be detrimental, overall. But it just seems puzzling.
It means that each pixel shader (12xALU + 4xTMU + 4xROP in R580) has one data bus that connects it to the ring stop and one data bus that connects it to the MC. Instead of a "double-wide" bus that connects it to the ring stop, and a command bus (tiny) that connects it to the MC. Then you have the write data from MC to ring-stop, the implication being that each ring-stop has a full speed dedicated data connection to the MC.
Cell's EIB isn't asymmetric in this sense - the ring does all data transport. The big difference with EIB is that it's not solely for client<->memory data, but also for client<->client data (hence your point about the intelligence all being on the issue side, which is the MC). It may be that EIB, being 2 pairs of rings (i.e. 4 in total, 2 contra-rotating) just has the brute capacity whereas R5xx's ring bus doesn't. Or, it may be that EIB has to cater for more clients, so symmetry is a simpler solution.
I think EIB's meant to easily sustain 200GB/s, whereas I don't know what the MC+ring bus is targetted at - but in R5xx it would appear to be in the range of 60-100GB/s. So perhaps double that for R600
So, this puts my focus back on the large die area of the MC, what's it all doing? If the MC is as big as R520's ALUs+register file, and R520's register file is in the region of 400KB (split four ways, say 100KB per pixel shader unit), does that imply about 0.5MB of memory in the MC? 1MB?
Jawed
