If the association really matters, then that is usually managed at placement time ?.
If the caps are all in parallel, then association is only cosmetic, and many designs
simply use a separate page for decoupling caps (avoids any implied association)
I have (rarely) seen a special decoupling prefix, where CD1 decouples IC1 and CD9 decouples IC9 etc,
which is another way to manage association, and is also removes the Power caps, from others. C1..Cn
Thank you for the suggestions. In our case, we use the schematic association during the EE review process in checking for adequate bypass and understanding what type of capacitor(s) is associated with a certain I.C. We do handle the groupings during initial layout but are forced (by our internal standard) to renumber any components that get moved to the bottom side of the board. When we back annotate, the associations get lost.
It is also not uncommon for us to reuse sections of schematics and board layouts for future designs. In this case also, renumbering is desired.
I was hoping there was some way to force the groupings to remain via a property like "CLUSTER". Not a new problem but I was hoping the new tools offered a solution.
It would be quite cumbersome to enter & control this via any rules/cluster.
However, I see you mention this
"renumber any components that get moved to the bottom side"
At this point, you could create a script that did the rename rule, and kept the sub-string ?
Jim, Thank you. Should I also pose this question on the DxDesgner community since my schematic tool is DxDesgner not PADS logic?
You could, but I don't think it's a SCH end problem, as you say
"We do handle the groupings during initial layout but are forced (by our internal standard) to renumber any components that get moved to the bottom side of the board."
- but you also want some decoupled part association as well ?
So I'm guessing that means you rename U6,C6 pair, as U6,CB6, or C6B, or C6_ or whatever name rules you use to tag as both associated with U6 and bottom placed.
If this is common (frequenty recurring), my solution would be a script in PADS Layout, that applies BOTH rename rules, that you run as a post-design check/cleanup. Then, eco that back to SCH and it will rename the caps, with the bottom-tag you use.
This is interesting as we have a similar issue in our company. Our requirement is that when the design goes to the first production release, all reference designators must be re-sequenced to remove gaps and reflect page order. Like you, we must forward-annotate these into the layout. Up until now, we have had to deal with the shared-net components by manualy changing them before bringing the netlist in. I am currently working on a script that works in conjuction with a DxDesigner script that handels the re-sequencing on that end. I found that script in the DxDesigner group section, but it needed modifying to work correctly with PADS. It also required further mods by a Mentor AE to correct a problem with a file that it outputs that is the key to the PADS script I'm writing. This file is a listing of the original refdes' and the new values, exactly the info needed to be processed. When I finish writing and testing the script, I'd be happy to post both our script and the modified DxDesigner script here. My script may need some minor mods to work in your environment, as in one area of the code I've hard-coded our schematic drive to look for the last opened project (this is only if DxDesigner is not currently open).
It turns out that after all the work writing the portions of the script that find the file with the changes, and then creates an intermediate file to hold temporary values, I found out that the most important property/method doesn't exist: the ability to actually CHANGE the reference designator through a script. For whatever reason, Mentor has chosen to not allow a set for the value. I plan on asking for such a feature on this site, but for now, you can't get there from here.
Bob, I would like to see your scripts when completed. Are you comfortable attaching them here or would you like my e-mail? Regards, Ted
You must have been posting just as I was replying to my last message. As I related in that post, it turns out changing the name (refdes) of a component is not availabe to the automation model, a fact I just had confirmed today by a Mentor AE. Sorry to get your hopes up, I know mine are fairly dashed right now. We're back to re-evaluating our requirements vs the time it takes to make the changes manually.
What were the chances we hit send at the same time! I appreciate you letting me know what you have found. Question: If you know the required changes through your script, could the information be manually loaded into a forward annotation ECO file? The idea being to run a forward annotation from the DxDesigner Link in PADS but select to view the ECO file before execution. Copy the changes into the appropriate section of the ECO file, then finish the forward annotation. Thoughts?
bob.hart wrote:it turns out changing the name (refdes) of a component is not availabe to the automation model, a fact I just had confirmed today by a Mentor AE. Sorry to get your hopes up, I know mine are fairly dashed right now.
PADS Logic allows this, from a script we have that prefixes all R1,C1 with _R1, _C1, prior to renaming them again.
(scripts and ecos will stall if you have two the same )
For Each aComp In aSheet.Components
cCount = cCount +1
If (Left(aComp.Name,1) <> TmpPfx ) Then 'Avoid multiple _
aComp.Name = TmpPfx + aComp.Name
If you have cases where the Script cannot reach or access all entities (which does happen, as Scripts are primarily Read-Focused),
then an alternative pathway, is to have the script create/write a simple ECO file, and then import this. (I think this was what Ted was meaning?)
Simple ECO file example:
and it can be created/imported (In PADS Logic Script) this way:
Const ECO_Header = "*PADS-ECO-V9.2-MILS*"
Const ECO_END = "*End*"
Const ECO_RenPart = "*RENPART*"
Open report For Output As #1
Print #1, ECO_Header
Print #1, ECO_RenPart
Print #1, "C9 _C9"
Print #1, ECO_END
Document.ImportECO(report) ' Apply the renames
DxD scripts will be slightly different, but this should give you a starting point.
I would expect that a two hop process would be needed, viz
C1 to _C1...C9 to _C9 etc
then apply your ECO OldName New name
This avoids ever having two C9's
We do handle the groupings during initial layout but are forced (by our internal standard) to renumber any components that get moved to the bottom side of the board. When we back annotate, the associations get lost
Ted, did you find a solution to this in the end ?
You could use attributes, if you wanted to maintain pairing associations with a Part(master) and Cap(slave), and a script
could force a rename, not based on the usual ECO net-checks, but on that pairing association ?
Thanks for the info and ideas. Our flow is actually DxDesigner to PADS Layout, with the problem being in Layout. However, your suggestion about the ECO file looks like it could be the solution, and coincidentally, was also suggested by someone commenting on my Bright Ideas request for the Set capability in Layout scripting. I'll add this to the script I've been working on and try it that way.
If you have a working model of the script that needs tuning, please send it to me along with your desription of what you need it to do. Use an SR to get it to me and I'll pass it along to Engineering to see if they can help. I know the objects are not publicly published, so you will need help.