Rules and Constraints

Standard Constraints for Capital Systems Integrator

Standard constraint templates are available for use in rules in Capital Systems Integrator. You can apply the rules or individual constraints to objects to control how the system performs various actions.

The constraints are:

Attributes and Properties

Length change for Jumper Allows you to automatically set the Length Change Type and Length Change Value attributes for jumper wires (which are generated by wiring synthesis and are given a length of 0.0 by default). You can apply the constraint to a connector, a hole, a slot or a design. Length change Type = Value for jumper of signal matching Name = .* Specify the following: Type Specify a Length Change Type of either: Absolute The Length attribute of jumper wires is set to value of the Length Change Value attribute.

Offset The Length attribute of jumper wires is set to the calculated graphical length plus the value of the Length Change Value attribute.

Value Specify the value for the Length Change Value attribute. This can be positive or negative.

Name = .* Specify an attribute or property name for a signal and a value for it (you can use wildcards). The constraint applies only to jumper wires carrying signals matching this condition. This value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

For example: Length change Absolute = 5.0 for jumper of signal matching Name = COND.* In this example, the Length attribute is set to 5.0 for any jumper wires carrying signals with a Name attribute value that starts COND. Length change Offset = 4.0 for jumper of signal matching Name = COND.* In this example, the Length attribute is set to the calculated graphical length plus 4.0 for any jumper wires carrying signals with a Name attribute value that starts COND.

Length change for Wire Allows you to automatically set the Length Change Type and Length Change Value attributes for wires. This is useful for increasing wire length in the case of u-turn wires. You can apply the constraint to a bundle region, a bundle, a harness or a design. Length change Type = Value for wire of signal matching Name = .* Specify the following: Type Specify a Length Change Type of either: Absolute The Length attribute of wires is set to value of the Length Change Value attribute.

Offset The Length attribute of wires is set to the calculated graphical length plus the value of the Length Change Value attribute.

Value Specify the value for the Length Change Value attribute. This can be positive or negative.

Name = .* Specify an attribute or property name for a signal and a value for it (you can use wildcards). The constraint applies only to wires carrying signals matching this condition. This value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

For example: Length change Absolute = 5.0 for wire of signal matching Name = COND.* In this example, the Length attribute is set to 5.0 for any wires carrying signals with a Name attribute value that starts COND. Length change Offset = 4.0 for wire of signal matching Name = COND.* In this example, the Length attribute is set to the calculated graphical length plus 4.0 for any wires carrying signals with a Name attribute value that starts COND.

Multicore Specification Allows you to specify that a topological multicore should have an attribute or property with a fixed value or a value derived from an attribute or property of the functional multicore from which the topological multicore is being routed. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. This is used when you want to use rules to add properties and attributes to multicores. See Rules to Add Properties and Attributes to Wires, Splices and Multicores During Wiring Synthesis.
Set Integrator/Topology Attribute/Property on Object Allows you to specify that a property or attribute must have a particular value on objects of a particular type when they have another property or attribute with a particular value. The property/attribute and value are assigned to the object when you run the Apply Constraints action in Capital Systems Integrator. You can run the Violated attribute/property rule design rule check to check for objects that violate this constraint.
Splice Specification Allows you to specify that a splice should have an attribute or property with a fixed value or a value derived from an attribute or property of the signal from which the splice is being routed. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. This is used when you want to use rules to add properties and attributes to splices. See Rules to Add Properties and Attributes to Wires, Splices and Multicores During Wiring Synthesis.
Terminal Type Specification Default: Terminal Spec: Terminal Material Spec is where signal matches Name = .* Allows you to specify the terminal material that a terminal must have for a particular signal. You can add this to a cavity, a slot connector, a slot, or a design. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Wire Specification Allows you to specify that a wire should have an attribute or property with a fixed value or a value derived from an attribute or property of the signal from which the wire is being routed. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. This is used when you want to use rules to add properties and attributes to wires. See Rules to Add Properties and Attributes to Wires, Splices and Multicores During Wiring Synthesis.

Placement

Assign Connector by Attribute/Property This is used when you place devices with footprints in slots. It allows you to control whether a device connector with a particular value for an attribute or property is mapped to a slot connector with an attribute or property that has the same value. If you change the connector group for a subset of pins in an existing group, those pins are mapped to a different connector by the Synchronize Logical Changes action.

If you change the connector groups for all of the pins, the Synchronize Logical Changes action will not change the connector mapping.

