Xilinx не любит latch, но умеет

[vak]

Обычно считается, что FPGA не годятся для асинхронной логики. Родной софт от Xilinx способствует этому предубеждению: при попытке создать latch традиционными средствами языка Verilog, к примеру:

    always @(*)
        if (set)
            z <= 1;
        else if (clr)
            z <= 0;

получаем серию страшных предупреждений типа:

WARNING:Xst:737 - Found 1-bit latch for signal <z>. Latches may
be generated from incomplete case or if statements. We do not
recommend the use of latches in FPGA/CPLD designs, as they may
lead to timing problems.

(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
generated by combinatorial logic.

WARNING:PhysDesignRules:372 - Gated clock. Clock net clr is sourced by a
combinatorial pin. This is not good design practice. Use the CE pin to
control the loading of data into the flip-flop.

Между тем, задача отлично решается посредством компонента FDCPE из библиотеки Xilinx. Немного лёгкого шаманства, и он превращается в асинхронную защёлку:

module th22 (input a, input b, output z);
    assign set = a & b;
    assign clr = !a & !b;

    FDCPE latch (
        .Q   (z),      // Data output
        .D   (0),      // Data input
        .C   (0),      // Clock input
        .CE  (0),      // Clock enable 
        .PRE (set),    // Asynchronous set 
        .CLR (clr)     // Asynchronous clear 
    );
endmodule

Comments

[spamsink]

Чем тебя LDCP не устроил?

[vak]

LDCP добайляет лишний IBUF по какой-то причине, и это увеличивает задержку.
Вот FDCPE:

Timing constraint: Default OFFSET OUT AFTER for Clock 'N0'
  Total number of paths / destination ports: 1 / 1
-------------------------------------------------------------------------
Offset:              4.283ns (Levels of Logic = 1)
  Source:            FDCPE_inst (FF)
  Destination:       z (PAD)
  Source Clock:      N0 rising

  Data Path: FDCPE_inst to z
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FDCPE:C->Q            1   0.591   0.420  FDCPE_inst (z_OBUF)
     OBUF:I->O                 3.272          z_OBUF (z)
    ----------------------------------------
    Total                      4.283ns (3.863ns logic, 0.420ns route)
                                       (90.2% logic, 9.8% route)

А вот LDCP:

Timing constraint: Default path analysis
  Total number of paths / destination ports: 2 / 1
-------------------------------------------------------------------------
Delay:               7.332ns (Levels of Logic = 4)
  Source:            a (PAD)
  Destination:       z (PAD)

  Data Path: a to z
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     IBUF:I->O             2   1.218   0.622  a_IBUF (a_IBUF)
     LUT2:I0->O            1   0.704   0.420  set1 (set)
     LDCE:GE->Q            1   0.676   0.420  LDCE_inst (z_OBUF)
     OBUF:I->O                 3.272          z_OBUF (z)
    ----------------------------------------
    Total                      7.332ns (5.870ns logic, 1.462ns route)
                                       (80.1% logic, 19.9% route)

[spamsink]

Мерзкий Xilinx думает, что он очень умный, и превращает LDCP в LDCE + LUT2.

[spamsink]

Должен заметить, что FDCPE в новых (Virtex5 и моложе, и аналогичных) архитектурах нативно не представим, и раскладывается в общем случае, ЕМНИП, на FDPE+FDCE+LD+LUT3. Так как у тебя нет ни клока, ни данных, ни sync. enable, останется ровно то же самое, что Xilinx сделал из LDCP.

[vak]

Да и ладно.
Это я всё делал на старом софте Xilinx ISE 14.7 для архитектуры Spartan-3E, она же Virtex-5, как я понимаю.
Надо будет то же самое повторить для Vivado и Virtex-7.
Тогда и сравним.