General Constraints

This section lists various constraints that you can use with XST. These constraints apply to FPGAs, CPLDs, VHDL, and Verilog. You can set some of these options under the Synthesis Options tab of the Process Properties dialog box in Project Navigator. See "Constraints Summary" for a complete list of constraints supported by XST.

Add I/O Buffers

Add I/O Buffers, (–iobuf) enables or disables I/O buffer insertion. XST automatically inserts Input/Output Buffers into the design. You can manually instantiate I/O Buffers for some or all the I/Os, and XST will insert I/O Buffers only for the remaining I/Os. If you do not want XST to insert any I/O Buffers, set this option to no. This option is useful to synthesize a part of a design to be instantiated later on.

IOBUF enables or disables I/O buffer insertion. Allowed values are yes, no. By default, buffer insertion is enabled (yes).

When the yes value is selected, IBUF and OBUF primitives are generated. IBUF/OBUF primitives are connected to I/O ports of the top-level module. When XST is called to synthesize an internal module that will be instantiated later in a larger design, you must select the no this option. If I/O buffers are added to a design, this design cannot be used as a submodule of another design.

Architecture Support

The following table indicates supported and unsupported architectures.

Architecture	Supported/Unsupported
Virtex	Yes
Virtex-E	Yes
Spartan-II	Yes
Spartan-IIE	Yes
Spartan-3	Yes
Virtex-II	Yes
Virtex-II Pro	Yes
Virtex-II Pro X	Yes
XC9500, XC9500XL, XC9500XV	Yes
CoolRunner XPLA3	Yes
CoolRunner-II	Yes

Applicable Elements

Add I/O Buffers can only be applied globally.

Propagation Rules

Applies to all buffers inserted into a design.

Syntax Examples

XST Command Line

Define globally with the –iobuf command line option of the run command. Following is the basic syntax:

-iobuf {yes|no}

The default is yes.

Project Navigator

Specify globally with the Add IO Buffers option in the Xilinx Specific Options tab of the Process Properties dialog box within the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Box Type

BOX_TYPE is a synthesis constraint. It currently takes three possible values: primitive, black_box, and user_black_box, which instruct XST not to synthesize the behavior of a module. Please note that the black_box value is equivalent to primitive and will eventually become obsolete.

The main difference between the primitive (black_box) and user_black_box is that if the user_black_box value is specified, XST reports inference of a black box in the LOG file, but does not do this if primitive is specified.

Please not that if the box_type is applied to at least a single instance of a block at a particular hierarchical level, then box_type is propagated to all other instances of this block at this hierarchical level. This feature was implemented for Verilog and XCF only in order to have a VHDL-like support, where box_type can be applied to a component.

BOX_TYPE Architecture Support

The following table lists supported and unsupported architectures.

Architecture	Supported/Unsupported
Virtex	Yes
Virtex-E	Yes
Spartan-II	Yes
Spartan-IIE	Yes
Spartan-3	Yes
Spartan-3E	Yes
Virtex-II	Yes
Virtex-II Pro	Yes
Virtex-II Pro X	Yes
Virtex-4	Yes
XC9500, XC9500XL, XC9500XV	Yes
CoolRunner XPLA3	Yes
CoolRunner-II	Yes

Applicable Elements

The constraint applies to the following design elements:

VHDL: component, entity

Verilog: module, instance

XCF: model, instance

Propagation Rules

Applies to the design element to which it is attached.

Syntax Examples

VHDL

Before using BOX_TYPE, declare it with the following syntax:

attribute box_type: string;

After declaring BOX_TYPE, specify the VHDL constraint as follows:

attribute box_type of {component_name|entity_name}: {component|entity} is “{primitive|black_box|user_black_box}”;

Verilog

Specify as follows:

// synthesis attribute box_type [of] {module_name|instance_name} [is] “{primitive|black_box|user_black_box}”;

XCF

MODEL “entity_name” box_type=“{primitive|black_box|user_black_box}”;

