Virtex Primitive Support

Virtex Primitive Support

XST enables you to instantiate Virtex primitives directly in your VHDL/Verilog code. Virtex primitives such as MUXCY_L, LUT4_L, CLKDLL, RAMB4_S1_S16, IBUFG_PCI33_5, and NAND3b2 can be manually inserted in your HDL design through instantiation. These primitives are not by default optimized by XST and are available in the final NGC file. Use the Optimize Instantiated Primitives synthesis option to optimize instantiated primitives and obtain better results. Timing information is available for most of the primitives, allowing XST to perform efficient timing-driven optimization.

Some of these primitives can be generated through attributes.

BUFFER_TYPE (CLOCK_BUFFER) can be assigned to the primary input or internal signal to force the use of BUFGDLL, IBUFG, BUFR or BUFGP. The same constraints can be used to disable buffer insertion.

IOSTANDARD can be used to assign an I/O standard to an I/O primitive. For example:

// synthesis attribute IOSTANDARD of in1 is PCI33_5

assigns PCI33_5 I/O standard to the I/O port.

The primitive support is based on the notion of the black box. Refer to "Safe FSM Implementation" in Chapter 2 for the basics of the black box support.

There is a significant difference between black box and primitive support. Assume you have a design with a submodule called MUXF5. In general, the MUXF5 can be your own functional block or a Virtex primitive. So, to avoid confusion about how XST interprets this module, use a special constraint, called BOX_TYPE. This attribute must be attached to the component declaration of MUXF5.

If the BOX_TYPE attribute is attached to the MUXF5 with a value of:

primitive, or black_box, XST tries to interpret this module as a Virtex primitive and use its parameters, for instance, in critical path estimation.

user_black_box, XST processes it as a regular user black box. If the name of the user black box is the same as that of a Virtex primitive, XST renames it to a unique name and generates a warning message with the reason for the warning. For example, MUX5 could be renamed to MUX51 as in the following log sample:

...

================================================================

* Low Level Synthesis *

================================================================

WARNING:Xst:79 - Model 'muxf5' has different characteristics in destination library

WARNING:Xst:80 - Model name has been changed to 'muxf51'

...

If the BOX_TYPE attribute is not attached to the MUXF5. Then XST processes this block as a user hierarchical block. If the name of the user black box is the same as that of a Virtex primitive, XST renames it to a unique name and then generates a warning message with the reason for the warning.

To simplify the instantiation process, XST comes with VHDL and Verilog Virtex libraries. These libraries contain the complete set of Virtex primitives declarations with a BOX_TYPE constraint attached to each component. If you use:

VHDL—You must declare library "unisim" with its package "vcomponents" in your source code.

library unisim;

use unisim.vcomponents.all;

The source code of this package can be found in the vhdl\src\unisims_vcomp.vhd file of the XST installation.

Verilog— Starting in release 6.1i, the "unisim" library is already precompiled and XST automatically links it with your design.

Please note that you must use UPPERCASE for generic (VHDL) and parameter (Verilog) values when instantiating primitives.

For example the ODDR element has the following component declaration in UNISIM library:

component ODDR

generic

(DDR_CLK_EDGE : string := "OPPOSITE_EDGE";

INIT : bit := '0';

SRTYPE : string := "SYNC");

port(Q : out std_ulogic;

C : in std_ulogic;

CE : in std_ulogic;

D1 : in std_ulogic;

D2 : in std_ulogic;

R : in std_ulogic;

S : in std_ulogic);

end component;

When you instantiate this primitive in your code, the values of DDR_CLK_EDGE and SRTYPE generics must be in uppercase. If not, XST generates a Warning message stating that unknown values are used.

Some primitives, like LUT1, enable you to use an INIT during instantiation. There are two ways to pass an INIT to the final netlist.

Attach an INIT attribute to the instantiated primitive.

Pass the INIT via the generics mechanism in VHDL, or the parameters mechanism in Verilog. Xilinx recommends this method, as it allows you to use the same code for synthesis and simulation.

VHDL Code

These coding examples are accurate as of the date of publication. You can download any updates to these examples from ftp://ftp.xilinx.com/pub/documentation/misc/examples_v7.zip

Following is the VHDL code for passing an INIT value via the INIT constraint.
--
-- Passing an INIT value via the INIT constraint.
--

library ieee;
use ieee.std_logic_1164.all;

library unisim;
use unisim.vcomponents.all;

entity primitive_1 is
    port(I0,I1 : in std_logic;
         O     : out std_logic);
end primitive_1;

architecture beh of primitive_1 is

    attribute INIT: string;
    attribute INIT of inst: label is "1";

begin

    inst: LUT2 port map (I0=>I0,I1=>I1,O=>O);

end beh;
Following is the VHDL code for passing an INIT value via the generics mechanism.
--
-- Passing an INIT value via the generics mechanism.
--

library ieee;
use ieee.std_logic_1164.all;

library unisim;
use unisim.vcomponents.all;

entity primitive_2 is
    port(I0,I1 : in std_logic;
         O    : out std_logic);
end primitive_2;

architecture beh of primitive_2 is
begin

    inst: LUT2 generic map (INIT=>"1")
          port map (I0=>I0,I1=>I1,O=>O);

end beh;
Verilog Code

These coding examples are accurate as of the date of publication. You can download any updates to these examples from ftp://ftp.xilinx.com/pub/documentation/misc/examples_v7.zip

Following is the Verilog code for passing an INIT value via the INIT constraint.
//
// Passing an INIT value via the INIT constraint.
//

module v_primitive_1 (I0,I1,O);
    input I0,I1;
    output O;

    LUT2 inst (.I0(I0), .I1(I1), .O(O));

    // synthesis attribute INIT of inst is "1"

endmodule
Following is the Verilog code for passing an INIT value via the parameters mechanism
.

//
// Passing an INIT value via the parameters mechanism.
//

module v_primitive_2 (I0,I1,O);
    input I0,I1;
    output O;

    LUT2 #(4'h1) inst (.I0(I0), .I1(I1), .O(O));

endmodule
Following is the Verilog code for passing an INIT value via the defparam mechanism
.

//
// Passing an INIT value via the defparam mechanism.
//

module v_primitive_3 (I0,I1,O);
    input I0,I1;
    output O;

    LUT2 inst (.I0(I0), .I1(I1), .O(O));
    defparam inst.INIT = 4'h1;

endmodule
Log File

XST does not issue any message concerning instantiation of Virtex primitives during HDL synthesis because the BOX_TYPE attribute with its value, primitive, is attached to each primitive in the UNISIM library.

Please note that if you instantiate a block (non primitive) in your design and the block has no contents (no logic description) or the block has a logic description, but you attach a BOX_TYPE constraint to it with a value of user_black_box, XST issues a warning message as in the following log file sample:

...

Analyzing Entity <black_b> (Architecture <archi>).

WARNING : (VHDL_0103). c:\jm\des.vhd (Line 23). Generating a Black Box for component <my_block>.

Entity <black_b> analyzed. Unit <black_b> generated.

...

Related Constraints

Related constraints are BOX_TYPE and the various PAR constraints that can be passed from HDL to NGC without processing.