PS3 and Toshiba's Super Companion Chip..

T

Titanio

Legend
IIRC, this was still an open mystery, but this dropped in my lap which might shed some new light on the situation.

Code: 
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 6c108fc..8ef3516 100644 (file)
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -21,10 +21,6 @@
 
 /*-------------------------------------------------------------------------*/
 
-#ifdef CONFIG_PPC_PS3
-#include <asm/firmware.h>
-#endif
-
 /*
  * EHCI scheduled transaction support:  interrupt, iso, split iso
  * These are called "periodic" transactions in the EHCI spec.
@@ -1073,6 +1069,32 @@ iso_stream_find (struct ehci_hcd *ehci, struct urb *urb)
        return stream;
 }
 
+/**
+ * itd_in_use -  Fix for Cell Super Companion Chip ISO transfers
+ *
+ * The EHCI host controller in the Cell Processor's Super Companion
+ * Chip has a hardware errata in its handling of ISO TDs.  The
+ * controller will continue to access the iTD after the transaction
+ * active bit has been cleared.  The condition can be avoided by
+ * delaying the reuse of the iTD until the frame number changes.
+ */
+
+#if defined(CONFIG_PPC_PS3)
+#include <asm/firmware.h>
+
+static int itd_in_use(struct ehci_hcd *ehci, unsigned int itd_frame)
+{
+       return (firmware_has_feature(FW_FEATURE_PS3_LV1)
+               && (itd_frame == (ehci_readl(ehci,
+               &ehci->regs->frame_index) >> 3) % ehci->periodic_size));
+}
+#else
+static int itd_in_use(struct ehci_hcd *ehci, unsigned int itd_frame)
+{
+       return 0;
+}
+#endif /* defined(CONFIG_PPC_PS3) */
+
 /*-------------------------------------------------------------------------*/
 
 /* ehci_iso_sched ops can be ITD-only or SITD-only */