BEGIN MODEL “entity_name”

       INST “instance_name” box_type=“{primitive|black_box|user_black_box}”;

END;

Bus Delimiter

The Bus Delimiter (–bus_delimiter) command line option defines the format used to write the signal vectors in the result netlist. The available possibilities are <>, [], {}, (). The default is <>.

Architecture Support

The Bus Delimiter (–bus_delimiter) command line option is architecture independent

Applicable Elements

Applies to syntax

Syntax Examples

XST Command Line

Define this option globally with the –bus_delimiter command line option of the run command. Following is the basic syntax:

-bus_delimiter {<>|[]|{}|()}

The default is <>.

Project Navigator

Set globally with the Bus Delimiter option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Case

The Case command line option (–case) determines if instance and net names are written in the final netlist using all lower or upper case letters or if the case is maintained from the source. Note that the case can be maintained for either Verilog or VHDL synthesis flow.

Architecture Support

The Case command line option (–case) is architecture independent.

Applicable Elements

Applies to syntax

Syntax Examples

XST Command Line

Define globally with the –case command line option of the run command. Following is the basic syntax:

-case {upper|lower|maintain}

The default maintain.

Project Navigator

Set globally with the Case option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Case Implementation Style

The Case Implementation Style (–vlgcase) command line option instructs XST how to interpret Verilog Case statements. It has three possible values: full, parallel and full-parallel.

If the option is not specified, then XST implements the exact behavior of the case statements.
If full is used, XST assumes that the case statements are complete and avoids latch creation.
If parallel is used, XST assumes that the branches cannot occur in parallel and does not use a priority encoder.
If full-parallel is used, XST assumes that the case statements are complete and that the branches cannot occur in parallel, therefore saving latches and priority encoders.

See "Multiplexers" in Chapter 2, as well as, "Full Case (Verilog)" and "Parallel Case (Verilog)" for more information.

Architecture Support

Case Implementation Style is architecture independent and valid for Verilog designs only.

Applicable Elements

VLGCASE can only be applied globally.

Propagation Rules

Not applicable.

Syntax Examples

XST Command Line

Define globally with the –vlgcase command line option of the run command.

-vlgcase {full|parallel|full-parallel}

By default, there is no value.

Project Navigator

Specify globally with the Case Implementation Style option in the HDL Options tab of the Process Properties dialog box within the Project Navigator.

Allowed values are Full, Parallel, and Full-Parallel. By default, the value is blank.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Full Case (Verilog)

The Full Case (FULL_CASE) directive is used to indicate that all possible selector values have been expressed in a case, casex or casez statement. The directive prevents XST from creating additional hardware for those conditions not expressed. See "Multiplexers" in Chapter 2 for more information.

Architecture Support

The Full Case directive is architecture independent and valid for Verilog designs only.

Applicable Elements

You can apply FULL_CASE to case statements in Verilog meta comments.

Propagation Rules

Not applicable.

Syntax Examples

Verilog

The directive is exclusively available as a meta comment in your Verilog code and cannot be specified in a VHDL description or in a separate constraint file. The syntax differs from the standard meta comment syntax as shown in the following:

// synthesis full_case

The Verilog 2001 syntax is as follows: (* full_case *)

Since the directive does not contain a target reference, the meta comment immediately follows the selector.

Example:

casex select // synthesis full_case or (* full_case *)

4'b1xxx: res = data1;

4'bx1xx: res = data2;

4'bxx1x: res = data3;

4'bxxx1: res = data4;

endcase

XST Command Line

Define globally with the –vlgcase command line option of the run command using the full option. Following is the basic syntax:

-vlgcase {full|parallel|full-parallel}

Project Navigator

For Verilog files only, specify globally in the Synthesis Options tab of the Process Properties dialog box within the Project Navigator.

With a Verilog design selected in the Sources window, right-click Synthesize in the Processes window to access the Synthesis Options tab of the Process Properties dialog box. For Case Implementation Style, select Full as a Value.

