[SOLVED] Vivado optimising logic and ILA issues

[sreevenkjan]

Hi all,

I am using ILA from the xilinx coregen,the behav simulation results are fine.Synthesis,implementation,bitstream generation are finished but however I cannot see the data coming from ila.Could you tell me where am i going wrong?

I looked for answers regarding few errors in the xilinx forum.Some people had issues regarding vivado optimising the logic functions.Is there any way of stopping such issues or should i try working with xilinx ISE??

regards,
Sreenivas

 

[TrickyDicky]

Are theere warning during synthesis that logic is being removed? thats a warning that your logic either does nothing or has no effect on the output.
ISE will do exactly the same job.

 

[sreevenkjan]

Following warnings are reported during synthesis

[Synth 8-4446] all outputs are unconnected for this instance and logic may be removed ["c:/filter_mytop/filter_mytop.srcs/sources_1/bd/design_filter/ip/design_filter_processing_system7_0_0/hdl/verilog/processing_system7_v5_3_processing_system7.v":2177]

[Synth 8-3295] tying undriven pin reg_8IN_I[11] to constant 0

[Synth 8-3295] tying undriven pin \MU_STATUS[0].mu_tpid_reg IN_I[11] to constant 0

[Synth 8-3295] tying undriven pin \CNT_WIDTH_STATUS[0].cnt_width_reg IN_I[13] to constant 0

[Constraints 18-549] Could not create 'IBUF_LOW_PWR' constraint because cell 'filter/ila_system/U0/ila_core_inst/u_ila_regs/U_XSDB_SLAVE/xsdb_interface_buffers_inst/SL_IPORT_IBUF[3].temp_buf' is not directly connected to top level port. 'IBUF_LOW_PWR' is ignored by Vivado but preserved inside the database. ["c:/Users/venkatsa/filter_mytop/filter_mytop.srcs/sources_1/ip/ila_0/labtools_xsdb_slave_lib_v2_1/hdl/verilog/xsdb_interface_buffers.v":93]

[Constraints 18-549] Could not create 'SLEW' constraint because cell 'filter/ila_system/U0/ila_core_inst/u_ila_regs/U_XSDB_SLAVE/xsdb_interface_buffers_inst/SL_OPORT_OBUF[3].temp_buf' is not directly connected to top level port. 'SLEW' is ignored by Vivado but preserved inside the database. ["c:/Users/venkatsa/filter_mytop/filter_mytop.srcs/sources_1/ip/ila_0/labtools_xsdb_slave_lib_v2_1/hdl/verilog/xsdb_interface_buffers.v":105]

[Synth 8-3936] Found unconnected internal register 'col_buf_reg' and it is trimmed from '480' to '479' bits. ["C:/Users/venkatsa/filter_mytop/filter_mytop.srcs/sources_1/new/filter_mytop.vhd":145]

[Synth 8-3332] Sequential element (\ila_core_inst/xsdb_memory_read_inst/curr_read_block_reg[0] ) is unused and will be removed from module ila_v3_0_ila.

[Synth 8-3332] Sequential element (\col_buf_reg[473] ) is unused and will be removed from module filter_mytop.

When i searched for answers it said vivado is trying to remove logic.How am I supposed to proceed?

 

[TrickyDicky]

Like it says in the first warning - all outputs are unconnected. You need to assign them to pins. If it cannot connect the ouputs, all logic will be removed.
The clues are all there in the warnings. Inputs that are driven to 0 will also help remove logic.

 

[sreevenkjan]

I found these answers in the xilinx user community

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

I guess this is the problem in my implementation because the vivado trims my signals and registers to 0 values as mentioned in the link i have posted.is there a way to overcome it.

 

[TrickyDicky]

Yes. Assign pins to them in the Vivado project. Or connect them to some other logic.

 

[sreevenkjan]

Hi,

when you say assign pins.do you mean in the constraints file?

 

[TrickyDicky]

Yes - you assign pins on the device to signals in your design in the contraints file - for xilinx this is a .ucf file.

 

[sreevenkjan]

Yes. Assign pins to them in the Vivado project. Or connect them to some other logic.

