Need Help in my first synthesis.

[ghostridergr]

Well as this is my first synthesis, I need your help so as to realize certain things and be able to continue my project. I am using a Virtex6 , and my ISE is that ot Xilinx.

My code is this:

library IEEE;
use IEEE.std_logic_1164.all;
use STD.TEXTIO.all;
use IEEE.std_logic_unsigned.all;
use IEEE.std_logic_arith.all;
use work.my_package.all;

entity landmark is
  generic
		(N :integer := 8;
		NA:integer:=2 );
		port ( clk:in std_logic;
		new_set: in std_logic;
		vin:in std_logic;
		rst:in std_logic;
		din: in signed(N-1 downto 0);
		dout: out big_matrix(0 to 3); 
		done: out std_logic
		);
end landmark;


architecture TB_ARCHITECTURE of landmark is

signal inp1,inp2: matrix1_t(0 to NA);
signal flag:std_logic:='0';
signal k:integer range 0 to 100:= 0;
signal l:integer range 0 to 100:= 0;
signal i:integer range 0 to 100:= 0;
signal j:integer range 0 to 100:= 0;

function sum_of_square_dif( a1,b1: in signed(N-1 downto 0); previous_sum:in std_logic_vector(3*N-1 downto 0))return std_logic_vector is     
     variable temp_sum:std_logic_vector(3*N-1 downto 0):=(others=>'0');
     variable diff: signed(N-1 downto 0):=(others=>'0');
	 variable square_diff: std_logic_vector(2*N-1 downto 0):=(others=>'0');
begin
  temp_sum:=previous_sum;
  diff:=a1-b1;
	square_diff:=ext(diff*diff,2*N);
	temp_sum:=ext(temp_sum+square_diff,3*N);
  return temp_sum;
end sum_of_square_dif;

function find_min(row: in big_matrix(0 to NA)) return signed is
variable temp_min:signed(3*N-1 downto 0);
begin
  temp_min:=row(0);
  checking: for t in 1 to 3 loop
      if  (row(t)<temp_min) then
        temp_min:=row(t);
    end if;
  end loop checking;
  return temp_min;
end find_min;

begin
  
  process (clk,rst)
	variable ii,jj,kk:integer:=0;
	begin
	if (rst='1') then
	  jj:=0;
	  ii:=0;
		--mhdenise mnhmh
	elsif (clk'event and clk='0') then  --diavasma sthn arnhtikh akmh
	if (vin='1') then --vin enable signal
		--main body
		if (new_set='0') then --gemisma prwtou pinaka
			ii:=i;
			if (ii<=NA) then
			  inp1(ii)<=din;
		    i<=i+1;
		  end if;
		else --gemisma defterou pinaka
			jj:=j;
			if (jj<=NA) then
			   inp2(jj)<=din;
			   j<=j+1;
			end if;
		end if;
		if ((j>=NA)and(i>=NA)) then
			flag<='1';
		end if;
	end if;
end if;
end process;
   
    
    process(clk)
       variable row:integer;
       variable column: integer;
       variable line_finished: std_logic;
		 variable temp,min:signed(23 downto 0);
    begin
      --row:=k;
      --column:=l;
      if (clk'event and clk='1') then
			if (flag='1') then
          if (k<=NA) then 
              if(l<NA) then
                line_finished:='0';
					 if(l=1) then
						min:=signed(ext(sum_of_square_dif(inp1(k),inp2(l),"000000000000000000000000"),3*N));
					--	dout(k)<=min;
					 else
						temp:=signed(ext(sum_of_square_dif(inp1(k),inp2(l),"000000000000000000000000"),3*N));
						if (temp < min) then
							min:=temp;
						else
						  min:=min;					  
						end if;
					 end if;	
                l<=l+1;
              else --l=3
                line_finished:='1';
                l<=0;
                k<=k+1;
                dout(k)<=min;
          end if;
			 else
				line_finished:='Z'; --value that does nothing
        end if;
	  end if;
   end if;
end process;
    
end TB_ARCHITECTURE;

and after many changes the remaining warnings and info are those:
1)
Info

Xst:3218 - HDL ADVISOR - The RAM <Mram_inp1> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.

Xst:3218 - HDL ADVISOR - The RAM <Mram_inp2> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.

Xst:3218 - HDL ADVISOR - The RAM <Mram_inp21> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.

What are these? Does it mean that the synthesizer doesn't understanfd my array as RAM? If this is so, is there any standard model for the synthesizer to understand my component as a RAM?

2)
Warnings:

Xst:1710 - FF/Latch <min_16> (without init value) has a constant value of 0 in block <landmark>. This FF/Latch will be trimmed during the optimization process.

and I get the same one for min_16 to min_23, k_5 to k_8 signals and so on. Is this because with the constant chosens these bits tend to always be 0? If this is, its now worrying becauce I used these numbers just to test it, it will not be like that in my final code.

3) I am getting also this warning several times.

