Yes, it can be
checked in lvl1 dump. From the
testbench logs we now know the Fab and "DS line" (Design/specification line? I'd be curious if you think that's the correct acronym. I asked Chat GPT and it seemed plausible). There's a ton more nuanced context I'd love to chat about, but it'd derail this thread with techical details about partnerships and specific roles of enginners on the physical design and thermal design teams. But I would like to learn more about who's making what descisions.
I've been looking at these timelines fairly closely and their LSI projections follow their development goals with the exception that the 65nm seemed to have been rushed to market early. Likely as part of a crysis mitigation strategy to avoid bumpgate allegations and the $h!tstorm both Nvidia and Microsoft were experiancing. So SSONY released the 65nm chipsets, which have a reliable packaging material set, as a way to dilute the failure rate. The DIA-002 MB revision appeared in J/K models with the CXD2982 65nm RSX and only a few months later the VER-001 with CXD2991 65nm RSX released in L/P models. But rushing them out left a stockpile of DIA-001 MB revisions with their defective 90nm RSX. Instead of scrap them, they created 2 new models of console (M and Q) that were identical to the H model, but released alongside the reliable J/K models and only in 2 regions. M03 (uk/ireland), and Q00 (japan). This is a little known fact.
They diluted their failure rate by hiding defective RSX among reliable models and in smaller markets that would limit their liability. They could blame a batch, and have plausible deniability. And that's if it raised alarm bells and outrage, which it never did.
Their crysis managment was clever and diabolical. From their perspective it was a win to avoid a recall. From our perspective (as a consumer) it's some shady BS!
I've done extensive characterization of the core voltage ripe and noise of failing nec/tokins and designed an attenuated polymer/mlcc filter to replace the proadlizers, which has superior broadband performance. I call it the
PS3 Tantilizer.
Reduces ripple to between 10 and 20mVpp, 1-2% of output voltage (1.0v to 1.3v VDDC), which is a good general target.
The on COK-00X the CELL has 3 phase IOR "power blocks" (buck converters) and the RSX has 2. Each capable of delivering 40A. Switching frequencey of between 500 and 1KHz. Ripple is easily attenuated by bulk filtering low ESR/ESL processor decoupling capacitors. Harmonic noise/ringing extending into frequencies above 2-10MHz need to be attenuated by an additional array of MLCC bridging the gap in the frequency response curve created by using 470uf polymers that handle the ripple, and the existing array of 36x 0.1uF mlcc which handle cross talk, common mode noise, and EMI. So I reccomend a similar approach as what sony did with the slims (adding 22uf and 10uf). My sumulations suggest 47uf, 22uf, 10uf, 4.7uf, 2.2uf, and 1uf mlcc broaden the band and bridge the gap well. And the ripple/noise on the scope is well under control.
So I think they will perform well if I were to attempt to overclock on a COK. The VRM is overspec'd for the 40nm RSX's core and VRAM voltages. It can deliver way more watts than it'll ever need. And since it's not operating nesr it's limit, will do so more efficiently and produce less switching noise than it would with a 90nm.
Contrast that with a slim's VRM solution that was spec'd down for the 40nm and the filter as well, the COK should have more headroom.
And the Heatsink is is designed for a higher TDP 90nm.
Overclocking a Frankie intrigues me for these reasons.
I dont think this would be too difficult to acomplish. The VID is dynamically set, but the feedback and compensation loop has a voltage divider that could be shunted. Perhaps a varistor mod could do just what you suggest. I have a few ideas of what to target.
Same with FBVDDQ, I think increasing to 1.9v for higher spec'd VRAM modules wouldn't be too difficult. It's a matter of whether or not the syscon or RSX can handle it. I'm curious about XDR as well. VDD_MEM could also be increased to support faster XDR clocks if need be. These are solvable problems. For COK-00X, we have the benifit of the service manuals and their circuit diagrams.
There will be plenty of PS3s that can of course handle above 650MHz core speed but what we are aiming for here is a maximum universally safe frequency for all slim model PS3s which is why I arrived at the figures of 650\700 because you have to consider not all PS3s are going to have core\memory that clocks well and not all PS3s (in fact, definitely are not) using the same Samsung memory some consoles are equipped with memory rated for more than 700MHz so the best thing to do is to set clocks at what should be universally attainable and anything higher than that is at the users risk. I'm thinking of saving as many peoples PS3s from becoming paperweights as possible.
It used to be you could openly talk to hardware and software engineers but doing those kinds of things is long gone, you'd have to go back some 20+ years for that, but it is partly how I learned. Slowly but surely though as things became more cut throat and secretive engineering divisions got smaller, quieter, until it got to the point we are at now - essentially gagged by NDAs and worse still companies don't want the customers to be informed anymore because when a lot more people like me were around companies HAD to make a good product lest they be lambasted for it, and they didn't like doing that, more time = more money, informed buyers = higher production costs because an informed buyer won't buy tat. All I can really say is that the engineers today are not the ones making final decisions there is always compromise that shouldn't even be just because marketing and suits want to try and persuade everyone to spend hundreds (or more) extra on one or two features that on the design\manufacturing line cost literally pennies to add.
(I was itching to try.)
