AR# 47831


14.x PlanAhead - The constraints applied by the PlanAhead tool do not seem to match the constraints in my UCF file


The constraints applied by the PlanAhead tool do not seem to match the constraints in my UCF file.

Some of the things I noticed are:

  • During MAP, PAR or BitGen, an error or warning is issued saying a constraint is required. The UCF file contains the constraint in question.
  • The size of the UCF file sent to Synthesis and Implementation is much larger than the UCF file added to the project.
  • Attribute values applied to an object do not match values passed in the constraint file.
  • I receive warnings or errors about a specific constraint when I open the Elaborated, Synthesized, or Implemented design. However, the constraint does seem to have been applied.
  • I receive warnings or errors about a specific constraint when implementing my design. However, the same UCF and design files complete successfully in a Project Navigator or ISE command line flow.

Why are the constraints changed?

What process does the PlanAhead constraint system use to process the UCF constraints?

What happens with wildcard characters that are entered in a UCF file?


When a PlanAhead project contains a UCF based constraints file, the constraints are first read into the PlanAhead tool and applied to the open design.

When a synthesis run or implementation run is started, the constraints that have been read into PlanAhead tool are written out to a new constraints file in the runs directory (e.g., my_project_name/my_project_name.runs/synth_1).

Where possible, the constraints written in the "runs" constraint file are correlated back to the line they came from in the original constraint file. Some of the things that will cause the "runs" constraint file to be different from the original constraint file are:

  • The PlanAhead tool writes one constraint out per line. The UCF format allows multiple constraints to be applied to a single object on one line with the use of the pipe character separating the constraints. The PlanAhead tool will read the constraint line and write it out to multiple lines.
    • Example: Original UCF line:
    • NET CLK_N LOC = "K22" | DIFF_TERM = "TRUE" | IOSTANDARD = "LVDS_25";
    • This gets changed by the PlanAhead tool into:
      NET "CLK_N" LOC = K22;
  • Wildcards are not handled the same by the PlanAhead tool.
    • If wildcard characters are included in a constraint, the PlanAhead tool will attempt to apply the constraint to each net/instance that matches the wildcard name. The size of the resulting UCF may be much larger than the original UCF if wildcard characters are used to represent a large number of nets or instances.
    • The PlanAhead tool replaces the net name when wildcards are used in the middle of a name. For instance:
    • NET "my_net/module_1.*.new/last_module"

      Where NET name attribute will be replaced after Synthesis process for all names matching the previous instance.

      However, the problem does not happen if the name contains a wildcard at the beginning or end of the matching pattern:

      NET "*my_net/module_1_new/last_module*"
  • The PlanAhead tool does not propagate constraints through objects as freely as the ISE tools did. For example, a pin location constraint should be placed on an I/O port. In ISE, if a pin location constraint is placed on a net that connects to a buffer that drives another net connected to an I/O port, MAP is able to propagate the LOC constraint through the buffer to the desired I/O Port. PlanAhead tool does not attempt to do this propagation.
  • A net or object being constrained cannot be found by PlanAhead tool for one reason or another (e.g. black boxed or encrypted module) and the constraint is dropped in the "runs" UCF.
  • DRC checks in PlanAhead tool do not match those from ISE Design Suite. For instance, this issue has been seen quite often with different permutations of Location and I/O STANDARD constraints being applied to differential pair I/O ports. The PlanAhead tool has incorrectly determined that some combinations were not valid and dropped a constraint. (These incorrect design rule checks have been fixed or are scheduled for fix when found).
  • If constraints are not understood, they should be passed on to the "runs" UCF file as is. However, there have been issues where a constraint that was not understood was simply dropped.

As mentioned in a few cases above, many of the issues with PlanAhead tool recognizing constraints correctly have been corrected where found. However, other issues are due to a fundamental difference between PlanAhead and ISE tools related to constraints handling and design database structure. A user should carefully read the constraints DRC warnings, critical warnings, and errors when a UCF constraint file is first used in PlanAhead tool, and compare the constraint file written to the runs directory with the original constraint.

If a user wants to simply pass the original UCF constraints to the implementation tools and not graphically view the constraint interaction in the PlanAhead tool (e.g., viewing or manipulating constraints in the Pin Planning or Design view), the UCF file can be removed or disabled in the active constraint set and passed directly to NGDBUILD using the -uc switch in the more options field under Translate (NGDBUILD) in the Implementations Project Settings.

AR# 47831
Date 04/12/2013
Status Archive
Type General Article
People Also Viewed