That's why I suggested that it might prove better to replace the 8 pads
and a via with 9 in-pad thermal vias with holes small enough to prevent
wicking. However, I don't know how small that hole should be to
*reliably* prevent wicking (no matter who manufactures the board).
It's also possible that for a small enough via hole diameter the
reduction in total copper area inside the via(s) would make it no more
or even less effective than a single relatively large hole at the
centre. I haven't done the necessary calculations and experiments
because the arrangement I came up with works for my purposes ("if it
ain't broke, don't fix it"). It could be it's not good enough for
higher power dissipations. It's also possible that even if the heat
transfer through the board were improved upon, the limiting factor is in
fact the available copper area on the reverse side. I've always
struggled to get a large, continuous copper area, as there are
inevitably tracks all round the chip, often passing very close to the
central via (I always have to design for absolute minimum cost, which
means double-sided boards that mix power planes and signal tracks).
The 32 pin MLF/QFN doesn't have much area beneath it. For a chip with
a significantly larger area I would increase the number of vias
appropriately. So far I've not needed to design for a sufficiently
large MLF/QFN to make that practical.
When I did the research into MLF/QFN footprint design I found that even
the manufacturers of the chips didn't know what constituted an optimal
design. There was plenty of information about what the problems are,
and quite a few suggestions for footprint designs (not all of which were
practical), but no tried and tested solutions recommended by the
manufacturers. That situation may have changed (I hope it has). My
design is intended to address the problems, to be low risk (in terms of
reliable manufacturing), and to be practical in kicad, and so far it's
meeting those aims.
Regards,
Robert.
On 17/05/2010 20:26, Cat C wrote:
>
> Shouldn't there be more vias to take the heat to the bottom?
>
>
>
> T
>
>> To: [email protected]
>> From: [email protected]
>> Date: Mon, 17 May 2010 09:57:50 +0100
>> Subject: Re: [kicad-users] Preventing thermals on special pads of SM packages
>>
>> I often have to work with MLF/QFN devices, which have a thermal pad on
>> the bottom. There are two considerations here. Firstly there is the
>> heatsinking requirement, and secondly if you get the copper design wrong
>> the chip will float on a central blob of solder, resulting in unreliable
>> soldering of the pins.
>>
>> For the thermal pad footprint for a 32 pin device I arrange 8 square
>> pads around a central via, and I place solder resist over the via. I
>> number all the (thermal) pads as "33", so I only end up with one extra
>> pin in eeschema. I connect together the pads and the via with a grid
>> of thick tracks. The use of a tented via in this way means that the
>> via will be solidly connected to the heatsinking copper zone on the
>> reverse side, whilst the tenting prevents solder wicking through the
>> via. This arrangement has worked well for me.
>>
>> An alternative arrangement might be to use nine untented vias with very
>> small drill holes in the same pattern. This would give better thermal
>> contact between board and component, but I don't know how small the
>> holes would have to be to prevent solder wicking, or whether they would
>> end up so small that their heat transfer capability would be
>> compromised. If that were the case I guess you could use more vias
>> with a smaller annulus. However, whilst I would be interested to know
>> if this is a better method, I've no idea what size the holes would have
>> to be, I don't have the means to do the necessary experimentation, and
>> the arrangement I use currently works well enough for me.
>>
>> Regards,
>>
>> Robert.
>>
>> On 15/05/2010 22:30, Karl Schmidt wrote:
>>> Today, there are many surface mount parts (MOSFETS, driver-chips etc.) that
>>> depend on a solid copper
>>> connection to aid in dissipating heat. Those pins should not have a thermal
>>> created to a ground
>>> plane. What is the best way to prevent the generation of this thermal?
>>>
>>> ( I think this should be an attribute of a pin type in eeschema - but it
>>> isn't there .. there might
>>> have been a 'T' attribute in PADS - might have been in the pad-stack
>>> definition? - if memory serves
>>> me right. I think it could default to T unless told not to do so).
>>>
>>>
>>> I think I can create a zone with thermals turned off - and kludge it up to
>>> work.
>>>
>>> This wasn't much of an issue in the past, but is rather common with the SM
>>> boards of today -
>>> probably should have some way to do this..
>>>
>>> I want to write this up..
>>>
>>> --------------------------------------------------------------------------------
>>> Karl Schmidt EMail [email protected]
>>> Transtronics, Inc. WEB http://xtronics.com
>>> 3209 West 9th Street Ph (785) 841-3089
>>> Lawrence, KS 66049 FAX (785) 841-0434
>>>
>>> Action speaks louder than words but not nearly as often. -- Mark Twain
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------
>>>
>>> Please read the Kicad FAQ in the group files section before posting your
>>> question.
>>> Please post your bug reports here. They will be picked up by the creator of
>>> Kicad.
>>> Please visit http://www.kicadlib.org for details of how to contribute your
>>> symbols/modules to the kicad library.
>>> For building Kicad from source and other development questions visit the
>>> kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups
>>> Links
>>>
>>>
>>>
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 9.0.819 / Virus Database: 271.1.1/2878 - Release Date: 05/16/10
>>> 19:26:00
>>>
>>
>> ------------------------------------
>>
>> Please read the Kicad FAQ in the group files section before posting your
>> question.
>> Please post your bug reports here. They will be picked up by the creator of
>> Kicad.
>> Please visit http://www.kicadlib.org for details of how to contribute your
>> symbols/modules to the kicad library.
>> For building Kicad from source and other development questions visit the
>> kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups
>> Links
>>
>>
>>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.819 / Virus Database: 271.1.1/2879 - Release Date: 05/17/10
> 07:26:00
>
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 9.0.819 / Virus Database: 271.1.1/2879 - Release Date: 05/17/10
07:26:00
