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 davekenny
Visitor
5,814 Views
Registered: ‎06-27-2013

Xst not handling generics correctly

I have a module which uses generics to paramatise the port widths. The module simulates OK with various generics. However when I come to synthesise I get an error Xst:792 complaining about mis-matched vector widths. This only occurs when the generics produce a port of 0 downto 0 parameters (i.e.. 1 bit wide). If the generics are such that all port widths are > 1 bit wide everything is OK.
I have even tried using a conditional generate function to use a different process when the generics would produce a 1 bit wide port. This also fails with the same error.
I have attached a cut down design directory, fred.vhd contains the paramatisable module, fredTop.vhd instantiates this module and fred2.vhd is the version with conditional generate in it. JogWheelTypesPkg.vhd contains the constants used in the design.
If you set NoOfLedCols to 2 then you get the error. Anything greater than 2 works fine and synthesises what I would expect.
If anybody has any ideas why this won't work I would appreciate it. I currently have to support 2 (or more) modules to support uses where the port width is 1 - not ideal.

0 Kudos
5 Replies
Historian
Historian
5,806 Views
Registered: ‎02-25-2008

Re: Xst not handling generics correctly


@davekenny wrote:

I have a module which uses generics to paramatise the port widths. The module simulates OK with various generics. However when I come to synthesise I get an error Xst:792 complaining about mis-matched vector widths. This only occurs when the generics produce a port of 0 downto 0 parameters (i.e.. 1 bit wide). If the generics are such that all port widths are > 1 bit wide everything is OK.
I have even tried using a conditional generate function to use a different process when the generics would produce a 1 bit wide port. This also fails with the same error.
I have attached a cut down design directory, fred.vhd contains the paramatisable module, fredTop.vhd instantiates this module and fred2.vhd is the version with conditional generate in it. JogWheelTypesPkg.vhd contains the constants used in the design.
If you set NoOfLedCols to 2 then you get the error. Anything greater than 2 works fine and synthesises what I would expect.
If anybody has any ideas why this won't work I would appreciate it. I currently have to support 2 (or more) modules to support uses where the port width is 1 - not ideal.


I wonder if the confusion is the result of the use of the math_real package and there's a conversion error somewhere?

Perhaps using an integer version of log2 will work. 

Certainly XST doesn't have a problem with a (say) std_logic_vector declared as (0 downto 0), as long as it's accessed as a vector and not a simple std_logic.

----------------------------Yes, I do this for a living.
0 Kudos
Visitor davekenny
Visitor
5,788 Views
Registered: ‎06-27-2013

Re: Xst not handling generics correctly

Surely if XST can't use mathsreal then it should whinge about it. I don't think this is the case because the generics are static at elaboration and XST reports them with the correct values (see log file). Mathsreal is only used to calculate the generics (which according to "The Designers Guide to VHDL - Third Edition" is legal providing mathsreal calculations are static at elaboration). It is not used in the synthesis. Mathsreal calulates the generics and then the module is instantiated with these static calculated generics. This is why the constants LedRowMsb, LedColMsb etc are passed in as generics so that Mathsreal is not called in the module and you can't calculate generics from generics. 

 

What is this integer version of log2 you speak of?

0 Kudos
Historian
Historian
5,776 Views
Registered: ‎02-25-2008

Re: Xst not handling generics correctly


@davekenny wrote:

Surely if XST can't use mathsreal then it should whinge about it. I don't think this is the case because the generics are static at elaboration and XST reports them with the correct values (see log file). Mathsreal is only used to calculate the generics (which according to "The Designers Guide to VHDL - Third Edition" is legal providing mathsreal calculations are static at elaboration). It is not used in the synthesis. Mathsreal calulates the generics and then the module is instantiated with these static calculated generics. This is why the constants LedRowMsb, LedColMsb etc are passed in as generics so that Mathsreal is not called in the module and you can't calculate generics from generics. 


 

I agree; if the tool can't support something it should complain. But I don't think that math_real's static functions are the issue. I was rather confused by your code though, since it seemed like generics weren't getting passed down in the manner you expect.

 

I don't understand why you put the constants in a package. Your top level uses the constants package and then those constants are setting the width of the vectors in the port list. It's legal VHDL but I don't think the synthesizer groks it.

 

