you use flag_r and ctr_r to store information. If you store information 
in a design without clock, you have a latch (and cannot avoid that).

If this storage is really needed (and at least for ctr_r it is needed 
for sure) you can remove the latch by storing the information in a 
Flipflop. I.e. use a clock and make a synchronous design (the "standard 
way" to work with an FPGA)

At least for the counter this is a real necessity. Cause
 ctr_r <= ctr_r +1;
forms a combinatorial loop. The latch in your design might still work in 
real hard, but this combinatorial loop will never do the things you want 
it to do.

By the way: you are aware, that the following if statement does not make 
much sense either?
           if ((in_o(0) = '0') or (in_o(0) = '1'))  then

And: a good indentation of your code would improve the readability very 
much.

Unfortunately, the restriction is to use only one process with a clock. 
I want the counter to count on both the edges. So I have implemented a 
dual edge counter (in_o) and use in_o to increment the counter on both 
the edges.

1

in_o <= cnt(cnt'left downto 1) & (not clk_i); -- Dual edge detection

2

3

   reg : process(clk_i, reset_n_i)

4

   begin

5

      -- Asynchronous Reset

6

7

      if(reset_n_i = '0') then

8

         cnt(cnt'left downto 1) <= (others => '0');

9

   -- Clock the Register on Rising Edge

10

      elsif RISING_EDGE(clk_i) then    

11

   -- Dual Edge counter

12

         cnt(cnt'left downto 1) <= std_logic_vector(unsigned(cnt(cnt'left downto 1)) + 1);

13

14

      end if;

15

16

   end process;

Rob wrote:
> Unfortunately, the restriction is to use only one process with a clock.
> I want the counter to count on both the edges.

don't mix the things. You raise two new topics and probable have not yet 
understood the problem of the code you showed in the beginning.

Having only one process with a clock is fine. Then everything, which 
must be stored in flipflops, has to be assigned inside that process.

But the process you showed in the beginning has no clock at all. Try to 
imagine, how fast ctr_r tries to count upwards (cause it has no clock 
that defines the pace of the counter).

Having a Counter which counts on both clock edges is in general not 
fine: it works only in those very special cases, where the hardware 
supports dual edge triggerd Flipflops. Most hardware does not support 
this.

But it's a different thing, if you have a fast clock and count the 
transistions (rising and falling) of a slower input signal: that can be 
done without problems by an edge detection.