Generate RTL Schematic

The Generate RTL Schematic (–rtlview) command line option enables XST to generate a netlist file, representing an RTL structure of the design. This netlist can be viewed by the RTL and Technology Viewers. This option has three possible values: yes, no and only. When the only value is specified, XST stops the synthesis process just after the RTL view is generated. The file containing the RTL view has an NGR file extension.

Architecture Support

The Generate RTL Schematic command line option is technology independent.

Applicable Elements

Applies to a file

Syntax Examples

XST Command Line

Define globally with the –rtlview command line option of the run command. Following is the basic syntax:

-rtlview {yes|no|only}

From the command line, the default is no.

Project Navigator

Set globally with the Generate RTL Schematic option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

From Project Navigator, the default is yes.

Duplication Suffix

The Duplication Suffix (–duplication_suffix) command line option controls how XST names replicated flip-flops. By default, when XST replicates a flip-flop, it creates a name for the new flip-flop by taking the name of the original flip-flop and adding "_n" to the end of it, where n is an index number. For example, if the original flip-flop name is my_ff, and this flip-flop was replicated three times, XST generates flip-flops with the following names: my_ff_1, my_ff_2 and my_ff_3.

Using the Duplication Suffix command line option, you can specify a text string to append to the end of the default name. You can use the %d escape character to specify where in the name the index number appears. For example, for the flip-flop named my_ff, if you specify _dupreg_%d with the Duplication Suffix option, XST generates the following names: my_ff_dupreg_1, my_ff_dupreg_2, and my_ff_dupreg_3. Please note that %d can be placed anywhere in the suffix definition. For example, if the Duplication Suffix value is specified as _dup_%d_reg, XST generates the following names: my_ff_dup_1_reg, my_ff_dup_2_reg and my_ff_dup_3_reg.

Architecture Support

The Duplication Suffix command line option is technology independent.

Applicable Elements

Applies to a file.

Syntax Examples

XST Command Line

Define globally with the –dupilcation_suffix command line option of the run command. Following is the basic syntax:

-duplication_suffix string%dstring

The default is _%d.

Project Navigator

The Duplication Suffix option does not appear on the Process Properties dialog box. Set it globally with the Other option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box. Specify the option in the Other XST Command Line Options menu item. See XST Command Line example for coding details.

Hierarchy Separator

The Hierarchy Separator (–hierarchy_separator) command line option defines the hierarchy separator character that is used in name generation when the design hierarchy is flattened.

There are two supported characters, '_' and '/'. The default is '/' for newly created projects.

If a design contains a sub-block with instance INST1, and this sub-block contains a net, called TMP_NET, then the hierarchy is flattened and the hierarchy separator character is '_'. The name of TMP_NET becomes INST1_TMP_NET. If the hierarchy separator character is '/', then the name of the net will be 'INST1/TMP_NET'. Using '/' as a hierarchy separator is very useful in the design debugging process because this separator makes it much easier to identify a name if it is hierarchical.

Architecture Support

The Hierarchy Separator command line option is technology independent.

Applicable Elements

Applies to a file.

Syntax Examples

XST Command Line

Define this option globally with the –hierarchy_separator command line option of the run command. Following is the basic syntax:

-hierarchy_separator {_|/}

The default is '/' for newly created projects.

Project Navigator

Set globally with the Hierarchy Separator option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

From Project Navigator, the default is '/'.

Iostandard

Use the IOSTANDARD constraint to assign an I/O standard to an I/O primitive. See "IOSTANDARD" in the Constraints Guide for details.

Keep

The KEEP constraint is an advanced mapping constraint. When a design is mapped, some nets may be absorbed into logic blocks. When a net is absorbed into a block, it can no longer be seen in the physical design database. This may happen, for example, if the components connected to each side of a net are mapped into the same logic block. The net may then be absorbed into the block containing the components. KEEP prevents this from happening.

