Updating ICD Rules

If an ICD definition has changed within Capital Device Modeler these changes require propagating into Capital Logic Designer. However, a number of scenarios may exist that require consideration when a refresh or update action is run.

Capital follows a number of rules depending on the nature of the update; be it a change to connectivity, a switching of signals or multicore, backshell, or device side connectors updates. Design rule checks (DRCs) ensure that any inconsistencies are captured and can be resolved.

When updating ICDs the system considers the following:

• The update action checks the signals on each pin and deletes the wire if the pin signal does not match the connected conductor. This instance will be reported by a DRC.

• Any connections that are not described in the original Capital Device Modeler ICD definition are retained.

You can automatically generate conductors based on the signals defined in the ICD if the project preference “Generate conductors on ICD pins” is selected, even if the signals have no connected endpoints. See Automatic Generation of Conductors.

The following sub-sections describe the methodology Capital applies in handling updates and also certain example cases that require particular consideration if encountered.

Tip

If you are changing connectivity on ICDs manually, Siemens recommends that you create new conductors rather than using those created within Capital Device Modeler.

Rules Followed When Updating ICD Connectivity

When the Update From ICD action is run, the system checks if a signal is defined between a source pin and destination pin, and then calculates the following:

1. Determines if there is a path from source pin to destination pin.

2. If a path exists the system updates all the conductors on the path as follows: For each conductor on the path, if it is not referring to the correct ICD signal according to the Capital Device Modeler definition, it carries out the following: For wires, it updates the properties on the wire with those of the signal.

For nets, it creates a new net with its name equivalent to the signal name, and makes the schematic conductor on the path point to the new connectivity. This can result in old nets moving into the unplaced folder, if there was only one schematic conductor. Properties on the old net are deleted.

3. If no path exists, the system will attempt to establish the path. It does this by: Traversing from the destination pin to a new destination pin. or

Traversing from the source pin to a new source pin.

It then connects the new destination and new source pins.

When connecting these pins, it reuses any unconnected (dangling) conductors present on the new destination pin or new source pin.

4. Clean up of the connectivity is then carried out. The system: Deletes any ICD signals on the source pin that are not defined on the corresponding pin in Capital Device Modeler.

Deletes any ICD signals on the source pin that match the definition in Capital Device Modeler, but end on an incorrect ICD pin and do not have any other valid path.

Rules

Followed When Creating and Updating Conductors and Multicores

The system takes the following courses of action with regard to the creating and updating of conductors and multicores, including shared cables. These are differentiated between placing ICDs, adding pins and updating ICDs as follows:

When Placing an ICD or Adding Pins

1. All the existing multicores in the design or shared conductors / multicores in the project are considered when a signal is added into multicore. Priority for matching multicores is as follows: Multicores connected to the ICD being placed on the diagram.

Multicores connected to an ICD already placed.

Design multicores.

Matching shared signal in project.

Matching shared multicore in project.

2. If a match is not found, a new multicore is created for the signal.

3. Multicores are matched using a bottom up structure. In this scenario the matching innermost multicore is given priority irrespective of its parent structure.

When Updating an ICD Containing Conductors and Multicores

1. Any existing inner core conductor that does not match with its original Capital Device Modeler definition is first removed from its parent multicore.

2. All the existing multicores in the design or shared conductors / multicores in the project are considered when a signal is added into multicore. Priority for matching multicores is as follows: Multicores connected to the ICD being placed on the diagram.

Multicores connected to an ICD already placed. Updates from ICD match the structure and the inner core names on both ICDs between which the multicore is connected.

If the multicore inner cores and structure matches exactly for both ICDs, the process ignores any difference in multicore names and does not regenerate any multicores.

If the multicore structure or inner core names do not match exactly for both ICDs, the system regenerates the multicore.

Design multicores.

Matching shared signal in project.

Matching shared multicore in project.

3. If a match is not found, a new multicore is created for the signal.

4. Multicores are matched using a top-down structure. This means a matching outermost to innermost multicore is given priority.

Note

In instances where ICDs have signals, but no associated multicore definitions - these being added manually in Capital Logic Designer, the system will retain the manually added definition on the running of the Update From ICD action rather than replacing it with the partially complete ICD definition.

Limitations

on Shared Conductors and Multicores

The following limitations are applied when working with shared conductors and multicores:

1. A conductor is added into target shared multicore only if a lock is obtained on the shared conductor manager and the target shared multicore.

2. If more than one matching shared conductors or multicores are found when adding a conductor, it will not be added to any multicore. This is true even if matching shared multicores / signals are part of same shared revision hierarchy.

3. Update ICD A shared conductor will be updated or removed from parent multicore only if lock on it can be acquired.

A shared conductor will be updated or removed from parent multicore only if designs using this conductor are not being edited by other users.

If shared conductor is the base revision in the revision hierarchy, it will be updated only if all the child revisions of the shared conductor can be locked.

If shared conductor is the intermediate revision in the revision hierarchy, it will be updated only if all the immediate child revisions of the shared conductor can be locked.

Note

If a signal has three or more ICDs defined in Capital Device Modeler, placing a further ICD will create a dangling wire with new multicore, to avoid multicores terminating at more than two pinlists.

Additional

Rules and Limitations When Updating ICDs

The following rules are applied when updating ICDs:

1. Wiring abstraction - If a signal has three or more ICDs defined in ICD cables, placing a further ICD will create a dangling wire with a new multicore, to avoid multicores terminating at more than two pinlists.

2. Wiring abstraction

• If a signal corresponding to a dangling conductor has three or more ICDs defined in Capital Device Modeler, the Update From ICD action may not connect it to other end, if the ICD has any matching multicores that can potentially result in connecting the multicore to more than two pinlists. In the example below, WIRE1033 will not be connected to PIN16 as it should have been. However, WIRE1033 will be added to the multicore of WIRE1034 and WIRE1035.

The following limitations apply when updating ICDs:

1. When using Place ICD or Add Pin: A signal having two or more multicores with the same name in the cable hierarchy may not be added to the matching shared multicore. However, the update flow still updates a child multicore.

2. When updating an ICD: A conductor may be removed from an invalid multicore, but may not get added to existing multicores owing to the failure reasons of shared multicores / conductors described in this procedure.

3. The Update From ICD action cannot update conductors if they are distributed across multiple matching multicores originating from the same cable definition.

Parent Topic:

Updating ICDs

Capital Logic Designer User Guide, 2512

Unpublished work. © 2025 Siemens