I am not using any of the DDRs,USB ports and other ethernet ports. So even if they are removed and made as constant 0 it does not affect my system. However my bram IP is being made to 0 and as a result i am facing these issues.
However i have attached component BRAM in my top module and have port mapped the clock of the top module to that of BRAM and have connected the clock of the processing system i.e 100Mhz to the clk of my top module in the wrapper file.i do not know why my bram components are removed and made to constant 0.

 

[TrickyDicky]

If your system is not connected to any output pins, then it is compltly useless as it does nothing, and will be removed. Input pins also need to be connected to something, otherwise how will they work?

 

[sreevenkjan]

output and input pins of the processing system are connected to input and output pins.however internally in the filter system schematic my mux are connected to gnd i.e 0.
is this because I have assigned the signals as 0 in the beginning of the process?Shall I leave them as 'U'??

 

[TrickyDicky]

No, they need to be connected to something that is viable. COnnecting them to 'u' is jst as bad as '0'. With them conneected to 0, it knows the mux is never going to change, so the compiler knows which option is always required and strips out the other options, that then have follow on consequences that means some logic is never used, so this is removed.

 

[sreevenkjan]

Hi,

I am having problems during indexing.for example when i say I need to find the buffer(x) where x in the index where my pixel is located in the register buffer.These indexing is removed and made as '0'.Can you use a different logic or how can I overcome these issues??

 

[TrickyDicky]

without the code, I dont understand what you mean.
YOu've said you've connected a mux to 0 - is X 0 in your logic?

 

[sreevenkjan]

well this is what I mean

col_buf(0) <= row_out(col_count);
			 col_buf(479 downto 1) <= col_buf(478 downto 0);	
             col1 <= col_buf(0);
             col2 <= col_buf(1);
             col3 <= col_buf(2);
             col_out <= col1 or col2 or col3;

As you can see my row_out register is (479 downto 0).So i have a counter with the range from 0 to 479 known as col_count which increments every time from 0 to 479 indexing the row_out register.then i use col_buffer as my shift register which gets input from the row_out register by indexing 1 bit at a time.

 

[TrickyDicky]

You've got a 480 long shift register. But only elements 0, 1 and 2 are used. So 3-480 can be removed. What you dont show (for others, I have it on a PM) is the rest of the code: here it is:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_textio.all;
 
entity filter_mytop is
    Port ( clk : in STD_LOGIC;
           rstn : in STD_LOGIC;
           data_out : out STD_LOGIC);
end filter_mytop;
 
architecture Behavioral of filter_mytop is
 
-- Adding BRAM content
COMPONENT blk_img3
    PORT (
       clka  : IN STD_LOGIC;
       wea   : IN STD_LOGIC_VECTOR(0 DOWNTO 0);
       rsta  : IN STD_LOGIC;
       addra : IN STD_LOGIC_VECTOR(8 DOWNTO 0);
       dina  : IN STD_LOGIC_VECTOR(479 DOWNTO 0);
       douta : OUT STD_LOGIC_VECTOR(479 DOWNTO 0)
    );
END COMPONENT;
 
---- Adding ILA component
COMPONENT ila_0
        PORT (
        clk : IN STD_LOGIC;
        probe0 : IN STD_LOGIC_VECTOR(0 DOWNTO 0)
        );
END COMPONENT ila_0;
 
--signal declarations
 
signal we : std_logic_vector(0 downto 0);--:= "0";
signal pixel_addr : std_logic_VECTOR(8 downto 0):= (others => '0');
signal row,out_pixel : std_logic_vector(479 downto 0):= (others => '0');
-- State machine definitions for filter
type filter_state is (pixel_increment,row_filter,col_filter,filter_loop);
signal state : filter_state := pixel_increment;
 
-- Array buffer declaration for filter 
type array_buffer is array(1 to 3) of std_logic_vector(479 downto 0);
signal row_buf : array_buffer := (others=>(others=>'0'));
 
--file data:text open write_mode is "data.txt";
 