Please note that the KEEP constraint preserves the existence of the signal in the final netlist, but not its structure. For example, if your design has a 2-bit multiplexer selector and you attach a KEEP constraint to it, then this signal will be preserved in the final netlist. But the multiplexer could be automatically reencoded by XST using one-hot encoding. As a consequence, this signal in the final netlist will be four bits wide instead of the original two. To preserve the structure of the signal, in addition to the KEEP constraint you must also use the ENUM_ENCODING constraint. See "Enumerated Encoding (VHDL)" for more information.

See "KEEP" in the Constraints Guide for details.

Library Search Order

The Library Search Order (–lso) command line option is related to the use of mixed language (VHDL/Verilog) projects support. It allows you to specify the order in which various library files are used.

It can be invoked by specifying the file containing the search order in the value field to the right of Library Search option under the Synthesis Options tab in the Process Properties dialog box in Project Navigator, or with the –lso command line option.

Architecture Support

The Library Search Order command line option is architecture independent

Applicable Elements

Applies to a file.

Syntax Examples

XST Command Line

Define this option globally with the –lso command line option of the run command. Following is the basic syntax:

-lso {_|/}

The default is '/' for newly created projects.

See the "Library Search Order File" in Chapter 8 for details.

Project Navigator

Set globally with the Library Search option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator. See the "Library Search Order File" in Chapter 8 for details.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

LOC

The LOC constraint defines where a design element can be placed within an FPGA/CPLD. See "LOC" in the Constraints Guide for details.

Optimization Effort

The Optimization Effort (OPT_LEVEL) constraint defines the synthesis optimization effort level. Allowed values are 1 (normal optimization) and 2 (higher optimization). The default optimization effort level is 1 (Normal).

1 (Normal)

Very fast processing, especially for hierarchical designs. This is the default mode and suggested for use with a majority number of designs.

2 (Higher Optimization)

Time consuming processing—sometimes with better results in the number of macrocells or maximum frequency.

Note: In speed optimization mode, Xilinx strongly suggests using 1 (Normal) optimization effort for the majority of designs. Selecting optimization level 2 usually results in increased synthesis run times and does not always bring optimization gain.

Architecture Support

The following table lists supported and unsupported architectures.

Architecture	Supported/Unsupported
Virtex	Yes
Virtex-E	Yes
Spartan-II	Yes
Spartan-IIE	Yes
Spartan-3	Yes
Spartan-3E	Yes
Virtex-II	Yes
Virtex-II Pro	Yes
Virtex-II Pro X	Yes
Virtex-4	Yes
XC9500, XC9500XL, XC9500XV	Yes
CoolRunner XPLA3	Yes
CoolRunner-II	Yes

Applicable Elements

OPT_LEVEL can be applied globally or to an entity or module.

Propagation Rules

Applies to the entity or module to which it is attached.

Syntax Examples

VHDL

Before using OPT_LEVEL, declare it with the following syntax:

attribute opt_level: string;

After declaring OPT_LEVEL, specify the VHDL constraint as follows:

attribute opt_level of entity_name: entity is “{1|2}”;

Verilog

Specify as follows:

// synthesis attribute opt_level [of] module_name [is] “{1|2}”;

XCF

MODEL “entity_name” opt_level={1|2};

XST Command Line

Define OPT_LEVEL globally with the –opt_level command line option. Following is the basic syntax:

-opt_level {1|2}

The default is 1.

Project Navigator

Define globally with the Optimization Effort option in the Synthesis Options tab of the Process Properties dialog box in Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Optimization Goal

The Optimization Goal (OPT_MODE) constraint defines the synthesis optimization strategy. Available strategies are speed and area. By default, XST optimizations are speed-oriented.

speed
Priority is to reduce the number of logic levels and therefore to increase frequency.
area
Priority is to reduce the total amount of logic used for design implementation and therefore to improve design fitting.

Architecture Support

The following table lists supported and unsupported architectures.

