Two processes with communication through a signal.

Discussion in 'VHDL' started by jumpz, May 30, 2008.

  1. jumpz

    jumpz Guest

    signal trigger;

    proc1 : process(clk)
    begin
    trigger <= '0';
    case state_proc1 is
    when ... (other states)
    when STATE1 =>
    trigger <= '1';
    state_proc1 <= STATE2;
    when STATE2 =>
    -- do something, but don't set trigger to anything
    when ... (other states)
    end case;
    end process proc1;

    proc2 : process(clk)
    begin
    case state_proc2 is
    when STATE1 =>
    if trigger = '1' then
    state_proc2 <= STATE2;
    end if;
    when STATE2 =>
    -- do something
    state_proc2 <= STATE1;
    end case;
    end process proc2;

    Can proc1 transition from (some state)->STATE1->STATE2->(some other
    state) without causing proc2 to transition from STATE1 to STATE2?
    (assuming state_proc2 is STATE1 to start)

    I have similar code which is implemented on a FPGA where proc2 somehow
    misses the trigger signal going high unless I keep it high for a few
    clock cycles and I really don't understand how this can happen. I
    thought in the above case both processes would run and then pending
    signal assignments (such as trigger going to 1) would be made
    simultaneously after a delta delay.

    If this is indeed not possible, any ideas on trying to identify what
    is causing this?

    Thanks!
    jumpz, May 30, 2008
    #1
    1. Advertising

  2. jumpz

    Guest

    jumpz wrote:

    >
    > Can proc1 transition from (some state)->STATE1->STATE2->(some other
    > state) without causing proc2 to transition from STATE1 to STATE2?
    > (assuming state_proc2 is STATE1 to start)
    >
    > I have similar code which is implemented on a FPGA where proc2 somehow
    > misses the trigger signal going high unless I keep it high for a few
    > clock cycles and I really don't understand how this can happen. I
    > thought in the above case both processes would run and then pending
    > signal assignments (such as trigger going to 1) would be made
    > simultaneously after a delta delay.
    >
    > If this is indeed not possible, any ideas on trying to identify what
    > is causing this?
    >


    Don't think about delta delays here. As long as both processes run on
    the same clock you just think of clock cycle delays. You'll see
    'trigger' going high on the clock *after* proc1 is in STATE1, i.e.
    rising edge of trigger coincides with the proc1 state transition from
    STATE1 -> STATE2.

    If your code is *exactly* as written, proc2 should always pick up on
    the trigger when proc2 is in STATE1 intially, and proc2 will be in
    STATE2 the clock after the trigger pulse.

    Other things that could be going on: you might not really be in STATE1
    in proc2. If you have rapid back-to-back triggers, proc2 might still
    be in state2 and will then not be looking for the trigger.

    You also are using a state type constant or enum which has more than 2
    states (hinted at in proc1). But proc2 doesn't recover if for any
    reason (ESD, DCM glitch, bad reset timing) it gets into one of the
    other states.

    You might also have a "gross motor function" problem like power supply
    glitches, unstable clocks, missed timing constraints during synthesis/
    P&R etc. Also, make sure they're the identical clocks on both
    processes.

    Also doublecheck that proc1 doesn't write to 'trigger' anywhere else
    in the process.

    HTH,
    - Kenn
    , May 31, 2008
    #2
    1. Advertising

  3. jumpz

    KJ Guest

    "jumpz" <> wrote in message
    news:...
    > signal trigger;
    >
    >
    > If this is indeed not possible, any ideas on trying to identify what
    > is causing this?
    >


    Use a simulator...it will happily provide you all the clues you need.

    KJ
    KJ, May 31, 2008
    #3
  4. jumpz wrote:

    > Can proc1 transition from (some state)->STATE1->STATE2->(some other
    > state) without causing proc2 to transition from STATE1 to STATE2?
    > (assuming state_proc2 is STATE1 to start)


    Your state values are stored in two
    different registers, state_proc1 and state_proc2.
    They may or may not have the same value,
    but this, in itself, does not cause interaction
    any more than if I had two counter
    registers both with the value 42.

    > I have similar code which is implemented on a FPGA where proc2 somehow
    > misses the trigger signal going high unless I keep it high for a few
    > clock cycles and I really don't understand how this can happen.


    A one-way handshake strobe can only succeed
    if the receiving process is *always* waiting
    whenever the strobe might occur.

    > I thought in the above case both processes would run and then pending
    > signal assignments (such as trigger going to 1) would be made
    > simultaneously after a delta delay.


    The processes run one case per clock tick.
    What happens depends on the input and state values
    for that tick.

    > If this is indeed not possible, any ideas on trying to identify what
    > is causing this?


    Any operation is possible.
    What might eliminate your confusion is to avoid
    two process when one would do
    and to use boolean flags and counters
    instead of a state enumeration.

    Or, as KJ suggests, use simulation
    instead of trial-and-error synthesis.
    Stepping through the code and watching
    the register values change tick by tick
    is educational.

    -- Mike Treseler
    Mike Treseler, May 31, 2008
    #4
  5. jumpz schrieb:

    > proc1 : process(clk)
    > begin
    > trigger <= '0';
    > case state_proc1 is
    > when ... (other states)
    > when STATE1 =>
    > trigger <= '1';
    > state_proc1 <= STATE2;
    > when STATE2 =>
    > -- do something, but don't set trigger to anything
    > when ... (other states)
    > end case;
    > end process proc1;


    I can't see no "if rising_edge(clk) then". This process ist triggered
    during simulation only if clk has an event, but after synthesis it is
    purely combinational logic.

    Ralf
    Ralf Hildebrandt, Jun 2, 2008
    #5
  6. jumpz

    Guest

    On Jun 2, 3:45 pm, Ralf Hildebrandt <> wrote:
    > jumpz schrieb:
    >
    > > proc1 : process(clk)
    > > begin
    > > trigger <= '0';
    > > case state_proc1 is
    > > when ... (other states)
    > > when STATE1 =>
    > > trigger <= '1';
    > > state_proc1 <= STATE2;
    > > when STATE2 =>
    > > -- do something, but don't set trigger to anything
    > > when ... (other states)
    > > end case;
    > > end process proc1;

    >
    > I can't see no "if rising_edge(clk) then". This process ist triggered
    > during simulation only if clk has an event, but after synthesis it is
    > purely combinational logic.
    >
    > Ralf


    D'Oh! Good catch -- it's easy to get fooled into seeing what you
    *think* should be there. Either the OP has overly simplified the
    example, but really did include a rising_edge(clk) (then the the
    original advice holds), or he's doing a Bad Thing. In that case, take
    Kevin's advice and use a simulator to explore the ways in which this
    can fail. Then fix it.

    - Kenn
    , Jun 3, 2008
    #6
    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. Phil Hays
    Replies:
    1
    Views:
    1,140
    Jeremy Pyle
    Jun 30, 2003
  2. Jonathan Bromley

    Re: Two processes writing one signal

    Jonathan Bromley, Jun 30, 2003, in forum: VHDL
    Replies:
    0
    Views:
    2,216
    Jonathan Bromley
    Jun 30, 2003
  3. Divyang M
    Replies:
    4
    Views:
    982
    Divyang M
    Feb 17, 2005
  4. Silver
    Replies:
    7
    Views:
    1,332
    Thomas Stanka
    Oct 16, 2007
  5. Gerhard
    Replies:
    17
    Views:
    1,854
    Alessandro Basili
    Jul 12, 2011
Loading...

Share This Page