Note This constraint can be useful when performing a variant placement of a device in single slot. That is, when you want to place a device in one slot multiple times using option expressions. This enables you to map harness connectors from footprints to slot connectors. See Variant Placement of a Device for general concept information and an example.

Assign Footprint to Device Default: Assign part library part and footprint where slot device Name = .* Allows you to specify the library part that is assigned to a device (with a particular property or attribute value) when that device is placed in the slot. It also allows you to specify which footprint from that library part is used. For example: Assign part device01 and footprint fp02 where slot device Name = dev01 In this example, when a device with the name dev01 is placed in a slot with this constraint applied, the library part device01 is assigned to that device and the footprint fp02 from that library part definition is used. You can set this for a design or an individual slot. Note This constraint can be used when performing a variant placement of a device in single slot. That is, when you want to place a device in one slot multiple times using option expressions. This enables the device to have a different footprint depending on the configuration. See Variant Placement of a Device for general concept information and an example.

The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. Note You can define a custom constraint in Java that also defines the pin mapping when the part is assigned to the device. This custom constraint assigns the pin mapping directly without the need to define device part numbers and footprints in Capital Component Manager. For more information about writing and loading custom constraints, see the PluginDevelopment.pdf document that is located in the doc\plugin folder of your installation.

Map To Same Cavity by Signal Attribute/Property By default, each instance of a signal and the pin for that instance are mapped to different connector cavities when a device is placed in a slot. This constraint allows you to specify that multiple instances of a signal and the pins for those instances are mapped to the same connector cavity. This constraint is applied again if a re-mapping occurs. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Move splice into slot Default: Do move splices into slot where splice attribute/property matches Name = Slot Name This is used when you move splices to slots (see Moving Splices to Slots Automatically). It allows you to specify whether splices with a particular attribute or property value should or cannot be moved to a slot. For example: The default definition will move any splices with names that match a slot name. If a splice does not have a name that matches a slot name, it will not be moved to a slot. The Slot Name value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. You can set this for a design or an individual slot. Note You can write your own custom “Move splice into slot” constraints, and load them into Capital Systems Integrator. In addition, you can write custom “Assign footprint to device” constraints for the mapping of splices when they are placed in slots. For more information about writing and loading custom constraints, see the PluginDevelopment.pdf document that is located in the doc\plugin folder of your Capital installation. Move splice into slot - controls which slot each splice is moved into. Assign footprint to device - controls the mapping of the splice to specific connector cavities. The constraint must implement IXFootprintConstraint.
Option place by Attribute/Property Allows you to specify whether objects with a particular property or attribute should or cannot be placed conditionally with an option expression in a slot. This enables the automatic variant-based placement of an object in multiple slots. During the automatic placement of devices, a device is placed in any slots where it matches this constraint and the option expression from this constraint is applied to the placed device. Note This constraint can be used when performing a variant placement of a device in multiple slots or in a single slot. See Variant Placement of a Device for general concept information and examples.
```
                      The option expression can have a maximum of 255 characters.
```

The Slot Name value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. The Slot that breaks placement rules design rule check identifies conflicts between this constraint and the Place by Attribute/Property constraint and identifies any placed object whose option expression does not match the option expression from this constraint. The check does not validate the option expression and it does not check for variant placements that result in an object being active in multiple slots at the same time.

Place by Attribute/Property Allows you to specify whether objects with a particular property or attribute should or cannot be placed in a slot. The system obeys this rule when automatically placing objects. By default, any slot has the following constraint: Do place devices with property matching Object Name = Ruled Object Name You can edit or remove this constraint. The Slot Name value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

Ground

Refinement

Ground Device Combination This is relevant only to ground devices in ground slots. It allows you to specify whether ground devices with the same value for a particular property or attribute (either on the devices or on connected signals) are to be combined when the Auto-Refine All Grounds or Auto-Refine Grounds operation is performed. See Combining Ground Devices in Selected Ground Slots or Combining Ground Devices in All Ground Slots. You can set this for a design or an individual ground slot.
Max Ground Slot Connector Cavities This is relevant only to ground slots and the combining of ground devices. It allows you to specify the maximum number of cavities that you can add to a slot connector during the combining of ground devices. You can set this for a design or an individual ground slot. When the system has added the maximum number of cavities to a slot connector, it generates a new slot connector. Note that external bundle connections do not alter and you need to make the proper harness connections to the new slot connector. If the maximum number of cavities is set to 1, each ground signal has its own slot connector with one cavity.
Max multitermed Ground Signals This is relevant to the combining of ground devices (see Combining Ground Devices in All Ground Slots). It allows you to specify the maximum number of ground signals that you can map to the same cavity in a ground slot. Any cavities that reach or exceed this maximum do not allow more signals to be added to the multiple termination at them during the combining of ground devices.
Multiterm Ground Devices This is relevant to the combining of ground devices (see Combining Ground Devices in All Ground Slots). It allows you to specify whether signals of ground devices, that you have placed in the same ground slot and have mapped to the same harness, form a multiple termination so that they use the same connector cavity.

