Synthesis

[eteam00]

I thought that clock gatting can reduce power

It can reduce  power if done properly.

If done improperly, it will not reduce power and it can create timing hasards.

If you are completely shutting down a large section of your design for extended periods, clock gating will reduce power.

If you are using clock gating to reduce clock frequency by 1/4, then you are burning extra power by distributing both the gated and ungated clocks.

In any case, a clock generated directly from combinatorial logic (a LUT) can glitch, which will wreak havoc in the locked logic.  Clocks generated from internal logic should be generated directly from registers outputs, as register outputs are glitch-free.

Finally, any and all internally generated clocks must be properly buffered and distributed.  Even a small length of interconnect "wiring" can result in enough clock skew to guarantee failure.

-- Bob Elkind

[hgleamon1]

OK - if the warning message has gone away then that is a good thing.

I am not sure, however, that you have fully grasped the point of the clock enable suggestion. My (and I believe others on this thread) point was that, by using a clock enable (or several as your design requires), you don't need to be setting clock attributes on signals like rd_thrd_latch_clk (even the name makes me a bit unsure) because you will only have the main "system" clock to be clocking all of your gates.

Consider the following pseudo-vhdl (my God I hope I get this right!):

first_process : process (clock)

if rising_edge(clock) then

  if (my_first_enable = '1') then

    change data_set_1;

  end if;

end if;

end process first_process;

second_process : process (clock)

if rising_edge(clock) then

  if (my_second_enable = '1') then

    change data_set_2;

  end if;

end if;

end process second_process;

And so all behaviour is fully synchronised to clock but the activities defined under change data_set_x will only occur at times when the two different enables dictate (i.e. at different times and at different frequencies). These enables should also be generated synchronously (to clock) as eteam00 referred to in his previous post (#9).

In short, I am glad that we are helping but I think that you could really rationalise your clocks further.

Can you post the clock information from your latest synthesis?

Regards,

Howard

[melika]

Consider the following pseudo-vhdl (my God I hope I get this right!):

first_process : process (clock)

if rising_edge(clock) then

  if (my_first_enable = '1') then

    change data_set_1;

  end if;

end if;

end process first_process;

second_process : process (clock)

if rising_edge(clock) then

  if (my_second_enable = '1') then

    change data_set_2;

  end if;

end if;

end process second_process;

Hello,

yes that's right.

and I'm Sorry because I have deleted  attribute setting and synthesis my code twice , there is no problem without attribute setting.

I am so sorry.

Thank you so much

but my issue about combinatorial loop is not resolved, I tried and found what is the reason of combinatorial loop in my design, in detail of  my block diagram  here

 I have expressed that, signals from multiplexers go to two parts, like this Image and this is the reason of "warning 2170".

Signals should be entered in two parts, Please guide me. what can I do?

Thanks a lot

[melika]

Thanks for your guidance "eteam00"

[hgleamon1]

Signals should be entered in two parts, Please guide me. what can I do?

Is it a registered signal?

It is not unusual to have signal routed to more than one place (just think about a reset or a clock enable) and I do not believe that this particular type of connection is the cause of your combinatorial loop. As a check, you could remove the multiplexers so that only one signal is ever routed and see what your synthesis results are. I'm going to guess that the loop problem remains.

One other thing that concerns me is the information in the timing summary. A minimum period of 1163ns? What is the design frequency of "clk"? This seems a very large amount to me and further suggests that there are not many clocked registers in the system or that you are trying to do an awful lot of logic between clock cycles (i.e. very large, nested "if").

Regards,

Howard

[melika]

Test_combonatorial_loop code isa simple code for test combinatorial loop.

In this code, if signal Out_end1 describes  like this:  

signal out_end1 : std_logic_vector(0 to 31)

we do not have any warning about combinatorial loop,

but if out_end1 describes as an output   (out_end1 : out std_logic_vector(0 to 31))

we have attached warning.

Thanks a lot for your guidance

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

library ieee;
    use ieee.std_logic_1164.all;

entity test_combinatorial_loop is
    port(
            mux_in0 : in std_logic_vector(0 to 31);
           cipher_selector : in std_logic;
          out_end1 : out std_logic_vector(0 to 31)
         );
end entity;

architecture arch of test_combinatorial_loop is
    signal sec_mux128_out : std_logic_vector(0 to 31);
    signal output :  std_logic_vector(0 to 31);
   -- signal out_end1 :  std_logic_vector(0 to 31);
    signal dec_mix_column_out : std_logic_vector(0 to 31);
 

begin
    
element0 : entity work.inv_mix1_col(arch)
port map(inv_mix_out => dec_mix_column_out(0 to 7), inv_mix0_in => sec_mux128_out(0 to 7), inv_mix1_in => sec_mux128_out(8 to 15),  
inv_mix2_in => sec_mux128_out(16 to 23), inv_mix3_in => sec_mux128_out(24 to 31));

element1 : entity work.inv_mix1_col(arch)
port map(inv_mix_out => dec_mix_column_out(8 to 15), inv_mix0_in => sec_mux128_out(8 to 15), inv_mix1_in => sec_mux128_out(16 to 23),  
inv_mix2_in => sec_mux128_out(24 to 31), inv_mix3_in => sec_mux128_out(0 to 7));

element2 : entity work.inv_mix1_col(arch)
port map(inv_mix_out => dec_mix_column_out(16 to 23), inv_mix0_in => sec_mux128_out(16 to 23), inv_mix1_in => sec_mux128_out(24 to 31),  
inv_mix2_in => sec_mux128_out(0 to 7), inv_mix3_in => sec_mux128_out(8 to 15));

element3 : entity work.inv_mix1_col(arch)
port map(inv_mix_out => dec_mix_column_out(24 to 31), inv_mix0_in => sec_mux128_out(24 to 31), inv_mix1_in => sec_mux128_out(0 to 7),  
inv_mix2_in => sec_mux128_out(8 to 15), inv_mix3_in => sec_mux128_out(16 to 23));
----------------------------------------------------------

cipher2_selection_mux : entity work.mux32(arch)
port map( in0 => dec_mix_column_out, in1 => mux_in0, sel => cipher_selector,   --output
mux32_out => sec_mux128_out);
out_end1 <= sec_mux128_out;

end architecture;
-------------------------------------------------------------------------------------------------------

[melika]

This seems a very large amount to me and further suggests that there are not many clocked registers in the system or that you are trying to do an awful lot of logic between clock cycles (i.e. very large, nested "if").

That's right , and my biggest warning is this: 

WARNING:Xst:1336 -  (*) More than 100% of Device resources are used

:-/

and this is the report of synthesis my code with XC3S400-5fg320

Thank you so much for your guidance

[hgleamon1]

I have tried to understand your test code. This is what I have learned:

1. There is no clock. Anywhere.

2. sec_mux128_out is an input to every elementx : entity work.inv_mix1_col(arch) and the output of cipher2_selection_mux : entity work.mux32(arch) 

3. dec_mix_column_out is an output of every elementx : entity work.inv_mix1_col(arch) and the input to cipher2_selection_mux : entity work.mux32(arch)

Does this look like a big combinatorial loop already? All the inputs are dependent on each other with no registered signals.

What is the actual synthesis output when out_end1 is a signal and not an output? In that case, your entity has no outputs which, generally, isn't very useful and will probably be completely optimised away (thus removing the combinatorial loop warning).

I can't really "advise" you without being able to understand what it is you are trying to achieve, which I cannot fathom from the code you have posted.

Regards,

Howard