01.07.2013 Views

Xilinx Constraints Guide

Xilinx Constraints Guide

Xilinx Constraints Guide

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Defining From Timing Groups<br />

Chapter 4: <strong>Xilinx</strong> <strong>Constraints</strong><br />

To create an area group based on a timing group, use the following User <strong>Constraints</strong> File<br />

(UCF) and Netlist <strong>Constraints</strong> File (NCF) syntax:<br />

TIMEGRP timing_group_name AREA_GROUP = area_group_name ;<br />

• timing_group_name is the name of a previously defined timing group.<br />

• area_group_name is the name of a new area group to be defined from the TIMEGRP<br />

contents.<br />

This is equivalent to manually assigning each member of the timing group to<br />

area_group_name. The area group name defined by this statement can be used in RANGE<br />

constraints, just like any other area group name.<br />

TNM_NET Groups<br />

In the AREA_GROUP definition, the timing_group_name is generally a TNM_NET<br />

group. This allows area groups to be formed based on the loads of clock or other control<br />

nets. Defining AREA_GROUP constraints from TIMEGRP constraints can improve<br />

placement of designs with many different clock domains in devices that have more<br />

clocks than clock regions.<br />

TNM and TIMEGRP Groups<br />

You can also specify<br />

• A TNM group name, or<br />

• The name of a user group defined by a TIMEGRP statement.<br />

Edge qualifiers used in the TIMEGRP definition are ignored when determining area<br />

group membership. In all cases, the AREA_GROUP members are determined after the<br />

TIMEGRP has been propagated to its target elements.<br />

TIMEGRP constraints can contain only synchronous elements and pads. Area groups<br />

defined from timing groups also contain only these element types. If an AREA_GROUP<br />

is defined by a TIMEGRP that contains only Flip-Flops or Latches, assigning a RANGE<br />

to that group is useful only if ungrouped logic is also allowed within the area. For this<br />

reason, don not define COMPRESSION for such groups.<br />

PERIOD Specifications<br />

If a TNM_NET is used by a PERIOD specification, and is traced into any DCM, PLL, or<br />

MMCM, new TNM_NET groups and PERIOD specifications are created at the DCM,<br />

PLL, or MMCM outputs. If the original TNM_NET is used to define an area group, and<br />

if more than one clock tap is used on the DCM, PLL, or MMCM, the area group is<br />

split into separate groups at each clock tap.<br />

For example, assume you have the following UCF constraints:<br />

NET "clk" TNM_NET="clock";<br />

TIMESPEC "TS_clk" = PERIOD "clock" 10 MHz;<br />

TIMEGRP "clock" AREA_GROUP="clock_area";<br />

If the net clk is traced into a DCM, PLL, or MMCM, a new group and PERIOD<br />

specification is created at each clock tap. Similarly, a new area group is created at each<br />

clock tap. A suffix indicates the clock tap name. If the CLK0 and CLK2X taps are used,<br />

the AREA_GROUP clock_area_CLK0 and clock_area_CLK2X are defined automatically.<br />

When AREA_GROUP definitions are split in this manner, NGDBuild issues an<br />

informational message, showing the names of the new groups. Use these new group<br />

names, rather than the ones originally specified, in RANGE constraints.<br />

<strong>Constraints</strong> <strong>Guide</strong><br />

UG625 (v. 13.2) July 6, 2011 www.xilinx.com 75

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!