Ug912-Vivado-Design Suite Reference
Ug912-Vivado-Design Suite Reference
Properties Reference
Guide
Revision History
The following table shows the revision history for this document.
Introduction
This reference manual discusses the first class objects, and the properties available for
those objects, in the Xilinx ® Vivado ® Design Suite. It consists of the following:
• Chapter 1, Vivado First Class Objects: Describes the various design and device objects
used by the Vivado Design Suite to model the FPGA design database. A definition of
the object, a list of related objects, and a list of properties attached to the object are
provided.
• Chapter 2, Key Property Descriptions: For many Vivado Design Suite properties, a
description, supported architectures, applicable elements, values, syntax examples
(Verilog, VHDL, and XDC), and affected steps in the design flow are provided.
• Appendix A, Additional Resources: Resources and documents available on the Xilinx
support website at www.xilinx.com/support are provided.
1HW
3RUW
3LQ
&ORFN
7LPLQJ 1RGH
&HOO
3DWK
%HO3LQ
&ORFN
%HO
5HJLRQ
:LUH
3DFNDJH
6LWH 6LWH3LQ
3LQ
6LWH3LS 3LS
,2%DQN
7LOH
,2
6WDQGDUG
The objects displayed in Figure 1-1 are defined as netlist objects, or as device objects.
Netlist objects, shown in pink above, include logic cells, pins, ports, and nets. Device objects
include placement sites, such as clock regions, tiles, sites, and bels, shown in blue above.
Device objects also include package pins and I/O banks, shown in green, and routing
resources such as nodes, wires, and pips, shown in purple in Figure 1-1.
A double headed arrow indicates that the relationship can be queried from either direction.
For instance, you can query the cells attached to specific nets (get_cell -of_objects
[get_nets]), or query the nets connected to specific cells (get_nets -of_objects
[get_cells]).
A single-ended arrow reflects a relationship that can only be queried in the direction of the
arrow. For instance, in Figure 1-1, page 6, you can see that you can query the bels located
in specific clock regions (get_bels -of_objects [get_clock_regions]), but you cannot get
clock regions associated with specific bels. You can get tiles associated with specific bels
(get_tiles -of_objects [get_bels]), but not bels associated with tiles.
This figure is representative, and is not intended to depict all Vivado first class objects, or
all their relationships. A description of first class objects, their relationships to other
objects, and the properties defined on those objects follows in this chapter.
Additional categories of objects exist in the Vivado Design Suite, such as timing objects,
which combine with the netlist design to create preliminary timing reports. Timing objects
associated with the netlist and device objects, provide a complete timing analysis of the
implemented design. Timing objects include clocks, timing paths, and delay objects.
This guide gives numerous syntax and coding examples to assist you in inserting properties
into your code. Problems may arise if you copy those examples directly from this PDF
document into your code.
• The dash character, ‘-’, may be replaced with an en-dash or em-dash character when
copying and pasting from the PDF into the Vivado Tcl console, or into a Tcl script or
XDC file.
• PDF documents insert end of line markers into examples that wrap from line to line.
These markers will cause errors in your Tcl scripts or XDC files.
• Copying examples that span more than one page in the PDF captures extraneous
header and footer information along with the example. This extraneous information
causes errors in your TCL scripts or XDC files.
To avoid these problems, edit the example in an ASCII text editor to remove any
unnecessary markers or information, then paste it into your code, or the Vivado Design
Suite Tcl shell or Tcl console.
BELs are grouped together on the device in SITE objects, such as SLICEs and IO Blocks
(IOBs). One or more BELs can be located in a single SITE, and you can use the BEL to assign
logic from the design netlist into specific locations or device resources on the target device.
Related Objects
X-Ref Target - Figure 1-2
1HW
3RUW
3LQ
&ORFN
7LPLQJ 1RGH
&HOO
3DWK
%HO3LQ
&ORFN
%HO
5HJLRQ
:LUH
3DFNDJH
6LWH 6LWH3LQ
3LQ
6LWH3LS 3LS
,2%DQN
7LOH
,2
6WDQGDUG
As seen in Figure 1-2, leaf-level CELLs from the netlist design can be mapped onto BELs on
the target part. BELs are grouped in SITEs on the target Xilinx FPGA, and both BELs and
SITEs are grouped into CLOCK_REGIONs and TILEs. Each BEL also has BEL_PINs that map to
PINs on the cells, and are connection points to the NET netlist object.
The properties assigned to BEL objects vary by TYPE. To report the properties for any of the
TYPEs of BEL listed above, you can use the report_property command:
Where <BEL_TYPE> should be replaced by one of the listed BEL types. For example:
TIP: The report_property command may return a warning that no objects were found if there are no
related objects in the current design. Refer to the Vivado Design Suite Tcl Command Reference (UG835)
[Ref 4] for more information on this command.
1HW
3RUW
3LQ
&ORFN
7LPLQJ 1RGH
&HOO
3DWK
%HO3LQ
&ORFN
%HO
5HJLRQ
:LUH
3DFNDJH
6LWH 6LWH3LQ
3LQ
6LWH3LS 3LS
,2%DQN
7LOH
,2
6WDQGDUG
CELLs can be hierarchical or leaf-cells, which are primitive. As seen in Figure 1-3, leaf-cells
have PINs which are connected to NETs to define the external netlist, and hierarchical cells
contain PORTs that are associated with hierarchical PINs, and which connect internally to
NETs to define the internal netlist.
CELLs are placed, or mapped, onto device resources on the target Xilinx FPGA. The CELL can
be placed onto a BEL object in the case of basic logic such as flops, LUTs, and MUXes; or can
be placed onto a SITE object in the case of larger logic cells such as BRAMs and DSPs. BELs
are also collected into larger SITEs, called SLICEs, so a cell can be associated with a BEL and
a SITE object. SITEs are grouped into CLOCK_REGIONs and TILEs.
CELLs are also associated with TIMING_PATHs in the design, and can be associated with
DRC_VIOLATIONs to help you quickly locate and resolve design issues.
TIP: The report_property command may return a warning that no objects were found if there are no
related objects in the current design. Refer to the Vivado Design Suite Tcl Command Reference (UG835)
[Ref 4] for more information on this command.
• HIERARCHICAL CELL
report_property -all [lindex [get_cells -hier -filter {!IS_PRIMITIVE}] 0]
• BMEM
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
BMEM.bram.RAMB18E1}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
BMEM.bram.RAMB36E1}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
BMEM.fifo.FIFO36E1}] 0]
• CARRY
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
CARRY.others.CARRY4}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
CARRY.others.MUXCY}] 0]
• CLK
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
CLK.gclk.BUFG}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
CLK.gclk.MMCME2_ADV}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
CLK.rclk.BUFHCE}] 0]
• DMEM
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
DMEM.srl.SRL16E}] 0]
• FLOP_LATCH
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
FLOP_LATCH.flop.FDCE}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
FLOP_LATCH.flop.FDPE}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
FLOP_LATCH.flop.FDRE}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
FLOP_LATCH.flop.FDSE}] 0]
• LUT
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
LUT.others.LUT1}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
LUT.others.LUT2}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
LUT.others.LUT3}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
LUT.others.LUT4}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
LUT.others.LUT5}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
LUT.others.LUT6}] 0]
• MULT
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
MULT.dsp.DSP48E1}] 0]
• MUXFX
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
MUXFX.others.MUXF7}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
MUXFX.others.MUXF8}] 0]
• OTHERS
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
OTHERS.others.GND}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
OTHERS.others.VCC}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
others.others.others}] 0]
• RTL_GATE
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_GATE.buf.RTL_BUF}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_GATE.buf.RTL_INV}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_GATE.logical.RTL_AND}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_GATE.logical.RTL_NAND}] 0]
• RTL_MEMORY
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_MEMORY.ram.RTL_RAM}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_MEMORY.rom.RTL_ROM}] 0]
• RTL_MUX
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_MUX.mux.RTL_MUX}] 0]
• RTL_OPERATOR
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.arithmetic.RTL_ADD}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.arithmetic.RTL_SUB}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.equality.RTL_EQ}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.equality.RTL_NEQ}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.relational.RTL_GEQ}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.relational.RTL_GT}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.relational.RTL_LEQ}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.relational.RTL_LT}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.reduction.RTL_REDUCTION_OR}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_OPERATOR.reduction.RTL_REDUCTION_XOR}] 0]
• RTL_REGISTER
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_REGISTER.flop.RTL_REG}] 0]
• RTL_SPECIAL
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_SPECIAL.others.RTL_BMERGE}] 0]
report_property -all [lindex [get_cells -hier -filter {PRIMITIVE_TYPE ==
RTL_SPECIAL.others.RTL_BSEL}] 0]
1HW
3RUW
3LQ
&ORFN
7LPLQJ 1RGH
&HOO
3DWK
%HO3LQ
&ORFN
%HO
5HJLRQ
:LUH
3DFNDJH
6LWH 6LWH3LQ
3LQ
6LWH3LS 3LS
,2%DQN
7LOH
,2
6WDQGDUG
Description
A net is a set of interconnected pins, ports, and wires. Every wire has a net name, which
identifies it. Two or more wires can have the same net name. All wires sharing a common net
name are part of a single NET, and all pins or ports connected to these wires are electrically
connected.
A default net name is assigned to the NET object as it is added to the netlist design during
elaboration or compilation of the RTL source files into a netlist design. You can also
manually assign names to nets.
• Routing a number of signals from one side of the schematic to the other
• Connecting more than one signal to a block symbol
• Connecting more than one signal to pass between hierarchical levels by connecting
to a single I/O marker
Related Objects:
In the design netlist, a NET can be connected to the PIN of a CELL, or to a PORT. As the
design is mapped onto the target Xilinx FPGA, the NET is mapped to routing resources such
as WIREs, NODEs, and PIPs on the device, and is connected to BELs through BEL_PINs, and
to SITEs through SITE_PINs.
NETs are also associated with CLOCKs brought onto the design through PORTs, and to
TIMING_PATHs in the design.
NETs can also be associated with DRC_VIOLATIONs to allow you to more quickly locate and
resolve design issues.
Properties:
The properties assigned to a NET are as follows:
The properties of a NET object can be reported using the following command:
1HW
3RUW
3LQ
&ORFN
7LPLQJ 1RGH
&HOO
3DWK
%HO3LQ
&ORFN
%HO
5HJLRQ
:LUH
3DFNDJH
6LWH 6LWH3LQ
3LQ
6LWH3LS 3LS
,2%DQN
7LOH
,2
6WDQGDUG
Description
A pin is a point of logical connectivity on a primitive or hierarchical cell. A pin allows the
contents of a cell to be abstracted away, and the logic simplified for ease-of-use. Pins can
be scalar, containing a single connection, or can be defined as bus pins to group multiple
signals together.
PINs can also be associated with DRC_VIOLATIONs to allow you to more quickly locate and
resolve design issues.
Properties
The various properties found on PIN objects include the following:
1HW
3RUW
3LQ
&ORFN
7LPLQJ 1RGH
&HOO
3DWK
%HO3LQ
&ORFN
%HO
5HJLRQ
:LUH
3DFNDJH
6LWH 6LWH3LQ
3LQ
6LWH3LS 3LS
,2%DQN
7LOH
,2
6WDQGDUG
Description
A PORT is a special type of hierarchical pin, providing an external connection point at the
top-level of a hierarchical design, or an internal connection point in a hierarchical cell or
block module to connect the internal logic to the pins on the hierarchical cell. Ports can be
scalar, containing a single connection, or can be bus ports to group multiple signals
together.
PORTs can also carry CLOCK definitions onto the design from the system or BOARD, and
should be assigned to TIMING_PATHs using the set_input_delay or set_output_delay
constraint. Refer to the Vivado Design Suite User Guide: Using Constraints (UG903) for
more information on these constraints.
Inside hierarchical cells, PORTs are assigned to CELLs, and connect to NETs inside the cell,
the build the hierarchical netlist.
Properties
The properties found on PORT objects is as follows:
1HW
3RUW
3LQ
&ORFN
7LPLQJ 1RGH
&HOO
3DWK
%HO3LQ
&ORFN
%HO
5HJLRQ
:LUH
3DFNDJH
6LWH 6LWH3LQ
3LQ
6LWH3LS 3LS
,2%DQN
7LOH
,2
6WDQGDUG
Description
A SITE is a device object representing one of many different types of logic resources
available on the target Xilinx FPGA.
SITEs includes slices which are collections of basic logic elements (BELs) like look-up-tables
(LUTs), flip-flops, muxes, carry logic resources to implement fast addition, subtraction, or
comparison operations, with dedicated carry chains running vertically from slice to slice.
Two slices are grouped into a configurable logic block (CLB), which is a type of TILE object
on the device.
SITEs also include diverse objects such as block RAM, DSPs, I/O blocks, Clock resources, and
GT blocks.
You utilize slice resources by inference from the HDL source by Vivado synthesis, or by
instantiating a primitive or macro from the FPGA library, or an IP core from the Vivado IP
catalog. The Libraries Guide describes the list of primitives that can be instantiated.
PORTs, PINs, IO Banks, and Package Pins relate to IO blocks (IOBs) which are also SITEs.
Further, SITEs have pins, or SITE PINs, that map to NODEs, PINs, and NETs.
Properties
There are over 80 different SITE types on Xilinx FPGA devices, but they all share the
following properties:
Where <SITE_TYPE> should be replaced by one of the listed SITE types. For example:
Properties Information
This chapter provides information about Xilinx ® Vivado™ Design Suite properties. The
entry for each property contains the following information, where applicable:
IMPORTANT: When a property is defined in both HDL code and as a constraint in the XDC file, the XDC
property takes precedence and overrides the HDL property.
For more information on the use of these properties within the Vivado Design Suite, refer to
the Vivado Design Suite User Guide: Using Constraints (UG903) [Ref 6].
• A register can receive asynchronous data on the D input pin relative to its source clock.
or
During simulation, when a timing violation occurs, the default behavior is for a register
element to output an 'X', or unknown state (not a 1 or 0). When this happens, anything that
element drives will see an 'X' on its input and in turn enters an unknown state. This
condition can propagate through the design, in some cases causing large sections of the
design to become unknown, and sometimes the simulator can not recover from this state.
ASYNC_REG modifies the register to output the last known value even though a timing
violation occurs.
Specifying ASYNC_REG also affects optimization, placement, and routing to improve Mean
Time Between Failure (MTBF) for registers that may go metastable. If ASYNC_REG is applied,
the placer will ensure the flip-flops on a synchronization chain are placed closely to
maximize MTBF. Registers with ASYNC_REG that are directly connected will be grouped and
placed together into a single SLICE, assuming they have a compatible control set and the
number of registers does not exceed the available resources of the SLICE.
Note: ASYNC_REG also affects inference behavior in Vivado synthesis because the tool will not
optimize registers or surrounding logic in ways which could reduce MTBF.
X-Ref Target - Figure 2-1
With the ASYNC_REG property, the registers are grouped so that they are placed as close
together as possible.:
X-Ref Target - Figure 2-2
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
The register can be optimized away, or absorbed into a block such as SRL, DSP, or RAMB.
No special simulation, placement, or routing rules will be applied to it.
• TRUE
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the instantiation or reg declaration of a
register:
(* ASYNC_REG = "{TRUE|FALSE}" *)
VHDL Syntax
Declare the VHDL attribute as follows:
Where
• name is either:
or
XDC Syntax
set_property ASYNC_REG value [get_cells instance_name]
Where
Affected Steps
• launch_xsim
• synth_design
• place_design
• route_design
• phys_opt_design
• power_opt_design
• report_drc
• write_verilog
• write_vhdl
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Values
• BEL = <name>
BEL names can take many different forms depending on the specific logic contents of
the BEL. BEL names can also hierarchically include the SITE name for the BEL. For
instance, some valid BEL names are BSCAN_X0Y0/BSCAN, IPAD_X0Y54/IPAD,
BUFGCTRL_X0Y16/BUFG, and SLICE_X1Y199/A5FF.
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the instantiation of a LUT or register. The
Verilog attribute can also be placed before the reg declaration of an inferred register, SRL,
or LUTRAM.
(* BEL = "site_name" *)
Where
Where
XDC Syntax
set_property BEL site_name [get_cells instance_name]
Where
See Also
LOC, page 97
Architecture Support
All architectures
Applicable Objects
• The BUFFER_TYPE attribute can be placed on any top-level port (all_inputs, get_ports).
Values
• ibuf: Specify this value on clock ports where the default IBUF/BUFG pair is not wanted.
In this case only, the IBUF is inferred for the clock.
• none: Indicates that no input or output buffers are used. A none value on a clock port
results in no buffers.
Syntax
Verilog Syntax
(* buffer_type = "none" *) input in1; //this will result in no buffers
(* buffer_type = "ibuf" *) input clk1; //this will result in a clock with no bufg
VHDL Syntax
entity test is port(
in1 : std_logic_vector (8 downto 0);
clk : std_logic;
out1 : std_logic_vector(8 downto 0));
attribute buffer_type : string;
attribute buffer_type of in1 : signal is "none";
end test;
Where:
Affected Steps
• Synthesis
The CFGBVS pin setting determines the I/O voltage support for bank 0 at all times. On
devices in which bank 14 and bank 15 are the HR bank type, the CONFIG_VOLTAGE property
determines the I/O voltage support.
IMPORTANT: When CFGBVS is set to GND for 1.8V I/O operation, the VCCO_0 supply and I/O signals
to Bank 0 must be 1.8V (or lower) to avoid damage to the XIlinx FPGA.
Refer to the 7 Series FPGAs Configuration User Guide (UG470) [Ref 1] for more information
on Configuration Bank Voltage Select.
The Report DRC command checks the CFGBVS and CONFIG_VOLTAGE properties to
determine the compatibility of CONFIG_MODE setting on the current design.
Architecture Support
All architectures
Applicable Objects
• Designs (current_design, get_designs)
Values
• VCCO: Configure I/O Bank 0 for 3.3V/2.5V operation.
• GND: Configure I/O Bank 0 for 1.8V operation.
VHDL Syntax
Not applicable
XDC Syntax
set_property CFGBVS [VCCO | GND] [current_design]
Affected Steps
• I/O Planning
• Report DRC
• write_bitstream
See Also
CONFIG_MODE, page 47
CONFIG_VOLTAGE, page 49
External user clocks must be brought into the FPGA on differential clock pin pairs called
clock-capable inputs (CCIOS). These CCIOs provide dedicated, high-speed routing to the
internal global and regional clock resources to guarantee timing of various clocking
features. Refer to the 7 Series FPGAs Clocking Resources User Guide (UG472) [Ref 3] for more
information on clock placement rules.
Architecture Support
All architectures
Applicable Objects
• Nets (get_nets) connected to the input of a global clock buffer (BUFG, BUFGCE,
BUFGMUX, BUGCTRL)
Values
• TRUE: Clock placement DRC violations are reported as an ERROR (the default).
• FALSE: Clock placement DRC violations are downgraded to a WARNING. This should be
used anytime a clock component (such as a BUFG, MMCM, or PLL) is placed so that the
dedicated fast clock route cannot be used.
• BACKBONE: You may need to use this value if you assign location constraints that
violate basic clock placement rules, but is not generally recommended. Use this value
when an MMCM or PLL is placed far from the source CCIO pin. The extra wire length
will add delay to the timing path from the CCIO to the MMCM, which may not be
completely removed by the MMCM or PLL feedback. Use BACKBONE if the design
meets timing with the added delay.
VHDL Syntax
Not applicable
XDC Syntax
set_property CLOCK_DEDICATED_ROUTE [TRUE | FALSE | BACKBONE] [get_nets net_name]
Where
• net_name is the signal name connected to the input of a global clock buffer.
Affected Steps
• place_design
• report_drc
IMPORTANT: COMPATIBLE_CONFIG_MODES property has been deprecated in the 2013.3 release, and
is replaced by the CONFIG_MODE property.
Architecture Support
All architectures
Applicable Objects
• Design (current_design)
Values
• S_SERIAL
• M_SERIAL
• S_SELECTMAP
• M_SELECTMAP
• B_SCAN
• S_SELECTMAP+READBACK
• M_SELECTMAP+READBACK
• B_SCAN+READBACK
• S_SELECTMAP32
• S_SELECTMAP32+READBACK
• S_SELECTMAP16
• S_SELECTMAP16+READBACK
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
XDC Syntax
set_property CONFIG_MODE <value> [current_design]
Affected Steps
• I/O Planning
• place_design
• report_drc
• write_bitstream
The CFGBVS pin setting determines the I/O voltage support for bank 0 at all times. For
devices in which bank 14 and bank 15 are the HR bank type, the respective
CONFIG_VOLTAGE property determines the I/O voltage support.
Report DRC checks are run on Bank 0, 14, and 15 to determine compatibility of
CONFIG_MODE settings on the current design. DRCs are issued based on IOSTANDARD and
CONFIG_VOLTAGE settings for the bank. The configuration voltages are also used when
exporting IBIS models.
Architecture Support
All architectures
Applicable Objects
• Designs (current_design, get_designs)
Values
• 1.5, 1.8, 2.5, or 3.3
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
Affected Steps
• place_design
• report_drc
• write_bitstream
See Also
CFGBVS, page 43
CONFIG_MODE, page 47
DCI_CASCADE specifies which adjacent banks use the DCI Cascade feature, thereby sharing
reference resistors with a master bank. If several I/O banks in the same I/O bank column are
using DCI, and all of those I/O banks use the same VRN/VRP resistor values, the internal
VRN and VRP nodes can be cascaded so that only one pair of pins for all of the I/O banks
in the entire I/O column is required to be connected to precision resistors. DCI_CASCADE
identifies the master bank and all associated slave banks for this feature. For more
information refer to the 7 Series FPGAs SelectIO Resources User Guide (UG471) [Ref 2].
Architecture Support
• Kintex™-7 devices
• Virtex ®-7 devices
• Larger Zynq™ devices
Applicable Objects
• I/O Bank (get_iobanks)
Values
Valid High Performance (HP) bank numbers. See
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
Where
Affected Steps
• I/O planning
• place_design
• DRC
• write_bitstream
• report_power
Architecture Support
All architectures
Applicable Objects
• Ports (get_ports)
° LVDS
° LVDS_25
° MINI_LVDS_25
° PPDS_25
° RSDS_25
Values
• FALSE (default)
• TRUE
Verilog Syntax
To set DIFF_TERM, assign the DIFF_TERM parameter on the instantiated differential buffer.
The following example enables differential termination on the IBUFDS instance named
clk_ibufds.
VHDL Syntax
DIFF_TERM can be set by assigning the DIFF_TERM generic on the instantiated differential
buffer.
The following example enables differential termination on the IBUFDS instance named
clk_ibufds.
Where:
Where
Affected Steps
• I/O Planning
• report_ssn
• report_power
See Also
• IOSTANDARD, page 90
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Values
• FALSE (default)
• TRUE
Preserves the hierarchy by not allowing optimization across the hierarchy boundary.
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the user hierarchy instantiation:
(* DONT_TOUCH = "{TRUE|FALSE}" *)
Where
XDC Syntax
set_property DONT_TOUCH {TRUE|FALSE} [get_cells instance_name]
Where
Affected Steps
• synth_design
• opt_design
• phys_opt_design
• floorplanning
Architecture Support
All architectures
Applicable Objects
• Ports (get_ports)
Values
Integer values:
• 2
• 4
• 6
• 8
• 12 (default)
• 16
• 24
Syntax
Verilog Syntax
To set this attribute when inferring I/O buffers, place the proper Verilog attribute syntax
before the top-level output port declaration.
(* DRIVE = "{2|4|6|8|12|16|24}" *)
If the output or bidirectional buffer is instantiated, DRIVE can be set by assigning the DRIVE
parameter on the instantiated output buffer.
RECOMMENDED: Use the instantiation template from the Language Templates or the Vivado Design
Suite 7 Series FPGA Libraries Guide (UG953) [Ref 9] to specify the proper syntax.
The following example sets the drive strength on the OBUF instance named status_obuf
to 2 mA:
VHDL Syntax
To set this attribute when inferring I/O buffers, place the proper VHDL attribute syntax
before the top-level output port declaration.
Where
If the output or bidirectional buffer is instantiated, DRIVE can be set by assigning the DRIVE
generic on the instantiated output buffer.
The following example sets the drive strength on the OBUF instance named status_obuf
to 2 mA.
-- OBUF: Single-ended Output Buffer
-- Virtex-7
-- Xilinx HDL Language Template, version 2013.2
status_obuf : OBUF
generic map (
DRIVE => 2,
IOSTANDARD => "DEFAULT",
SLEW => "SLOW")
port map (
O => STATUS, -- Buffer output (connect directly to top-level port)
I => status_int -- Buffer input
);
-- End of status_obuf instantiation
XDC Syntax
set_property DRIVE value [get_ports port_name]
Where
Affected Steps
• I/O Planning
• Report Noise
• Report Power
See Also
Refer to the following design elements in the Vivado Design Suite 7 Series FPGA Libraries
Guide (UG953) [Ref 9].
• OBUF
• OBUFT
• IOBUF
As a default, the Vivado synthesis tool chooses an encoding protocol for state machines
based on internal algorithms that determine the best solution for most designs. However,
the FSM_ENCODING property lets you specify the state machine encoding of your choice.
Architecture Support
All architectures
Applicable Objects
• State machine registers
Values
• off - This disables state machine encoding within the Vivado synthesis tool. In this case
the state machine is synthesized as logic.
• one_hot
• sequential
• johnson
• gray
• auto - This is the default behavior when FSM_ENCODING is not specified. it allows the
Vivado synthesis tool to determine the best state machine encoding method. In this
case, the tool may use different encoding styles for different FSMs in the same design.
Verilog Syntax
(* fsm_encoding = "one_hot" *) reg [7:0] my_state;
VHDL Syntax
type count_state is (zero, one, two, three, four, five, six, seven);
signal my_state : count_state;
attribute fsm_encoding : string;
attribute fsm_encoding of my_state : signal is "sequential";
XDC Syntax
No applicable
See Also
• FSM_SAFE_STATE, page 63
However, a state machine can enter into an invalid, or “unreachable” state that causes the
design to fail. If a Finite State Machine (FSM) enters an invalid state, the FSM_SAFE_STATE
defines a recovery state for use when an FSM is synthesized in the Vivado synthesis tool.
TIP: The unreachable state can also be managed in the HDL definition of the state machine, with a
default case for instance. However, the FSM_SAFE_STATE property can be used as a fail safe for the
design.
Architecture Support
All architectures
Applicable Objects
• Design (current_design)
Values
• reset_state - Return the state machine to the RESET state, as determined by the Vivado
synthesis tool.
• power_on_state - Return the state machine to the POWER_ON state, as determined by
the Vivado synthesis tool.
Syntax
Verilog Syntax
(* fsm_safe_state = "reset_state" *) reg [2:0] state;
VHDL Syntax
attribute fsm_safe_state : string;
attribute fsm_safe_state of state : signal is "power_on_state";
Affected Steps
• Synthesis
See Also
• FSM_ENCODING, page 61
H_SET is a property that is implied due to the presence of RLOC properties on logic cells in
the hierarchy of a design. Logic elements inside of a hierarchical block, that have the RLOC
property, are automatically assigned to the same Hierarchical Set, or H_SET.
Each hierarchical module is assigned an H_SET property based on the instance name of the
module. Each hierarchical module may only have a single H_SET name, and all logic
elements inside that hierarchy are elements of that H_SET.
Note: H_SET is only defined if there is no HU_SET or U_SET defined, but RLOC is defined.
You can also manually create a User-defined Hierarchical Set, or HU_SET, or a User-defined
Set, or U_SET, that is not dependant on the hierarchy of the design.
You can define multiple HU_SET names for a single hierarchical module, and assign specific
instances of that hierarchy to the HU_SET. This allows you to divide the logic elements of a
single hierarchical module into multiple HU_SETs.
IMPORTANT: When using H_SET or HU_SET, the KEEP_HIERARCHY property is also required for Vivado
Synthesis to preserve the hierarchy for the RPM in the synthesized design.
When RLOC is also present in the RTL source files, the H_SET, HU_SET, and U_SET properties
get translated to a read-only RPM property on cells in the synthesized netlist. The HU_SET
and U_SET are visible on the RTL source file in the Text editor in the Vivado Design Suite.
However, in the Properties window of a cell object, the RPM property is displayed.
Architecture Support
All architectures.
• Registers
• LUT
• Macro Instance
• RAMS
• RAMD
• RAMB18/FIFO18
• RAMB36/FIFO36
• DSP48
Values
• NAME: A unique name for the HU_SET.
Syntax
Verilog Syntax
This is a Verilog attribute used in combination with the RLOC property to define the set
content of a hierarchical block that will define an RPM in the synthesized netlist. Place the
Verilog attribute immediately before the instantiation of a logic element.
Verilog Example
The following Verilog module defines RLOC and HU_SET properties for the shift register
Flops in the module.
module ffs (
input clk,
input d,
output q
);
assign q = outr;
endmodule // ffs
In the preceding example, you will need to specify the KEEP_HIERARCHY property to
instances of the ffs module to preserve the hierarchy and define the RPM in the synthesized
design:
module top (
input clk,
input d,
output q
);
endmodule // top
VHDL Syntax
Declare the VHDL attribute as follows:
Where:
XDC Syntax
The HU_SET property can not be defined using XDC constraints. The HU_SET property, when
present on logic elements with the RLOC property, defines relatively placed macros (RPMs),
and results in the read-only RPM property in the netlist of synthesized designs.
TIP: You can use the create_macro and update_macro commands to define macro objects in the
Vivado Design Suite, that act like RPMs within the design. Refer to the Vivado Design Suite Tcl
Command Reference (UG835) [Ref 4] for more information on these commands.
Affected Steps
• Design Floorplanning
• place_design
• synth_design
See Also
KEEP_HIERARCHY, page 93
If you use HIODELAY_GROUP to assign a group name to an IDELAYCTRL, you need to also
associate an IDELAY or ODELAY cell to the group using the same HIODELAY_GROUP
property.
IMPORTANT: While an HIODELAY_GROUP can contain multiple cells, a cell can only be assigned to one
HIODELAY_GROUP.
The following example uses set_property to group all the IDELAY/ODELAY elements
associated with a specific IDELAYCTRL.
and
• You do not intend to group that instance with any IDELAY or ODELAY instances in other
logical hierarchies.
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Values
Any specified group name
(* HIODELAY_GROUP = "value" *)
VHDL Syntax
Declare the VHDL attribute as follows:
Where
Where
Affected Steps
place_design
See Also
IODELAY_GROUP, page 87
Refer to the following design elements in the Vivado Design Suite 7 Series FPGA Libraries
Guide (UG953) [Ref 9].
• IDELAYCTRL
• IDELAYE2
• ODELAYE2
• Use HLUTNM when you expect to have multiple instances of a module that contains
LUT components to be grouped together.
• Use LUTNM to group two LUT components that exist in different hierarchies.
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
° SRL (SRL16E)
° LUTRAM (RAM32X1S)
Values
A unique group name
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the instantiation of a LUT.
The Verilog attribute must be used in pairs in the same logical hierarchy.
(* HLUTNM = "group_name" *)
VHDL Syntax
Declare the VHDL attribute as follows:
Where
The VHDL attribute must be used in pairs in the same logical hierarchy.
XDC Syntax
set_property HLUTNM group_name [get_cells instance_name]
Where
See Also
LUTNM, page 103
The IBUF_LOW_PWR property is applied to the I/O buffer instance. This property is set to
TRUE by default, which implements the input buffer in the lower-power mode rather than
the higher-performance mode (FALSE).
The change in power can be estimated using the XPower Estimator (XPE) or the
report_power command in the Vivado Design Suite.
Architecture Support
All architectures
Applicable Objects
• Input ports (get_ports) or Input buffers (get_cells) with a VREF-based I/O
Standard such as SSTL or HSTL or a differential standard such as LVDS or DIFF_HSTL.
Values
• TRUE: Implements the input or bidirectional buffer in low power mode.
• FALSE: Implements the input or bidirectional buffer in high performance mode.
Syntax
Verilog Syntax
To set IBUF_LOW_PWR, assign the parameter on the buffer module definition, or the
instantiated buffers.
VHDL Syntax
IBUF_LOW_PWR can be set by assigning the generic on the entity definition, or on the
instance.
XDC Syntax
IBUF_LOW_PWR can be assigned as a property on port objects with a DIRECTION of IN or
INOUT.
Affected Steps
• report_power
• report_timing
See Also
IOSTANDARD, page 90
The termination is present constantly on inputs, and on bidirectional pins whenever the
output buffer is 3-stated. However, an important difference between this un-calibrated
split-termination option and the 3-state split-termination DCI is that instead of calibrating
to external reference resistors on the VRN and VRP pins when using DCI, this feature
invokes internal resistors that have no calibration routine to compensate for temperature,
process, or voltage variations. This option has target Thevenin equivalent resistance values
of 40Ω, 50Ω, and 60Ω. For more information refer to the 7 Series FPGAs SelectIO Resources
User Guide (UG471) [Ref 2].
Architecture Support
All architectures on High Range (HR) bank inputs only.
Applicable Objects
• Ports (get_ports)
Values
• NONE (default)
• UNTUNED_SPLIT_40
• UNTUNED_SPLIT_50
• UNTUNED_SPLIT_60
(* IN_TERM = "{NONE|UNTUNED_SPLIT_40|UNTUNED_SPLIT_50|UNTUNED_SPLIT_60}" *)
VHDL Syntax
To set this attribute, place the proper VHDL attribute syntax before the top-level output
port declaration.
Where
XDC Syntax
set_property IN_TERM value [get_ports port_name]
Where:
• IN_TERM can be assigned to port objects, and nets connected to port objects.
• port_name is an output or bidirectional port.
Affected Steps
• I/O Planning
• Report Noise
• Report Power
See Also
DCI_CASCADE, page 51
DIFF_TERM, page 53
Architecture Support
All architectures
Applicable Objects
• I/O Bank (get_iobanks)
Values
• 0.60
• 0.675
• 0.75
• 0.90
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
XDC Syntax
set_property INTERNAL_VREF {value} [get_iobanks bank]
Where
Architecture Support
All architectures
Applicable Objects
• Ports (get_ports)
Values
• FALSE (default)
• TRUE
Syntax
Verilog Syntax
To set this attribute, place the proper Verilog attribute syntax before the top-level output
port declaration.
(* IOB = "{TRUE|FALSE}" *)
Where
XDC Syntax
set_property IOB value [get_ports port_name]
Where
Affected Steps
• place_design
The ILOGIC block is located next to the I/O block (IOB), and contains the synchronous
elements for capturing data as it comes into the FPGA through the IOB. The ILOGIC block in
7 series devices can be configured as ILOGICE2 in HP I/O banks, and as ILOGICE3 in HR I/O
banks. ILOGICE2 and ILOGICE3 are functionally identical except that ILOGICE3 has a zero
hold delay element (ZHOLD) which can be configured with IOBDELAY. Refer to the 7 Series
FPGAs SelectIO Resources User Guide (UG471) [Ref 2] for more information on the use of
IOBDELAY.
Architecture Support
All architectures
Applicable Objects
• Input Buffers (get_cells)
• Nets (get_nets)
Values
• NONE: Sets the delay to OFF for both the IBUF and input flip-flop (IFD) paths.
• IBUF
° Sets the delay to OFF for any register inside the I/O component.
° Sets the delay to ON for the buffered path through the ILOGIC block.
• IFD
° Sets the delay to ON for the IFF register inside the I/O component.
° Sets the delay to OFF for the BUFFERED path through the ILOGIC.
• BOTH: Sets the delay to ON for both the IBUF and IFD paths.
Syntax
Verilog Syntax
Place the Verilog constraint immediately before the module or instantiation.
(* IOBDELAY = {NONE|BOTH|IBUF|IFD} *)
VHDL Syntax
Declare the VHDL constraint as follows:
XDC Syntax
set_property IOBDELAY value [get_cells cell_name]
Where:
Affected Steps
• Timing
• Placement
• Routing
If you use IODELAY_GROUP to assign a group name to an IDELAYCTRL, you need to also
associate an IDELAY or ODELAY cell to the group using the same IODELAY_GROUP property.
IMPORTANT: While an IODELAY_GROUP can contain multiple cells, a cell can only be assigned to one
IODELAY_GROUP. .
The following example uses set_property to group all the IDELAY/ODELAY elements
associated with a specific IDELAYCTRL.
HIODELAY_GROUP groups I/O delay components under the same hierarchical module.
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Values
Any specified group name
(* IODELAY_GROUP = "value" *)
VHDL Syntax
Declare the VHDL attribute as follows:
Where
Where
Affected Steps
• Placement
See Also
HIODELAY_GROUP, page 69
Refer to the following design elements in the Vivado Design Suite 7 Series FPGA Libraries
Guide (UG953) [Ref 9].
• IDELAYCTRL
• IDELAYE2
• ODELAYE2
Architecture Support
All architectures
Applicable Objects
• Ports (get_ports)
° Any port - Define the IOSTANDARD in the RTL source of I/O Ports, or as XDC
constraints for port cells.
• Cells (get_cells)
° I/O Buffers (all IBUF, OBUF, and IOBUF variants) - For instantiated buffers,
IOSTANDARD must be defined in the RTL as an attribute of the cell. XDC Syntax is
not supported.
Values
A valid I/O Standard for the target Xilinx FPGA. Refer to the 7 Series FPGAs SelectIO
Resources User Guide (UG471) [Ref 2].
Syntax
Verilog Syntax
To set this attribute when inferring I/O buffers, place the proper Verilog attribute syntax
before the top-level output port declaration.
(* IOSTANDARD = "value" *)
If the I/O buffer is instantiated, IOSTANDARD can be set by assigning the IOSTANDARD
parameter on the instantiated I/O buffer.
The following example sets the I/O Standard on the STATUS output to LVCMOS12.
VHDL Syntax
To set this attribute when inferring I/O buffers, place the proper VHDL attribute syntax
before the top-level output port declaration.
Where
To set IOSTANDARD when the I/O buffer is instantiated, assign the IOSTANDARD generic on
the instantiated I/O buffer. The following example sets the I/O Standard on the STATUS
output to LVCMOS12.
XDC Syntax
set_property IOSTANDARD value [get_ports port_name]
Where
Affected Steps
• I/O Planning
• Report Noise
• Report Power
• Report DRC
• place_design
See Also
Refer to the following design elements in the Vivado Design Suite 7 Series FPGA Libraries
Guide (UG953) [Ref 9].
• OBUF
• OBUFT
• IOBUF
RECOMMENDED: To avoid these negative effects, register all outputs of a module instance in which a
KEEP_HIERARCHY is attached. To be most effective, apply this attribute before synthesis.
Architecture Support
All
Applicable Objects
• Cells (get_cells)
Values
• FALSE (default)
• TRUE
Preserves the hierarchy by not allowing optimization across the hierarchy boundary.
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the user hierarchy instantiation:
(* KEEP_HIERARCHY = "{TRUE|FALSE}" *)
Where
XDC Syntax
set_property KEEP_HIERARCHY {TRUE|FALSE} [get_cells instance_name]
Where
Affected Steps
• Design Floorplanning
• opt_design
• phys_opt_design
• synth_design
For example, if logic 1 is being driven onto a net, KEEPER drives a weak or resistive 1 onto
the net. If the net driver is then tri-stated, KEEPER continues to drive a weak or resistive 1
onto the net to preserve that value.
Input buffers (e.g., IBUF), 3-state output buffers (e.g., OBUFT), and bidirectional buffers
(e.g., IOBUF) can have a weak pull-up resistor, a weak pull-down resistor, or a weak “keeper”
circuit. This feature can be invoked by adding the one of the following properties to the net
object connected to the buffer:
• PULLUP
• PULLDOWN
• KEEPER
Architecture Support
All
Applicable Objects
• Nets connected to I/O Buffers (get_nets)
Values
• TRUE | YES: Use a keeper circuit to preserve the value on the net.
• FALSE | NO: Do not use a keeper circuit. Default.
VHDL Syntax
Declare the VHDL constraint as follows:
XDC Syntax
set_property KEEPER {TRUE|FALSE} [get_nets net_name]
Where
Affected Steps
• Logical to Physical Mapping
See Also
PULLDOWN, page 123
RECOMMENDED: To assign I/O ports to physical pins on the device package, use the PACKAGE_PINS
property rather than LOC.
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Values
Site name (for example, SLICE_X15Y14 or RAMB18_X6Y9)
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the instantiation of a component.
The Verilog attribute can also be placed before the reg declaration of an inferred register,
SRL, or LUTRAM when that reg can be placed into a single device site:
(* LOC = "site_name" *)
// Designates placed_reg to be placed in Slice site SLICE_X0Y0
(* LOC = "SLICE_X0Y0" *) reg placed_reg;
VHDL Syntax
Declare the VHDL attribute as follows:
Where
• signal_name is the signal name of an inferred primitive that can be placed into a
single site.
XDC Syntax
set_property LOC site_name [get_cells instance_name]
Where
Affected Steps
• Design Floorplanning
• place_design
See Also
BEL, page 38
By default, LUT pins are mapped in order from highest to lowest. The highest logical pin is
mapped to the highest physical pin.
• ALUT6 placed on an A6LUT bel, would have a default pin mapping of:
I5:A6 I4:A5 I3:A4 I2:A3 I1:A2 I0:A1
• A LUT5 placed on a D5LUT bel, would have a default pin mapping of:
I5:A5 I4:A4 I3:A3 I2:A2 I1:A1
• A LUT2 placed on an A6LUT bel, would have a default pin mapping of:
I1:A6 I0:A5
The LOCK_PINS property is used by the Vivado router, which will not modify pin mappings
on locked LUTs even if it would result in improved timing. LOCK_PINS is also important for
directed routing. If a pin that is connected by a directed route, is swapped with another pin,
the directed route will no longer align with the LUT connection, resulting in an error. All LUT
cells driven by a directed route net should have their pins locked using LOCK_PINS. Refer to
the Vivado Design Suite User Guide: Implementation (UG904) [Ref 7] for more information
on directed routing.
When the LOCK_PINS property is removed from a cell, the pin mapping is cleared and the
pins are free to be swapped. However, there is no immediate change to the current pin
assignments.
Architecture Support
All architectures
Applicable Objects
• LUT Cells (get_cells)
° The list of possible instance pins ranges from I0 for a LUT1, to I0 through I5 for a
LUT6. The physical pins range from A6 (fastest) to A1 for a 6LUT and A5 (fastest) to
A1 for a 5LUT.
TIP: The ISE supported values of ALL, or no value to imply ALL, are not supported in the Vivado Design
Suite. To lock ALL pins, each pin must be explicitly specified. Any unlisted logical pins are mapped to a
physical pin using the default mapping.
Syntax
Verilog Syntax
LOCK_PINS values can be assigned as a Verilog attribute placed on instantiated LUT cells
(e.g. LUT6, LUT5, etc).
The following example defines LOCK_PINS with pin mapping logical I1 to A5, and logical I2
to A6, on a LUT cell LUT_inst_0:
Verilog Example
module top (
i0,
i1,
i2,
i3,
i4,
i5,
o0);
input i0;
input i1;
input i2;
input i3;
input i4;
input i5;
output o0;
(* LOCK_PINS = "I1:A5,I2:A6" *)
LUT6 #(
.INIT(64'h0000000000000001))
LUT_inst_0
(.I0(i0),
.I1(i1),
VHDL Syntax
LOCK_PINS values can be assigned as a VHDL attribute placed on instantiated LUT cells (e.g.
LUT6, LUT5, etc).
The following example defines LOCK_PINS with pin mapping logical I1 to A5, and logical I2
to A6, on a LUT cell LUT_inst_0:
VHDL Example:
entity top is port (
i0, i1, i2, i3, i4, i5 : in std_logic;
o0 : out std_logic
);
end entity top;
begin
LUT_inst_0 : LUT6 generic map (
INIT => "1"
) port map (
I0 => i0,
I1 => i1,
I2 => i2,
I3 => i3,
I4 => i4,
I5 => i5,
O => o0
);
end architecture struct;
XDC Syntax
The LOCK_PINS property can be set on LUT cells using the set_property Tcl command in the
Vivado Design Suite:
Where:
IMPORTANT: XDC requires white space separation between pin pairs to satisfy the Tcl list syntax, while
HDL syntax requires comma-separated values.
Affected Steps
• phys_opt_design
• route_design
See Also
BEL, page 38
DONT_TOUCH, page 56
LOC, page 97
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
° SRL (SRL16E)
° LUTRAM (RAM32X1S)
Values
A unique group name
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the instantiation of a LUT. The Verilog
attribute must be used in pairs in the same logical hierarchy.
(* LUTNM = "group_name" *)
VHDL Syntax
Declare the VHDL attribute as follows:
Where
The VHDL attribute must be used in pairs in the same logical hierarchy.
XDC Syntax
set_property LUTNM group_name [get_cells instance_name]
Where
Affected Steps
place_design
See Also
HLUTNM
Architecture Support
All architectures
Applicable Objects
• Nets (get_nets)
Values
• TRUE
• FALSE
Syntax
Verilog Syntax
To set this attribute, place the proper Verilog attribute syntax before the top-level output
port declaration:
(* MARK_DEBUG = "{TRUE|FALSE}" *)
Where
XDC Syntax
set_property MARK_DEBUG value [get_nets net_name]
Where
Affected Steps
• place_design
• ChipScope
See Also
DONT_TOUCH
RECOMMENDED: To assign I/O ports to physical pins on the device package, use the PACKAGE_PINS
property rather than LOCS. Use the LOC property to assign logic cells to device resources on the target
Xilinx FPGA.
Architecture Support
All architectures
Applicable Objects
• Ports (get_ports)
Values
Package pin name
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the port declaration:
(* PACKAGE_PIN = "pin_name" *)
VHDL Syntax
Declare the VHDL attribute as follows:
XDC Syntax
set_property PACKAGE_PIN pin_name [get_ports port_name]
Affected Steps
• Pin planning
• place_design
See Also
LOC
A Pblock is a collection of cells, and one or more rectangular areas or regions that specify
the device resources contained by the Pblock. Pblocks are used during floorplanning
placement to group related logic and assign it to a region of the target device. Refer to the
Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906) [Ref 8] for
more information on the use of Pblocks in floorplanning your design.
Pblocks are created using the create_pblock Tcl command, and are populated with cells
using the add_cells_to_pblock command. The following code defines a Pblock:
create_pblock Pblock_usbEngine
add_cells_to_pblock [get_pblocks Pblock_usbEngine] [get_cells -quiet [list
usbEngine1]]
resize_pblock [get_pblocks Pblock_usbEngine] -add {SLICE_X8Y105:SLICE_X23Y149}
resize_pblock [get_pblocks Pblock_usbEngine] -add {DSP48_X0Y42:DSP48_X1Y59}
resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB18_X0Y42:RAMB18_X1Y59}
resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB36_X0Y21:RAMB36_X1Y29}
The second line assigns logic cells to the Pblock. In this case, all of the cells in the specified
hierarchical module are assigned to the Pblock. Cells that are assigned to a specific Pblock
are assigned the PBLOCK property.
The subsequent commands, resize_pblock, define the size of the Pblock by specifying a
range of device resources that are contained inside the Pblock. A pblock has a grid of four
device resource types: SLICE, DSP48, RAMB18, RAMB36. Logic that does not match one of
these device types can be placed anywhere in the device. To constrain just the Block RAMs
in the level of hierarchy, disable (or simply do not define) the other Pblock grids.
Refer to the Vivado Design Suite Tcl Command Reference Guide (UG835) [Ref 4] for details on
the specific Tcl commands mentioned above.
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
XDC Syntax
The Pblock can be defined in the XDC file, or directly in the design, with the Tcl command:
create_pblock <pblock_name>
XDC Example
create_pblock Pblock_usbEngine
add_cells_to_pblock [get_pblocks Pblock_usbEngine] [get_cells -quiet [list
usbEngine1]]
resize_pblock [get_pblocks Pblock_usbEngine] -add {SLICE_X8Y105:SLICE_X23Y149}
resize_pblock [get_pblocks Pblock_usbEngine] -add {DSP48_X0Y42:DSP48_X1Y59}
resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB18_X0Y42:RAMB18_X1Y59}
resize_pblock [get_pblocks Pblock_usbEngine] -add {RAMB36_X0Y21:RAMB36_X1Y29}
Affected Steps
• Design Floorplanning
• place_design
See Also
BEL, page 38
LOC, page 97
Enabling the POST_CRC property controls the generation of a pre-computed CRC value in the
bitstream. As the configuration data frames are loaded, the device calculates a Cyclic Redundancy
Check (CRC) value from the configuration data packets. After the configuration data frames are
loaded, the configuration bitstream can issue a Check CRC instruction to the device, followed by
the pre-computed CRC value. If the CRC value calculated by the device does not match the
expected CRC value in the bitstream, the device pulls INIT_B Low and aborts configuration. For
more information refer to the 7 Series FPGA Configuration User Guide (UG470) [Ref 1].
When CRC is disabled a constant value is inserted in the bitstream in place of the CRC, and the
device does not calculate a CRC.
Architecture Support
• Artix-7
• Virtex-7
• Kintex-7
Applicable Objects
• Design (current_design)
Values
• DISABLE: Disables the Post CRC checking feature (default).
• ENABLE: Enables the Post CRC checking feature.
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
Affected Steps
• write_bitstream
• launch_runs
See Also
POST_CRC_ACTION, page 114
During readback, the syndrome bits are calculated for every frame. If a single bit error is detected,
the readback is stopped immediately. If correction is enabled using the POST_CRC_ACTION
property, then the readback CRC logic performs correction on single bit errors. The frame in error
is readback again, and using the syndrome information, the bit in error is fixed and written back
to the frame. If the POST_CRC_ACTION is set to Correct_And_Continue, then the readback logic
starts over from the first address. If the Correct_And_Halt option is set, the readback logic stops
after correction. Refer to the 7 Series FPGA Configuration User Guide (UG470) [Ref 1].
Architecture Support
• Artix-7
• Virtex-7
• Kintex-7
Applicable Objects
• Design (current_design)
Values
• HALT: If a CRC mismatch is detected, stop reading back the bitstream, stop computing the
comparison CRC, and stop making the comparison against the pre-computed CRC.
• CONTINUE: If a CRC mismatch is detected by the CRC comparison, continue reading back
the bitstream, computing the comparison CRC, and making the comparison against the
pre-computed CRC.
• CORRECT_AND_CONTINUE: If a CRC mismatch is detected by the CRC comparison, it is
corrected and continues reading back the bitstream, computing the comparison CRC, and
making the comparison against the pre-computed CRC.
• CORRECT_AND_HALT: If a CRC mismatch is detected, it is corrected and stops reading back
the bitstream, computing the comparison CRC, and making the comparison against the
pre-computed CRC.
VHDL Syntax
Not applicable
XDC Syntax
set_property POST_CRC_ACTION <VALUE> [get_ports port_name]
Where:
Affected Steps
• write_bitstream
• launch_runs
See Also
POST_CRC, page 112
This property is only applicable when POST_CRC is set to ENABLE. Enabling the POST_CRC
property controls the periodic comparison of a pre-computed CRC value in the bitstream with an
internal CRC value computed by readback of the configuration memory cells.
The POST_CRC_FREQ defines the frequency in MHz of the readback function, with a default value
of 1 MHz.
Architecture Support
• Artix-7
• Virtex-7
• Kintex-7
Applicable Objects
• Design (current_design)
Values
• Specify the frequency in MHz as an integer with one of the following accepted values:
° 1 2 3 4 6 7 8 10 12 13 16 17 22 25 26 27 33 40 44 50 66 100
° Default = 1 MHz
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
Where:
Affected Steps
• write_bitstream
• launch_runs
See Also
POST_CRC, page 112
The error condition is always available from the FRAME_ECC site. However, when the
POST_CRC_INIT_FLAG is ENABLED, which is the default, the INIT_B pin also flags the CRC
error condition when it occurs.
Architecture Support
• Artix-7
• Virtex-7
• Kintex-7
Applicable Objects
• Design (current_design)
Values
• DISABLE: Disables the use of the INIT_B pin, with the FRAME_ECC site as the sole source
of the CRC error signal.
• ENABLE: Leaves the INIT_B pin enabled as a source of the CRC error signal. (Default)
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
XDC Syntax
set_property POST_CRC_INIT_FLAG ENABLE | DISABLE [curent_design]
Affected Steps
• write_bitstream
• launch_runs
See Also
POST_CRC, page 112
Enabling the POST_CRC property controls the generation of a pre-computed CRC value in the
bitstream. As the configuration data frames are loaded, the device calculates a Cyclic Redundancy
Check (CRC) value from the configuration data packets. The POST_CRC_SOURCE property defines
the expected CRC value as either coming from a pre-computed value, or as being taken from the
configuration data in the first readback pass.
Architecture Support
• Artix-7
• Virtex-7
• Kintex-7
Applicable Objects
• Design (current_design)
Values
• PRE_COMPUTED: Determine an expected CRC value from the bitstream. (Default)
• FIRST_READBACK: Extract the actual CRC value from the first readback pass, to use for
comparison with future readback iterations.
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
Affected Steps
• write_bitstream
• launch_runs
See Also
POST_CRC, page 112
Architecture Support
All architectures
Applicable Objects
• Sites (get_sites)
• BELs (get_bels)
Values
1
Syntax
Verilog Syntax
Not applicable
VHDL Syntax
Not applicable
XDC Syntax
set_property PROHIBIT 1 [get_sites site]
Affected Steps
• I/O planning
• place_design
Input buffers (e.g., IBUF), 3-state output buffers (e.g., OBUFT), and bidirectional buffers
(e.g., IOBUF) can have a weak pull-up resistor, a weak pull-down resistor, or a weak “keeper”
circuit. This feature can be invoked by adding the one of the following properties to the net
object connected to the buffer:
• PULLUP
• PULLDOWN
• KEEPER
For more information see Vivado Design Suite 7 Series FPGA Libraries Guide (UG953) [Ref 9].
Architecture Support
All
Applicable Objects
• Nets connected to I/O Buffers (get_nets)
Values
• TRUE | YES: Use a pulldown circuit to avoid signal floating when not being driven.
• FALSE | NO: Do not use a pulldown circuit. Default.
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the module or instantiation. Specify as
follows:
XDC Syntax
set_property PULLDOWN {TRUE|FALSE} [get_nets net_name]
Where
Affected Steps
• Logical to Physical Mapping
See Also
KEEPER, page 95
Input buffers (e.g., IBUF), 3-state output buffers (e.g., OBUFT), and bidirectional buffers
(e.g., IOBUF) can have a weak pull-up resistor, a weak pull-down resistor, or a weak “keeper”
circuit. This feature can be invoked by adding the one of the following properties to the net
object connected to the buffer:
• PULLUP
• PULLDOWN
• KEEPER
For more information see Vivado Design Suite 7 Series FPGA Libraries Guide (UG953) [Ref 9].
Architecture Support
All
Applicable Objects
• Nets connected to I/O Buffers (get_nets)
Values
• TRUE | YES: Use a pullup circuit to avoid signal floating when not being driven.
• FALSE | NO: Do not use a pullup circuit. Default.
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the module or instantiation. Specify as
follows:
XDC Syntax
set_property PULLUP {TRUE|FALSE} [get_nets net_name]
Where
Affected Steps
• Logical to Physical Mapping
See Also
KEEPER, page 95
The REF_NAME property is defined automatically by the Vivado Design Suite, and can not
be modified by the user in either HDL or XDC. It is intended for reference only.
The property does not influence any steps but is very useful in defining filters and other
Vivado Tcl command queries to identify specific cells or other objects.
For example, to select the clock pins on RAM cells, you can filter the pin objects based on
the REF_NAME property of the cells:
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Values
Not applicable
Syntax
Not applicable
Affected Steps
None
The REF_PIN_NAME is automatically defined from the NAME or HIERARCHICAL NAME of the
pin, and can not be modified by the user in either HDL or XDC. It is intended for reference
only.
The property does not influence any steps but is very useful in defining filters and other
Vivado Tcl command queries to identify specific cells or other objects.
Architecture Support
All architectures
Applicable Objects
• Pins (get_pins)
Values
Not applicable
Syntax
Not applicable
Affected Steps
None
When RLOC is present in the RTL source files, the H_SET, HU_SET, or U_SET properties get
translated into a read-only RPM property on cells in the synthesized netlist. The RLOC
property is preserved, but becomes a read-only property after synthesis. For more
information on using these properties, and defining RPMs, refer to the Vivado Design Suite
User Guide: Using Constraints (UG903) [Ref 6].
You can define the placement of any element within the set relative to other elements in the
set, regardless of the eventual placement of the entire group onto the target device. For
example, if RLOC constraints are applied to a group of eight flip-flops organized in a
column, the mapper maintains the column and moves the entire group of flip-flops as a
single unit. In contrast, the LOC constraint specifies the absolute location of a design
element on the target device, without reference to other design elements.
Architecture Support
All architectures
Applicable Objects
• Instances or Modules in the RTL source files.
Values
The Relative Location constraint is specified using a slice-based XY coordinate system.
RLOC=XmYn
Where:
TIP: Because the X and Y numbers in Relative Location (RLOC) constraints define only the order and
relationship between design elements, and not their absolute locations on the target device, their
numbering can include negative integers.
Verilog Example
The following Verilog module defines RLOC property for the shift register Flops in the ffs
hierarchical module.
endmodule // inv
module ffs
(
input clk,
input d,
output q
);
assign q = outr;
endmodule // ffs
TIP: In the preceding example, the presence of the RLOC property implies the use of the H_SET property
on the FD instances in the ffs hierarchical module.
When using the modules defined in the preceding example, you will need to specify the
KEEP_HIERARCHY property to instances of the ffs module to preserve the hierarchy and
define the RPM in the synthesized design:
module top
(
input clk,
input d,
output q
);
endmodule // top
VHDL Syntax
Declare the VHDL constraint as follows:
Where:
TIP: You can use the create_macro and update_macro commands to define macro objects in the
Vivado Design Suite, that act like RPMs within the design. Refer to the Vivado Design Suite Tcl
Command Reference (UG835) [Ref 4] for more information on these commands.
Affected Steps
• Logical to Physical Mapping
• place_design
• synth_design
See Also
H_SET and HU_SET, page 65
Like relatively placed macros (RPMs), XDC macros enable relative placement of groups of
cells. Macros are similar to RPMs in many ways, yet also have significant differences:
• RPMs are defined in the RTL source files by a combination of the RLOC property and
the H_SET, HU_SET, or U_SET property.
• RPMs cannot be edited in the post-synthesis design.
• Macros are created from leaf cells that are grouped together with relative placement,
after synthesis, and can be edited.
• RPMs cannot be automatically converted to macros.
• RPMs are not design objects, and the XDC macro commands cannot be used on RPMs.
The RLOCS property reflects the relative placement values specified by the update_macro
command, as represented by the rlocs argument:
You can use update_macro command to change the RLOCS property assigned to an XDC
macro object.
The RLOCS property is converted to an RLOC property on each of the individual cells that
are part of the XDC macro. The RLOC property then functions in the same way it does for an
RPM, by defining the relative placement of cells in the macro.
Architecture Support
All architectures
Applicable Objects
• Cells (get_cells)
Values
• Cell1 RLOC1 Cell2 RLOC2 Cell3 RLOC3...: The name of a cell in the macro paired with the
relative location of the cell in the macro, defined for each cell in the macro.
VHDL Syntax
Not applicable
XDC Syntax
The RLOCS property is indirectly defined when an XDC macro is created and populated with
cells and relative locations:
XDC Example
create_macro macro1
update_macro macro1 {u1/sr3 X0Y0 u1/sr4 X1Y0 u1/sr5 X0Y1}
Affected Steps
• Logical to Physical Mapping
• place_design
• synth_design
See Also
H_SET and HU_SET, page 65
RPMs are defined by assigning design elements to a set using the H_SET, HU_SET, or U_SET
proeprties in the RTL design. The design elements are then assigned a relative placement to
one another using the RLOC property. You can define the relative placement of any element
within the set relative to other elements in the set, regardless of the eventual placement of
the entire group onto the target device.
Having defined the elements of an RPM, and their relative placement, the RLOC_ORIGIN
property lets you define the absolute placement of the RPM onto the target device. The
RLOC_ORIGIN property is converted into LOC constraint during synthesis.
In the Vivado Design Suite, the RLOC_ORIGIN property defines the lower-left corner of the
RPM. This is most often the design element whose RLOC property is X0Y0. Each remaining
cell in the RPM set is placed on the target device using its relative location (RLOC) as an
offset from the group origin (RLOC_ORIGIN).
Architecture Support
All architectures.
Applicable Objects
• Instances within the RTL source file.
Values
The Relative Location constraint is specified using a slice-based XY coordinate system.
RLOC_ORIGIN=XmYn
Where:
Verilog Example
The following top-level Verilog module defines the RLOC_ORIGIN property for the ffs
modules in the design.
module top
(
input clk,
input d,
output q
);
endmodule // top
The following example is very similar to the first, except that the RLOC_ORIGIN is only
assigned to the first ffs module, u0, and the rest are defined with RLOC properties for
relative placement:
module top
(
input clk,
input d,
output q
);
endmodule // top
Where:
XDC Syntax
The RLOC_ORIGIN property translates to the LOC property in the synthesized design. You
can specify the LOC property of RPMs by placing one of the elements of the RPM onto the
target device. The other elements of the RPM will be placed relative to that location, and
assigned to LOC property.
Affected Steps
• Logical to Physical Mapping
• place_design
• synth_design
See Also
H_SET and HU_SET, page 65
The property can be queried by the individual net, or group of nets, using the
get_property or report_property commands.
Architecture Support
All architectures.
Applicable Objects
• Nets (get_nets)
Values
• ROUTED: The net is fully placed and routed.
• PARTIAL: All pins and/or ports for the net are placed and some of the net is routed, but
portions of the net are unrouted and route_design should be run.
• UNPLACED: The route has some unplaced pins or ports, and place_design should be
run to complete the placement.
• UNROUTED: All pins and/or ports for the net are placed, but no route data exists on the
net, and route_design should be run to complete the route.
• INTRASITE: The entire route is completed within the same Site on the target device, and
no routing resources were required to complete the connection. This is not an error.
• NOLOADS: The route either has no logical loads, or has no routable load pins, and so
needs no routing. This is not an error.
• NODRIVER: The route either has no logical driver, or has no routable driver, and so
needs no routing. This is a design error.
• HIERPORT: The route is connected to a top-level hierarchical port that either has no
routable loads or no routable drivers. This is not an error.
• ANTENNAS: The route has at least one antenna (a branch leaf that connects to a site
pin, but that site pin does not show that it is connected to this logical net) or the route
has at least one island (a section of routing that is not connected to any of the site pins
associated with the logical net). This is a routing error.
° Routing conflict: One or more of the nodes in this route are also used in some other
route, or another branch of this route.
° Site pin conflict: The logical net that is connected to the given site pin from inside
the site is different from the logical net that is connected via the route to the
outside of the site.
° Invalid site conflict: The route connects to a site pin on a site where the
programming of the site is in an invalid state, making it impossible to determine if
the route is connected correctly within the site.
• ERROR: There was an internal error in determining the route status.
• NONET: The net object specified for route status does not exist, or could not be found
as entered.
• NOROUTE: No routing object could be retrieved for the specified net due to an error.
• NOROUTESTORAGE: No route storage object is available for this device due to an error.
• UNKNOWN: The state of the route can not be calculated due to an error.
Syntax
The ROUTE_STATUS property is an enumerated property with one of the preceding property
values. It is a read-only property assigned by the Vivado router and cannot be directly
modified.
Affected Steps
• Route Design
When RLOC is also present in the RTL source files, the H_SET, HU_SET, and U_SET properties
get translated to a read-only RPM property on cells in the synthesized netlist. The HU_SET
and U_SET property are visible on the RTL source file in the Text editor in the Vivado Design
Suite. However, in the Properties window of a cell object, the RPM property is displayed. For
more information on using these properties, and defining RPMs, refer to the Vivado Design
Suite User Guide: Using Constraints (UG903) [Ref 6].
Architecture Support
All architectures.
Applicable Objects
• Cells in the synthesized design (get_cells)
Values
• NAME: The name of the RPM as it is derived from the set definition by the presence of
the RLOC property together with the H_SET, HU_SET, or U_SET property in the RTL
source files.
Syntax
The RPM property is a read-only property derived during synthesis of an RTL design with
RLOC defined together with one of H_SET, HU_SET, or U_SET to define the RPM. The RPM
property cannot be directly defined or edited.
See Also
H_SET and HU_SET, page 65
The RPM_GRID values are visible in the Site Properties window of the Vivado Integrated
Design Environment (IDE) when a specific site is selected in the Device window. The
coordinates can also be queried with Tcl commands using the RPM_X and RPM_Y site
properties. For more information on using the RPM_GRID property, and defining RPMs with
absolute coordinates, refer to the Vivado Design Suite User Guide: Using Constraints
(UG903) [Ref 6].
Architecture Support
All architectures.
Applicable Objects
• Cells (get_cells)
Values
• ”GRID”: The RPM_GRID property and GRID keyword combine to inform the Vivado
Design Suite that the specified RLOCs are absolute grid coordinates from the target
device, rather than the relative coordinates usually specified by RLOC.
Syntax
Verilog Syntax
Place the Verilog attribute immediately before the module or instantiation. Specify as
follows:
(* RPM_GRID = "GRID" *)
Verilog Example
module iddr_regs
(
input clk, d,
output y, z
);
endmodule // iddr_regs
VHDL Syntax
To use the RPM_GRID system, first define the attribute, then add the attribute to one of the
design elements:
XDC Syntax
The RPM_GRID property is assigned in the RTL source file, and cannot be defined in XDC
files or with Tcl commands. However, for XDC macros, the corresponding construct is the
-absolute_grid option used with the update_macros command.
Affected Steps
• Logical to Physical Mapping
• place_design
• synth_design
See Also
H_SET and HU_SET, page 65
Architecture Support
All architectures.
Applicable Objects
• Ports (get_ports)
Values
• SLOW (default)
• FAST
Syntax
Verilog Syntax
To set this attribute when inferring I/O buffers, place the proper Verilog attribute syntax
before the top-level output port declaration.
(* DRIVE = "{SLOW|FAST}" *)
To set SLEW when the output or bidirectional buffer is instantiated, assign the SLEW
parameter on the instantiated output buffer.
RECOMMENDED: Use the instantiation template from the Language Templates or the Vivado Design
Suite 7 Series FPGA Libraries Guide (UG953) [Ref 9] to specify the proper syntax.
VHDL Syntax
To set this attribute when inferring I/O buffers, place the proper VHDL attribute syntax
before the top-level output port declaration.
Where
To set SLEW when the output or bidirectional buffer is instantiated, assign the SLEW generic
on the instantiated output buffer.
RECOMMENDED: Use the instantiation template from the Language Templates or the Vivado Design
Suite 7 Series FPGA Libraries Guide (UG953) [Ref 9] to specify the proper syntax.
XDC Syntax
set_property SLEW value [get_ports port_name]
Where
Affected Steps
• I/O Planning
• Report Noise
• Report Power
See Also
Refer to the following design elements in the Vivado Design Suite 7 Series FPGA Libraries
Guide (UG953) [Ref 9].
• OBUF
• OBUFT
• IOBUF
• IOBUF_DCIEN
• IOBUF_INTERMDISABLE
U_SET is an attribute within the HDL design source files, and does not appear in the
synthesized or implemented design. U_SET is used when defining Relatively Placed Macros,
or RPMs in the RTL design. For more information on using these properties, and defining
RPMs, refer to the Vivado Design Suite User Guide: Using Constraints (UG903) [Ref 6].
While H_SET or HU_SET are used to define sets of logic elements based on the design
hierarchy, you can manually create a User-defined set of logic elements, or U_SET, that is
not dependant on the hierarchy of the design.
When RLOC is also present in the RTL source files, the H_SET, HU_SET, and U_SET properties
get translated to a read-only RPM property on cells in the synthesized netlist. The HU_SET
and U_SET property are visible on the RTL source file in the Text editor in the Vivado Design
Suite. However, in the Properties window of a cell object, the RPM property is displayed.
IMPORTANT: When attached to hierarchical modules, the U_SET constraint propagates downward
through the hierarchy to any primitive symbols that are assigned RLOC constraints.
Architecture Support
All architectures.
Applicable Objects
The U_Set constraint may be used in one or more of the following design elements, or
categories of design elements. Refer to the Vivado Design Suite 7 Series FPGA Libraries
Guide (UG953) [Ref 9] for more information on the specific design elements:
• Registers
• FMAP
• Macro Instance
• ROM
• RAMS
• RAMD
• MULT18X18S
• RAMB4_Sm_Sn
Values
• NAME: A unique name for the U_SET.
Syntax
Verilog Syntax
This is a Verilog attribute used in combination with the RLOC property to define the set
content of a hierarchical block that will define an RPM in the synthesized netlist. Place the
Verilog attribute immediately before the instantiation of a logic element.
Verilog Example
The following Verilog module defines RLOC and U_SET properties for the shift register flops
in the module.
module ffs (
input clk,
input d,
output q
);
assign q = outr;
endmodule // ffs
Unlike the HU_SET property, which applies to the level of hierarchy it is defined in, the
U_SET property transcends hierarchy. In this case, the following top-level module defines
three instances of the ffs module, but results in only two U_SETS being created: Uset_0 and
Uset_1, which contain Flops from all three ffs module instances defined below:
module top (
input clk,
input d,
output q
);
endmodule // top
VHDL Syntax
Declare the VHDL attribute as follows:
Where:
TIP: You can use the create_macro and update_macro commands to define macro objects in the
Vivado Design Suite, that act like RPMs within the design. Refer to the Vivado Design Suite Tcl
Command Reference (UG835) [Ref 4] for more information on these commands.
Affected Steps
• Design Floorplanning
• place_design
• synth_design
See Also
KEEP_HIERARCHY, page 93
For example, you could use the USED_IN property to specify an XDC file for use by the
Vivado synthesis tool, but not for use in implementation. You could also specify HDL source
files (.v or .vhd) as USED_IN simulation, but not for use in synthesis.
You can also use the more granular values to specify an unmanaged Tcl file to be USED_IN
opt_design or place_design, rather than simply used in implementation.
Architecture Support
All architectures
Applicable Objects
• Files
Values
• synthesis
• implementation
• simulation
• out_of_context
• opt_design
• power_opt_design
• place_design
• phys_opt_design
• route_design
• write_bitstream
• post_write_bitstream
• synth_blackbox_stub
Syntax
Verilog Syntax
Not applicable.
VHDL Syntax
Not applicable.
XDC Syntax
set_property USED_IN {<value>} [get_files <files>]
Where
Affected Steps
• Synthesis
• Simulation
• Implementation
• Bitstream generation
DRCs are available to ensure that VCCAUX_IO property assignments are correct:
• VCCAUXIOBT (warning): ensures that ports with VCCAUX_IO values of NORMAL or HIGH
are only placed in HP banks.
• VCCAUXIOSTD (warning): ensures that ports with VCCAUX_IO values of NORMAL or
HIGH do not use IOSTANDARDs that are only supported in HR banks.
• VCCAUXIO (error): ensures that ports with VCCAUX_IO values of NORMAL are not
constrained/placed in the same bank as a port with a VCCAUX_IO value of HIGH.
Architecture Support
All architectures on High Performance (HP) bank I/O only.
Applicable Objects
• Ports (get_ports)
• Cells (get_cells)
° I/O buffers
Values
• DONTCARE (default)
• NORMAL
• HIGH
Syntax
Verilog Syntax
To set this attribute, place the proper Verilog attribute syntax before the top-level output
port declaration.
(* VCCAUXIO = "{DONTCARE|NORMAL|HIGH}" *)
Where
XDC Syntax
set_property VCCAUX_IO value [get_ports port_name]
Where
Affected Steps
• I/O Planning
• place_design
• Report Power
Additional Resources
Xilinx Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see the
Xilinx® Support website at:
www.xilinx.com/support.
www.xilinx.com/company/terms.htm.
Solution Centers
See the Xilinx Solution Centers for support on devices, software tools, and intellectual
property at all stages of the design cycle. Topics include design assistance, advisories, and
troubleshooting tips.
References
The following documents provide supplemental material to this guide: