[PCB_FORUM] Re: Purge Unused Padstacks
- From: "Gary MacIndoe" <gemcad@xxxxx>
- To: <icu-pcb-forum@xxxxxxxxxxxxx>
- Date: Sat, 4 Sep 2010 14:35:27 -0600
Hi Michael,
I hadn't thought of a subsequent symbol using the "stale" padstack already in
the database. That sounds like as good a reason as any to purge.
We will purge unused padstacks before sending to Fab from now on.
Thanks for your lengthy reply!
----- Original Message -----
From: Baumstark Michael-EMB043<mailto:M.Baumstark@xxxxxxxxxxxx>
To: icu-pcb-forum@xxxxxxxxxxxxx<mailto:icu-pcb-forum@xxxxxxxxxxxxx>
Cc: Dave Seymour<mailto:dseymour@xxxxxxxxxxx>
Sent: Friday, September 03, 2010 2:38 PM
Subject: [PCB_FORUM] Re: Purge Unused Padstacks
Hi Gary:
I may be a little late in chiming in on this thread but I only review the ICU
forum discussions when I have a break from the hustle and bustle.
I did not think that I saw it mentioned in the other replies but.... One of
the most important reasons for purging unused padstacks: is to ensure that if
you ever load any new components into your design, you will get a fresh image
of that padstack information from your controlling library reference (padpath &
psmpath directives).
Recall, that once a (?)symbol or a padstack is loaded into a board file, that
image remains in the board file until intentional action is taken to update
those entities in the board file. This is accomplished by a variety of
directives: Place --> Update symbols (w/ update padstack option), select as
much or as little as you want, OR Refresh padstacks. (Some new users are not
aware that this GUI pick is only found under the Tools --> Padstack --> Refresh
menu AND not available under the Refresh symbols GUI.)
If for ANY reason you do not happen to refresh those (unused, then
subsequently used again) padstacks you will be referring to the padstack
information that has been retained in the *.brd file (perhaps since the
inception of the first design spin, x number of revisions ago :) ) . So there
exists some degree of risk, should your librarian modify any of those
padstacks, you could possibly not get those updates from your master Library.
It is a small detail: but the devil is in those details for flawless execution!
As a general practice we will Refresh ALL symbols AND padstacks in the design
at some point in advance of a Production Release to ensure we are up to date
with the master Library. But after that point in time a Decision block is
encountered to Refresh ALL or not to refresh. The answer is generally NO, with
exceptions being on a very selective basis. AND yes, we will always purge
unused padstacks on every design spin.
So besides getting the lead out of the design, you are also guaranteeing (by
taking that extra step) that you will be getting a fresh library image when
that padstack is used again.
On another note (which may be obsolete by now but): If you are engaging in
the ObjectCAM use model.... Before the last ObjectCAM update there were some
defect issues encountered with the array database file while reading the one
image database. As a SWAG to mitigate these defects, one of the recommendations
(by Cadence) was to Purge unused padstacks, along with a few other steps. These
defects did go away after the ObjectCAM version 2.0 update so it could be a
mute point with current version tools. But you did ask: and that is what I
know.
As with traditional Cadence convention, it takes an intentional action to
refresh database elements. So too, it takes an intentional action to flush some
Unused elements. So I would think that you would want to flush these items most
of the time but I would not want to automatically do so under all
circumstances. Are you now a convert?
Dave Seymour - Concur - Yes, we too are aware that there continues to persist
a Cadence defect where Shape Symbols (*.ssm) files do not refresh with the
Refresh symbols directive. Indeed, the workaround is to delete the parts that
contain *.ssm features, into an unplaced status, then purge the unused
padstacks to remove the image from the *.brd database, then replace those parts
to their original position, as you stated. Fortunately we do not have that many
parts that utilize *.ssm features, mostly shields. But it is certainly an
ongoing and EASY opportunity for defect, until this deficiency is repaired. We
have not started using the 16.3 tools yet, and I do not recall if the defect
has been repaired yet. I will post back if I find out that this particular item
has been fixed.
Sincerely yours,
Michael Baumstark
Sr. Staff Electrical Engineer / PCB Design, CID+
Motorola - EMS - Worldwide Radio Solutions -
Astro - APTC/Physical Design Organization
8000 West Sunrise Blvd. Mail Stop: 1329
Plantation, FL USA 33322-9947
Intra: http://rprc.mot.com<http://rprc.mot.com/> ;
http://pcbadvisor.mot.com<http://pcbadvisor.mot.com/>
web: http://www.motorola.com<http://www.motorola.com/>
-------------^------------------^-----------------^------------------^--------------
>---^-.--- >---^-.--- >---^-.---
Motorola Internal Use [ ]
Motorola Confidential Proprietary [ ]
------------------------------------------------------------------------------
From: icu-pcb-forum-bounce@xxxxxxxxxxxxx
[mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx] On Behalf Of Macindoe, Gary
Sent: Tuesday, August 24, 2010 4:00 PM
To: icu-pcb-forum@xxxxxxxxxxxxx
Subject: [PCB_FORUM] Purge Unused Padstacks
Hey guys,
Are you purging unused padstacks before sending your design to Fab (Tools ->
Padstack -> Modify Design Padstack, Purge -> All)?
If so, what is the benefit? What is the downside to not purging? Is it simply
a database cleaning function?
Thanks for any responses.
Regards,
Gary MacIndoe
Senior PCB Layout Designer
Contract - Kelly Services
Covidien
EbD R&D
5920 Longbow Drive
Boulder, CO 80301
303.476.7458
www.covidien.com
Other related posts:
