EmbDev.net

Forum: FPGA, VHDL & Verilog CLK='1' vs. CLK='1' and CLK'event


Author: Christian (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

I am new to VHDL and I have a stupid question, maybe.
What I have learned up to now is, that I have to write those signals 
that a process should react on, into its sensitivity list.
So, for a counter, I have to write at least the clock signal into the 
sensitivity list, right?
And the process is activated only if one of the signals in the 
sensitivity list changes, right?

So, I would really like to know if there is a difference (and if yes: 
what exactly this difference is?) between

process (CLK)
begin
  if CLK='1' then
    CNT <= CNT+1;
  end if;
end process;

and

process (CLK)
begin
  if CLK='1' and CLK'event then
    CNT <= CNT+1;
  end if;
end process;

What is this "CLK'event" for? Do I need it really or is it there just 
for improving the readability of the code?
Again: as far as I understand, the process is activated only when the 
CLK signal changes (i.e. at a rising or falling edge), so the condition 
CLK'event seems to be redundant. Am I right or am I wrong?

Regards,
Christian

: Locked by Moderator
Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
The  'event  means any change on the signal.

So this
  if CLK='1' then  ...
does implicitly exactly the same as
  if CLK='1' and CLK'event then  ...
because the process is calculated only, when any signal in the 
snsitivity list (here only CLK) changes its value.

> Do I need it really
No, not REALLY
> or is it there just for improving the readability of the code?
Its common to write it that way. And the best is, not to go too far away 
from the "common".

For best readability try this:
  if rising_edge(CLK) then  ...

EDIT:
Or try this:
process begin
  wait until rising_edge(CLK);
  CNT <= CNT+1;
end process;
Thats my preferred style  ;-)

Author: Andreas Schwarz (andreas) (Admin) Flattr this
Posted on:

Rate this post
0 useful
not useful
The sensitivity list is only relevant for the simulation. Your first 
process does not make sense to the synthesizer, it describes a feedback 
loop without a clock that can not be implemented in a sensible way. The 
second process is a clocked process and can be implemented.

Remember that, unless you are writing code only for the simulator, you 
are not using a programming language, but a synthesis language. You can 
not use all the functionality of VHDL at your will, you are restricted 
to what your synthesizer understands. There are two basic kinds of 
processes you can use if you want to describe a design that is 
synthesizeable:

Combinatorial process (no 'event or rising_edge, all signals in the 
sensitivity list):
process(a,b,c)
begin
  y <= a + b + c;
end process;

Clocked process ('event or rising_edge, only clock in sensitivity list):
process(clk)
begin
  if rising_edge(clk) then ; equivalent to CLK='1' and CLK'event
    x <= a + b + c;
  end if;
end process;

Author: Christian (Guest)
Posted on:

Rate this post
0 useful
not useful
Thanks to Lothar, thanks to Andreas,

I've now tried the three different versions

1.
  if CLK='1' then...
2.
  if CLK='1' and CLK'event then...

and
3.
  if rising_edge(CLK) then...

with Quartus (V7.2) and downloaded them to my FPGA. The FPGA behaves 
identical, so I conclude that all 3 version are treated equal by the 
synthesizer.
Andreas, is this a 'sleazy' bug in Quartus? Should I get a warning when 
synthesizing version #1? I am just curious.

Regards,
Christian

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
> The FPGA behaves identical, so I conclude that all 3 version are treated
> equal by the synthesizer.
This is a strange way to testify the equality of VHDL descriptions  :-o

First must be a look on the RTL schematics. There you can check whether 
the synthesis results are the same or not.

But in your case I assume the results are the same ;-)

> is this a 'sleazy' bug in Quartus? Should I get a warning when
> synthesizing version #1?
I don't think so.
In a simulation of version #1 the process is calculated, when CLK 
changes. an inside the process CLK is checked for '1'. So the 
synthesizer is capable of translating this description to correct 
hardware, that behaves like the simulation.
A few versions ago synthesis tools were not able to cope with this 
style:
  process begin
    wait until rising_edge(clk);
    :
    :
  end process
Now they are able to get hardware out of this description. But from the 
beginning on this description was able to be simulated.

Author: Christian (Guest)
Posted on:

Rate this post
0 useful
not useful
Thanks for your comment, Lothar,

meanwhile, I've found and checked the RTL schematics and found them to 
be equal in all 3 cases.

One question, at last:
Why do you prefer writing the process in your preferred style as

process begin
  wait until rising_edge(CLK);
  CNT <= CNT+1;