PhysDesignRules:372 - Gated clock. Clock net n0039 is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. New 
WARNING  PhysDesignRules:372 - Gated clock. Clock net flag_k[6]_AND_99_o is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. New 
WARNING  PhysDesignRules:372 - Gated clock. Clock net flag_k[6]_AND_545_o is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. New 
WARNING  PhysDesignRules:372 - Gated clock. Clock net flag_k[6]_AND_641_o is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. New 
WARNING  PhysDesignRules:372 - Gated clock. Clock net flag_k[6]_AND_449_o is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. New 
WARNING  PhysDesignRules:372 - Gated clock. Clock net flag_k[6]_AND_737_o is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. New 
WARNING  PhysDesignRules:372 - Gated clock. Clock net flag_k[6]_AND_833_o is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. New 
WARNING  PhysDesignRules:372 - Gated clock. Clock net flag_k[6]_AND_593_o is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop. 

and so on

What is this?

 

[barry]

The error messages refer to signals that don't appear in your code, so it's a little hard to identify the actual cause.Here are some ideas.

I don't actually see where you are creating a RAM array (in that package?), but what the message is telling you is that you are reading from the RAM asynchronously, so the synthesizer won't use the dedicated RAM blocks. I would suggest you use Coregen to create your RAM.

I haven't looked that closely at your code, but apparently the way you've written it, you'll never assign non-zero values to those bits. I don't see any "constants", as you say; I think it's just a function of your code. For instance, if you have an assignment like x<=2*y, bit zero of x will never have a value other than zero, and it will be trimmed. Check your code.

You have a whole bunch of nested if's. I suspect that's where your gated clocks are coming from. Make sure all your signals/variables are assigned for every if/else;

 

[achandra]

Well as this is my first synthesis, I need your help so as to realize certain things and be able to continue my project. I am using a Virtex6 , and my ISE is that ot Xilinx.

My code is this:

  process (clk,rst)
	variable ii,jj,kk:integer:=0;
	begin
	if (rst='1') then
	  jj:=0;
	  ii:=0;

What is this?

1) You need not initialize variables in reset. Reset should be used to provide initial values for signals, not variables. Hence most signals (including flag) will be called combinatorial signals even though they are not meant to be.

2) Right, your synthesizer is not able to recognize ur array as a block ram. How to get it recognized? There is a particular coding style in which the synthesizer will recognize it as a block ram, refer to the synthesis user guide, called the XST userguide

3) Nothing to worry about the trimming thing - if ur actual design doesn't use constants then they won't be trimmed.

4) About flag signal, u initialized it during declaration which am not sure if synthesis tools recognizes, try initializing it inside the reset, it should work.

 

[TrickyDicky]

1) You need not initialize variables in reset. Reset should be used to provide initial values for signals, not variables. Hence most signals (including flag) will be called combinatorial signals even though they are not meant to be.

Not true. If you expect the variable to be synthesised into a register with reset, then you will need to give it a reset condition.

3) Nothing to worry about the trimming thing - if ur actual design doesn't use constants then they won't be trimmed.

Registered are trimmed when the synthesisor understands that they do nothing. This may be very important if you expect the register to actually do something, so never ignore it.

4) About flag signal, u initialized it during declaration which am not sure if synthesis tools recognizes, try initializing it inside the reset, it should work.

They do now, and give it a power-up value from the inital declaration.


Notes on the OPs code:
1. Dont use std_logic_arith, use numeric_std.
2. you're not far off infering a ram. You need to register the output from the inp1 and inp2 before you can use them in the function (if it was altera, you might have got away with it). like the previous posted said - have a read of the recommended coding styles.
3. whats that "line_finished := 'Z' " all about? if you want it to do nothing, dont have the else case. All this does is make it look like you want a tri-state buffer, which you dont.

Your final errors relate to parts external to this design. It looks like you're creating a logic clock - and like the warnings say, they're a very bad idea in FPGAs. Use the standard clock everywhere and generate clock enables instead.

 

[achandra]

Not true. If you expect the variable to be synthesised into a register with reset, then you will need to give it a reset condition.

Am speaking of the current code which ghostridergr has posted. It looks obvious that the variables are not meant to be registers.

Registered are trimmed when the synthesisor understands that they do nothing. This may be very important if you expect the register to actually do something, so never ignore it.

Again, am speaking of the 'constants' which ghostridergr is talking of. Am asking him not to ignore anytime this warning shows up, after what i see, i understand all of the trimming warnings shown above by ghostridergr can be ignored. Spend some time on it, am sure u will agree too.

They do now, and give it a power-up value from the inital declaration.

Thanks for the confirmation, but i still believe it's a good practice to initialize registers in the reset and avoid initialization on declaration to the extant possible.

Your final errors relate to parts external to this design. It looks like you're creating a logic clock - and like the warnings say, they're a very bad idea in FPGAs. Use the standard clock everywhere and generate clock enables instead.

Assuming u r talking of the warnings on flag_k etc, they are related to the way the signal 'flag' is generated/used in his code, very much a part of the code provided by ghostridergr