Two processes with communication through a signal.

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

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

kennheinrich@sympatico.ca

"jumpz" <> wrote in message
news:95b5027c-47ad-44f6-a96c-...
> 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

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

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

On Jun 2, 3:45 pm, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> 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

kennheinrich@sympatico.ca