Architecture	Supported/Unsupported
Virtex	Yes
Virtex-E	Yes
Spartan-II	Yes
Spartan-IIE	Yes
Spartan-3	Yes
Spartan-3E	Yes
Virtex-II	Yes
Virtex-II Pro	Yes
Virtex-II Pro X	Yes
Virtex-4	Yes
XC9500, XC9500XL, XC9500XV	Yes
CoolRunner XPLA3	Yes
CoolRunner-II	Yes

Applicable Elements

You can apply OPT_MODE globally or to an entity or module.

Propagation Rules

Applies to the entity or module to which it is attached.

Syntax Examples

VHDL

Before using OPT_MODE, declare it with the following syntax:

attribute opt_mode: string;

After declaring OPT_MODE, specify the VHDL constraint as follows:

attribute opt_mode of entity_name: entity is “{speed|area}”;

Verilog

Specify OPT_MODE as follows:

// synthesis attribute opt_mode [of] module_name [is] {speed|area}

XCF

MODEL “entity_name” opt_mode={speed|area};

XST Command Line

Define globally with the –opt_mode command line option of the run command. Following is the basic syntax:

-opt_mode {AREA|SPEED}

The default is SPEED.

Project Navigator

Define globally with the Optimization Goal option in the Synthesis Options tab of the Process Properties dialog box in Project Navigator. The default is Speed.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Parallel Case (Verilog)

The PARALLEL_CASE directive is used to force a case statement to be synthesized as a parallel multiplexer and prevents the case statement from being transformed into a prioritized if/elsif cascade. See "Multiplexers" in Chapter 2 of this guide.

Architecture Support

The following table lists supported and unsupported architectures.

Architecture	Supported/Unsupported
Virtex	Yes
Virtex-E	Yes
Spartan-II	Yes
Spartan-IIE	Yes
Spartan-3	Yes
Spartan-3E	Yes
Virtex-II	Yes
Virtex-II Pro	Yes
Virtex-II Pro X	Yes
Virtex-4	Yes
XC9500, XC9500XL, XC9500XV	Yes
CoolRunner XPLA3	Yes
CoolRunner-II	Yes

Applicable Elements

You can apply PARALLEL_CASE to case statements in Verilog meta comments only.

Propagation Rules

Not applicable.

Syntax Examples

Verilog

The directive is exclusively available as a meta comment in your Verilog code and cannot be specified in a VHDL description or in a separate constraint file. The syntax differs from the standard meta comment syntax as shown in the following:

// synthesis parallel_case

Since the directive does not contain a target reference, the meta comment immediately follows the selector.

Example:

casex select // synthesis parallel_case

4'b1xxx: res = data1;

4'bx1xx: res = data2;

4'bxx1x: res = data3;

4'bxxx1: res = data4;

endcase

XST Command Line

Define PARALLEL_CASE globally with the -vlgcase command line option of the run command. Following is the basic syntax:

-vlgcase {full|parallel|full-parallel}

RLOC

The RLOC constraint is a basic mapping and placement constraint. This constraint groups logic elements into discrete sets and allows you to define the location of any element within the set relative to other elements in the set, regardless of eventual placement in the overall design. See "RLOC" in the Constraints Guide for details.

Synthesis Constraint File

The Synthesis Constraint File (–uc) command line option specifies a synthesis constraint file for XST to use. The XCF must have an extension of .xcf. If the extension is not .xcf, XST will error out and stop processing.

Please refer to "XST Constraint File (XCF)" for details on using the constraint file.

Architecture Support

The following table indicates supported and unsupported architectures.

Architecture	Supported/Unsupported
Virtex	Yes
Virtex-E	Yes
Spartan-II	Yes
Spartan-IIE	Yes
Spartan-3	Yes
Virtex-II	Yes
Virtex-II Pro	Yes
Virtex-II Pro X	Yes
XC9500, XC9500XL, XC9500XV	Yes
CoolRunner XPLA3	Yes
CoolRunner-II	Yes
CoolRunner-IIS	Yes

