wafer.space Community - Sounds like we might need to increase /

7:46 p.m.

Currently, the precheck makes no assumptions about the pads, except for checking that the pad masks exists at the right places. I suppose the platform could provide a test plan for the default padring and the foundry pads, and allow to upload a custom test plan. However, what format such a test plan should have, and which tests are available (e.g. shorts to other pads, measuring ESD diodes, etc.), would be for @Lauri to say.

This could be something maybe better to have on platform.wafer.space and they can opt in and put data if they care to. If not it will just be the standard.

@Leo Moser (mole99) - For now I don't think we want to go the route of providing a test plan or anything. I was thinking that the precheck should enable checking what ever needs to be checked so that it means @Lauri's tester will work with his default testing setup.

It would be great if one day the platform could output design pad map, die renders and even bonding diagrams

@Lauri - I agree that is something we should probably make happen.

1

@Tim 'mithro' Ansell We can't assume much more than the pad openings. Everything else could be custom and thus needs to be specified by the user. @Lauri The precheck already generates a render of the design. The platform just needs to be updated to display it or allow it to be downloaded.

Leo Moser (mole99)

@Tim 'mithro' Ansell We can't assume much more than the pad openings. Everything else could be custom and thus needs to be specified by the user. @Lauri The precheck already generates a render of the design. The platform just needs to be updated to display it or allow it to be downloaded.

@Leo Moser (mole99) - We can require whatever we want that makes our lives easier. If people want something different / custom they can always contract @stuart.

1

Tim 'mithro' Ansell

@Leo Moser (mole99) - We can require whatever we want that makes our lives easier. If people want something different / custom they can always contract @stuart.

I was talking about the chip design: we don't know what's underneath the pad openings. People could swap out digital pads for analog ones, change power/ground pads or even make their own fully custom pads. Therefore, we would need to require the user to specify which tests (measure ESD diodes, short, open...) should be done.

Leo Moser (mole99)

I was talking about the chip design: we don't know what's underneath the pad openings. People could swap out digital pads for analog ones, change power/ground pads or even make their own fully custom pads. Therefore, we would need to require the user to specify which tests (measure ESD diodes, short, open...) should be done.

There is nothing stopping the precheck from enforcing certain items under the pads? (Except maybe the code doesn't exist.)

I think I'm now set up to generate these documents for every die in reticle. My first instinct was to say that it would be good if the platform could generate these documents however, now I think best not to. Mainly because the time it takes from uploading the design to wirebonding is long and the pcb design may change multiple times in that time.

WSLG_chip_top_10_2_1x1.pdf

2.28 MB

Lauri

I think I'm now set up to generate these documents for every die in reticle. My first instinct was to say that it would be good if the platform could generate these documents however, now I think best not to. Mainly because the time it takes from uploading the design to wirebonding is long and the pcb design may change multiple times in that time.

Nice pdf, I like that all three pages are in the same doc. Makes sense imo

5:18 a.m.

I've also been thinking - re serial number placement and readability - would it make sense to shift the vias (for example the ones in the lower area) apart so we have enough room without vias for a serial number? Then we wouldn't necessarily need to plug them?