Routing

Backshell Termination by Attribute/Property Allows you to specify whether a signal with a particular property or attribute terminates at a backshell or at a slot connector pin. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Combine Physical Multicores Default: Do combine physical multicores for Combined multicore matching Name = .* You can set this on connectors, slots, or the design. Allows you to specify that wiring synthesis automatically combines physical multicores that belong to the same combined logical multicore when wiring synthesis is run with the “Combine Wires/Multicores” option selected. For a full description of this functionality with example constraints, see Automatic Combination of Physical Multicores During Wiring Synthesis. Specify the following: Do / Don’t Specifies whether physical multicores should be combined.

Combined / Logical Combined The constraint matches against a combined logical multicore.

Logical The constraint matches against a set of logical multicores that match the constraint and are part of the same combined logical multicore.

multicore Name = .* Specify an attribute/property and value combination to identify the multicores that this constraint matches against. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

					Note 
						You can run a ‘Physical multicore that breaks combination rule’
							design rule check to identify physical multicores that break any
							“Combine physical multicores” constraint. The check also reports
							where a physical multicore cannot be validated because of
							conflicting constraints.

Combine Wires at Cavity Default: Do combine Wires At Splice of signals Name = .* where cavity matches Name = .* You can set this on connectors, slots or the design. Allows you to specify that wires carrying particular signals should be combined at particular cavities when the post wiring synthesis action “Combine Wires” runs. Specify the following: Do/Don’t Specifies whether wires at the specified cavities should be combined.

Wires/Wires At Splice Wires At Splice Specifies the system inserts a splice. The wires meet at the splice and a single combined wire goes from the splice to the cavity. For example, you might want to do this if you have three shields connecting to one cavity. Wires Specifies that the system does not insert a splice. The wires are replaced by one wire. You might want to do this where you can combine the wires one side of an inline connector but need to keep separate wires on the other side.

signals Name = .* Specify an attribute/property and value combination to identify the wires that combine.

cavity Name = .* Specify an attribute/property and value combination to identify the cavities at which wires carrying particular signals combine. If this combination does not match a cavity, the signals Name =.* values are ignored. That is, this setting dictates whether the constraint is applied.

For example: Do combine Wires At Splice of signals Name = scrn.* where cavity matches Name = SCR In this example, the system identifies cavities with a Name attribute SCR. At those cavities, it identifies wires carrying signals with a Name attribute value that starts scrn. It inserts a splice to which those wires connect. A single combined wire for those wires connects the splice to the cavity. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

Cost of multiterm Allows you to specify the cost of a multiterm. By default, the cost of a multiterm is 0. This constraint is compared with the Cost of splice constraint in order to identify whether a multiterm or a splice is generated by wiring synthesis. The cheaper option is generated. You can apply this constraint to a cavity, a connector, a slot, a hole or a design. You can set it so that it only applies if a particular signal runs along a route. Cost of multiterm = num for where Signal matches Name = .* Specify the following: num Specify a value to represent the cost of a multiterm. Note that this cost is added only once for each cavity that has more than one wire (from a particular signal) connected. The cost is not more if, for example, there are three wires rather than two.

Name = .* Specify an attribute or property name for a signal and a value for it (you can use wildcards). The constraint applies only to objects carrying signals matching this condition. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

