The same voltage drop that prevent the CPU from running with high clockrate? And where it turned out that it was a wrong setting?
Nope, totally different voltage line (VDDR3).
Besides, the VSYS (power for the OMAP5) was still having a lot of noise and voltage drops, so improving it was mandatory.
Otherwiese, it could still have caused instabilities when more power was actually being used (like NEON, 3D and a high clockrate together).
It's only guaranteed to work if everything is inside specs, and it clearly wasn't.
Voltage drop for pcb traces that are only a few millimeters long is COMPLETE BS! If i read the mailing list, i am now 99% sure that you have no clue what causes this issue.
Yeah, right.
It seems you don't even have the most basic understanding of electronics.
If a wire (or trace) is too thin the for power you want to squeeze through, it will have an increased resistance, which will lead to a voltage drop.
The thinner the wire is, the higher the drop - and that has NOTHING to do with the length of the trace and wire.
Besides, you could even see NO wire as a wire with a diameter of 0 (which is really really thin), and now please don't tell me you don't lose all the voltage if no wire is there.
Here is a nice result of the simulation.
Here it shows we've got too high noise on the VDDR3 plane:
And here is where you can clearly see the nice voltage drops:
But yeah, these professional simulations are all bullshit. They were probably created by us using Microsoft Paint so we have some pretty pictures.
What you do is not testing. It is called "playing around". With a test, you make predictions for the result before you do it. Not afterwards trying to explain and interpret what you have experienced.
What you are explaining is a COMPLETELY different type of tests. These are tests to prove your assumptions.
There are also tests that you make to find out exactly what's going on if there are multiple reasons something can happen. This is what we did.
Of course, you still need to know WHAT to test and how to interpret the results. Which we did.
What we knew:
- It could be a software issue (wrong timings, wrong setup, etc.)
- It could be a hardware issue (noise, voltage drop).
- It could be a general incompatibility between the memory chip and the OMAP5
So, simulation showed the hardware is out of specs. But as before with the OMAP5: Out of specs doesn't necessarily mean that's the problem. Because the specs GUARANTEE that everything will work. Therefore, the manufacturers add A LOT of tolerance to them.
So even if we're out of spec, it could've been that it would still be fine.
Therefore, we also played around with the timings and settings, as this can give more clues.
For example, as the RAM worked fine with higher voltage (with the same timings), it's very likely the voltage drop is indeed an issue.
Why it worked with DLL Off and not with DLL On (which is the default) is a bit trickier to figure out.
The most likely reason is that the too high noise affects the internal clock divider of the DRAM (which is the DLL).
To rule out an issue with the memory, we also tried SingleRank Samsung memory (the 2GB version of the 4GB RAM we're using) and DualRank IM memory (which is the 4GB version of the 2GB RAM we used).
The 2GB Samsung memory works fine, whereas the 4GB IM memory works a bit better than the 4GB Samsung, but still crashes and reports memory errors. So while it's not as sensitive as the Samsung memory, it still doesn't work properly.
All these tests showed that the memory itself is fine and the voltage drop and noise are too far out of specs. So that's what we need to fix.
Besides, we've got support from some memory experts (for example, this company:
www.eyeknowhow.de, as well as Juliano who did the simulation for us). And even eyeknowhow could only give some assumptions but said without tests, nothing can be said for sure.
And that's what why we did the tests we could, and it showed us what the issue is.
If the rest of the world takes you as an example for german product development, then we are f*ed.
See? This is the reason why companies usually don't let anyone look into their development process, but rather present the finished product.
Do you think other companies don't have these things to figure out?
Why do you think companies like
www.eyeknowhow.de do exist, if they don't have any clients (as apparently, it's not needed to run any tests and everything works without issues from the first try)?
Do you think companies like Nintendo or Sony don't do tons of redesigns, testings, etc. before they publish their final product?
Dream on!
Sure, they've got a LOT more experience and know-how than we do, as they have a lot more experts, a LOT more money and they have already produced TONS of products using memory, so they might have some reference designs already for that.
BTW: Nikolaus (the designer of the hardware) has worked for one of the largest electronic companies in Germany before... and they usually even had more prototype revisions than we have.
Sure, it's easier. Instead of spending the time to test whether it's the hardware, we could've just assumed it is the hardware (as it was the most likely case), produced new CPU boards and test if that would fix it.
But that's also a lot more expensive. No prob for a big company, but certainly not possible for a smaller one like us.