Home > Community > Blogs > PCB Design > what s good about retaining electrical constraints look to spb16 5 and see
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the PCB Design blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

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

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

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

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.