rising_edge(CLK) == ( CLK'event and CLK = '1' )?

Post by Weng Tianxiang
comp.lang.vhdl ›
create 400 clocks delay for a signal
https://groups.google.com/forum/#!topic/comp.lang.vhdl/0q5kuIgX7eg
signal a : std_logic;
signal b : std_logic;
signal q : std_logic_vector(0 to 399);
begin
delay : process (CLK)
if( CLK'event and CLK = '1' ) then
q <= a & q(0 to 398);
end if;
end process;
b <= q(399);
I'm curious, why do you still use the notation above for a clock edge rather
than ( CLK'event and CLK = '1' )? Normally this is only seen in students being taught by teachers who aren't versed in modern methods.
1. I followed Rick's comment and changed all ( CLK'event and CLK = '1' ) to rising_edge(CLK) in a very thoroughly tested code.
2. Synthesization is OK.
3. I have assertion statements in my code and the assertion statements are located under ( CLK'event and CLK = '1' ).
4. it generates an error, indicating my result has an error which never happens before after the code was thoroughly debugged.
5. I restored the original coding, and the code runs without any error!
6. It seems that something different exists between rising_edge(CLK) and ( CLK'event and CLK = '1' ).
7. Any comment?
Weng

As long as the clock signal only has values of '0' or '1' the two will work
exactly the same in simulation and of course no matter what the two will
work the same in the real world. But in simulation there are other possible
values for the clock signal. rising_edge() will check that a transition
occurred between '0' or 'L' and '1' or 'H'. Any other transition is ignored.

The expression (CLK'event and CLK = '1') will respond to a transition
between *any other* state and '1' and will ignore transitions to 'H'.

I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag.

If rising_edge() was not different from (CLK'event and CLK = '1') there
would be no reason to use it. rising_edge() is closer to real hardware
responding to any valid transition from a logic low to a logic high while
(CLK'event and CLK = '1') does not but will respond to spurious transitions.

--
Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Weng Tianxiang

2017-11-13 15:43:35 UTC

As long as the clock signal only has values of '0' or '1' the two will work
exactly the same in simulation and of course no matter what the two will
work the same in the real world. But in simulation there are other possible
values for the clock signal. rising_edge() will check that a transition
occurred between '0' or 'L' and '1' or 'H'. Any other transition is ignored.
The expression (CLK'event and CLK = '1') will respond to a transition
between *any other* state and '1' and will ignore transitions to 'H'.
I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag.
If rising_edge() was not different from (CLK'event and CLK = '1') there
would be no reason to use it. rising_edge() is closer to real hardware
responding to any valid transition from a logic low to a logic high while
(CLK'event and CLK = '1') does not but will respond to spurious transitions.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Thank you, Rick and Allan,

I have pin-pointed the problem's reason and it has nothing to do with glitch, but really something with their behavior differences:

Rick is partially right:

"I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag."

Here is my code to demonstrate how the problem is pin-pointed:

-- SINI <= '1', '0' after 4 ns; OK for (CLK'event and CLK = '1'), fails
-- for Rising_edge(CLK)
-- SINI <= '1', '0' after 14 ns; OK for both
SINI <= '1', '0' after 14 ns;

MainClock : process
begin
-- the reason why '1' is chosen when time = 0 is that it makes all rising
-- edge on xxx0 ns, not on xxx5
CLK <= '1'; wait for 5 ns;
CLK <= '0'; wait for 5 ns;
end process;

SINI is used to initialize all necessary registers and at time 0 (CLK'event and CLK = '1') generates a true value while Rising_edge(CLK) doesn't. It causes an error, not because of any glitch, but because necessary registers are not initialized properly, because my assertion() is after SINI = '1' is generated.

There are two ways to correct the error:
1. As I do, extend the SINI assertion from 4ns to 14ns in case of (CLK'event and CLK = '1'). Because my assertion is after SINI = '1' is generated, so the assertion would not generate the error anymore.

2. As Allan suggested, the following would work for both
SINI <= '1', '0' after 6 ns;

MainClock : process
begin
CLK <= '0'; wait for 5 ns;
CLK <= '1'; wait for 5 ns;
end process;

Conclusion: at time 0 (CLK'event and CLK = '1') and Rising_edge(CLK) really have different behavior and it should be paid attention to, at least one should know it and adhere to one working method.

After the experiment, later I will choose Rising_edge(CLK) and
SINI <= '1', '0' after 14 ns;

MainClock : process
begin
CLK <= '1'; wait for 5 ns;
CLK <= '0'; wait for 5 ns;
end process;

Weng

Charles Bailey

2017-11-14 00:43:23 UTC

As long as the clock signal only has values of '0' or '1' the two will work
exactly the same in simulation and of course no matter what the two will
work the same in the real world. But in simulation there are other possible
values for the clock signal. rising_edge() will check that a transition
occurred between '0' or 'L' and '1' or 'H'. Any other transition is ignored.
The expression (CLK'event and CLK = '1') will respond to a transition
between *any other* state and '1' and will ignore transitions to 'H'.
I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag.
If rising_edge() was not different from (CLK'event and CLK = '1') there
would be no reason to use it. rising_edge() is closer to real hardware
responding to any valid transition from a logic low to a logic high while
(CLK'event and CLK = '1') does not but will respond to spurious transitions.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Thank you, Rick and Allan,
"I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag."
-- SINI <= '1', '0' after 4 ns; OK for (CLK'event and CLK = '1'), fails
-- for Rising_edge(CLK)
-- SINI <= '1', '0' after 14 ns; OK for both
SINI <= '1', '0' after 14 ns;
MainClock : process
begin
-- the reason why '1' is chosen when time = 0 is that it makes all rising
-- edge on xxx0 ns, not on xxx5
CLK <= '1'; wait for 5 ns;
CLK <= '0'; wait for 5 ns;
end process;
SINI is used to initialize all necessary registers and at time 0 (CLK'event and CLK = '1') generates a true value while Rising_edge(CLK) doesn't. It causes an error, not because of any glitch, but because necessary registers are not initialized properly, because my assertion() is after SINI = '1' is generated.
1. As I do, extend the SINI assertion from 4ns to 14ns in case of (CLK'event and CLK = '1'). Because my assertion is after SINI = '1' is generated, so the assertion would not generate the error anymore.
2. As Allan suggested, the following would work for both
SINI <= '1', '0' after 6 ns;
MainClock : process
begin
CLK <= '0'; wait for 5 ns;
CLK <= '1'; wait for 5 ns;
end process;
Conclusion: at time 0 (CLK'event and CLK = '1') and Rising_edge(CLK) really have different behavior and it should be paid attention to, at least one should know it and adhere to one working method.
After the experiment, later I will choose Rising_edge(CLK) and
SINI <= '1', '0' after 14 ns;
MainClock : process
begin
CLK <= '1'; wait for 5 ns;
CLK <= '0'; wait for 5 ns;
end process;
Weng

You might try this experiment:

Put an initial value on the CLK signal.
signal CLK : std_ulogic:='0';
or
signal CLK : std_ulogic:='1';

If you put an initial value of '0', you may find that both the
(CLK'event and CLK = '1') and the Rising_edge(CLK) processes get
triggered at time=0.

On the other hand, if you put an initial value of '1', you may find that
neither the (CLK'event and CLK = '1') nor the Rising_edge(CLK) processes
get triggered at time=0 and the first clock pulse they see is at time=10 ns.

Charles Bailey

Weng Tianxiang

2017-11-14 14:23:19 UTC

Post by Charles Bailey

As long as the clock signal only has values of '0' or '1' the two will work
exactly the same in simulation and of course no matter what the two will
work the same in the real world. But in simulation there are other possible
values for the clock signal. rising_edge() will check that a transition
occurred between '0' or 'L' and '1' or 'H'. Any other transition is ignored.
The expression (CLK'event and CLK = '1') will respond to a transition
between *any other* state and '1' and will ignore transitions to 'H'.
I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag.
If rising_edge() was not different from (CLK'event and CLK = '1') there
would be no reason to use it. rising_edge() is closer to real hardware
responding to any valid transition from a logic low to a logic high while
(CLK'event and CLK = '1') does not but will respond to spurious transitions.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Put an initial value on the CLK signal.
signal CLK : std_ulogic:='0';
or
signal CLK : std_ulogic:='1';
If you put an initial value of '0', you may find that both the
(CLK'event and CLK = '1') and the Rising_edge(CLK) processes get
triggered at time=0.
On the other hand, if you put an initial value of '1', you may find that
neither the (CLK'event and CLK = '1') nor the Rising_edge(CLK) processes
get triggered at time=0 and the first clock pulse they see is at time=10 ns.
Charles Bailey

Charles Bailey,

I will do the experiment you suggested, because it would give a CLK a definite value before time zero, but I am not sure if VHDL really defines to do so with initial value being used before time zero.

Rick,
If project is designed to work after a proper system initialization, simulation behaviors with any of two methods are the same. In my case, the rising edge is recognized at time zero for (CLK'event and CLK = '1) while the rising edge is recognized at time 10ns for Rising_edge(CLK).

I think there is no glitch at all in simulation for a synchronous design, so I put no attention to glitches. In realty if some logic combination would generate some glitches, it is synthesizer's problem, never a designer's problem.

I will accept your comment to use Rising_edge(CLK), not because it has any advantage to other method, but because it is more direct.

Weng

rickman

2017-11-14 21:56:44 UTC

Post by Charles Bailey

As long as the clock signal only has values of '0' or '1' the two will work
exactly the same in simulation and of course no matter what the two will
work the same in the real world. But in simulation there are other possible
values for the clock signal. rising_edge() will check that a transition
occurred between '0' or 'L' and '1' or 'H'. Any other transition is ignored.
The expression (CLK'event and CLK = '1') will respond to a transition
between *any other* state and '1' and will ignore transitions to 'H'.
I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag.
If rising_edge() was not different from (CLK'event and CLK = '1') there
would be no reason to use it. rising_edge() is closer to real hardware
responding to any valid transition from a logic low to a logic high while
(CLK'event and CLK = '1') does not but will respond to spurious transitions.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Thank you, Rick and Allan,
"I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag."
-- SINI <= '1', '0' after 4 ns; OK for (CLK'event and CLK = '1'), fails
-- for Rising_edge(CLK)
-- SINI <= '1', '0' after 14 ns; OK for both
SINI <= '1', '0' after 14 ns;
MainClock : process
begin
-- the reason why '1' is chosen when time = 0 is that it makes all rising
-- edge on xxx0 ns, not on xxx5
CLK <= '1'; wait for 5 ns;
CLK <= '0'; wait for 5 ns;
end process;
SINI is used to initialize all necessary registers and at time 0 (CLK'event and CLK = '1') generates a true value while Rising_edge(CLK) doesn't.. It causes an error, not because of any glitch, but because necessary registers are not initialized properly, because my assertion() is after SINI = '1' is generated.
1. As I do, extend the SINI assertion from 4ns to 14ns in case of (CLK'event and CLK = '1'). Because my assertion is after SINI = '1' is generated, so the assertion would not generate the error anymore.
2. As Allan suggested, the following would work for both
SINI <= '1', '0' after 6 ns;
MainClock : process
begin
CLK <= '0'; wait for 5 ns;
CLK <= '1'; wait for 5 ns;
end process;
Conclusion: at time 0 (CLK'event and CLK = '1') and Rising_edge(CLK) really have different behavior and it should be paid attention to, at least one should know it and adhere to one working method.
After the experiment, later I will choose Rising_edge(CLK) and
SINI <= '1', '0' after 14 ns;
MainClock : process
begin
CLK <= '1'; wait for 5 ns;
CLK <= '0'; wait for 5 ns;
end process;
Weng

Charles Bailey,
I will do the experiment you suggested, because it would give a CLK a definite value before time zero, but I am not sure if VHDL really defines to do so with initial value being used before time zero.
Rick,
If project is designed to work after a proper system initialization, simulation behaviors with any of two methods are the same. In my case, the rising edge is recognized at time zero for (CLK'event and CLK = '1) while the rising edge is recognized at time 10ns for Rising_edge(CLK).
I think there is no glitch at all in simulation for a synchronous design, so I put no attention to glitches. In realty if some logic combination would generate some glitches, it is synthesizer's problem, never a designer's problem.

The "glitch" is the initial transition on the clock line from a value of 'X'
or 'U' to '1' at time zero. This is detected by the one expression but not
by the other. The simulation has nothing to do with synthesis, it has to do
with the way you construct your design and test bench.

Post by Weng Tianxiang
I will accept your comment to use Rising_edge(CLK), not because it has any advantage to other method, but because it is more direct.

I don't agree that there is no advantage to using rising_edge for the clock
input to sequential logic. I don't want my logic to clock on spurious
transitions which (clk'event and clk = '1') will do. The real issue here is
not about the use of rising_edge(), it is about proper initialization of the
design and test bench. The fact that a simulation passes is not an
indication of a proper test bench. The test bench is used to verify the
design, but there is nothing but the designer's intellect to verify the test
bench. My real concern with your design would be initialization. My
concern with your test fixture is that it is not robust enough to deal with
the issue of synchronization, but then I don't know anything about how this
block will be used in the rest of the design.

--
Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

rickman

2017-11-14 06:05:33 UTC

As long as the clock signal only has values of '0' or '1' the two will work
exactly the same in simulation and of course no matter what the two will
work the same in the real world. But in simulation there are other possible
values for the clock signal. rising_edge() will check that a transition
occurred between '0' or 'L' and '1' or 'H'. Any other transition is ignored.
The expression (CLK'event and CLK = '1') will respond to a transition
between *any other* state and '1' and will ignore transitions to 'H'.
I expect your simulation is counting a transition from 'U' or 'X' to '1' as
a valid clock pulse in the assertions and when rising_edge() ignores it
there is a mismatch and subsequent error flag.
If rising_edge() was not different from (CLK'event and CLK = '1') there
would be no reason to use it. rising_edge() is closer to real hardware
responding to any valid transition from a logic low to a logic high while
(CLK'event and CLK = '1') does not but will respond to spurious transitions.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Your description is not perfectly clear to me but I believe you are using
SINI as a synchronous system reset. In your earlier example you are
counting on there being an initial clock edge generated at time zero which
does not work for rising_edge(clk) while it does work for (clk'event and clk
= '1'). You then fix the problem for rising_edge(clk) by making the SINI
reset signal last for 14 ns which includes a valid rising edge at time 10 ns
which is clearly seen by both edge detection constructs.

As I said before, this is because rising_edge() only detects true rising
edges involving the legally defined states representing defined logical
values and *not* any of the undefined levels while (clk'event and clk = '1')
will detect a rising edge by *any* transition that ends in the '1' state.
In any case, hoping for a reset condition at time zero is not a very good
test of the circuit reset capability since it depends on the simulation
working in ways the generated hardware likely will not.

--
Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Allan Herriman

2017-11-12 00:45:23 UTC