We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 21635

7.1i XST - "FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:"


Keywords: signal, initialize, synthesis, synthesize

Urgency: Standard

General Description:
While running synthesis on my design, I receive the following fatal error:


Xilinx is actively trying to provide better error messages to help you debug the issue. This Answer Record contains some of the solutions that have fixed the fatal error.



In a particular test case, the order in the aggregate is different than the one in the declaration; re-writing the aggregate to match the declaration order fixed the problem.

For example:
type t_request is record
in1 : std_logic_vector(6 downto 0);
in2 : unsigned(12 downto 0);
in3 : unsigned(11 downto 0);
in4 : std_logic;
end record

then initialize a signal of type t_request with a default value:
(in4 => '0',
in1 => (others => '0'),
in2 => (others => '0'),
in3 => (others => '0'))

In some cases, this will cause a fatal error and will need to be re-written to match the declaration below:
(in1 => (others => '0'),
in2 => (others => '0'),
in3 => (others => '0'),
in4 => '0')

This issue will be fixed in ISE 8.1i.


Another scenario where this has been seen is if a bus is assigned in one statement.

For example:
rx_fifo [rx_fifo_wptr] [7:0] <= rx_byte;

If the same code is recoded to assign each bit at a time:
rx_fifo [rx_fifo_wptr] [7] <= rx_byte[7];
rx_fifo [rx_fifo_wptr] [6] <= rx_byte[6];
rx_fifo [rx_fifo_wptr] [5] <= rx_byte[5];
rx_fifo [rx_fifo_wptr] [4] <= rx_byte[4];
rx_fifo [rx_fifo_wptr] [3] <= rx_byte[3];
rx_fifo [rx_fifo_wptr] [2] <= rx_byte[2];
rx_fifo [rx_fifo_wptr] [1] <= rx_byte[1];
rx_fifo [rx_fifo_wptr] [0] <= rx_byte[0];

the change fixed the fatal error for a particular case.

This issue will be fixed in ISE 8.1i.


This has also been seen in the following scenario:

When you declares a subtype, you can use a natural range for the subtype.

If you use a user-defined range, then XST gives this Fatal Error.

This issue is fixed in ISE 8.1i.


Also see (Xilinx Answer 21492).


This has also been seen in the following scenario:

If the following types are declared:

type STATE2_1_T is (IDLE, S2_1, S2_2);

signal STATE2 : STATE2_T;
signal STATE2_1 : STATE2_1_T;

the second signal name has _1 in it, which is causing the Fatal Error in XST. Changing the second signal name will work around this issue.

This issue is fixed in ISE 8.1i.


Look for warnings prior to the fatal errors. These usually provide insight as to what caused the fatal error.


Use the -safe_implementation switch in XST for cases.

More information on the safe implementation switch can be found in the XST User Guide.


This will also happen if the file defining package is included in the "prj" file, but not the one defining the package body.

XST crashes when looking for the package body in a function call.

This issue will be fixed in ISE 8.2i.


Two signals are tied to ground in the top level. If you add ports to these signals so they are not always tied to ground, then the fatal error goes away.

This issue will be fixed in ISE 9.1i.


This has also been seen if there is a port mismatch in the instantiation.

An example snippet is below:

The following ports:
rdaddress : in std_logic_vector(R_DATA_WIDTH-1 downto 0);
rddata : out std_logic_vector(R_ADDRESS_WIDTH-1 downto 0)

were changed to:
rdaddress : in std_logic_vector(R_ADDRESS_WIDTH-1 downto 0);
rddata : out std_logic_vector(R_DATA_WIDTH-1 downto 0)

This fixed the problem.

This issue will be fixed in ISE 8.2i
AR# 21635
Date 01/08/2009
Status Archive
Type General Article