Cost of splice Every bundle has a default cost of 0 for a splice. If you increase the value for a bundle, the less likely a splice is created on it during routing. You can set this so that it only applies if a wire with a particular signal is included in the splice. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Cost of wire per unit length Allows you to specify how expensive it is to route a wire along a bundle. The higher the cost for a bundle, the less likely a signal is routed along it. By default, a bundle has cost of 1 per unit length. When the system routes signals, it looks for the cheapest (and therefore shortest) route. If routing a signal along a particular bundle costs more (for example, if the wire requires extra shielding), you increase the cost per unit length. If an alternative route costs less per unit length and is not too much longer, the system selects the alternative route. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Cost per wire for Inline/Junction Box Every inline half and junction box has a default cost of 0 for a wire traversing it. If you increase the value for an inline half/junction box, the less likely a wire follows a route traversing it. This allows you, for example, to trade-off the cost of additional wires and connector cavities against the additional wire length of taking an alternative path. You can use the constraint to specify different costs for signals with a particular property or attribute and you can place it on an inline half or junction box itself, a harness or a design. Caution For inlines, the cost is checked for each inline half independently. This enables you to place a different cost on each half.

The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. This constraint causes the additional cost to be added to the signal wiring during synthesis. For an inline, the cost is added for each mated pin-pair that has wiring on both sides. For a junction box, the cost is added once and only if no internal devices connect to the signal. For example: If an inline has one or more wires connected to one half but not the other half, the cost is not added.

If an inline has one or more wires from the same signal connected to one half and one or more connected to the other half, the cost is added once for each mated pin-pair. This ensures, for example, that the system can consider the cost of moving a splice from one side of an inline to the other. For example:

If a junction box slot has one or more wires connected and those wires connect internally to a placed device, the cost is not added.

If a junction box slot has two or more wires connected and those wires connect internally to an internal splice (and not a placed device), the cost is added only once.

Create Bypass Wiring Default: Don’t create bypass wiring for Splice/Signal matching Name = .* When Composite Wiring Synthesis is run with the “Generate Bypass Wiring” option selected, if in any harness level a splice is connected to just two wires, the system replaces the splice and wires in that level with a single bypass wire (that has a read-write Bypass attribute). However, there are some situations where it is necessary to retain a two wire splice (for example, near to a connector where a larger CSA wire is required to fit the cavity and terminal). This constraint allows you to control whether the generation of a bypass wire is or is not allowed for a splice or a signal with a particular property or attribute. You can set it on a bundle region, a bundle, a harness or a design. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Daisy-chained network group Default = Set network group to group where Cavity matches Name = .* You can add this constraint to any object from a pin upwards (pin, connector, slot, design). You add it before running wiring synthesis. It specifies that a device pin or cavity matching a particular attribute value belongs to a particular network group. For example: Set network group to 1 where Device Pin matches Name = CAN1.*

Set network group to 2 where Device Pin matches Name = CAN2.*

Using these example constraints, wiring synthesis will recognize pins with names beginning CAN1 (such as CAN1H and CAN1L) as network group 1, and recognize pins with names beginning CAN2 (such as CAN2H and CAN2L) as network group 2. For further information about daisy-chained networks and network groups in wiring synthesis, see Daisy-chained Networks in Wiring Synthesis. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

Daisy-chained network specification Default = Daisy-chained network has max length = num where logical Multicore Name = .* You can set this for a design only (it does not work if applied to any other objects). You add it before running wiring synthesis. It allows you to specify that a particular multicore or signal should be synthesized as a daisy-chained network and also to specify the maximum network length. For example, you could specify that signals with Name attributes starting with CAN (such as CAN1 and CAN2) should be synthesized as a daisy-chained network with a maximum length of 10000.0: Daisy-chained network has max length = 10000.0 where logical Signal name = CAN.*. For further information about daisy-chained networks in wiring synthesis, see Daisy-chained Networks in Wiring Synthesis. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Generate center-strip Splices Allows you to specify whether butt splices should be converted to center strip splices when converting them automatically. This is determined by whether the signal passing through the splice has a property or attribute with a particular value. You can apply this constraint to a harness or an entire design. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. For information on running the automatic conversion, see Automatically Converting Butt Splices to Center Strip Splices.
Map To Inline Cavity by Signal Attribute/Property Allows you to control the cavity assignment when a signal is routed through an inline. The system can specify the signal and cavity by matching against their properties or attributes. You can apply this constraint to an inline half, harness or design. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. Note In considering each cavity as a potential match for a signal, the system first evaluates the cavities existing wiring, preferred signal, or constraint to determine if any of these would exclude the cavity as a match for the given signal. If they do, the cavity is discarded as a potential match. If they do not, and this results in multiple suitable cavities for the signal, the following priority hierarchy is applied to decide which cavity is used: preferred signal, Map To Inline Cavity by Signal Attribute/Property constraint, the first cavity in the list (when sorted alphabetically)
Max Wires per Multiterm Allows you to specify the maximum number of wires that can terminate at one cavity. You can apply this to any object that contains cavities (for example, a design, a connector, a cavity). If you specify a num value of 0, no wire can terminate at the cavities to which the rule applies. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. Note If Max Wires per Splice, Max Wires per Multiterm and other related rules are applied to a set of related objects, Capital Systems Integrator may not be able to synthesize all wiring. This is because some wires may not have a route to follow due to the combined restrictions from the rules.
```
                      The 'Allow MWS to multiterm different signals' project preference
                          controls the behavior of this constraint with regard to the creation
                          of multiterms from different signals that terminate at a single slot
                          connector, or at a hole that maps to a slot device. For a
                          description of the behavior of Modular Wiring Synthesis with and
                          without the preference selected, see "Project
```

