kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 19/07/2014 04:53, Carl Poirier a écrit :
> Why wouldn't KiCad be able to deal with that? As an example, I modified
> a QFN48 having a thermal pad to include thermal vias directly in the
> footprint. In the schematic, I have chosen a 48pin MSP430. I assigned
> all of the thermal stuff (pin number 49, not present in schematic) to
> ground statically. Alternatively, a via can be placed manually under the
> thermal pad, as shown in the middle. They can then be connected and DRC
> passes fine. Unless I am missing something, I tend to think the only
> thing we need is that the static assignments must not go away if you
> read the netlist again.
> 
> 
> 
> Regards,
> 
> Carl
> 
> 
> On Fri, Jul 18, 2014 at 9:01 PM, Jean-Paul Louis <louijp@xxxxxxxxx
> <mailto:louijp@xxxxxxxxx>> wrote:
> 
>     Carl,
> 
>     This is opening a whole new can of worms. First the request is for a
>     justified thermal pad that is becoming more frequent. But after
>     that, I have seen request for via patterns on thermal pads. So, now
>     an SMT part can be a mix of pads and through holes that can even be
>     blind in some cases.
>     No sure about kicad ability to deal with that.
> 
>     Jean-Paul
>     AC9GH
> 
> 
>     On Jul 18, 2014, at 7:52 PM, Carl Poirier <carl.poirier.2@xxxxxxxxx
>     <mailto:carl.poirier.2@xxxxxxxxx>> wrote:
> 
>     > Hi folks,
>     >
>     > I would like to discuss this here. Very recently, a contributor
>     has opened a pull request for a symbol to add an extra pin for an
>     exposed pad. Kerusey then suggested to statically assign the pad to
>     a net instead of having an extra symbol. This does indeed work, but
>     the contributor has raised the point that every time the netlist is
>     read, the static assignments have to be set again.
>     >
>     > First of all, is static assignment the way we should go to deal
>     with extra pads? If so, how about making the static assignments
>     stick through a netlist read, as long as that pin is not tied to
>     another net in the schematic?
>     >
>     > Regards,
>     >
>     > Carl



I fully agree with Jean-Paul Louis.

Generally speaking, This is a very bad idea to allow a board to have
connections which differ from the schematic.

If you want to use a QFN48 with exposed pad (your example):

1 - this is no more a QFN48, and you have to select something like a
QFN48+EP in your schematic. If the pad 49 does not appear in schematic,
and if you select a QFN48, you'll have no warning when reading the
netlist (minor issue, I know, but an issue).

2 - If the pad 49 (and  its connection) does not appear in schematic,
you can easily have a bad connection, if the net name changes (for
instance using DGND for pad 37 instead of GND) you'll have a broken board.
This is a major issue.
For large boards (with hundred of footprints), it is very difficult to
see this kind of error.


For me, the fact a schematic component which needs a "QFN48+EP footprint
with pin 49 connected" and does not have the pin 49 shown and connected
in the schematic is just a broken schematic component.

Therefore the request for a symbol to add an extra pin for an exposed
pad is a very good request.

-- 
Jean-Pierre CHARRAS