This section applies all FPGA families except XC3000.
The RLOC constraint groups logic elements into discrete sets. You can define the location of any element within the set relative to other elements in the set, regardless of eventual placement in the overall design. For example, if RLOC constraints are applied to a group of eight flip-flops organized in a column, the mapper maintains the columnar order and moves the entire group of flip-flops as a single unit. In contrast, absolute location (LOC) constraints constrain design elements to specific locations on the FPGA die with no relation to other design elements.
RLOC constraints allow you to place logic blocks relative to each other to increase speed and use die resources efficiently. They provide an order and structure to related design elements without requiring you to specify their absolute placement on the FPGA die. They allow you to replace any existing hard macro with an equivalent that can be directly simulated.
In the Unified Libraries, you can use RLOC constraints with BUFT- and CLB-related primitives, that is, DFF, HMAP, FMAP, and CY4 primitives. You can also use them on non-primitive macro symbols. There are some restrictions on the use of RLOC constraints on BUFT symbols; for details, see the “Fixing Members of a Set at Exact Die Locations” section. You cannot use RLOC constraints with decoders, clocks, or I/O primitives. LOC constraints, on the other hand, can be used on all primitives: BUFTs, CLBs, IOBs, decoders, and clocks.
The following symbols (primitives) accept RLOCs.
General syntax for assigning elements to relative locations is
RLOC=RmCn [.extension]
where m and n are relative row numbers and column numbers, respectively.
The extension uses the LOC extension syntax as appropriate; for example .1 and .2 for TBUF location.
The extension is required for XC5200 designs in order to fully specify the order of the elements (.LC0, .LC1, .LC2, .LC3). It is required for Virtex designs to specify the spatial relationship of the objects in the RPM (.S0, .S1).
The row and column numbers can be any positive or negative integer including zero. Absolute die locations, in contrast, cannot have zero as a row or column number. Because row and column numbers in RLOC constraints define only the order and relationship between design elements and not their absolute die locations, their numbering can include zero or negative numbers. Even though you can use any integer in numbering rows and columns for RLOC constraints, it is recommended that you use small integers for clarity and ease of use.
It is not the absolute values of the row and column numbers that is important in RLOC specifications but their relative values or differences. For example, if design element A has an RLOC=R3C4 constraint and design element B has an RLOC=R6C7 constraint, the absolute values of the row numbers (3 and 6) are not important in themselves. However, the difference between them is important; in this case, 3 (6 -3) specifies that the location of design element B is three rows away from the location of design element A. To capture this information, a normalization process is used at some point in the design implementation. In the example just given, normalization would reduce the RLOC on design element A to R0C0, and the RLOC on design element B to R3C3.
In Xilinx programs, rows are numbered in increasing order from top to bottom, and columns are numbered in increasing order from left to right. RLOC constraints follow this numbering convention.
The “Different RLOC Specifications for Four Flip-flop Primitives for an XC4000 or Spartan Series Design” figure demonstrates the use of RLOC constraints. Four flip-flop primitives named A, B, C, and D are assigned RLOC constraints as shown. These RLOC constraints require each flip-flop to be placed in a different CLB in the same column and stacked in the order shown - A above B, C, and D. Within a CLB, however, they can be placed either in the FFX or FFY position.
If you wish to place more than one of these flip-flop primitives per CLB, you can specify the RLOCs as shown in the “Different RLOC Specifications for Four Flip-flop Primitives for an XC4000 or Spartan Series Design” figure. The arrangement in the figure requires that A and B be placed in a single CLB and that C and D be placed in another CLB immediately below the AB CLB. However, within a CLB, the flip-flops can be placed in either of the two flip-flop positions, FFX or FFY.
To control the ordering of these flip-flop primitives specifically, you can use the extension field, as shown in the “Different RLOC Specifications for Four Flip-flop Primitives for an XC4000 or Spartan Series Design” figure. In this figure, the same four flip-flops are constrained to use specific resources in the CLBs. This specification always ensures that these elements are arranged exactly as shown - A must be placed in the FFX spot, B in the same CLB at the FFY spot, and so on.
Figure 12.4 Different RLOC Specifications for Four Flip-flop Primitives for an XC4000 or Spartan Series Design |  |
RLOC constraints give order and structure to related design elements. This section describes RLOC sets, which are groups of related design elements to which RLOC constraints have been applied. For example, the four flip-flops in the “Different RLOC Specifications for Four Flip-flop Primitives for an XC4000 or Spartan Series Design” figure are related by RLOC constraints and form a set. Elements in a set are related by RLOC constraints to other elements in the same set. Each member of a set must have an RLOC constraint, which relates it to other elements in the same set. You can create multiple sets, but a design element can belong to one set only.
Sets can be defined explicitly through the use of a set parameter or implicitly through the structure of the design hierarchy.
Four distinct types of rules are associated with each set.
These rules are discussed in the sections that follow.
The following sections discuss three different set constraints - U_SET, H_SET, and HU_SET. Elements must be tagged with both the RLOC constraint and one of these set constraints to belong to a set.
U_SET constraints enable you to group into a single set design elements with attached RLOC constraints that are distributed throughout the design hierarchy. The letter U in the name U_SET indicates that the set is user-defined. U_SET constraints allow you to group elements, even though they are not directly related by the design hierarchy. By attaching a U_SET constraint to design elements, you can explicitly define the members of a set. The design elements tagged with a U_SET constraint can exist anywhere in the design hierarchy; they can be primitive or non-primitive symbols. When attached to non-primitive symbols, the U_SET constraint propagates to all the primitive symbols with RLOC constraints that are below it in the hierarchy.
The syntax of the U_SET constraint is the following.
U_SET=set_name
where set_name is the user-specified identifier of the set. All design elements with RLOC constraints tagged with the same U_SET constraint name belong to the same set. Names therefore must be unique among all the sets in the design.
In contrast to the U_SET constraint, which you explicitly define by tagging design elements, the H_SET (hierarchy set) is defined implicitly through the design hierarchy. The combination of the design hierarchy and the presence of RLOC constraints on elements defines a hierarchical set, or H_SET set. You do not use an HSET constraint to tag the design elements to indicate their set membership. The set is defined automatically by the design hierarchy.
All design elements with RLOC constraints at a single node of the design hierarchy are considered to be in the same H_SET set unless they are tagged with another type of set constraint such as RLOC_ORIGIN or RLOC_RANGE. If you explicitly tag any element with an RLOC_ORIGIN, RLOC_RANGE, U_SET, or HU_SET constraint, it is removed from an H_SET set. Most designs contain only H_SET constraints, since they are the underlying mechanism for relationally placed macros. The RLOC_ORIGIN or RLOC_RANGE constraints are discussed further in the “Fixing Members of a Set at Exact Die Locations” section.
NGDBuild recognizes the implicit H_SET set, derives its name, or identifier, attaches the H_SET constraint to the correct members of the set, and writes them to the output file.
The syntax of the H_SET constraint as generated by NGDBuild follows.
H_SET=set_name
set_name is the identifier of the set and is unique among all the sets in the design. The base name for any H_SET is “hset,” to which NGDBuild adds a hierarchy path prefix to obtain unique names for different H_SET sets in the NGDBuild output file.
The HU_SET constraint is a variation of the implicit H_SET (hierarchy set). Like H_SET, HU_SET is defined by the design hierarchy. However, you can use the HU_SET constraint to assign a user-defined name to the HU_SET.
The syntax of the HU_SET constraint is the following.
HU_SET=set_name
where set_name is the identifier of the set; it must be unique among all the sets in the design. You must define the base names to ensure unique hierarchically qualified names for the sets after the mapper resolves the design and attaches the hierarchical names as prefixes.
This user-defined name is the base name of the HU_SET set. Like the H_SET set, in which the base name of “hset” is prefixed by the hierarchical name of the lowest common ancestor of the set elements, the user-defined base name of an HU_SET set is prefixed by the hierarchical name of the lowest common ancestor of the set elements.
The HU_SET constraint defines the start of a new set. All design elements at the same node that have the same user-defined value for the HU_SET constraint are members of the same HU_SET set. Along with the HU_SET constraint, elements can also have an RLOC constraint. The presence of an RLOC constraint in an H_SET constraint links the element to all elements tagged with RLOCs above and below in the hierarchy. However, in the case of an HU_SET constraint, the presence of an RLOC constraint along with the HU_SET constraint on a design element does not automatically link the element to other elements with RLOC constraints at the same hierarchy level or above.
Figure 12.5 Macro A Instantiated Twice | |
In the “Macro A Instantiated Twice” figure and the other related figures shown in the subsequent sections, the italicized text prefixed by => is added by NGDBuild during the design flattening process. You add all other text.
The “Macro A Instantiated Twice” figure demonstrates a typical use of the implicit H_SET (hierarchy set). The figure shows only the first “RLOC” portion of the constraint. In a real design, the RLOC constraint must be specified completely with RLOC=RmCn. In this example, macro A is originally designed with RLOC constraints on four flip-flops - A, B, C, and D. The macro is then instantiated twice in the design - Inst1 and Inst2. When the design is flattened, two different H_SET sets are recognized because two distinct levels of hierarchy contain elements with RLOC constraints. NGDBuild creates and attaches the appropriate H_SET constraint to the set members: H_SET=Inst1/hset for the macro instantiated in Inst1, and H_SET=Inst2/hset for the macro instantiated in Inst2. The design implementation programs place each of the two sets individually as a unit with relative ordering within each set specified by the RLOC constraints. However, the two sets are regarded to be completely independent of each other.
The name of the H_SET set is derived from the symbol or node in the hierarchy that includes all the RLOC elements. In the “Macro A Instantiated Twice” figure, Inst1 is the node (instantiating macro) that includes the four flip-flop elements with RLOCs shown on the left of the figure. Therefore, the name of this H_SET set is the hierarchically qualified name of “Inst1” followed by “hset.” The Inst1 symbol is considered the “start” of the H_SET, which gives a convenient handle to the entire H_SET and attaches constraints that modify the entire H_SET. Constraints that modify sets are discussed in the “Set Modifiers” section.
The “Macro A Instantiated Twice” figure demonstrates the simplest use of a set that is defined and confined to a single level of hierarchy. Through linkage and modification, you can also create an H_SET set that is linked through two or more levels of hierarchy. Linkage allows you to link elements through the hierarchy into a single set. On the other hand, modification allows you to modify RLOC values of the members of a set through the hierarchy.
The following table summarizes the RLOC set types and the constraints that identify members of these sets.
| Type | Definition | Naming | Linkage | Modification |
|---|---|---|---|---|
| Set | A set is a collection of elements to which relative location constraints are applied. | |||
| U_SET= name | All elements with the same user-tagged U_SET constraint value are members of the same U_SET set. | The name of the set is the same as the user-defined name without any hierarchical qualification. | U_SET links elements to all other elements with the same value for the U_SET constraint. | U_SET is modified by applying RLOC_ORIGIN or RLOC_RANGE constraints on, at most, one of the U_SET constraint-tagged elements. |
| H_SET (implicit through hierarchy) is not available as a constraint that you can attach to symbols. | RLOC on the node. Any other constraint removes a node from the H_SET set. | The lowest common ancestor of the members defines the start of the set. The name is the hierarchically qualified name of the start followed by the base name, “hset.” | H_SET links elements to other elements at the same node that do not have other constraints. It links down to all elements that have RLOC constraints and no other constraints. Similarly, it links to other elements up the hierarchy that have RLOC constraints but no other constraints. | H_SET is modified by applying RLOC_ORIGIN and RLOC_RANGE at the start of the set: the lowest common ancestor of all the elements of the set. |
| HU_SET= name | All elements with the same hierarchically qualified name are members of the same set. | The lowest common ancestor of the members is prefixed to the user-defined name to obtain the name of the set. | HU_SET links to other elements at the same node with the same HU_SET constraint value. It links to elements with RLOC constraints below. | The start of the set is made up of the elements on the same node that are tagged with the same HU_SET constraint value. An RLOC_ORIGIN or an RLOC_RANGE can be applied to, at most, one of these start elements of an HU_SET set. |
The example in the “Three H_SET Sets” figure explains and illustrates the process of linking together elements through the design hierarchy. Again, the complete RLOC specification, RLOC=RmCn, is required for a real design.
In this and other illustrations in this section, the sets are shaded differently to distinguish one set from another.
Figure 12.6 Three H_SET Sets | |
As noted previously, all design elements with RLOC constraints at a single node of the design hierarchy are considered to be in the same H_SET set unless they are assigned another type of set constraint, an RLOC_ORIGIN constraint, or an RLOC_RANGE constraint. In the “Three H_SET Sets” figure, RLOC constraints have been added on primitives and non-primitives C, D, F, G, H, I, J, K, M, N, O, P, Q, and R. No RLOC constraints were placed on B, E, L, or S. Macros C and D have an RLOC constraint at node A, so all the primitives below C and D that have RLOCs are members of a single H_SET set. Furthermore, the name of this H_SET set is “A/hset” because it is at node A that the set starts. The start of an H_SET set is the lowest common ancestor of all the RLOC-tagged constraints that constitute the elements of that H_SET set. Because element E does not have an RLOC constraint, it is not linked to the A/hset set. The RLOC-tagged elements M and N, which lie below element E, are therefore in their own H_SET set. The start of that H_SET set is A/E, giving it the name “A/E/hset.”
Similarly, the Q and R primitives are in their own H_SET set because they are not linked through element L to any other design elements. The lowest common ancestor for their H_SET set is L, which gives it the name “A/D/L/hset.” After the flattening, NGDBuild attaches H_SET=A/hset to the F, G, H, O, P, J, and K primitives; H_SET=A/D/L/hset to the Q and R primitives; and H_SET=A/E/hset to the M and N primitives.
Consider a situation in which a set is created at the top of the design. In the “Three H_SET Sets” figure, there would be no lowest common ancestor if macro A also had an RLOC constraint, since A is at the top of the design and has no ancestor. In this case, the base name “hset” would have no hierarchically qualified prefix, and the name of the H_SET set would simply be “hset.”
The RLOC constraint assigns a primitive an RLOC value (the row and column numbers with the optional extensions), specifies its membership in a set, and links together elements at different levels of the hierarchy. In the “Three H_SET Sets” figure, the RLOC constraint on macros C and D links together all the objects with RLOC constraints below them. An RLOC constraint is also used to modify the RLOC values of constraints below it in the hierarchy. In other words, RLOC values of elements affect the RLOC values of all other member elements of the same H_SET set that lie below the given element in the design hierarchy.
When the design is flattened, the row and column numbers of an RLOC constraint on an element are added to the row and column numbers of the RLOC constraints of the set members below it in the hierarchy. This feature gives you the ability to modify existing RLOC values in submodules and macros without changing the previously assigned RLOC values on the primitive symbols. This modification process also applies to the optional extension field. However, when using extensions for modifications, you must ensure that inconsistent extensions are not attached to the RLOC value of a design element that may conflict with RLOC extensions placed on underlying elements. For example, if an element has an RLOC constraint with the FFX extension, all the underlying elements with RLOC constraints must either have the same extension, in this case FFX, or no extension at all; any underlying element with an RLOC constraint and an extension different from FFX, such as FFY or F, is flagged as an error.
After resolving all the RLOC constraints, extensions that are not valid on primitives are removed from those primitives. For example, if NGDBuild generates an FFX extension to be applied on a primitive after propagating the RLOC constraints, it applies the extension if and only if the primitive is a flip-flop. If the primitive is an element other than a flip-flop, the extension is ignored. Only the extension is ignored in this case, not the entire RLOC constraint.
The “Adding RLOC Values Down the Hierarchy” figure illustrates the process of adding RLOC values down the hierarchy. The row and column values between the parentheses show the addition function performed by the mapper. The italicized text prefixed by => is added by MAP during the design resolution process and replaces the original RLOC constraint that you added.
Figure 12.7 Adding RLOC Values Down the Hierarchy | |
The ability to modify RLOC values down the hierarchy is particularly valuable when instantiating the same macro more than once. Typically, macros are designed with RLOC constraints that are modified when the macro is instantiated. The “Modifying RLOC Values of Same Macro and Linking Together as One Set” figure is a variation of the sample design in the “Macro A Instantiated Twice” figure. The RLOC constraint on Inst1 and Inst2 now link all the objects in one H_SET set. Because the RLOC=R0C0 modifier on the Inst1 macro does not affect the objects below it, the mapper only adds the H_SET tag to the objects and leaves the RLOC values as they are. However, the RLOC=R0C1 modifier on the Inst2 macro causes MAP to change the RLOC values on objects below it, as well as to add the H_SET tag, as shown in the italicized text.
Figure 12.8 Modifying RLOC Values of Same Macro and Linking Together as One Set | |
The HU_SET constraint is a variation of the implicit H_SET (hierarchy set). The HU_SET constraint defines the start of a new set. Like H_SET, HU_SET is defined by the design hierarchy. However, you can use the HU_SET constraint to assign a user-defined name to the HU_SET.
The “HU_SET Constraint Linking and Separating Elements from H_SET Sets” figure demonstrates how HU_SET constraints designate elements as set members, break links between elements tagged with RLOC constraints in the hierarchy to separate them from H_SET sets, and generate names as identifiers of these sets.
Figure 12.9 HU_SET Constraint Linking and Separating Elements from H_SET Sets | |
The user-defined HU_SET constraint on E separates its underlying design elements, namely H, I, J, K, L, and M from the implicit H_SET=A/hset that contains primitive members B, C, F, and G. The HU_SET set that is defined at E includes H, I, and L (through the element J). The mapper hierarchically qualifies the name value “bar” on element E to be A/bar, since A is the lowest common ancestor for all the elements of the HU_SET set, and attaches it to the set member primitives H, I, and L. An HU_SET constraint on K starts another set that includes M, which receives the HU_SET=A/E/bar constraint after processing by the mapper. In the “HU_SET Constraint Linking and Separating Elements from H_SET Sets” figure, the same name field is used for the two HU_SET constraints, but because they are attached to symbols at different levels of the hierarchy, they define two different sets.
Figure 12.10 Linking Two HU_SET Sets | |
The “Linking Two HU_SET Sets” figure shows how HU_SET constraints link elements in the same node together by naming them with the same identifier. Because of the same name, “bar,” on two elements, D and E, the elements tagged with RLOC constraints below D and E become part of the same HU_SET.
A modifier, as its name suggests, modifies the RLOC constraints associated with design elements. Since it modifies the RLOC constraints of all the members of a set, it must be applied in a way that propagates it to all the members of the set easily and intuitively. For this reason, the RLOC modifiers of a set are placed at the start of that set. The following set modifiers apply to RLOC constraints.
Xilinx-supplied flip-flop macros include an RLOC=R0C0 constraint on the underlying primitive, which allows you to attach an RLOC to the macro symbol. This symbol links the underlying primitive to the set that contains the macro symbol. Simply attach an appropriate RLOC constraint to the instantiation of the actual Xilinx flip-flop macro. The mapper adds the RLOC value that you specified to the underlying primitive so that it has the desired value.
Figure 12.11 Typical Use of a Xilinx Macro | |
For example, in the “Typical Use of a Xilinx Macro” figure, the RLOC = R1C1 constraint is attached to the instantiation (Inst1) of the FDRE macro. It is added to the R0C0 value of the RLOC constraint on the flip-flop within the macro to obtain the new RLOC values.
If you do not put an RLOC constraint on the flip-flop macro symbol, the underlying primitive symbol is the lone member of a set. the mapper removes RLOC constraints from a primitive that is the only member of a set or from a macro that has no RLOC objects below it.
NGDBuild continues to propagate LOC constraints down the design hierarchy. It adds this constraint to appropriate objects that are not members of a set. While RLOC constraint propagation is limited to sets, the LOC constraint is applied from its start point all the way down the hierarchy.
When the design is flattened, the row and column numbers of an RLOC constraint on an element are added to the row and column numbers of the RLOC constraints of the set members below it in the hierarchy. This feature gives you the ability to modify existing RLOC values in submodules and macros without changing the previously assigned RLOC values on the primitive symbols.
Specifying RLOC constraints to describe the spatial relationship of the set members to themselves allows the members of the set to float anywhere on the die as a unit. You can, however, fix the exact die location of the set members. The RLOC_ORIGIN constraint allows you to change the RLOC values into absolute LOC constraints that respect the structure of the set.
The design resolution program, NGDBuild, translates the RLOC_ORIGIN constraint into LOC constraints. The row and column values of the RLOC_ORIGIN are added individually to the members of the set after all RLOC modifications have been made to their row and column values by addition through the hierarchy. The final values are then turned into LOC constraints on individual primitives.
As noted in the previous section, you can fix the members of a set at exact die locations with the RLOC_ORIGIN constraint. You must use the RLOC_ORIGIN constraint with sets that include BUFT symbols. However, for sets that do not include BUFT symbols, you can limit the members of a set to a certain range on the die. In this case, the set could “float” as a unit within the range until a final placement. Since every member of the set must fit within the range, it is important that you specify a range that defines an area large enough to respect the spatial structure of the set.
The syntax of this constraint is the following.
RLOC_RANGE=Rm1Cn1:Rm2Cn2
where the relative row numbers (m1, m2) and column numbers (n1, n2) can be non-zero positive numbers, or the wildcard (*) character. This syntax allows for three kinds of range specifications as follows.
For the second and third kinds of specifications with wildcards, applying the wildcard character (*) differently on either side of the separator colon creates an error. For example, specifying R*C1:R2C* is an error since the wildcard asterisk is applied to rows on one side and to columns on the other side of the separator colon.
To specify a range or area, use the following syntax, which is equivalent to placing an RLOC_RANGE constraint on the schematic.
set_name RLOC_RANGE=Rm1Cn1:Rm2Cn2
The range identifies a rectangular area. You can substitute a wildcard (*) character for either the row number or the column number of both corners of the range.
The bounding rectangle applies to all elements in a relationally placed macro, not just to the origin of the set. See the “Relationally Placed Macros (RPMs)” section for more information.
The values of the RLOC_RANGE constraint are not simply added to the RLOC values of the elements. In fact, the RLOC_RANGE constraint does not change the values of the RLOC constraints on underlying elements. It is an additional constraint that is attached automatically by the mapper to every member of a set. The RLOC_RANGE constraint is attached to design elements in exactly the same way as the RLOC_ORIGIN constraint. The values of the RLOC_RANGE constraint, like RLOC_ORIGIN values, must be non-zero positive numbers since they directly correspond to die locations.
If a particular RLOC set is constrained by an RLOC_ORIGIN or an RLOC_RANGE constraint in the design netlist and is also constrained in the UCF file, the UCF file constraint overrides the netlist constraint.
Another important set modifier is the USE_RLOC constraint. It turns the RLOC constraints on and off for a specific element or section of a set. RLOC can be either TRUE or FALSE.
The application of the USE_RLOC constraint is strictly based on hierarchy. A USE_RLOC constraint attached to an element applies to all its underlying elements that are members of the same set. If it is attached to a symbol that defines the start of a set, the constraint is applied to all the underlying member elements, which represent the entire set. However, if it is applied to an element below the start of the set (for example, E in the “Using the USE_RLOC Constraint to Control RLOC Application on H_SET and HU_SET Sets” figure), only the members of the set (H and I) below the specified element are affected. You can also attach the USE_RLOC constraint directly to a primitive symbol so that it affects only that symbol.
Figure 12.12 Using the USE_RLOC Constraint to Control RLOC Application on H_SET and HU_SET Sets | |
When the USE_RLOC=FALSE constraint is applied, the RLOC and set constraints are removed from the affected symbols in the NCD file. This process is different than that followed for the RLOC_ORIGIN constraint. For RLOC_ORIGIN, the mapper generates and outputs a LOC constraint in addition to all the set and RLOC constraints in the PCF file. The mapper does not retain the original constraints in the presence of a USE_RLOC=FALSE constraint because these cannot be turned on again in later programs.
The “Using the USE_RLOC Constraint to Control RLOC Application on H_SET and HU_SET Sets” figure illustrates the use of the USE_RLOC constraint to mask an entire set as well as portions of a set.
Applying the USE_RLOC constraint on U_SET sets is a special case because of the lack of hierarchy in the U_SET set. Because the USE_RLOC constraint propagates strictly in a hierarchical manner, the members of a U_SET set that are in different parts of the design hierarchy must be tagged separately with USE_RLOC constraints; no single USE_RLOC constraint is propagated to all the members of the set that lie in different parts of the hierarchy. If you create a U_SET set through an instantiating macro, you can attach the USE_RLOC constraint to the instantiating macro to allow it to propagate hierarchically to all the members of the set. You can create this instantiating macro by placing a U_SET constraint on a macro and letting the mapper propagate that constraint to every symbol with an RLOC constraint below it in the hierarchy.
The “Using the USE_RLOC Constraint to Control RLOC Application on U_SET Sets” figure illustrates an example of the use of the USE_RLOC=FALSE constraint. The USE_RLOC=FALSE on primitive E removes it from the U_SET set, and USE_RLOC=FALSE on element F propagates to primitive G and removes it from the U_SET set.
Figure 12.13 Using the USE_RLOC Constraint to Control RLOC Application on U_SET Sets | |
While propagating the USE_RLOC constraint, the mapper ignores underlying USE_RLOC constraints if it encounters elements higher in the hierarchy that already have USE_RLOC constraints. For example, if the mapper encounters an underlying element with a USE_RLOC=TRUE constraint during the propagation of a USE_RLOC=FALSE constraint, it ignores the newly encountered TRUE constraint.
To specify a single origin for an RLOC set, use the following syntax, which is equivalent to placing an RLOC_ORIGIN attribute on the schematic.
set_name RLOC_ORIGIN=RmCn
The set_name can be the name of any type of RLOC set - a U_SET, an HU_SET, or a system-generated H_SET.
The origin itself is expressed as a row number and a column number representing the location of the elements at RLOC=R0C0.
When the RLOC_ORIGIN constraint is used in conjunction with an implicit H_SET (hierarchy set), it must be placed on the element that is the start of the H_SET set, that is, on the lowest common ancestor of all the members of the set.
If you apply an RLOC_ORIGIN constraint to an HU_SET constraint, place it on the element at the start of the HU_SET set, that is, on an element with the HU_SET constraint. However, since there could be several elements linked together with the HU_SET constraint at the same node, the RLOC_ORIGIN constraint can be applied to only one of these elements to prevent more than one RLOC_ORIGIN constraint from being applied to the HU_SET set.
Similarly, when used with a U_SET constraint, the RLOC_ORIGIN constraint can be placed on only one element with the U_SET constraint. If you attach the RLOC_ORIGIN constraint to an element that has only an RLOC constraint, the membership of that element in any set is removed, and the element is considered the start of a new H_SET set with the specified RLOC_ORIGIN constraint attached to the newly created set.
Figure 12.14 Using an RLOC_ORIGIN Constraint to Modify an H_SET Set | |
In the “Using an RLOC_ORIGIN Constraint to Modify an H_SET Set” figure, the elements B, C, D, F, and G are members of an H_SET set with the name A/hset. This figure is the same as the “Adding RLOC Values Down the Hierarchy” figure except for the presence of an RLOC_ORIGIN constraint at the start of the H_SET set (at A). The RLOC_ORIGIN values are added to the resultant RLOC values at each of the member elements to obtain the values that are then converted by the mapper to LOC constraints. For example, the RLOC value of F, given by adding the RLOC value at E (R0C1) and that at F (R0C0), is added to the RLOC_ORIGIN value (R2C3) to obtain the value of (R2C4), which is then converted to a LOC constraint, LOC = CLB_R2C4.
Figure 12.15 Using an RLOC_ORIGIN to Modify H_SET and HU_SET Sets | |
The “Using an RLOC_ORIGIN to Modify H_SET and HU_SET Sets” figure shows an example of an RLOC_ORIGIN constraint modifying an HU_SET constraint. The start of the HU_SET A/bar is given by element D or E. The RLOC_ORIGIN attached to E, therefore, applies to this HU_SET set. On the other hand, the RLOC_ORIGIN at A, which is the start of the H_SET set A/hset, applies to elements B and C, which are members of the H_SET set.