Applicable Elements

Applies to a file

Propagation Rules

Not applicable.

Syntax Examples

XST Command Line

Specify a file name with the –uc command line option of the run command. Following is the basic syntax:

–uc filename

Project Navigator

Specify a synthesis file with the Use Synthesis Constraints File option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Translate Off/Translate On (Verilog/VHDL)

The Translate Off (TRANSLATE_OFF) and Translate On (TRANSLATE_ON) directives can be used to instruct XST to ignore portions of your VHDL or Verilog code that are not relevant for synthesis; for example, simulation code. The TRANSLATE_OFF directive marks the beginning of the section to be ignored, and the TRANSLATE_ON directive instructs XST to resume synthesis from that point.

Note: TRANSLATE_OFF and TRANSLATE_ON are also Synplicity and Synopsys constraints that are supported by XST in Verilog. Automatic conversion is also available in VHDL and Verilog.

Note: TRANSLATE_ON/TRANSLATE_OFF can be used with the following words:

synthesis
synopsys
pragma

Architecture Support

TRANSLATE_OFF and TRANSLATE_ON directives are architecture independent

Applicable Elements

TRANSLATE_OFF and TRANSLATE_ON can be applied locally only.

Propagation Rules

Instructs synthesis tool to enable or disable portions of code.

Syntax Examples

VHDL

In your VHDL code, the directives should be written as follows:

-- synthesis translate_off

...code not synthesized...

-- synthesis translate_on

Verilog

The directives are available as VHDL or Verilog meta comments. The Verilog syntax differs from the standard meta comment syntax presented earlier in this chapter, as shown below.

// synthesis translate_off

...code not synthesized...

// synthesis translate_on

Use Synthesis Constraints File

The Use Synthesis Constraints File (–iuc) command line option allows you to ignore the constraint file during synthesis.

Architecture Support

The Use Synthesis Constraints File command line option is architecture independent.

Applicable Elements

Applies to a file

Propagation Rules

Not applicable.

Syntax Examples

XST Command Line

Define globally with the -iuc command line option of the run command. Following is the basic syntax:

-iuc {yes|no}

The default is no.

Project Navigator

Set globally by selecting the Use Synthesis Constraints File option under the Synthesis Options tab in the Process Properties dialog box within the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Verilog Include Directories (Verilog Only)

Use the Verilog Include Directories option (–vlgincdir) to enter discrete paths to your Verilog Include Directories.

Architecture Support

The Use Synthesis Constraints File command line option is architecture independent.

Applicable Elements

Directories

Propagation Rules

Not applicable.

Syntax Examples

XST Command Line

Define this option globally with the –vlgincdir command line option of the run command. Allowed values are names of directories. Please refer to "Names with Spaces" in Chapter 10 for more information.

-vlgincdir {directory_path [directory_path]}

There is no default.

Project Navigator

Define globally with the Verilog Include Directories option of the Synthesis Options tab in the Process Properties dialog box in the Project Navigator. Allowed values are names of directories. There is no default.

You must have Property Display Level set to Advanced in the Processes tab of the Preferences dialog box (Edit Preferences) to display the Verilog Search Paths option.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Verilog 2001

The Verilog 2001(–verilog2001) command line option enables or disables interpreted Verilog source code as the Verilog 2001 standard. By default Verilog source code is interpreted as the Verilog 2001 standard.

Architecture Support

The Verilog 2001 command line option is architecture independent.

Applicable Elements

Applies to syntax

Propagation Rules

Not applicable.

Syntax Examples

XST Command Line

Define globally with the –verilog2001 command line option of the run command. Following is the basic syntax:

-verilog2001 {yes|no}

The default is yes.

Project Navigator

Set globally with the Verilog 2001 option in the Synthesis Options tab of the Process Properties dialog box in the Project Navigator.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

HDL Library Mapping File (.INI File)

Use the HDL Library Mapping File command (–xsthdpini) to define the library mapping.

