• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. System, PCB, & Package Design
  3. What's Good About Retaining Electrical Constraints? Look…
Jerry GenPart
Jerry GenPart

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
CDNS - RequestDemo

Try Cadence Software for your next design!

Free Trials
PCB SI
PCB
PCB Layout and routing
IC Packaging and SiP Design
SI
ECSets
Allegro Design Entry
Constraint-driven PCB Design flow
diff pairs
Design Rule Checker
Routing
Signal Intregrity
DEHDL
Analog and RF SiP design
Digital SiP design
electrical constraints
SigXP UI
PCB Signal and power integrity
High Speed
APD
PCB power integrity
Allegro Design Workbench
Allegro 16.5
PCB Editor
Design Entry HDL
advanced package designer
ASA
Layout
Allegro System Architect (ASA)
Xnets
Front-end PCB design
design
PCB Signal integrity
Allegro PCB SI
PCB design
Design Entry
SPB16.5
Allegro PCB Editor
differential pairs
SI analysis and modeling
Differential Pair Support
ConceptHDL
Schematic
Allegro

What's Good About Retaining Electrical Constraints? Look to SPB16.5 and See!

8 Aug 2011 • 8 minute read

Currently, many of the SPB products support extended nets, better known as Xnets. Xnets are created automatically when a signal model is assigned to a component and that signal model defines that a connection is to be made between two pins of the component. This creates an Xnet that connects the nets that are assigned to these two pins.

When an Xnet is created, all of the electrical constraints on the nets that form the Xnet are moved from the nets to the Xnet. This process is usually referred to as "bubbling the constraints up to the Xnet." If the same electrical constraint exists on more than one of the nets in the Xnet, then rules have been developed that define how these constraints are to be combined to form the single constraint that will be added to the Xnet.

The effect of this constraint bubbling process is that these constraints will now be checked at the Xnet level rather than the net level. For example, assume that a net has a Total Etch Length constraint of 500 mils. This constraint will be checked by totaling the length of all the clines in that net. Once this net becomes a member of an Xnet, this constraint is moved from the net to its owner Xnet, and the constraint will now be checked by totaling the length of all the clines in each of the nets in this Xnet. Changing or deleting a signal model that is assigned to a component can also cause an existing Xnet to be destroyed. In this case the electrical constraints assigned to the Xnet being destroyed are moved to each of the nets in the Xnet.

In 16.5, you can retain electrical constraints at the net level. This feature lets you optionally disable the process of moving electrical constraints from member nets to the owner Xnets when an Xnet is created and destroyed. You can control when to check a constraint at the net level or at the Xnet level. In essence, this feature helps you decide whether an electrical constraint continues to reside on the net or be moved to the Xnet it is assigned to.


Read on for more details …


A new option known as Retain Electrical Constraints at Net Level has been created. You will be able to define this option from any product that has the ability to create or destroy Xnets. This option controls whether electrical constraints are to be automatically moved between nets and Xnets as Xnets are created and destroyed.


How to Retain Electrical Constraints at the Net Level


The option to retain electrical constraints at the net level is disabled, by default, which means that the constraints are moved to the nets comprising the Xnet. You can opt to retain electrical constraints at net level using one of the following two methods:
•    Setting CPM Directive
•    Defining Allegro Environment Variable

Setting the CPM Directive

In the START_CONSTRAINT_MGR section of the .cpm file, add the following directive:

RETAIN_ELECTRICAL_CONSTRAINTS_ON_NETS 'YES'

This indicates that the options is turned on. A value of NO, or the absence of this directive, in the .cpm file indicates that the option is turned off.
Note: This value will be applicable to any new logic design created using Allegro Design Entry HDL or System Connectivity Manager. It will also be applicable to any new board design where the editor has been started with the -proj command line option that defines a .cpm file.

Defining Allegro Environment Variable

You can set the retain_electrical_constraints_on_nets environment variable in your local env file. The presence of this variable indicates that the option is turned on; the absence of the variable indicates that the option is turned off.

Note: This will only affect new designs created by a back-end tool.

WARNING: The option is set when the design is created. You cannot change the option after that.

When starting a new logic design, only the CPM directive is checked. When starting a new board design, first the CPM directive is checked. If it is not found, the Allegro environment variable is checked. If none of these options is found, the option is assumed to be off.
 
