Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
10 years ago

Clock gating with enable or not

Here is a n00b question from one which is rusty in VHDL:

The statement is not to gate the clock, but is the following considered clock gating? ena is a synchronous enable signal.


process (clk)
begin
  if clk'event and clk='1' then
    if ena='1' then
      -- useful code
    end if;
  end if;
end process;

Is this above functionally the same as the line below? Syntax-wise it seems so, but it starts to feel awfully like gating.


if clk'event and clk='1' and ena='1' then

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You can use synthesis attribute direct_enable set to false but you can get lut instead of sload signal for LE

    And replace checking for clock edge with rising_edge cause later provide real 0 to 1 compare it with X to 1 in your code

    Then using synchronous signal- you should allow it in synthesis.

    You can try utilize both sclear and sload so tool understand synchronous
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Here is a n00b question from one which is rusty in VHDL:

    The statement is not to gate the clock, but is the following considered clock gating? ena is a synchronous enable signal.

    
    Is this above functionally the same as the line below? Syntax-wise it seems so, but it starts to feel awfully like gating.
    if clk'event and clk='1' and ena='1' then
    

    --- Quote End ---

    Compilers are good here and I assume they will not gate clock. But why divert away from simple template of first code to mislead the compilers?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Oh... I've tried to use template from quartus text editor. perhaps it shoud be verified. What can be in else clause for sync_load???

    -- In Altera devices, register signals have a set priority.
    -- The HDL design should reflect this priority.
    process(<reset>, <aload>, <adata>, <clock_signal>)
    begin
    	-- The asynchronous reset signal has the highest priority
    	if (<reset> = '0') then
    		<register_variable> <= '0';
    	-- Asynchronous load has next-highest priority
    	elsif (<aload> = '1') then
    		<register_variable> <= <adata>;
    	else 
    		-- At a clock edge, if asynchronous signals have not taken priority,
    		-- respond to the appropriate synchronous signal.
    		-- Check for synchronous reset, then synchronous load.
    		-- If none of these takes precedence, update the register output
    		-- to be the register input.
    		if (rising_edge(<clock_signal>)) then
    			if (<clock_enable> = '1') then
    				if (<synch_reset> = '0') then
    					<register_variable> <= '0';
    				elsif (<synch_load> = '1') then
    					<register_variable> <= <synch_data>;
    				else
    					<register_variable> <= <data>;
    				end if;
    			end if;
    		end if;
    	end if;
    end process;
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    All signals inside branch for clock transition are synchronus.

    even if it enable clock signal per LAB. (okay this signal could come along with active clock-edge?)

    I think about synchronus and synchronus, and clock-gating at source or enable clock per flip-flop.

    does documentation juggle the termins so free? Hope no, cause for each case we have a nice figures for clarification. but it is terrible.

    It is due to optimization technique.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    finally, i found who is responible for such situation. Among 80 global assignments we have Auto Clock Enable Replacement which("witch") is on by default.

    So default assignments is very smart , smarter than required.