@@ -1184,21 +1206,12 @@ itd_urb_transaction (
                if (likely (!list_empty(&stream->free_list))) {
                        itd = list_entry (stream->free_list.prev,
                                        struct ehci_itd, itd_list);
-#ifdef CONFIG_PPC_PS3
-                       /* Fix for Cell SCC ISO transfer (PS3 Bluetooth). */
-                       if (firmware_has_feature(FW_FEATURE_PS3_LV1)
-                               && itd->frame == ((ehci_readl(ehci,
-                               &ehci->regs->frame_index) >> 3)
-                               % ehci->periodic_size))
+                       if (itd_in_use(ehci, itd->frame))
                                itd = NULL;
                        else {
                                list_del (&itd->itd_list);
                                itd_dma = itd->itd_dma;
                        }
-#else
-                       list_del (&itd->itd_list);
-                       itd_dma = itd->itd_dma;
-#endif
                } else
                        itd = NULL;
 
@@ -1824,21 +1837,12 @@ sitd_urb_transaction (
                if (!list_empty(&stream->free_list)) {
                        sitd = list_entry (stream->free_list.prev,
                                         struct ehci_sitd, sitd_list);
-#ifdef CONFIG_PPC_PS3
-                       /* Fix for Cell SCC ISO transfer (PS3 Bluetooth). */
-                       if (firmware_has_feature(FW_FEATURE_PS3_LV1)
-                               && sitd->frame == ((ehci_readl(ehci,
-                               &ehci->regs->frame_index) >> 3)
-                               % ehci->periodic_size))
+                       if (itd_in_use(ehci, sitd->frame))
                                sitd = NULL;
                        else {
                                list_del (&sitd->sitd_list);
                                sitd_dma = sitd->sitd_dma;
                        }
-#else
-                       list_del (&sitd->sitd_list);
-                       sitd_dma = sitd->sitd_dma;
-#endif
                } else
                        sitd = NULL;

I didn't find this code, it was literally just handed to me - though not by a nobody, so I trust its validity :) From the looks of it, it includes code for when "CONFIG_PPC_PS3" is defined (presumably on PS3) that interacts with a Super Companion Chip :)
 
makaveli87 said:
seems to have DDR2 ram thats connected to XDR via FlexIO, wonder how much of it there is?
Click to expand...

Non.

This was the chip that was immediatly shrunk for the PAL release. The full SCC may have been just a stop-gap solution, before a more tailored chip was put there, but you never know, the Cell equipped boards presented by Sony earlier in the fall had some DDR2 RAM IIRC.
 
Last edited by a moderator:
makaveli87 said:
seems to have DDR2 ram thats connected to XDR via FlexIO, wonder how much of it there is?
Click to expand...

Just because it can have a DDR2 memory pool attached to it does not mean that it has one ... also, I think I agree with what another poster said, that is the only version of PS3 with the full SCC was the Japanese and American launch PS3's and that even in those configurations not the whole set of SCC's capabilities was used: there is no trace of different SCC versions support in the PS3 kernel sources AFAIK.

Was the SCC only shrunk between the first PS3 model and the latter ones or were some extra and unused features cut too ?

It is reasonable to think that for launch they needed as much availability of every chip as possible and that the customization of the SCC was not ready in large enough numbers so that they decided to wait for the SCC's die shrink to re-work the internals of it (it is perhaps one of the most appropriate moments since the die shrink it is kind of a chip re-design process anyways).
 
This begs the question that I have asked before. Why, if the SCC is present, are there separate controllers for SATA, USB, .... ? Also, the SCC was also designed to perform video scaling, why is it not used either?
 
Well I think the most important question is when is Sony going to use it and for what?????
 
The most important question is if they ditched it in favour of a more customized part, and as such you can't use the SCC in the older PS3's with it.
 
I've said this in the past, but the SCC is the most ridiculously big southbridge in the history of the universe, and it's way too big even after you consider its A/V capabilities. Even the 'revised' version is way bigger than it should be. The MCPX in the original XBox is something ridiculous like 23mm² and AMD's SB600 is about 36mm² with 6xSATA, 12xUSB, and so on.

IMO, the only sane way for Sony to fix this horror quickly is to include a mini-southbridge into the 65nm RSX. I certainly expect that to happen, but we'll see this spring. Given that NVIDIA apparently doesn't have the PSP2 contract, I believe that is what the 'NRE2' at the 2006 Analyst Day was all about. If it was just 65nm, they wouldn't have refused to say what it was about.
 
Arun said:
IMO, the only sane way for Sony to fix this horror quickly is to include a mini-southbridge into the 65nm RSX. I certainly expect that to happen, but we'll see this spring. Given that NVIDIA apparently doesn't have the PSP2 contract, I believe that is what the 'NRE2' at the 2006 Analyst Day was all about. If it was just 65nm, they wouldn't have refused to say what it was about.
Click to expand...
How about integrating PS2 GS into it for a new 80GB version?
 
Arun said:
I believe that is what the 'NRE2' at the 2006 Analyst Day was all about. If it was just 65nm, they wouldn't have refused to say what it was about.
Click to expand...

To include a southbridge in the 65 nm RSX nets nVIDIA more royalties per unit than the original RSX contract brought ? That was one of the main reasons that made people think the new R&D contract was for a new chip (like PSP2 GPU or RSX2 ;)).

If nVIDIA like you say did not get PSP2's contract and given that IMHO Sony understood that it can get outside what it needs without spending a lot of money on in-house R&D... also... given that IMG Tech was rumored to be working with a big Japanese CE maker and that a PVR5-6 series GPU would fit the bill with what Sony might want PSP2's GPU to be: low power consumption, small die area, programmable Shaders enabled GPU... ;).

One can hope :).
 
Panajev2001a said:
To include a southbridge in the 65 nm RSX nets nVIDIA more royalties per unit than the original RSX contract brought ?
Click to expand...
Not necessarily unless Nvidia provides the best deal for the commodity IP-blocks for USB, SATA, .... etc.

The SCC operates on a lower frequency (333 MHz) than the RSX (500-550 MHz), that may be a reason to keep the circuitry separate from the RSX as it can be implemented on a slightly simpler process, if the size of the southbridge circuitry is reasonably large that is. I agree with previous posters that the full SCC functionality is just total overkill for the PS3. I think it´s already been replaced with a more tailored chip in the current models, unless it is just a 65 nm version of the SCC, but I have not seen such an announcement by Toshiba.

My personal bet is that Nvidia added some GS BC circuitry to the RSX 65 nm version like one suggested. It just doesn´t make any sense that Sony suddenly decides that the PS2 BC is no longer a desired function. I have a feeling that the non-BC version was not in the original plan, it´s a plan B to cut the cost faster to reach a more competetive price faster after the slow sales at launch.