end process;

What is the advantage of that?
Sorry for so many newbie-questions!

Christian

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
> What is the advantage of that?
Becuase you don't have any sensitivity list, you cannot have a 
incomplete sensitivity list. So the simulation and the resulting 
hardware is always consistent.

Given this #1 style description:
process (clk) begin 
   if (clk='1') then   
      outp <= inp;
   end if;
end process;
I just want to add a reset signal:
process (reset,clk) begin 
   if (reset='1') then
      outp <= '0';
   elsif (clk='1') then   
      outp <= inp;
   end if;
end process;
Due to a extending your #1 style description with a asynchronous reset, 
this will no longer be synthesized as a flipflop. It will result as a 
transparent latch in the hardware: when clk is '1' then inp will be 
directed to outp    :-o

But the simulation will look different, because the process will be 
calculated only on a change of one of the signals reset and clk. And the 
simulation will check for clk='1' and therefore behave like a fliflop.

So we have in
hardware:   latch
simulation: flipflop

Believe me: that will cost you some hours of debugging...

For a correct simulation of the incorrect description of the flipflop it 
would be necessary to complete the sensitivity list this way:
process (reset,clk,inp) begin ...
Now the simulation and the hardware will show the erroneous latch.


BTW:
This is also a reason not to use your description #1   ;-)

Author: Christian (Guest)
Posted on:

Rate this post
0 useful
not useful
Thanks, Lothar, your comments were quite enlightening!

Christian

Author: Klaus Falser (kfalser)
Posted on:

Rate this post
0 useful
not useful
Just to be picky, Lothar,
but the simulation of the above description with the reset gives not a 
FF, but a mixture between FF and latch, something simply not available 
in hardware.
When reset goes to '0', and inp did change in the meantime the output 
jumps to the new value, simply as a latch with reset would do.
On the other side it does not react to inp, somethibg a real latch would 
do.

It would be therefore better to say that the modification of the 
sensitivity list to
process (reset,clk,inp) begin ...
corrects the description to behave now correctly like a latch, something 
the synthesis had probabely assumed erroneously.

It's a pity, but this discussions could all be avoided if the synthesis 
compilers would not accept erroneous sensitivity lists.

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:
Attached files:

Rate this post
0 useful
not useful
> Just to be picky ...
Ok, one more strange behaviour   :-o

Now I synthesized this 4 descriptions with Xilinx XST:
entity ClockStyles is
    Port ( clk1 : in  STD_LOGIC;
           i1   : in  STD_LOGIC;
           o1   : out  STD_LOGIC;
           clk2 : in  STD_LOGIC;
           i2   : in  STD_LOGIC;
           o2   : out  STD_LOGIC;
           clk3 : in  STD_LOGIC;
           i3   : in  STD_LOGIC;
           o3   : out  STD_LOGIC;
           clk4 : in  STD_LOGIC;
           i4   : in  STD_LOGIC;
           o4   : out  STD_LOGIC);
end ClockStyles;

architecture Behavioral of ClockStyles is
begin

  process (clk1) begin
    if (clk1='1') then
      o1 <= i1;
    end if;
  end process;
 
  process (clk2) begin
    if (clk2='1' and clk2'event) then
      o2 <= i2;
    end if;
  end process;
 
  process (clk3) begin
    if rising_edge(clk3) then
      o3 <= i3;
    end if;
  end process;
 
  process begin
     wait until rising_edge(clk4);
     o4 <= i4;
  end process;
 
end Behavioral;

During synthesis I got a warning:
WARNING:Xst:819 ... The following signals are missing in the process sensitivity list:  i1
As a result I had a look on the RTL schematics (attachement).
The signal i1 was added automatically to the sensitivity list of process 
#1 and therefore a latch was generated.

In contrast Christian said:
>> meanwhile, I've checked the RTL schematics and found them
>> to be equal in all 3 cases.

So here the Xilinx tools act very different to the Altera tools :-(

Author: ahmed junaid j. (ahmedjunaid_j)
Posted on:

Rate this post
0 useful
not useful
i am a be 2nd yr student. so iwant some knowledge abt vhdl coding. pls 
explain the logic of vhdl code to control the speed and direction of 
simple dc motor?

Author: ahmed junaid j. (ahmedjunaid_j)
Posted on:

Rate this post
0 useful
not useful
wat is meant by clock division

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Pls do not take over others threads and continue with a completely 
different new question. Start a new thread instead!

This topic is locked and can not be replied to.