Preferences for Capital Systems Integrator Designs" in the Capital Design Tools - Common Functions User Guide.

Composite Wiring Synthesis (CWS) and Modular Wiring Synthesis (MWS) apply this constraint differently. MWS routes each signal in isolation. Consequently, it respects this constraint but only in the context of one signal. For example: You have a ground slot connector ‘GND’ that maps to 3 non-exclusive signals: GND1, GND2, and GND 3. The connector has a constraint with a num value of 1. If you run Composite Wiring Synthesis (CWS), it routes only GND1.

If you run MWS, it routes GND1, GND2, and GND3. This is because it only applies the constraint in the context of each individual signal.

You can run the design rule check ‘Multiterm that breaks number of wires rule’ to check for the MWS scenario.

Max Wires per Splice Allows you to specify the maximum number of wires that can be in a splice. You can set this so that it only applies if a wire with a particular signal is included in the splice. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Maximum multicore takeout Default: Maximum multicore Wire takeout length = num where signal matches Name = .* Allows you to model the untwisting of a multicore before it ends at multiple distinct connectors (either on the same slot or different slots). You do this by specifying the maximum length of takeout (untwist) possible for the wires or shields of a multicore when the system synthesizes it. You can set this so that it only applies if particular signals are included in the multicore. You can apply this constraint to a bundle, harness, or diagram. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. Without the constraint added, the wires in the twisted multicore terminate at a two-wire splice, with the other wire going from the multicore to the connector cavity. The constraint compares the distance between the connector cavities and the splice at the end of the multicore and, provided the distance is less than or equal to the distance specified in the constraint, removes the splice so what is left are the wires coming from the untwisted multicore. If the distance between the terminating connector on the ‘untwisted end’ and the splice is greater than the distance specified in the constraint, the splice is not removed. This is true even if one or more of the other wires meets the condition of the constraint in respect to the distance between the splice and connector on the ‘untwisted end’. This can lead to a subset of wires in the multicore retaining the two-wire splice. Caution Even if the distance between the slot and the takeout on the bundle is less than or equal to the distance specified in the constraint, the constraint may not be applied. This can happen if splice separation constraints move the splice outside the specified distance. This could be as simple as minimum distance to a takeout, but could be caused by many splices being placed in that location. This may result in the constraint being applied on some splices but not others.

For example: The multicore in the figure below has an ‘untwisted end’ if the following constraint is applied: CopyMaximum multicore Wire takeout length = 5.0 where signal matches Name = .*Figure 102: Multicore Modeled with Untwisted End In the following case, you have used the “Termination of single ended wires/shields” constraint to create dangling wires for unused signals in the multicore. Therefore, this constraint is not evaluated as there are no 1:1 splices.

In the following case, you have not used the “Termination of single ended wires/shields” constraint to create dangling wires for unused signals in the multicore. Therefore, this constraint is used and if the length of D1 and D2 is less than the specified multicore takeout length, the splices are removed.

In the following case, a shielded multicore has a dangling shield but no dangling wires on the inner-cores. The shield is not evaluated for this constraint because it has no 1:1 splices. Note that this constraint has no effect on pigtail splices.

However, if the multicore has no dangling shield, the shield is evaluated by this constraint and the splice may be released. Note that the length evaluated against the constraint is the total of the shield and the pigtail wire.

