原创 Latch 与 FF

一般的设计规则是：在绝大多数设计中避免产生ＬＡＴＣＨ．

它会让您设计的时序完蛋，并且它的隐蔽性很强，非老手不能查出．latch最大的危害在于不能过滤毛刺。这对于下一级电路是极其危险的。所以，只要能用D触发器的地方，就不用latch。有些地方没有时钟，也只能用latch了。

很简单一个例子来说明:
比如现在用一个clk接到latch的使能端(假设是高电平使能),这样需要的setup时间,就是数据在时钟的下降沿之前需要的时间,但是如果是一个 DFF,那么setup时间就是在时钟的上升沿需要的时间.这就说明如果数据晚于控制信号的情况下，只能用latch,这种情况就是,前面所提到的 latch timing borrow.基本上相当于借了一个高电平时间.也就是说，latch借的时间也是有限的.

对latch进行STA的分析其实也是可以,但是要对工具相当熟悉才行.不过很容易出错.当前PrimeTime,是支持进行latch分析的.现在一些综合工具内置的STA分析功能也支持,比如RTL compiler, Design Compiler. 除了ASIC里可以节省资源以外。
我感觉latch这个东西在同步设计里出现的可能还是挺小的吧，现在处理过程中大都放在ff里打一下，影响不太大吧

组合逻辑避免产生latch的一种常用做法。

在process里面的最开头对组合逻辑的输出赋初值。举例说明如下：

process (Rdlenth,WrAddr_En,RdAddr_En,MRd_En,MWr_En,lm_Ackn)
          begin
            next_state<=cur_state；
            case  cur_state  is
                       when idle=>
                         if(xxxx) then
                              next_state<=busy;
                            else
                              。。。。。。
                            endif;
                     。。。。。。
              End process;

       相当的电路是在每个状态底下，如果下一个clk到来时，下一个状态条件没满足，状态机继续留在原状态，相当于在cur_state的寄存器前面做了一个选择器。

  原因分析：为什么是这样的，要把VHDL的语法拿出来复习了：在一个进程以内，对一个信号如果多次赋值，最后一个对信号的赋值有效。
在if语句和case不全很容易产生latch

VIA题目——题目问的是这两个代码哪个综合更容易产生latch

if case不全会产生latch
代码1
always @(enable or ina or inb)
   begin
    if(enable)
     begin
      data_out = ina;
     end
     else
     begin
       data_out = inb;
     end
   end
代码2
input [3:0] data_in;
always @(data_in)
    begin
      case(data_in)
        0 :          out1 = 1'b1;
        1,3 :        out2 = 1'b1;
        2,4,5,6,7 : out3 = 1'b1;
        default :    out4 = 1'b1;
       endcase
    end
当然是下面一个更容易产生LATCH啦。其实，对于下面的情况，如out1而言，只是类似于if(data_in == 0) out1 = 1'b1;如果在default里面，把out1,out2,out3都描述一下就不会产生LATCH了。