Replace SOT-363 with generated FP

[chschlue]

pointhi/kicad-footprint-generator#460

https://www.jedec.org/sites/default/files/docs/MO-203C.pdf

---

All contributions to the kicad library must follow the KiCad library convention

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the footprint(s) you are contributing
• An example screenshot image is very helpful
• If there are matching symbol or 3D model pull requests, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required
• Give a reason behind any intentional library convention rule violation.

---

Be patient, we maintainers are volunteers with limited time and need to check your contribution against the datasheet. You can speed up the process by providing all the necessary information (see above). And you can speed up the process even more by providing a dimensioned drawing of your contribution. A tutorial on how to do that is found here: https://forum.kicad.info/t/how-to-check-footprint-correctness/9279 (This is optional!)

[plaes]

It seems that you removed the SC-70-6 from tags and description.
And while you're at it, can you also add SC-88 (this terminology seems to be used by ON Semiconductor) into tags and description as well.

https://www.nexperia.com/packages/SOT363.html

[evanshultz]

@chschlue
Are the other packages exactly the same? Seems a bit silly to have multiple footprints for compatible packages, but if the dimensions used by JEDEC for SOT-363 don't match other compatible packages then we'll have to decide what to do.

[chschlue]

@evanshultz Oops. I kinda forgot about this PR and can't seem to find the discussion that led to it right now.
Call it a request for comments.

Problems I see:

1. You don't have to dig deep to find... variations... among SOT-xxx, compare https://www.nxp.com/docs/en/package-information/SOT523-1.pdf to https://www.diodes.com/assets/Package-Files/SOT523.pdf, for example. We probably have lots of SOT FPs that should actually have MF prefixes, OTOH if there's a JEDEC spec availabe, the lib should also contain a vendor-neutral FP.
2. I don't have access to IPC-7351 but AFAIK it contains explicit exemptions for SOT-23 and the like (with the almost square pads we all know and love). I'd like to know what it actually says there; this one is basically a gullwing package but as the screenshot above shows, heels and toes resulting from the usual calculations seem to be excessive for packages that size.

[evanshultz]

1. I was thinking differences between JEDEC, JEITA, etc. for packages which are considered compatible by the industry. Vendor datasheets definitely vary in dimensions even if they state adherence to some governing body's package. And note that NXP uses their own nomenclature which you can't compare with any industry-standard package name. By 'MF prefix' did you mean 'MO'? I'm in favor of a single footprint, or a combo footprint if it comes down to it, but we'd have to see how compatible the governing body packages drawings are.
2. I'm looking at IPC 7351B and I don't see anything of the sort. Do you have more information to what you're referring? The SOT23 package is in section 8.6 on page 58. Table 3-2 on page 16 discusses gullwing packages, and it lists applicability for SOT packages described in section 8.6 (among others). But I see there's a note under the table for packages where Smin is <= Amax to use different heel fillet goals. Perhaps that would affect these footprints? In addition, it may be that Level B (the default) is just too much for these smaller packages even though it works fine for bigger SOIC packages. It may be more inline with what users expect to default to Level C density for physically smaller packages. I supported varying densities for chip parts at Support generating two-terminal footprints with IPC density argument pointhi/kicad-footprint-generator#439 and so something similar could be done for the gullwing generator script as well.

You requested comments, so there are mine. :)

[chschlue]

1. I know my example was extreme, but still I'm pretty sure it's not to hard to find clashing SOT-xxx packages even if you disregard NXP's nomenclature.
   I have yet to read up on the v6 file format drafts but FP aliases or hierachies might help clean up the current mess (getting rid of FP names like SOT-363_SC-70-6_SC-88, especially if nobody has ever actually verified JEITA specs)
2. I thought I had seen this
   
   actually codified somewhere. Density variations don't explain it.
   No, I don't have more information right now. Guess I'll buy a copy when I'm back from vacation.

[cpresser]

It seems that you removed the SC-70-6 from tags and description.
And while you're at it, can you also add SC-88 (this terminology seems to be used by ON Semiconductor) into tags and description as well.

There are even more names (Center of the picture is the current FP)