The  'event  means any change on the signal.

So this

1

  if CLK='1' then  ...

does implicitly exactly the same as

1

  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:

1

  if rising_edge(CLK) then  ...

EDIT:
Or try this:

1

process begin

2

  wait until rising_edge(CLK);

3

  CNT <= CNT+1;

4

end process;

Thats my preferred style  ;-)

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):

1

process(a,b,c)

2

begin

3

  y <= a + b + c;

4

end process;

Clocked process ('event or rising_edge, only clock in sensitivity list):

1

process(clk)

2

begin

3

  if rising_edge(clk) then ; equivalent to CLK='1' and CLK'event

4

    x <= a + b + c;

5

  end if;

6

end process;

> 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:

1

  process begin

2

    wait until rising_edge(clk);

3

    :

4

    :

5

  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.

> 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:

1

process (clk) begin 

2

   if (clk='1') then   

3

      outp <= inp;

4

   end if;

5

end process;

I just want to add a reset signal:

1

process (reset,clk) begin 

2

   if (reset='1') then

3

      outp <= '0';

4

   elsif (clk='1') then   

5

      outp <= inp;

6

   end if;

7

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:

1

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   ;-)

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

1

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.

> Just to be picky ...
Ok, one more strange behaviour   :-o

Now I synthesized this 4 descriptions with Xilinx XST:

1

entity ClockStyles is

2

    Port ( clk1 : in  STD_LOGIC;

3

           i1   : in  STD_LOGIC;

4

           o1   : out  STD_LOGIC;

5

           clk2 : in  STD_LOGIC;

6

           i2   : in  STD_LOGIC;

7

           o2   : out  STD_LOGIC;

8

           clk3 : in  STD_LOGIC;

9

           i3   : in  STD_LOGIC;

10

           o3   : out  STD_LOGIC;

11

           clk4 : in  STD_LOGIC;

12

           i4   : in  STD_LOGIC;

13

           o4   : out  STD_LOGIC);

14

end ClockStyles;

15

16

architecture Behavioral of ClockStyles is

17

begin

18

19

  process (clk1) begin

20

    if (clk1='1') then

21

      o1 <= i1;

22

    end if;

23

  end process;

24

25

  process (clk2) begin

26

    if (clk2='1' and clk2'event) then

27

      o2 <= i2;

28

    end if;

29

  end process;

30

31

  process (clk3) begin

32

    if rising_edge(clk3) then

33

      o3 <= i3;

34

    end if;

35

  end process;

36

37

  process begin

38

     wait until rising_edge(clk4);

39

     o4 <= i4;

40

  end process;

41

42

end Behavioral;

During synthesis I got a warning:

1

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 :-(

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?

wat is meant by clock division

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