Minimum Splice Separation Allows you to specify the minimum distance that there must be between a splice and a connector, splice or takeout. You can set this so that it only applies if a wire with a particular signal is included in the splice. If you specify a minimum separation from connectors or splices you also need to specify a minimum separation from takeout nodes. The two rules are intended to work in conjunction with one another. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Network Specification Default = Network specification has max length = num min stub length = num max stub length = num stub distance = num where logical Multicore Name =.* You can set this for a diagram only (it does not work if applied to any other objects). It allows you to control the routing of particular multicores or signals in a backbone network by specifying the following: max length The maximum length of the overall network.

min stub length The minimum length of a stub in the network.

max stub length The maximum length of a stub in the network.

min stub distance The minimum distance between stubs in the network

For example, for signals with Name attributes starting with CAN (such as CAN1 and CAN2), you could specify a maximum length of 10000.0, stubs of lengths between 2000.0 and 4000.0, and a minimum distance of 1000.0 between stubs: Network specification has max length = 10000.0 min stub length = 2000.0 max stub length = 4000.0 stub distance = 1000.0 where logical Signal Name = CAN.* The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. See Backbone Networks in Wiring Synthesis for further information about object attributes and constraints that you use to control backbone network synthesis.

Network termination Default: Do set cavity as IxO terminated where logical Multicore matches Name = .* Allows you to specify whether wiring synthesis sets logical pins as IxO Terminated or not. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. When wiring synthesis defines a network, it identifies logical device pins of the type IxO Terminated as the network start and end. This information may not be available in the associated logical designs so this constraint enables synthesis to set pins as IxO Terminated when a multicore or signal going to that pin has a particular property or attribute value. You can apply this constraint to a cavity, slot connector, interface connector, hole, slot or diagram. It cannot be applied to an inline or its cavities. When synthesis looks for IxO Terminated cavities, it: Firstly, uses this constraint and looks for a Do or Don’t

If no matching constraint is found, defaults to using the pin type from the associated logical design

See either Backbone Networks in Wiring Synthesis or Daisy-chained Networks in Wiring Synthesis for further information about object attributes and constraints that you use to control network synthesis.

Pigtail Usage by Attribute/Property Allows you to specify whether a shield signal (the shield termination of a shield multicore) with a particular property or attribute connects to a connector using a pigtail splice and wire or whether it connects directly into the connector. You can use this constraint on cavities, backshell terminations, or any object further up the rule hierarchy for these objects. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Prefer Route Default: Prefer route in configuration where signal matches Name = .* Allows you to to define a preferred route that a signal could use in a configuration during wiring synthesis. With this constraint applied (on a route), the route is considered as lower cost than alternate routes considered by synthesis. This constraint will only be evaluated for a signal if synthesis does consider the route containing the object on which the constraint is applied. Hence, using this constraint does not guarantee that the signal will be routed through the preferred route. You can apply the constraint to a bundle, connector, harness, junction box slot, or design. You edit the value to specify an option expression that defines the applicability of the constraint.
```
                  Note 
                      The option expression can have a maximum of 255 characters.
```

For further information and examples, see Prefer Route Constraint for Defining a Preferred Route for a Signal and Standard Constraints for Capital Systems Integrator. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

Protect Wiring by Attribute/Property Allows you to specify whether the wiring of signals with a particular property or attribute is protected from the following operations: Modular Wiring Synthesis

Composite wiring synthesis (when both Clear Promoted Options and Delete all Wiring, Harness Levels and Configurations are not selected)

Delete all wiring

Generate center-strip splices

Generate option expressions

Synthesize all wiring

Move Splices to Slots

Move All Splices to Slots

Does not protect wiring from batch wire length update and batch attribute assignment. This constraint applies separately for combined signals and their children. If the constraint matches a combined signal, it protects only wiring directly owned by the combined signal. If the constraint matches a child signal, it protects only wiring directly owned by the child signal. Protected signals are not reported as not routed or partly routed during synthesis operations. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. Signals whose wiring is protected by one of these constraints have a shield icon () in the Design Browser (Design tab) on the bottom left of the application window.

Route by Attribute/Property Allows you to specify whether signals with a particular property or attribute can or cannot be routed along a bundle, through a junction box, or through an inline pair. This constraint can apply to bundles, inline connectors, harnesses and designs. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.
Set multicore type Default: Retain multicore and set multicore type to existing where multicore matches Name = .* You can set this on a a harness or a design. Allows you to specify that wiring synthesis changes a multicore type, remove a multicore, or removes shielding from a multicore where a multicore matches a certain attribute or property value.
```
                  Caution 
                      You cannot use this constraint with combined logical multicores. It
                          works with functional-source multicores only.
```