-- Signal declarations for filter
signal row1,row2,row3 : std_logic_VECTOR(479 downto 0):= (others => '0');
signal row_out,output,col_buf : std_logic_VECTOR(479 downto 0):= (others=>'0');
signal col1,col2,col3,col_out : std_logic := '0';
signal data_ready,label_start : std_logic;
signal loop_count : integer range 1 to 4;
signal col_count : integer range 0 to 479;
 
-- Signal declarations for ILA
signal ila_output : STD_LOGIC_VECTOR(0 DOWNTO 0):= (others=>'0');
 
begin
 
--Instantiating BRAM.
bram : blk_img3
    port map(
    clka => clk,  
    rsta => rstn,   
    wea => we,   
    addra => pixel_addr,
    dina => out_pixel,
    douta => row);
 
-- Instantiating ILA
ila_system : ila_0
        PORT map (
        clk    => clk,
        probe0 =>  ila_output
        );
        
-- Filtering Process
dilation_filter : process(clk)
--variable txt:line;
begin
 
    if rising_edge(clk) then
     if rstn = '0' then
            pixel_addr <= "000000000";
            state <= pixel_increment;
     else
        case state is
        when pixel_increment =>
             we <= "0";
             pixel_addr <= pixel_addr + "000000001";
             if pixel_addr = "111011111" then
                --report "loop finished";
                loop_count <= loop_count + 1;
             if loop_count = 4 then
                   loop_count <= 1;
                   pixel_addr <= "000000000";
                   state <= pixel_increment;
             end if;
                pixel_addr <= "000000000";
             end if;
             data_ready <= '0';
             state <= row_filter;
        when row_filter =>
             row_buf(1) <= row;
             row_buf(2 to 3) <= row_buf(1 to 2);
             row1 <= row_buf(1);
             row2 <= row_buf(2);
             row3 <= row_buf(3);
             row_out <= row1 or row2 or row3;
             state <= col_filter;
        when col_filter =>
             col_buf(0) <= row_out(col_count);
             col_buf(479 downto 1) <= col_buf(478 downto 0);    
             col1 <= col_buf(0);
             col2 <= col_buf(1);
             col3 <= col_buf(2);
             col_out <= col1 or col2 or col3;
             data_ready <= '0';
             state <= filter_loop;
        when filter_loop =>
             output(col_count) <= col_out;
             ila_output <= output(col_count downto col_count);
             if loop_count = 3 then
                data_out <= col_out;
             end if;
             col_count <= col_count + 1;
             if col_count = 479 then
                col_count <= 0;
                we <= "1";
                out_pixel <= output;
                data_ready <= '1';
                state <= pixel_increment;
             else
                state <= col_filter;
             end if;
       end case;
 
    end if;
    end if;
 
end process dilation_filter;
         
end Behavioral;

---

You're only incrementing the counter every clock, and col_buf only gets set every other clock cycle, so why do you need a 480 long line of pixels? why cant col_count be an address to memory?

Plus, why are all 3 rows or'd together?

 

[sreevenkjan]

i am using a 480 long line so that I can have 3 buffer arrays where i use it as a shift buffer. 3 rows are being OR'd because I am doing the filter operation in that x direction that is vertically then I store the output in a horizontal buffer i.e column buffer and then do it the y direction.yes i increment the counter clock so that I can use the count value as the address of my row output.

 

[TrickyDicky]

But you dont need the shift registers at all. The lines could easily be stored in ram as you only ever need a single value per clock.
Plus this state machine just gets in the way of processing. But having the register array you risk it building a 480 to 1 mux, which will give you a terrible FMax. You could remove the state machine entirely and just run a simple pipelined solution, rather than this fudged software approach.

 

[sreevenkjan]

as you see I am updating the BRAM address with the output so that I can reuse the same bram data after I am done filtering with the entire bram data.so its like i read the data from bram in the first address and then write the data back into the same address position.what so you mean by FMax.fudged software approach where did you get that from??..FYI its much simpler in software than in vhdl and we dont need state machines in software..

can you tell me if it has got anything to do with my code logic being removed and being terminated to 0??

- - - Updated - - -

I would not done it in a simpler way if I was not updating my bram with the output of my filter.

 

[TrickyDicky]

The the clk input connected to a clock pin or output from a DCM? is the rstn tied to '0'?