Counter with asynchronous enable

Discussion in 'VHDL' started by Ramya Murali, Feb 29, 2012.

  1. Ramya Murali

    Ramya Murali Guest

    I have a counter (positive edge triggered) whose enable (active high)
    is generated by a two state FSM (positive edge state transition).
    Counter_enable is set to '0' in State 1 and set to '1' in State 2.

    signal count : std_logic_vector (3 downto 0) := "0000";
    p1 : process (clk, counter_enable)
    begin
    if ((rising_edge (clk) and (counter_enable = '1')) then
    count <= count +1;
    end if;
    end process p1;

    p2 : process (current_state)
    case current_state is
    when '0' => next_state <= '1'; counter_enable <= '0';
    when '1' => next_state <= '1'; counter_enable <= '1;
    when OTHERS => next_state <= '0'; counter_enable <= '0';
    end case;
    end process;

    While simulating using ModelSim, at the positive edge of the clock
    ( say edge1) when the state transitions from S1 to S2, the
    counter_enable is set to '1' correctly. But the counter doesnot begin
    to count at this positive edge (edge1) but begins to count at the next
    positive edge of the clock (edge2).

    My reasoning is as follows.
    The assignment to counter_enable occurs at the end of process p2,
    which is at delta time after edge1. At delta time, even though the
    process p1 is activated as counter_enable is included in its
    sensitivity list, the condition rising_edge(clk) is not true and the
    count is not incremented.

    Is this correct? Is the counter_enable asynchronous?
     
    Ramya Murali, Feb 29, 2012
    #1
    1. Advertising

  2. Ramya Murali

    Gabor Guest

    Ramya Murali wrote:
    > I have a counter (positive edge triggered) whose enable (active high)
    > is generated by a two state FSM (positive edge state transition).
    > Counter_enable is set to '0' in State 1 and set to '1' in State 2.
    >
    > signal count : std_logic_vector (3 downto 0) := "0000";
    > p1 : process (clk, counter_enable)
    > begin
    > if ((rising_edge (clk) and (counter_enable = '1')) then
    > count <= count +1;
    > end if;
    > end process p1;
    >
    > p2 : process (current_state)
    > case current_state is
    > when '0' => next_state <= '1'; counter_enable <= '0';
    > when '1' => next_state <= '1'; counter_enable <= '1;
    > when OTHERS => next_state <= '0'; counter_enable <= '0';
    > end case;
    > end process;
    >
    > While simulating using ModelSim, at the positive edge of the clock
    > ( say edge1) when the state transitions from S1 to S2, the
    > counter_enable is set to '1' correctly. But the counter doesnot begin
    > to count at this positive edge (edge1) but begins to count at the next
    > positive edge of the clock (edge2).
    >
    > My reasoning is as follows.
    > The assignment to counter_enable occurs at the end of process p2,
    > which is at delta time after edge1. At delta time, even though the
    > process p1 is activated as counter_enable is included in its
    > sensitivity list, the condition rising_edge(clk) is not true and the
    > count is not incremented.
    >
    > Is this correct? Is the counter_enable asynchronous?


    It is correct and it is synchronous. This is how synchronous
    logic behaves. By the way, you should not have counter_enable in
    the sensitivity list of the clocked process. For simulation
    it does nothing, because the only place it is used is when
    it is ANDed with a rising edge of the clock. For synthesis
    it could confuse the tools to think you're trying to use
    counter_enable as an asynchronous reset input, or it could also do
    nothing, or it could cause an error like "invalid sequential
    description" depending on the synthesizer you use.

    In any sort of real synchronous logic, anything that depends on
    the rising edge of the clock takes its inputs from logic
    levels before the rising edge of the clock and won't change
    its output until after the rising edge of the clock. If you
    want your counter to count on the same edge when your state machine
    goes into state 2, then you need to enable the counter with
    the same terms that cause the state transition so the count
    enable is valid before the clock where the state transitions.

    -- Gabor
     
    Gabor, Feb 29, 2012
    #2
    1. Advertising

  3. Ramya Murali

    JimLewis Guest

    Clock rises, the output of the current_state flip-flop
    changes state, it is decoded, and the counter_enable
    output is generated. Just like real hardware, the
    counter_enable does not update on the same clock
    edge that generates it, however, it is synchronous
    since it is generated off of Clk (the same clock we are
    referencing).

    Asynchronous signals are independent of the current
    clock domain and require special handling.

    You may want to try out your count enable in your preferred synthesis
    tool as some have issues with that coding style. You may need to
    code counter_enable in a separate if statement.

    > My reasoning is as follows.
    > The assignment to counter_enable occurs at the end of process p2,
    > which is at delta time after edge1. At delta time, even though the
    > process p1 is activated as counter_enable is included in its
    > sensitivity list, the condition rising_edge(clk) is not true and the
    > count is not incremented.

    Counter_enable change 2 delta cycles after clock. One for the update
    to current_state and one for the update to counter_enable.

    It will help if you draw all of your timing diagrams with
    a small propagation delays - the real hardware will have these.
    Although delta cycles are part of the simulation algorithm, in
    an abstract way they work similar to a propagation delay.
     
    JimLewis, Feb 29, 2012
    #3
  4. Ramya Murali

    Andy Guest

    On Feb 29, 5:05 pm, JimLewis <> wrote:
    > You may want to try out your count enable in your preferred synthesis
    > tool as some have issues with that coding style.  You may need to
    > code counter_enable in a separate if statement.


    1076.6-2004, section 6.1.3.1, example 4, supports this construct. By
    now, every synthesis tool should support it or be drawn and
    quartered.

    That said, verifying feature support by the tool in use is never a bad
    idea! We don't want to draw and quarter anyone unless they really
    deserve it.

    Andy
     
    Andy, Mar 8, 2012
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Georges Konstantinidis

    asynchronous counter an Xilinx FPGA for a newbie

    Georges Konstantinidis, Jan 30, 2004, in forum: VHDL
    Replies:
    12
    Views:
    5,975
  2. Jan Behrend

    Asynchronous up/down counter

    Jan Behrend, Mar 2, 2006, in forum: VHDL
    Replies:
    2
    Views:
    8,064
    Jan Behrend
    Mar 3, 2006
  3. Patrick
    Replies:
    1
    Views:
    682
  4. ckyz
    Replies:
    0
    Views:
    4,553
  5. coldplay112
    Replies:
    2
    Views:
    699
    rickman
    Sep 25, 2006
Loading...

Share This Page