B
Troubleshooting Constraints
This appendix provides information and guidance on the recommended use of the constraints management system. Its aim is to provide assistance and support in any areas where you may encounter unexpected results or difficulties.
If your concern is not addressed here, you should contact your local Cadence representative.
The following troubleshooting areas are covered in this appendix:
See also:
Performance Issues
Opening the Constraint Manager is Slow Even When No Constraints Exist
This can occur because the constraints system looks for a config.xml file with constraint extensions in all directories in the Cadence search path (which includes the shell path).
A shorter path, or one that points to existing directories in the network, will reduce the lookup time considerably, therefore speeding up Constraint Manager opening time.
For more information on the Cadence search path, see
Running a Circuit Prospector Finder is Slow When There Are Many Results
The highlighting of finder results using the Circuit Prospector can impact the speed. For cellviews with many results, you can improve the speed by setting the environment variable to nil, which switches off the highlight feature.
Read-Only Issues
Closing Read-Only Schematic Does Not Ask for Constraints To Be Saved
When a read-only schematic window is closed, but not purged from memory, the Constraint Manager could also be closed even though it contains constraints that have not yet been saved. If this occurs you will be prompted to save any unsaved constraints upon exiting Virtuoso/CIW. Alternatively, you can save and close data ahead of exit by selecting File – Close Data from the CIW.
Constraints Shown as Read-Only When Schematic Is Opened in Write Mode
If a constraint view is read-only, or had previously been opened in read mode by another tool, the Constraint Manager reuses that data instead of forcing to re-open it in append mode. If this occurs, you can manually toggle the editing mode by selecting Make Editable / Read Only from the Save pull-down on Constraint Manager Toolbar.
Transfer and Migration Issues
Constraint Migration to Open Access (OA) Based Storage in IC612
When constraints are migrated to the new OA based storage system in IC612, the constraint view must be writable. If the view is not writable, errors will be produced by the OA design management layer.
How you approach this issue is largely dependent upon the importance of the constraints to be migrated:
- If the constraints are important you should make the constraint view writable to facilitate constraint migration.
-
If the constraints are not of great importance, or you are content to just maintain them for potential future IC611 use, you should MOVE the entire view into, for example, a
constraint_611directory. -
If you just want to save a copy of the constraints for potential future use in IC611, COPY the view into, for example, a
constraint_611directory and also make the original constraint view writable to facilitate a successful migration to IC612 and beyond.
Constraints in Layout
To transfer/update constraints in the Virtuoso Layout Suite XL, select Connectivity – Update – Layout Constraints. This will transfer all the relevant constraints to the layout view.
- All single occurrence constraints will have a matching layout constraint, and all mFactor and iterated instance transfers will also be performed.
- All multiple occurrence (cell) constraints will have a matching layout constraint for each of the occurrences.
Missing All Constraints For a Schematic
If you switch between an ADE XL configuration and a physical configuration, the specified constraint view lists may differ. If this is the case, you should ensure that the content and order of the constraint views, in the new list to be used, is identical so that the intended constraint view will be used.
For example, for a schematic that has both “constraints_1” and “constraints_2” views, the first view in the list will be used. However, if your configuration has “constraints_2 constraints_1” as the constraint view list, the “constraints_2” view would be used.
Constraint Conflict Issues
The constraint system identifies most common geometrical over-constraints; when a number of constraints share the same members. These over-constraints can cause conflicts in the design intent. Most constraint member and parameter inconsistencies are detected during constraint entry, when a consistency check is performed. It may however be beneficial to understand what potential inconsistencies can exist before entering constraints into a design, as it can help build a solid strategy when choosing an appropriate minimal constraint set.
Clusters
Clusters cannot have overlapping members. However, clusters can be hierarchical.
Modgen as Member of Other Constraints
In addition to existing as a constraint in its own right, a modgen can also be the member of the following constraint types:
Modgen and Cluster
A modgen cannot be a member of a cluster constraint. However, all instance members of a modgen can be members of a cluster.
Modgen and Alignment
All modgen constraints contain embedded alignment constraints for each row and column.
Although it is possible to set an additional, and compatible, alignment constraint for the same members, it is preferable to choose only one constraint type (either modgen or alignment) for those same members.
Modgen and Symmetry
All modgen constraints specify the order and orientation of each member inside the formed array. Although it is possible to set an additional, and compatible, symmetry constraint for a single, or number of the same members, it is preferable to choose only one constraint type (either modgen or symmetry) for those members.
Two symmetrical instances can also be members of different modgens. However, if this is the case, then the two modgens must be symmetrical.
Net Class
Net-based constraints that apply to groups of nets are not allowed to have common members that are shared with other constraints. For example, the following combinations of constraints are infeasible:
If an overlap is detected, such constraints are not generated and a warning message is displayed in the CIW with the names of the common members.
Symmetry and Alignment
A symmetry constraint, defined for a pair of objects, will contain an embedded alignment constraint. The alignment axis will be orthogonal to the symmetry axis. It is therefore not required (and not recommended) to over-constrain a pair of symmetrical objects with an additional alignment constraint.
However, an alignment constraint can be valuable and its use is especially valid when aligning two, or more, pairs of symmetrical objects together.
Symmetry and Cluster
If a symmetrical object is a member of a cluster, the other object must also be a member of the same cluster.
Symmetry and Orientation
Two symmetrical objects can both have an orientation constraint. However, the allowed orientation for these objects must be compatible with the value of the mirror parameter.
For example, if mirror = true the orientation of one symmetrical object must be the mirrored orientation of the other object of the same symmetrical pair.
Symmetry Axis
When several self-symmetrical objects, or pairs of symmetrical objects, have the same symmetry axis they will share the same symmetry axis for placement.
To have different groups of symmetry placement at least two different names of symmetry axis are required.
It is recommended that a specific axis be set for all symmetry and alignment constraints, as leaving the constraints with the default axis may lead to unpredictable results.
Return to top