You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 2, 2020. It is now read-only.
I've mentioned this before, but I don't think I've ever created an issue and I just ran into it again...
Sometimes our QFN footprint names aren't specific enough. I'm talking specifically about scripted footprints. There are inputs to the script, which aren't captured in the footprint name, that can differ between footprints which would end up with the same footprint name. This means that we have powerful scripts to take in the full set of package dimensions and generate unique footprints, but the footprints names aren't unique.
It's sorta like a collision with a hash function. Sorta. We can have multiple, unique inputs that all result in the same output.
Does this matter? Perhaps not. They're awfully close and likely to work. But if we're claiming IPC 7351-compliant footprints thanks to our script, the footprints used for symbols in the library may not always have the fillets that one would expect when looking at the package drawing.
Good point. Maybe something to include for version 6. Even if it pains me to do another massive rename. However as i generally would like to get away from manufacturer specific namings for QFN and other standardized packages this might actually be a good time to do it.
I've mentioned this before, but I don't think I've ever created an issue and I just ran into it again...
Sometimes our QFN footprint names aren't specific enough. I'm talking specifically about scripted footprints. There are inputs to the script, which aren't captured in the footprint name, that can differ between footprints which would end up with the same footprint name. This means that we have powerful scripts to take in the full set of package dimensions and generate unique footprints, but the footprints names aren't unique.
It's sorta like a collision with a hash function. Sorta. We can have multiple, unique inputs that all result in the same output.
Let's look at a specific example.
QFN-48-1EP_7x7mm_P0.5mm_EP5.6x5.6mm
in our library was derived from the package drawing at https://www.st.com/resource/en/datasheet/stm32f042k6.pdf#page=94. Generating a footprint for the package at https://www.analog.com/media/en/technical-documentation/data-sheets/AD9542.pdf would result in the same footprint name. However, dimensionsb
andL
are different for those packages. So while the footprint may have to shared between those parts in our library, it will only be ideal for one.Does this matter? Perhaps not. They're awfully close and likely to work. But if we're claiming IPC 7351-compliant footprints thanks to our script, the footprints used for symbols in the library may not always have the fillets that one would expect when looking at the package drawing.
It's worth pointing out that the IPC 7351 naming convention doesn't capture lead length and width for QFNs (see http://ohm.bu.edu/~pbohn/__Engineering_Reference/pcb_layout/pcbmatrix/IPC-7x51%20&%20PCBM%20Land%20Pattern%20Naming%20Convention.pdf) so it's either an oversight or perhaps they decided it didn't matter enough and left it off as the name is already long enough. So while the fillets may not match IPC 7351, it seems the naming is still compliant. Or perhaps I just didn't catch where this is captured in the doc.
There may be other footprint types that suffer the same issue.
The text was updated successfully, but these errors were encountered: