race conditions/pulse width

[The Weiss Family]

The "Clock Edge Transitions" thread got me thinking.
If I have two synchronous processes, one of which outputs a signal
synchronous to a clock and is a single clock in width, and the other process
monitors the status of the signal, is it possible that the pulse could occur
without the second process seeing it?
I have code in a design that seems to work fine, but I have doubts that this
is not the best way of doing things...
See the example below:

PROC_A: process(clk, rst)
begin
-- async reset, set to zero
if (rst = '1') then
pulse <= '0';

-- at each rising edge, set pulse to '1'
elsif (rising_edge(clk)) then
if (pulse <= '1') then -- here always limit pulse to 1 clock.
That is, if it is '1', set it right back to '0' on the next clock
pulse <= '0';

elsif (some_condition_is_true)
pulse < = '1';
endif;
endif;
end process;

PROC_B: process(clk, rst)
begin
-- async reset, set to zero
if (rst = '1') then
pulse2 <= '0';

elsif (rising_edge(clk)) then
if (pulse = '1') then -- is it possible that this process will
never see pulse = '1' because it is only 1 clock wide?
pulse2 <= '1'
end if;
end process;

 

[Paul Uiterlinden]

The "Clock Edge Transitions" thread got me thinking.
If I have two synchronous processes, one of which outputs a signal
synchronous to a clock and is a single clock in width, and the other
process monitors the status of the signal, is it possible that the
pulse could occur without the second process seeing it?

No. Remember that there always is a delta cycle delay in any signal
assignment.

So the watching process will not see the new value at the same clock
edge, because that value is not there yet (it will happen one delta
cycle in the future).

At the next clock edge it will see the new value, which is going to
stay for just another delta cycle. So your pulse of one clock period
will not be missed.

Think in hardware. The output of a flip-flop changes after the clock
edge. Another flip-flop on the same clock clocks in the "old" value
at the same clock edge and the "new" value on the next clock edge.

Paul.

 

[The Weiss Family]

No. Remember that there always is a delta cycle delay in any signal
assignment.

So the watching process will not see the new value at the same clock
edge, because that value is not there yet (it will happen one delta
cycle in the future).

At the next clock edge it will see the new value, which is going to
stay for just another delta cycle. So your pulse of one clock period
will not be missed.

Think in hardware. The output of a flip-flop changes after the clock
edge. Another flip-flop on the same clock clocks in the "old" value
at the same clock edge and the "new" value on the next clock edge.

Paul.

I guess I was thinking that the pulse could potentially be a glitch.
That is, in terms of hardware, if the pulse signal was exactly one clock,
and it lined up just right, it could violate a setup/hold time and
potentially be missed by the observing flop. Is this something to worry
about?

 

[Ken Smith]

I guess I was thinking that the pulse could potentially be a glitch.
That is, in terms of hardware, if the pulse signal was exactly one clock,
and it lined up just right, it could violate a setup/hold time and
potentially be missed by the observing flop. Is this something to worry
about?

The biggest worry in hardware is whether the signal is ready for the next
clock in time.

Only when you have a clock skew issue, do you need to worry about
interactions on the same edge.

 

[Element Blue]

No. Remember that there always is a delta cycle delay in any signal
assignment.

So the watching process will not see the new value at the same clock
edge, because that value is not there yet (it will happen one delta
cycle in the future).

At the next clock edge it will see the new value, which is going to
stay for just another delta cycle. So your pulse of one clock period
will not be missed.

Think in hardware. The output of a flip-flop changes after the clock
edge. Another flip-flop on the same clock clocks in the "old" value
at the same clock edge and the "new" value on the next clock edge.

Paul.

I agree with Paul. While the pulse will not be missed, it will be read
only at the next clock edge,when it will be a "old" value.

 

[The Weiss Family]

No. Remember that there always is a delta cycle delay in any signal
assignment.

So the watching process will not see the new value at the same clock
edge, because that value is not there yet (it will happen one delta
cycle in the future).

At the next clock edge it will see the new value, which is going to
stay for just another delta cycle. So your pulse of one clock period
will not be missed.

Think in hardware. The output of a flip-flop changes after the clock
edge. Another flip-flop on the same clock clocks in the "old" value
at the same clock edge and the "new" value on the next clock edge.

Paul.

Good!
I think everyone concurs that I don't have to change my design!
Thanks for the input.

Adam

 

[Jim Lewis]

The one thing that you can do wrong here is
to mess with clock. Lets suppose you merge two
designs and one uses the name Clk and the other
Clock for the same signal. Make sure to fix it
by changing the names and not by doing:

Clock <= Clk ; -- bad: clocks not delta cycle aligned.

Note in your second ff I changed Clk to Clock.

PROC_A: process(clk, rst)
begin
-- async reset, set to zero
if (rst = '1') then
pulse <= '0';

-- at each rising edge, set pulse to '1'
elsif (rising_edge(clk)) then
if (pulse <= '1') then -- here always limit pulse to 1 clock.
That is, if it is '1', set it right back to '0' on the next clock
pulse <= '0';

elsif (some_condition_is_true)
pulse < = '1';
endif;
endif;
end process;

PROC_B: process(clk, rst)
begin
-- async reset, set to zero
if (rst = '1') then
pulse2 <= '0';

elsif (rising_edge(CLOCK)) then
-- This would be bad: ^^^^^^

if (pulse = '1') then -- is it possible that this process will
never see pulse = '1' because it is only 1 clock wide?
pulse2 <= '1'
end if;
end process;

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~