Without the retain electrical constraints at net level option:



 
 
With the retain electrical constraints at net level option:



Electrical Constraints on Nets and Xnets


In general, electrical constraints can have different values for the constraint on both a net and its owner Xnet. Each constraint is checked separately and DRC errors can be generated for each. The following section describes the exceptions to this rule:

Pin-Pair Constraints

The user-defined pin-pair constraints, which define specific pins of the net or Xnet, are not affected by the new option. The constraint continues to be owned by the object to which the pin-pair belongs. However, the auto-generated pin pair constraints, such as AD:AR and L:S are impacted by the option. These constraints are expanded on the fly when the constraint is checked. The pin-pairs that are selected depend on the object to which the constraint is applied. For example, an L:S constraint on a net selects the longest and the shortest pin-pair in that net. If the same constraint is on the Xnet that owns this net, the longest and shortest pin pair across the entire Xnet is selected.

Schedule/Stub Length

The Xnet constraints are ignored if the member nets of the Xnet are constrained.

Impedance

Explicit impedance constraints on pin-pairs follow the rules described above. Constraints captured on Xnets are ignored if the member nets of the Xnet are constrained.

ECSet Assignment

Similar to electrical constraints, ECSet assignment is also moved between member nets and the owner Xnet. If the Retain Electrical Constraints at Net Level option is on, these assignments are not moved. You can assign separate ECSets for a net and its owner Xnet. If both ECSets contain topology data, the net is scheduled based on the topology data in the ECSet that is assigned to the net. Any net in the Xnet that does not have an ECSet assignment is scheduled based on the topology in the ECSet assigned to the owner Xnet. The rules for the pin scheduling based on an ECSet topology do not change.

Note: Any constraints in an ECSet assigned to a net only apply to the net. The constraints in the ECSet assigned to the owner Xnet only apply to the Xnet.

Note: This new option has no impact on the members of differential pairs and buses. If a net that is a member of a differential pair or bus becomes part of an Xnet, the Xnet always becomes a member of the differential pair or the bus.


Constraint Manager Behavior


In Constraint Manager, if an electrical constraint is added to a net that is a member of an Xnet, the constraint is automatically moved to the Xnet:


 

If the Retain Electrical Constraints at Net Level is turned on, the constraint remains on the member net:



By default, nets are not displayed as children of their Xnets in the electrical worksheets:



 

If the Retain Electrical Constraints at Net Level is enabled, nets are displayed as children of their Xnet, by default. You can change this behavior from the Constraint Manager Filter dialog:



 

If the Retain Electrical Constraints at Net Level is enabled, an ECSet applied to an Xnet is not inherited by its member nets:




Important:
When exporting a DCF, the Retain Electrical Constraints at Net Level option is written to the DCF file. The option is not written to any other file including technology, actuals, and worksheet. When importing a DCF, the option is compared to the setting in the current design. If the option in the DCF does not match the setting in the design, the Import will generate an error and not continue.

Front-to-Back Flow

The new option is only processed in the front-to-back (F2B) flow for new designs. When a board is created with the -proj command line option, the new board is created with the Retain Electrical Constraints at Net Level option as defined in the CPM file. Similarly, if the corresponding environment variable is specified, it is processed for the new design. If the option differs between front end and back end for an existing design, the F2B flow fails. You need to update either the FE or BE before you re-run the F2B flow.

Back-to-Front Flow

The new option will not be processed in the back-to-front (B2F) flow. If the option differs between front end and back end for an existing design, the B2F flow fails. You need to update either the FE or BE before you re-run the B2F flow.


Show Element Command in PCB Editor


The Show Element command that is available in all of the Allegro-based editors lists the electrical constraints that are assigned to a net being displayed. With the Retain Electrical Constraints at Net Level option on, if the net is a member of an Xnet both the net level constraints and the Xnet level constraints are listed:


 

 
Diff Pairs


It should be noted that this new option will have no effect on the creation of diff pairs. If a net that is a member of a diff pair becomes part of an Xnet, then the Xnet will always become the diff pair member. A net will never be a member of a diff pair and also a member of an Xnet. The Xnet will always be the diff pair member.

 As always - I would like to hear your experience with this new 16.5 capability.

 Jerry "GenPart" Grzenia


CDNS - RequestDemo

Have a question? Need more information?

Contact Us

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information