After all the emphasis on PS1 BC lately such as the PSP can play all old PS1 games via remote and so on, it´s just weird that Sony cuts off the possibility to exploit the PS2 library in a similar fashion for all future PS3 models. I think proper PS2 BC (not just some limited GS BC through software emulation) will return when they can implement it really cheap, perhaps through the 65 nm RSX or maybe later?
 
Panajev2001a said:
To include a southbridge in the 65 nm RSX nets nVIDIA more royalties per unit than the original RSX contract brought ? That was one of the main reasons that made people think the new R&D contract was for a new chip (like PSP2 GPU or RSX2 ;)).
Click to expand...
It would obviously only happen if Sony was willing to increase the royalties, NVIDIA isn't the kind of company that works for free...

[...]
One can hope :).
Click to expand...
My understanding is indeed that this is the PSP2 deal, although I obviously can't be sure of that: http://www.imgtec.com/News/Release/index.asp?ID=676

The SCC operates on a lower frequency (333 MHz) than the RSX (500-550 MHz), that may be a reason to keep the circuitry separate from the RSX as it can be implemented on a slightly simpler process, if the size of the southbridge circuitry is reasonably large that is.
Click to expand...
As I said above, the 90nm SCC is ~160mm2 while a 'normal' southbridge doing the same things should be about ~25mm2... As for GS BC, don't forget it might not be a good idea to just add eDRAM to RSX because that can increase cost/wafer by ~10%.
 
Arun said:
As I said above, the 90nm SCC is ~160mm2 while a 'normal' southbridge doing the same things should be about ~25mm2...
Click to expand...
Yes, the current size is a mystery, even after the shrink.

Arun said:
As for GS BC, don't forget it might not be a good idea to just add eDRAM to RSX because that can increase cost/wafer by ~10%.
Click to expand...

I am not assuming the BC circuitry must include EDRAM, because as you say it adds substantial costs and makes future shrinks harder and more expensive than what an ordinary CMOS process offers.

IIRC the memory of the GS consists of two banks of 2 MB. Perhaps the GDDR3 memory offers enough bandwidth to replace one of those banks and the other bank can reuse some of the internal buffers of the RSX together with some added bog standard space efficient SRAM memory, that could help reduce the extra size required for the BC circuitry to make it a cost efficient solution on a 65 nm CMOS process compared to the old BC solution with the separate GS chip on a 90 nm EDRAM process. Just speculating. :D

Edit: From this picture one can deduce that 2 MB SRAM on 65 nm in the Power6 (total 341 mm2) occupies < 31 mm2 die space, keep in mind that the Power6 level2 cache memory is designed for high speed. It may be possible to make it even smaller if the performance requirements are lower, by making the memory cells simpler and slower.
 
Last edited by a moderator:
Arun said:
It would obviously only happen if Sony was willing to increase the royalties, NVIDIA isn't the kind of company that works for free...
Click to expand...

To me it did sound more like well Sony paid $X for RSX and has to pay $X+Y to have this chip... of course I maybe wanted to assume it was for a new design so that Sony would be paying $X for RSX and $X+Y for another GPU/chip.. although nVIDIA might be wanting more money to not do a simple RSX die shrink but to add more enhancements of course.

My understanding is indeed that this is the PSP2 deal, although I obviously can't be sure of that: http://www.imgtec.com/News/Release/index.asp?ID=676
Click to expand...

I would be cool beyond words IMHO: I did not like the idea of moving SCE more and more towards the fab-less design model and outsource external chips, but it does have its advantages if you play your cards right ;). For the embedded space, I really think PowerVR has a winner on its hands.
Also the current PSP's GPU while it makes good use of its e-DRAM it does not push the bandwidth and brute force fill-rate angle like SCE did with the GS so I would not think they would have major problems emulating PSP's GPU with a PowerVR based set-up.

I'd personally move all the fixed-T&L/surface engines in the GE and GU to the CPU of a PSP2 system (software emulation).

I do wonder what kind of CPU would be used in such a system... CELL lite (thus PowerPC) ? ARM based ? MIPS again ?
 
Last edited by a moderator:
You must log in or register to reply here.

Similar threads

J
PAL PS3 Will we still have the Super Companion Chip?
Replies
8
Views
2K
Rolf N
R
L
Toshiba's New Chip inside PS3!
2
Replies
33
Views
6K
wco81
W
P
Look at this Google-cached (pulled down) PlayStation 3 page
10 11 12
Replies
224
Views
30K
Guden Oden
G
Back
Top