cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
14,398 Views
Registered: ‎03-16-2012

Vhdl generate statement increase logic count - ISE

Hi,

 

Does generate statement in VHDL increase LUT count with ISE?

When i implement the same code with and without the generate statement, I get about 15 LUT difference of the MAP result.

It happens after synthesis, synthesis results are same.

How can it be?

 

Best Regards,

Burak

0 Kudos
10 Replies
Highlighted
Moderator
Moderator
14,393 Views
Registered: ‎01-16-2013

Hi,

Generate statement used for replication of logic. If you used generate statement it will definitely increase the logic as compared to single logic statement.

Also tool performs differently as per your coding style.

Thanks,
Yash
0 Kudos
Highlighted
Participant
Participant
14,385 Views
Registered: ‎03-16-2012

Sorry i forgot to write,

 

If-generate is used to implement according to a parameter.

Like below:

 

   gen_0: if d=1 generate
      i_inst : inst
         generic map(
            q        => q)
         port map(
            rst    => rst_n , -- : in std_logic;
            clk    => clk        , -- : in std_logic;

            ...
         );
      
      a_q <= a(q-1 downto 0);
   end generate;
   
   gen_1: if d>1 generate           
      i_inst : inst2
         generic map(
            d        => d  , -- : integer := 4;
            q        => q
         )
         port map(
            rst    => rst_n ,
            clk    => clk        ,

            ...

         );
   end generate;            

---------------------------------------------------------------------------

Even in this case does it increase logic count?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
14,362 Views
Registered: ‎01-03-2008

> Even in this case does it increase logic count?

 

In comparison to what baseline?

 

The code that you posted has two generate statements in it that appear to either build a single bit wide instance or a multi-bit wide instance.  The amount of logic resources that are required will be determined by the parameters.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Participant
Participant
14,348 Views
Registered: ‎03-16-2012

Only difference between two implementation is generate statement, logic is same.

 

 

Without changing the parameters or other parts of the module, i just comment out the first generate statement in the first implementation and d=4 :

 

-- gen_0: if d=1 generate
-- i_inst : inst
-- generic map(
-- q => q)
-- port map(
-- rst => rst_n , -- : in std_logic;
-- clk => clk , -- : in std_logic;
-- ...
-- );
--
-- a_q <= a(q-1 downto 0);
-- end generate;
--
-- gen_1: if d>1 generate
i_inst : inst2
generic map(
d => d , -- : integer := 4;
q => q
)
port map(
rst => rst_n ,
clk => clk ,
...
);
-- end generate;

------------------------------------------------------

In the second implementation d=4 again:

 

gen_0: if d=1 generate
i_inst : inst
generic map(
q => q)
port map(
rst => rst_n , -- : in std_logic;
clk => clk , -- : in std_logic;
...
);

a_q <= a(q-1 downto 0);
end generate;

gen_1: if d>1 generate
i_inst : inst2
generic map(
d => d , -- : integer := 4;
q => q
)
port map(
rst => rst_n ,
clk => clk ,
...
);
end generate;

------------------------------------------------------

I expect both should be the same circuit, because of the d parameter, second generate statement is selected in the second implementation like in the first one.

 

 

0 Kudos
Highlighted
Professor
Professor
14,344 Views
Registered: ‎08-14-2007

Xilinx Map program is very sophisticated and somewhat random.  It is sophisticated in that it knows how to optimize and combine logic to better fit into the underlying logic elements of the FPGA.  It is somewhat random (actually pseudorandom - with absolutely no changes the result will be the same) in that it starts with a "cost table" seed and then starts re-arranging elements from there.  So in any large design, you can run the exact same code through map with all other settings the same but different "cost table" seeds (i.e. -t 1 vs. -t 2) and come up with a slightly different LUT count due to the way it has arranged (mapped) the logic into LUTs.  Designs with more combinatorial logic levels between registers may see larger differences in LUT usage than simpler more pipelined designs.

 

Now what happens is that the starting seed is also randomized by the order in which stuff was written into the netlist by synthesis, which in turn can depend on small changes in syntax or re-ordering of code in your HDL source that otherwise don't change the hardware specification.  So in fact the small changes between your "generate" and "non-generate" versions are enough to have a similar effect to changing the cost table seed.  You should see something similar if you run the SmartXplorer through a number of passes on either of the two designs and look at the LUT usage for each.  For any given seed the two versions will probably be different, but the low to high range of LUT count should be similar over a sufficiently large number of cost table settings.  Note that this happens even when you have not re-run synthesis, so it matches your findings for two source versions producing the same usage numbers in synthesis.

-- Gabor
SmartXplorerResultSnippet.PNG
0 Kudos
Highlighted
Participant
Participant
14,337 Views
Registered: ‎03-16-2012

It might be.
I actually rerun both implementations several times and the resource usage is always same.

Anyway, thanks for all your answers,
Burak
0 Kudos
Highlighted
Professor
Professor
14,328 Views
Registered: ‎08-14-2007


@govemb wrote:
It might be.
I actually rerun both implementations several times and the resource usage is always same.

Anyway, thanks for all your answers,
Burak


But did you change the "starting placer cost table (1 to 100)" value when you re-run?  If not, then you should get the same results for the same HDL.  SmartXplorer will run through multiple cost table numbers as shown in the picture I posted, where the name of each run ends in the setting like CT3, CT4, CT5, ...

-- Gabor
0 Kudos
Highlighted
Participant
Participant
14,322 Views
Registered: ‎03-16-2012

No, i did not change any option, flag, ...etc
Only the code changed described in my second post.
0 Kudos
Highlighted
Professor
Professor
14,313 Views
Registered: ‎08-14-2007

So what I was saying is that without changing the code, you can get a similar difference in LUT count between two Map runs simply by changing the starting cost table number.  I suggest that the difference in LUT count between your two different HDL implementations is similar to changing this value, and you could see it using SmartXplorer to automatically step through a set of cost table numbers for each design.

 

The point is that I would not expect the output of MAP to remain exactly the same when making any change even if it doesn't affect the synthesis usage report.  And it could have just as easily gone the other way.  i.e. at another cost table setting it is just as likely that the non-generate version of the HDL uses more LUTs than the generate version.

-- Gabor
Highlighted
Adventurer
Adventurer
4,512 Views
Registered: ‎03-05-2008

Very well explained Gabor, no wonder you're a teacher!

 

 

Thinking about what you wrote makes me wonder if the variations in my timing score is caused by the same mechanism. I've often been appalled when tiny changes in my source code make a difference between a timing score of zero and one in the thousands ... and when I investigate the routes that fail are usually completely unrelated to what I've changed.

 

Do you know if its possible to fix the MAP starting seed so that, if by chance one of my builds gets a timing score of zero, I might be able to use the same seed again with the hope of getting a timing score of zero despite any benign changes in the source?

 

Kind regards

Paul

 

0 Kudos