"Some additional info for you here. Since you're active on the forum, if you want post the following, it might help some users understand this issue here. Seems that the board suddenly got popular, so while we're resolving things now it seems the "forum" is as impacted as much as any one user.
The specific problem is deterministic based on the design, but the conditions to force it are extremely rare (an arc with a length of 0.000001 and 0.000004 inches). As a result, this problem will impact a bunch of people who've ordered the SDRAM boards, but no one else would be affected. Other than this one board, we haven't seen this issue occur in the two years since we previously submitted patches for the base problem.
In the near term, we're going to flag all these boards as they come in so we can swap in corrected files. Long term, we just have to patch one more software package, which should be pretty quick.
So, the technical detail for the failure is how arcs are treated in gerber viewers, and how some software handles this.
Internally, gerbers have arcs represented as 3 points: A start point, a centerpoint offset, and an end point. Gerber circles are represented the exact same way, only the gerber spec simply states to have the start and end point be the same. The upshot of this file format decision is that if a gerber ever loses precision on the coordinate data, it's possible to convert arcs of an extremely small length to a zero length, which in turn converts it to a full circle. This has to be precisely mitigated by either A) Never changing the format precision to a lower value, or B) Carefully tracking any arcs and avoiding this drop.
There's also some specific gerber commands that are intended to prevent this conversion through single or multi-quadrant arc specifications, but they tend to be less robust in how they're interpreted in practice. We've seen this exact issue come up in several software packages, including our fab's production equipment and processing tools.
Over the years we've patched a bunch of software to avoid this gracefully (allowing precision loss without causing arc wrapping). However, apparently we missed one software tool which is still is using 3.5 format instead of 3.6, which generates a precision loss of 1 digit. This means arcs that are between 0.000001 to 0.000004 inches in length, _and_ does not cross value of 0.000005 (which would cause them to round them to different values), can get converted to full circles.
Hopefully this helps explain the issue, and we encourage anyone affected to contact us for replacements and/or refunds. We really dislike bugs like this impacting our users, so we're happy to help correct things however we can."
RETR0Gamer wrote:So only order from OSH if you only plan to make a few boards and want them delivered faster in the USA.
gratte wrote:need bom capacitors
from antonio villena.
richx wrote:If you are worried unevenly trimmed header pins or too much solder will affect the max frequency a SDRAM module will test at, take a look at the this experiment.
Apparently PCBWay botched one of the inner layer header vias on this batch, causing no-connections between the header pins and IC pads. Didn't even imagine that vias could be left unconnected and that testing continuity might be a good idea on bare PCB and then again before mounting the ICs..
But this module tests fine at 140MHz for 2 hours with all the patched connections, even with the single CLK wire patch. Minimig core seem fine as well.
About 8 of the connections were obvious no-connects and were initially patched. Some others measured 3-10 ohms but must have disconnected after module warmed up for about 15 minutes (memtest started getting tons of fails), so I just patched all of the inner layer ones to fix.
Users browsing this forum: No registered users and 4 guests