I’m creating a symbol and footprint for MPM3811. Pins 2, 3, 4 and pins 6, 7, 8 are connected together.
I like creating symbols with every pin because I want to know what every pin does. I’ve created the following symbol.
My concerns are:
When I place the part, will pcbnew’s DRC complain that I have pad 11 connected to 2, 3, 4 and 12 to 6, 7, 8?
Pads 11, 12 don’t exist in my schematic symbol. Is that okay?
a) Seems poor form to have pins in the footprint that isn’t in the symbol. Is this fine?
Pad 1 is constructed with three elements: a big rectangle on the left, a small square on the right bottom and a trapezoid on the right side.
a) The big rectangle doesn’t overlap with either the square or the trapezoid. Is that okay?
b) The square and the trapezoid overlap. Is that okay?
When constructing pins 2, 3, 4, 11, I have them overlap. Is that okay?
I’m in batch create mode and haven’t gotten to the point of verifying the footprint and wanted to learn the techniques as I create assets than bulk fix later.
No not ok. Connections to unused pads will be flagged by DRC.
a). Unused pins wil just be left open.
With KiCad it is normal to build a big pad out of several pads with the same pad number. All should be connected. I’m not sure where the limits are.
Normally you give all overlapping pis the same pin number. It may work if you create a schematic symbol which also has pins 2, 3, 4 and 11 and have them tied together. You will have to check if DRC does accept that. Possibly you can try to rename pad 11 to pad 2, and then connect 2, 3 and 11 together in the schematic. It is more common though to give pads 2, 3, 4, and 11 the same pad number.
The way you want to do things is a bit unusual. The quickest way is probably to just do it and then see what the DRC tells you. If it does not work you can easily renumber the overlapping pads to the same pad number, and then live with the uncomfortable feeling that not all pins have their own number on the schematic. As long as your schematic symbol fits with the Footprint, it is electrically sound and you will have no DRC problems.
The first (few) footprints will take a significant amount of time. After the learning curve, most of the time is for getting the coordinates of the pads right (maybe clone an existing package as a starting point?) After that work, renumbering some pads if needed is just a few minutes.
P.S:
Quite an impressive chip you found. A 2mm * 2mm SMPS module with built in inductor. I did not even know such things existed.
Wow, nifty. This looks like it could be a low voltage replacement for an LM314. it has similar minimum support component requirements, input and output filter caps and a voltage divider for feedback. Just need to watch out for switching noise on the output (output filter cap and/or network should help), and any possible EMI coming off of that large SW triple-pin area. It’s amazing what they can fit into those tiny packages.
only if the schematic does not ensure that the 4 connected pins are on the same net (in this case there are the pins 11 and 12 which also need to be connected. A potentially better option would be to give these two at least the same number as one of the other 3.
In the end it will all depend on how the symbol is drawn.
I’m also not sure how it is now. I’m sure that some time ago (4.0.7 or may be later) the algorithm for detecting that pads are connected was not perfect. For two rectangle pads (with the same number) if center of one was inside the second (or second inside the first) KiCad assumed they are connected. But if not you got the connection lines telling that you have to connect them. I was doing keys like at top of page 13 in:
And I had to add many tracks inside each key to not have connection lines.
I reported it as a bug suggesting to assume that pins with the same number are just connected (even not overlap - for example if in touch-button they are internally connected) but developers don’t wont it. They have some serious arguments against, which I don’t fully understand (I know too little about KiCad internal dependencies).
Pins 2…4 are physically one, as are 6…8. Seemingly they have been numbered only because each pin sticks out in three parts from the package. I would probably replace them with one pin. The pin numbers can be for example “2…4” and “6…8” to reflect the datasheet. The pad numbers must match. Yes, they are called numbers but are really text strings.
The E-shaped pads can be made with custom pad shape polygon. Because the device is for relatively high currents you should use zones for connections. Therefore you could as well have bigger rectangular copper pads and separate mask opening pads (without pad numbers). Pins 2…4 are for soldering only, they won’t be connected, so you should think only about solderability there, although they can even be left unsoldered. See PCB Layout Guidelines in the datasheet. In such layout the mask openings really define the pads, the copper shapes don’t matter.
It is fully ok to have the pins 2…4 in the footprint even if they are connected. As long as the symbol represents them. I mean i would then stack the symbol pins but this is also not required. Some users might just want to have every pin even such connected ones in the schematic for easier identification when debuggin.
I’m sure the manufacture chose to number the pads in that way simply because it is a modified QF10 package and this is the simplest starting point for drawing the footprint.The data sheet shows no separate functional difference between the pins. The suggested layout needs zones as @eelik noted and the pins themselves are not visible or ‘probable’ individually on the final mounted board. Treat the footprint as a ‘serving suggestion’ - different EDA software might work with different strategies but lumping the pads and stacking the pins would be a good, clean solution in KiCad.
Here are a simple symbol and footprint which show two strategies: 3 pins or one pin. Neither strategies produce DRC errors and there are no extra numbered pads needed (your original 11 and 12).
I’m running (5.1.8 )-1 on Windows - full version below. When I rotated the Custom Shape Primitives for pad 3 in the footprint you created by 180 deg. in the Transform Primitives command I get a partial rotation. Please see below. Do you see the same thing?
Application: KiCad
Version: (5.1.8)-1, release build
Libraries:
wxWidgets 3.0.5
libcurl/7.71.0 OpenSSL/1.1.1g (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.73.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.71.0
Compiler: GCC 10.2.0 with C++ ABI 1014
Custom shape pads are not without difficulties in editing. They consist of a polygon and a normal pad. The primitives aren’t normally edited with that interface, it’s too difficult. They are created like this:
Create a normal pad which fits inside the shape.
Create a graphic polygon (on any layer).
Select both.
Use the context menu -> Create Pad from Selected Shapes.
For later editing you would use Explode Pad, then combine them again.
Thank you for the tip on how to make custom shape pads.
I ended up putting a small pad in the center and then drawing the new pad around it (and centered) so that placement didn’t have any offsets to deal with.
@eelik and @Harjit: There may be another good reason to number pins 2-4 as one pin and also 6-8 as one pin. They are outputs/power pins. According to the datasheet, pins 2-4 are not to be used in a normal design, but 6-8 are the IC’s normal output pins. If you want to have strict DRC checking, it would be a good idea to declare them as power output pins. With all these power output pins connected together, DRC will complain, unless you silence the combination from the error-matrix settings. Otherwise, you will probably need the power flag tied to the output net, to let DRC know the net is driven. None of this is a show stopper, of course. Personally, I like strict DRC checks and not even warnings.
I have encountered this issue several times with voltage regulators which have multiple output pins. One way around this that I’ve been using is to declare only one of the power output pins as such and the other passive. Not a real situation, but at least DRC does not complain about more than one power output pins tied together. Maybe in version 6 there could be a flag in the symbol pins, telling the DRC not to worry if these particular power output pins are tied together?
With my personal libraries I never use power output pins. I set all power pins to power input pins. That forces me to scrutinize the net and force me to place a PWR_FLAG. I then use the PWR_FLAG as a visual indicator on my schematics as where the source of power is coming from.
I recognize that this won’t catch accidentally connecting the output of two different regulators w/o any sort of load balancing network between them. That is a risk that I personally accept, and have caught this a couple times on my designs when I’m deciding the best place to place the PWR_FLAG to indicate to me the source of my power. (And occasionally I caught an accidental shorting of two power nets because the PWR_FLAGs that I had previously placed now clashed with the shorted nets.)
But that is my personal way of skinning this particular cat.
