UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor blackphoenix
Visitor
7,068 Views
Registered: ‎04-12-2010

Possible bug concerning user functions

Jump to solution

Hello,

I'm having trouble with a problem that keeps coming up in my design and which I think is a bug. I've defined a couple of functions which I use throughout my design to set some constants (such as vector widths) dynamically in synthesis time. However, for the following code I get:

ERROR:Xst:785 - "C:/Users/asd/Documents/Xilinx/StereoCensus/comparator_tree.vhd" line 49: Type must be constrained for this object : 'IndxA'.

INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate. For technical support on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support. 

 

use work.common.all;



entity comparator_tree is
	 Generic ( DataNum : positive := 64;
				  DataWidth : positive := 11);
    Port ( Input : in STD_LOGIC_VECTOR(DataNum*DataWidth-1 downto 0);
			  Min : out STD_LOGIC_VECTOR(DataWidth-1 downto 0);
			  Idx : out  STD_LOGIC_VECTOR(log2_ceil(DataNum)-1 downto 0);
			  Clk : in STD_LOGIC);
end comparator_tree;

architecture Structural of comparator_tree is

constant H_of_tree : positive := log2_ceil(DataNum);

constant DataNum_SbTree1 : integer := DataNum/2;
constant DataNum_SbTree2 : integer := DataNum-DataNum_SbTree1;
constant IdxSize1 : integer := log2_ceil(DataNum_SbTree1);
constant IdxSize2 : integer := log2_ceil(DataNum_SbTree2);
constant Pipeline_Width  : integer := IdxSize2+DataWidth-1;

signal MinA, MinB, MinA_s, MinB_s , newMin_s : std_logic_vector(DataWidth-1 downto 0);
signal IndxA, IndxA_s : std_logic_vector(IdxSize1-1 downto 0);
signal ndxB, IndxB_s : std_logic_vector(IdxSize2-1 downto 0);
signal newIdx_s : std_logic_vector(0 downto 0);

 

log2_ceil is a function I've defined in common.vhd which does exactly what its name implies and is verified to work correctly. I'm getting the feeling that IdxSize1 isn't set for some reason.

 

A similar situation exists with vector slices. I'm forced to use

  constant DISP_SIZE					  : natural := log2_ceil(MAX_DISPARITY);
  constant DISP_SIZE_static		  : natural := 7; -- same as DISP_SIZE

  so that 

 

D(DISP_SIZE-1 downto 0)=>RefDisp_s,

doesn't give the error:

ERROR:HDLParsers:3299 - "C:/Users/asd/Documents/Xilinx/StereoCensus/Census_LR_Check.vhd" Line 136. Discrete range on slice is not locally static.
ERROR:HDLParsers:852 - "C:/Users/asd/Documents/Xilinx/StereoCensus/Census_LR_Check.vhd" Line 137. Value DISP_SIZE is not static. 

 

Something similar appears in my parameters.vhd file (file that declares all parameters of my system and gets included almost everywhere in my design) where if a constant is set with a series of encapsulated user function calls, it isn't assigned a value. It appears that constants are correct only if assigned a literal directly or through at most 1 function call.

 

Is this a known issue and if so are there any remedies for it? I'm using ISE 12.1 and targeting virtex5 x330t. 

Thanks 

 

edit: retargetting to spartan 6 made the first error go away so it has something to do with the virtex 5 parser??

 

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
8,781 Views
Registered: ‎08-14-2007

Re: Possible bug concerning user functions

Jump to solution

By default XST uses the "new parsers" for S6, V6, and 7-series parts only.  You can force XST

to use the "new parsers" for older parts (V5).  See this thread:

 

http://forums.xilinx.com/xlnx/board/crawl_message?board.id=SYNTHBD&message.id=3601

 

Otherwise you should probably open a webcase as the error message indicated.

 

-- Gabor

-- Gabor
0 Kudos
6 Replies
Instructor
Instructor
8,782 Views
Registered: ‎08-14-2007

Re: Possible bug concerning user functions

Jump to solution

By default XST uses the "new parsers" for S6, V6, and 7-series parts only.  You can force XST

to use the "new parsers" for older parts (V5).  See this thread:

 

http://forums.xilinx.com/xlnx/board/crawl_message?board.id=SYNTHBD&message.id=3601

 

Otherwise you should probably open a webcase as the error message indicated.

 

-- Gabor

-- Gabor
0 Kudos
Visitor blackphoenix
Visitor
7,052 Views
Registered: ‎04-12-2010

Re: Possible bug concerning user functions

Jump to solution

thanks gszakacs that solved my problem.

0 Kudos
Historian
Historian
7,027 Views
Registered: ‎02-25-2008

Re: Possible bug concerning user functions

Jump to solution

The simplest solution is to use an unconstrained std_logic_vector on your entity's port list, and then use the standard VHDL attributes (like 'length, etc) to determine the actual size of the vector.

 

The vector size is set in the higher-level (instantiating) entity in the port map.

 

So, consider the lower-level entity:

 

entity lowerlevel is 

    port (

        clk : in std_logic;

        foo : in std_logic_vector;

        bar : out std_logic_vector);

end entity lowerlevel;

 

and a higher-level instantiating entity:

 

entity higherlevel is

  ...

end entity higherlevel;

architecture high is

    signal foo : std_logic_vector(7 downto 0);

    signal bar : std_logic_vector(15 downto 0);

begin

    u_lower : work.lowerlevel

        port map (

            clk => clk,

            foo => foo,

            bar => bar);

end architecture high;

 

In this example, the 'length of foo in the instance u_lower will be 8 and it'll be a std_logic_vector(7 downto 0). Similarly, the 'length of bar in the lower-level instance will be 16 and it'll be a std_logic_vector(15 downto 0)

 

This gets rid of the need for functions on the port declarations and all of that, and it's portable and has been in the language forever. Attributes are your friends!

    

----------------------------Yes, I do this for a living.
0 Kudos
Visitor blackphoenix
Visitor
7,019 Views
Registered: ‎04-12-2010

Re: Possible bug concerning user functions

Jump to solution

I remember trying such a solution very early in my design but encountered problems. I don't remember what exactly went wrong (has passed some time) but I was forced to revert to generics. For example I use a fully generic adder tree (M inputs of N size) that I don't know if it can be coded with unconstrainted ports.

0 Kudos
Instructor
Instructor
7,013 Views
Registered: ‎08-14-2007

Re: Possible bug concerning user functions

Jump to solution

@blackphoenix wrote:

I remember trying such a solution very early in my design but encountered problems. I don't remember what exactly went wrong (has passed some time) but I was forced to revert to generics. For example I use a fully generic adder tree (M inputs of N size) that I don't know if it can be coded with unconstrainted ports.


 

You might want to try it again with the new parsers to see if that fixes those issues as well.

 

-- Gabor

-- Gabor
0 Kudos
Visitor nxphtc46
Visitor
4,035 Views
Registered: ‎11-20-2014

Re: Possible bug concerning user functions

Jump to solution

This solved my problem for Spartan-3A FPGA, Xilinx 14.7 ISE. Thank you !

0 Kudos