There is a library mapping file and two associated parameters: XSTHDPINI and XSTHDPDIR. The library mapping file contains the library name and the directory in which this library is compiled. XST maintains two library mapping files:

The "pre-installed" file, which is installed during the Xilinx® software installation.
The "user" file, which users may define for their own projects.

The "pre-installed" (default) INI file is named "xhdp.ini," and is located in %XILINX%\vhdl\xst. These files contain information about the locations of the standard VHDL and UNISIM libraries. These should not be modified, but the syntax can be used for user library mapping. This file appears as follows:

-- Default lib mapping for XST

std=$XILINX/vhdl/xst/std

ieee=$XILINX/vhdl/xst/unisim

unisim=$XILINX/vhdl/xst/unisim

aim=$XILINX/vhdl/xst/aim

pls=$XILINX/vhdl/xst/pls

You can use this file format to define where each of your own libraries must be placed. By default, all compiled VHDL flies will be stored in the "xst" sub-directory of the ISE™ project directory. You can place your custom INI file anywhere on a disk by using one of the following methods:

Selecting the VHDL INI File option in the "Synthesis Options" tab of the Synthesis process properties in Project Navigator.
Setting up the –xsthdpini parameter, using the following command in
stand-alone mode:

set -xsthdpini file_name

You can give this library mapping file any name you wish, but it is best to keep the .ini classification. The format is:

library_name=path_to_compiled_directory

Note: (Use "--" for comments.)

Sample text for "my.ini":

work1=H:\Users\conf\my_lib\work1

work2=C:\mylib\work2

Architecture Support

The HDL Library Mapping File command is architecture independent.

Applicable Elements

Files

Propagation Rules

Not applicable.

Syntax Examples

XST Command Line

Define globally with the set -xsthdpini command line option before running the run command. Following is the basic syntax:

set -xsthdpini file_name

The command can accept a single file only.

Project Navigator

Define globally with the VHDL INI File option of the Synthesis Options tab in the Process Properties dialog box in the Project Navigator.

You must have Property Display Level set to Advanced in the Processes tab of the Preferences dialog box (Edit Preferences) to display the VHDL INI File option.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.

Work Directory

The Work Directory (–xsthdpdir) parameter defines the location in which VHDL-compiled files must be placed if the location is not defined by library mapping files. You can access this switch by using one of the following methods:

Selecting the VHDL Working Directory menu in the "Synthesis Options" tab of the Synthesis process properties in Project Navigator.
Using the following command in stand-alone mode:

set -xsthdpdir directory

Example:

Suppose three different users are working on the same project. They must share one standard, pre-compiled library, shlib. This library contains specific macro blocks for their project. Each user also maintains a local work library, but User 3 places it outside the project directory (i.e., in c:\temp). Users 1 and 2 will share another library ("lib12") between them, but not with User 3. The settings required for the three users are as follows:

User 1:

Mapping file:

schlib=z:\sharedlibs\shlib

lib12=z:\userlibs\lib12

User 2:

Mapping file:

schlib=z:\sharedlibs\shlib

lib12=z:\userlibs\lib12

User 3:

Mapping file:

schlib=z:\sharedlibs\shlib

User 3 will also set:

XSTHDPDIR = c:\temp

Architecture Support

The Work Directory command is architecture independent.

Applicable Elements

Directories

Propagation Rules

Not applicable.

Syntax Examples

XST Command Line

Define this parameter globally with the set –xsthdpdir command line option before running the run command. Following is the basic syntax:

set -xsthdpdir directory

The command can accept a single path only. You must specify the directory you want to use. There is no default.

Project Navigator

Define globally with the VHDL Work Directory option of the Synthesis Options tab in the Process Properties dialog box in the Project Navigator.

You must have Property Display Level set to Advanced in the Processes tab of the Preferences dialog box (Edit Preferences) to display the option.

With a design selected in the Sources window, right-click Synthesize in the Processes window to access the appropriate Process Properties dialog box.