For a full description of this functionality and example constraints, see Automatic Change of Multicore Type During Wiring Synthesis. Specify the following: Remove multicore / Remove shield / Retain multicore Select the action that you want wiring synthesis to take.

Existing / coax / oval / twist-commercial / twist-military / twist-z / none Specifies the multicore type to be applied to a multicore that matches this constraint. You select the multicore type from the dropdown list. If you have selected ‘Remove multicore’ at the start of the constraint, this value is ‘none’ and cannot be edited. If a multicore type needs to be restricted for a certain harness, you can select ‘existing’ as the multicore type so that the type is protected. ‘Existing’ takes the multicore type from the associated, logical design.

multicore matches Name = .* Specify an attribute/property and value combination to identify the multicores upon which wiring synthesis performs the specified action. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

Splice exclusive wires Default: Treat options Option List as not exclusive during synthesis in configuration Allows you to specify that exclusive options on a harness are not treated as exclusive during Modular Wiring Synthesis (MWS) and Composite Wiring Synthesis (CWS) for all or specific configurations. This constraint can apply to harnesses and designs.

Click the Option List value to display the Edit Options List Dialog Box where you select the exclusive options that you want included in the constraint. Click the value to specify the configurations in which you want synthesis to apply this constraint.

					Note 
						The option expression can have a maximum of 255 characters.

For examples of this constraint, see Splice Exclusive Wires. You can also use this constraint to give away negated options. See Option Expressions for Negated Options.

Terminate shield to pigtail near connector Default: Terminate shields matching Name = .* near Slot matching Name = Value Capital Systems Integrator is capable of synthesizing multicore shields, including connections through pigtail wires and single-ended shields using cut-end splices. In Capital Logic Designer, you specify that a shield terminates at one or more pins (on devices or grounds). However, Capital Systems Integrator does not know which end of the multicore should be connected to a shield termination point and arbitrarily chooses. This is often correct but can produce unintended results in some cases. For example: Figure 103: Single-ended Shield in Capital Logic Designer Figure 104: Synthesized Shield in Capital Systems Integrator - Desired Result Figure 105: Synthesized Shield in Capital Systems Integrator - Actual Result This constraint allows you to indicate the multicore end to which a particular single-ended shield termination must connect (normally with a pigtail wire). You can apply it to a slot, a connector on a slot, or a diagram. Typically, you would place it on the slot where the terminating device (that is, ground) is placed. For the example already mentioned, you would place it on the GND1 slot at the bottom: Terminate shields matching Name = SH1 near Slot matching Name = DEV1 Figure 106: Desired result You are specifying that the shield SH1 must terminate at the end of the multicore connecting to the slot called DEV1. Note You can change Slot to Connector and therefore specify that it must terminate near a particular connector on a slot.

The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses.

Termination of single ended wires/shields Default: Do terminate single ended Wire where Multicore matches Name = .* For cases where not all signals in a multicore connect to a device, this allows you to specify whether wiring synthesis creates dangling wires or shields that terminate on cut-end splices close to the device’s connector. You can set this so that it only applies for multicores with a particular attribute or property. You can apply this constraint to a device, a slot, a connector on a slot, or a diagram. If Do is selected, a wire (or shield) with a cut-end splice is created on any branch of the multicore where the signal does not connect to the device. If Don’t is selected and the signal does not connect to the device on a branch of the multicore, then no wire (or shield) is created but a two-wire splice exists at the splice between multicores. The value can be evaluated as either a regular expression, or an expression using wildcards, or as a string literal. See Selecting Evaluation Mode for Match Clauses. For example: You have the following logical connectivity:

The synthesized topological design may look like this:

In this example, there are seven physical multicores. All of them contain four wires except for the multicore connected to slot DEV5 (bottom right), which has only two wires. At the middle slot DEV4, you have applied this constraint with Do selected so a wire with a cut-end is created. At the slot DEV5, you have applied this constraint with Don’t selected so there are no cut ends and the wiring for the signals that do not go to this slot are spliced at the same point as the wiring of the signals that do. These splices have just two wires connecting to them (one from DEV2 and the other to the next splice along) as opposed to the signals that do go to DEV5 whose splices have three wires connected (one from DEV2, one from DEV5 and one from the next splice along).

Parent Topic:

Rules and Constraints