You should have your generics set from the top level of the design -- put a list of generics when you declare the port list for the entity JogWheelTop. Those generics can then be used to set the generics in the lower-level entities through their generic maps. You can also use those generics to create the other constants which then are used to set generics in the lower-level entities. 

 

Note that you can pass new values for generics to a top-level entity from ISE.

 

(Also, coding style hints: first, delete the component declarations in the top level and just use direct instantiation of entities. Save yourself a ton of redundant typing. Also, constants should be ALL_CAPS!) 


What is this integer version of log2 you speak of?


Something like this:

 

function log2 (constant N : integer)
    return integer is
begin -- function log2
    for i in 1 to 30 loop
        if (2 ** i) > N then
            return (i - 1);
        end if;
    end loop; -- i
    return (30);
end function log2;

 

Put it into a package, or cut-and-paste it into your code. It works well enough.

----------------------------Yes, I do this for a living.
0 Kudos
Visitor davekenny
Visitor
5,754 Views
Registered: ‎06-27-2013

Re: Xst not handling generics correctly

Hi,

I mentioned that this is a clip from a larger project. The generics are declared in the package so that I only have to change them in one place. This was to be a piece of code that would be used in many projects with different widths. I also use the generics in other modules which are instantiated at the top level. Again I re-iterate that the generics are static at elaboration. The package will always produce static values as the constants only vary with "NoOfLedRows" and "NoOfLedCols" which are static. I have set generics from packages many times without any problems. I have also tried your idea and it still fails. The problem is definitely related to "0 downto 0" but I can't report it as a bug because Xilinx don't take webcases anymore. I have fully explored this problem and as far as I am concerned this is a bug of which there may be a workaround. Perhaps the question I should ask is "How do you get into the Xilinx inner Sanctum and get an issue taken seriously"

I'm sorry I don't understand your line "It's legal VHDL but I don't think the synthesizer groks it."

Also, as I have an editor macro to take an entity and produce a component declaration and instantiation. I'm quite happy to carry on with my style and produce fully documented portable VHDL. As VHDL is not case sensitive (boo) then I think everyone has their own way of styling constants etc. My style harps back to the halcyon days when case mattered.

0 Kudos
Historian
Historian
5,741 Views
Registered: ‎02-25-2008

Re: Xst not handling generics correctly


@davekenny wrote:

 

I mentioned that this is a clip from a larger project. The generics are declared in the package so that I only have to change them in one place. This was to be a piece of code that would be used in many projects with different widths. I also use the generics in other modules which are instantiated at the top level. Again I re-iterate that the generics are static at elaboration. The package will always produce static values as the constants only vary with "NoOfLedRows" and "NoOfLedCols" which are static. I have set generics from packages many times without any problems. I have also tried your idea and it still fails. The problem is definitely related to "0 downto 0" but I can't report it as a bug because Xilinx don't take webcases anymore. I have fully explored this problem and as far as I am concerned this is a bug of which there may be a workaround. Perhaps the question I should ask is "How do you get into the Xilinx inner Sanctum and get an issue taken seriously"


I know that (0 downto 0) is legal, and that as long as the signal using it is declared as a vector and it is accessed like myvector(0) then it's good.

 

As for getting Xilinx to give a **bleep**, good luck. Your best bet is to contact your local FAE and have them escalate. 


I'm sorry I don't understand your line "It's legal VHDL but I don't think the synthesizer groks it."


 "grok" is the Martian term for "full and complete understanding" of the subject at hand. See Heinlein's "Stranger In A Strange Land." 


Also, as I have an editor macro to take an entity and produce a component declaration and instantiation. I'm quite happy to carry on with my style and produce fully documented portable VHDL. As VHDL is not case sensitive (boo) then I think everyone has their own way of styling constants etc. My style harps back to the halcyon days when case mattered.


Case matters in Verilog, if that matters. I (and everyone I know) prefers UPPER_CASE to indicate a constant.

 

As for the component declaration and then instantiation, it just makes more work for you when maintaining code. Change the port list of an entity? Well, now you need to change the component declarations as well as instantiations everywhere you use that entity. (Of course, you should put the components into a pacakge ...) But direct instantiation works for me. Much less typing.

----------------------------Yes, I do this for a living.
0 Kudos