[PCB_FORUM] Re: Soft Located Ref Des vs Hard Located
- From: Mark Salberg <msalberg@xxxxxxxxxxxx>
- To: icu-pcb-forum@xxxxxxxxxxxxx
- Date: Mon, 17 Apr 2006 10:03:42 -0400
Thanks Bill and Chris.
I really appreciate your feedback, but it is scary to say the least.
Seems like a bunch of workarounds if you use the tool the way it was
"designed" for.
Does anyone else out there that uses $LOCATION / soft lated ref des do
any of the following?
1. STATE_WINS_OVER_DESIGN (must this always be set?)
2. Moving OPF directory?
3. Modify the pxl.state file? (an ascii text file)
4. How do you know what the next available "GROUP" property is? Display
and search across the entire schematic each time?
I can't say this gives me the warm fuzzies about making the switch!
I guess I will have to do some testing on this.
Thanks again,
Mark
Bill O'Leary wrote:
Chris, Mark,
I only edit the pxl.state when there are problems that arise after big
schematic changes. I don't recommend doing it until you have to!
There are certain times I have found where you need to. For example,
if you want to insert a page in a schematic and still keep in sync,
you can do it by updating page
numbers in the state file... I wrote a script to to insert pages in
the middle of a schematic (by moving and renaming the .csa, files,
fixing the page number attributes in the .csa files, and then fixing
the pxl.state files, by bumping uop tge the page numbers for every
page after the inserted one so that all ref-designators stay as they
were.
What I was trying to say is that the state file is pretty straight
forward, and provides a place to fix problems when they do occur.
Oh... One other benefit of moving the OPF file... large designs
package much faster (almost 15 minute savings in some cases) J
Thanks,
Bill
------------------------------------------------------------------------
From: icu-pcb-forum-bounce@xxxxxxxxxxxxx
[mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Shaw
Sent: Friday, April 14, 2006 11:46 AM
To: icu-pcb-forum@xxxxxxxxxxxxx
Subject: [PCB_FORUM] Re: Soft Located Ref Des vs Hard Located
Mark, Bill,
I have used packager XL for many years both as a designer and
supporting other designers. I would always recommend using soft
locations over hard locations, except for specific cases such as
forcing all of one type of ref des prefix, such as those for
connectors, to match pre-assignments in a customer spec. However I
would never recommend manually editing or deleting the pxl.state file,
or any other packager file. I have seen many problems when you do
this. Sticking to a few simple do's and don'ts, I have never had any
major reassignment problems using soft locations, selecting
'preserve' and just letting the packager do it's own thing. If you
select 'repackage' then of course it;s going to re-assign everything,
but you just have to remember never to do that - it's not rocket
sceince. If you need certain gates bundled together in one package
then you need to anticpate this and add a unique GROUP property to
those gates before you package. Or you can add the GROUP property to
hierarchical blocks if you don't want to split gates across blocks. If
you forget a group and the design packages incorrectly then it's a
pain but I always temporarily set the incorrect gate to a hard
location to fix it, then after checking it has packaged OK, change it
back to a soft location. Not only do hard locations not work for
hierarchy like Bill said, but who wants to keep track of what the
latest highest number of resistor, capacitor, etc is, so you can add
one to it for each new ref des? OK, you can let the packager assign
new soft locations for new additions, but I have seen problems with
such hard and soft location mixes of the same ref des prefix, and you
also have to go back and change them all to hard locations every time
if you are sticking to your 'all hard' rule. It's all extra work that
you don't need to do. I have to admit though that occasionally I have
had to remove the opf (binary) directory to fix a problem, but this is
far safer than messing with the packager text files in my opinion.
One other very important rule to remember is, to change a part type
(other than a simple part table 'modify' change) but keep it's ref
des, NEVER delete the part then add the new one. ALWAYS use the
'replace' command, or the new global component change tool. This is
because the PATH variable, unique to each part, is what is linked to
the packager state file. If you delete the part then you have lost
that PATH variable and so that link to the state file. Using 'replace'
or global component change keeps the same PATH variable and so
maintains the link.
Mark,
To answer some of your specific questions:
2. If you copy an existing part with a $LOCATION, even using 'copy
all' so that the ref des value is copied also, then thae new part ref
des will change, not the old, because the old part will have an entry
in the packager state file.
3. Yes you can copy a hard location part and turn the copy to a soft
location - one way is to select and edit the attributes of the copy.
You can add a $ sign in front of LOCATION to change it to $LOCATION.
Take care though if you also want to change the $LOCATION value to
'?'. You need to change this first, because then you will notice that,
if the property is $LOCATION, then it changes to LOCATION, i.e. the
package thinks you have just assigned a hard location of '?' (and this
would show up in your BOM). So then after you change the value to '?'
you should edit the LOCATION property to add the $.
I have writen too much also. I hope all this helps!
Chris
Bill O'Leary wrote:
Mark,
I have always used soft locations ($LOCATION) for my designs. I have
had problems like you say in the past, until I discovered
The STATE_WINS_OVER_DESIGN setting in the packager XL setup. This is
not the default setting, but I have found that it works wonders
keeping a design in sync. The main reason you shouldn't hard-locate
things... it doesn't work with a hierarchical design!
When you use this setting, all reference designators are captured in
the pxl.state file in each worklib/block/packaged directory that you
package (if you use Sub-Designs, you will have multiple pxl.state
files, one for each hierarchical block that you use as a sub_design)
The state file keeps track of each reference designator in the design
according to block/instance/page... (This is the reason you have to
replace a part in a design instead of deleting it and putting in a new
part. If the instance number changes, the packager thinks it has a
license to start renumbering from scratch... (if you delete an h-block
and put a new one in, It will renumber every part under that block!)
The beauty is that pxl.state is an ascii text file (not like the
binary OPF file) so if something goes wrong, you can go in and fix
it. I have often had problems of putting down a multisection part and
the packager decides it needs to make 2 parts out of it.... I just fix
that by hand fixing the ref-des for the instance that the packager
tool named wrong in the state file, and then re-packaging. You can
even "pseudo Hard Locate" just by editing the pxl.state file.
The tool also makes a copy of the last pxl.state file for you, so you
can always revert the design
I have also taken to skipping the use of the OPF (Occurrence Property
File) file by moving the OPF directory to OPF_1 before packaging. The
OPF exists to let you change things in each instance of a hierarchical
block (so you could hard-locate a ref des in the first instance of the
block and then set a different hard location in another instance) .
You would do this by editing the schematic in occurrence mode. I
don't believe in doing this, It is hard to track what you've done (the
OPF is a binary file), and it gets away from the reason you did the
design hierarchically in the first place.
The OPF has caused the weirdest packaging anomalies I have ever seen.
(One instance was a design where I had 9 identical hierarchical blocks
with one SDRAM (built out of 3 asymmetrical symbols) For some
un-known reason, the packager decided it could scramble ref
designators within the h-blocks so when all 3 sections in block one
should have been named U1, one section ended up as U1, the next was
U3 and the third was U9) (this happened right before we were ready to
ship the board!)
Cadence would not recommend this method, but it is the only way I have
ever found to workaround the strange packaging problems that arise for
seemingly no reason.
If this sounds very scary, It really isn't too bad. I standardized my
last company on using this method, and we were always able to get out
of trouble when packaging problems arose. (Cadence never could help us
fix them). My last design was 7 levels of hierarchy deep, and was
over 500 pages when expanded. I was able to fix countless packaging
problems because I could fix things in the pxl.state file. When I
have gotten away from this method I have gotten in trouble.
Sorry if I talked your ear off,
Good Luck,
Bill O'Leary
------------------------------------------------------------------------
From: icu-pcb-forum-bounce@xxxxxxxxxxxxx
<mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx>
[mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx] On Behalf Of Mark Salberg
Sent: Thursday, April 13, 2006 11:54 AM
To: Cadence User Group
Subject: [PCB_FORUM] Soft Located Ref Des vs Hard Located
Hello all,
If we move over to using $LOCATION / soft located ref des across a
schematic, will my ref des's change indisciminantly?
I would appreciate any feedback that would help me move to this with
confidence.
1. If I use "preserve packaging, will it retain all original ref des
and only update new part ref des?
In the past I have seen some parts get reassigned, changing ref des in
layout.
<>2. If all are $LOCATION and I add a new part with "? location" or
copy an existing symbol to same ref des but $LOCATION which one will
change, the original or copied part.
3. If you copy a hard located part (connector) can you soft locate it
and add ? value so it will package?
My concern is...IS IT SAFE TO USE $LOCATION WITH NO DANGER OF PARTS IN
ALLEGRO CHANGING REF DES THAT ARE ALREADY PLACED / ROUTED?
Also, if someone selects re-package by mistake, will it change any
original ref des? I have seen this in the past.
Thanks in advance,
Mark
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by
MessageLabs. For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by
MessageLabs. For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs. For
more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
Other related posts:
