Maintaining REFDES association of parts grouping (cluster) when back annotating after renumbering (resequencing)

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

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 ?

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.

Ted,

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).

Well........

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.

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.

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     
         End If    
     Next aComp

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:

*PADS-ECO-V9.2-MILS*

*RENPART*
C9 _C9
*END*

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
    Print #1, ECO_RenPart
    Print #1, "C9 _C9"
    Print #1, ECO_END
    Close #1
    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

_C3  C9

This avoids ever having two C9's

ted_casper wrote:

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 ?

Jim,

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.

Bob:

  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.

Thank you,

George