EmbDev.net

Forum: FPGA, VHDL & Verilog Removing Latches


Author: Rob (Guest)
Posted on:

Rate this post
0 useful
not useful
Hallo,

I have a logic which infers latches for the signals flag_r and ctr_r. 
The signal flag_r is read in another process. Trying to remove latches 
changes the logic. Any tips on how to remove these latches?

Thanks!
    flag_r_gen: process(reset_n,in_o,reg_q, ctr_r) 
    begin
      if reset_n_i = '0' or (reg_q.cs_adc_1_n = '1' and reg_q.cs_adc_2_n = '1') then 
        ctr_r <= 0;
        flag_r <= '0';
      elsif (reg_q.cs_adc_1_n = '0' or reg_q.cs_adc_2_n= '0') then 
      if reg_q.wr_n = '0' then
      --   flag_r <= '0';  -- Removes Latch but logic does not work
        --   ctr_r <= 0;     -- Removes Latch but logic does not work
           if ((in_o(0) = '0') or (in_o(0) = '1'))  then
            if (ctr_r < 3) then  
           ctr_r <= ctr_r +1;
           flag_r <= '0';
        else
        flag_r <= '1';
            end if;
       end if;
      else
          flag_r <= '0';  
          ctr_r <= 0;    
        end if;
    else
          flag_r <= '0';  
          ctr_r <= 0;
         
    end if;
    end process;

Author: Achim S. (Guest)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Rob (Guest)
Posted on:

Rate this post
0 useful
not useful
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.


in_o <= cnt(cnt'left downto 1) & (not clk_i); -- Dual edge detection
   
   reg : process(clk_i, reset_n_i)
   begin
      -- Asynchronous Reset
    
      if(reset_n_i = '0') then
         cnt(cnt'left downto 1) <= (others => '0');
   -- Clock the Register on Rising Edge
      elsif RISING_EDGE(clk_i) then    
   -- Dual Edge counter
         cnt(cnt'left downto 1) <= std_logic_vector(unsigned(cnt(cnt'left downto 1)) + 1);
         
      end if;
    
   end process;


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

Rate this post
0 useful
not useful
Achim S. wrote:
> 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.
A combinatorial loop usually results from a misunderstood 
"2-process-coding-style" with split up registered and related 
combinatorial processes. Try this with google translator: 
http://www.lothar-miller.de/s9y/archives/42-Kombin...

Rob wrote:
> Trying to remove latches changes the logic.
How did you find that out? Do you run a simulation on that code?

BTW: does xxx_r mean, that the signal xxx_r should be in a register? 
If so, then you MUST use a clock. Only a clock infers a register. But 
keep in mind: a beginners design has exactly ONE clock. That "one and 
only" clock is used throughout the WHOLE design.

BTW: those_under_scores make your_code nearly_un_read_able!

Author: Achim S. (Guest)
Posted on:

Rate this post
0 useful
not useful
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.

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

Rate this post
0 useful
not useful
Achim S. wrote:
> Try to imagine, how fast ctr_r tries to count upwards
In reality such a counter does NOT count at all. It's just a random 
noise generator.

> 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.
Usually FPGA nowadays support that only in IO-cells. And the 
"double-datarate" flipflops there are just a "workaround" consisting of 
two flipflops and a multiplexter.

> Most hardware does not support this.
Afaik only some Xilinx Coolrunner CPLD have such flipflops inside the 
chip.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.