0
\$\begingroup\$

consider this file : tb_sr_latch.v

`include "sr_latch.v"

module tb_sr_latch;
    reg [4:0] t_in;
    wire out;

    sr_latch M1(t_in[4], t_in[3], t_in[2], t_in[1], t_in[0], out);

    initial begin
        $dumpfile("tb_sr_latch.vcd");
        $dumpvars(0);
        t_in = 5'b00000;
        repeat(32) begin
            #1 t_in = t_in + 5'b00001;
        end
    end
endmodule

and this file : sr_latch.v

module sr_latch(input set, reset, enable, preset, clear, output out);
    assign out = ((!clear && (preset || !(reset && enable))) && 
            (!clear && (preset || (out || (enable && set)))));
endmodule

I compiled tb_sr_latch.v with the following command:

iverilog tb_sr_latch.v -o a.out

and when I tried to run a.out with the following command:

./a.out

it stuck [maybe] in a loop with this message:

VCD info: dumpfile tb_sr_latch.vcd opened for output.

Can anyone help me to solve my problem ? please tell me where Im wrong and why it happends, because I know it is possible to implement it with always block instead of using gates.

\$\endgroup\$
  • \$\begingroup\$ The issue is called an update (or delta) loop. \$\endgroup\$ – TFuto Aug 9 '19 at 16:25
0
\$\begingroup\$

A signal should not exists on the left and right side of an assign statement. A latch should be assigned in it own always @* block (with SystemVerilog use always_latch) and use non-blocking assignments (<=).

When all possible inputs combinations are described in an always @* then the block describes combinational logic. If it is not fully described then a latch is inferred. Unintentionally latches are troublesome for all RTL designers.

Non-blocking assignments (<=) should be used for the same reason it should be used for edge-sensitive flip-flops (hint simulation race conditions). In addition it helps identify intentional latches; but most synthesizers don’t care.

Note most FPGAs do not support level-sensitive latches or have limited support.

Your sr_latch should look something like this (not tested or syntax checked).

module sr_latch(input set, reset, enable, preset, clear, output reg out);
  always @* begin
    if (clear) out <= 1'b0;
    else if (preset) out <= 1'b1;
    else if (enable && reset) out <= 1'b0;
    else if (enable && set) out <= 1'b1;
    // inferred latch since not all possible conditions are defined
  end
endmodule 
\$\endgroup\$
  • \$\begingroup\$ so you mean it is not possible to create a latch with gates in verilog and not with if else ... ? because I did that in this way and it is still not working: \$\endgroup\$ – Ali Ramezanian Nik Jul 27 '19 at 22:07
  • \$\begingroup\$ module sr_latch(input set, reset, enable, preset, clear, output reg out); reg B, D, F, C , E, G, H; always @* begin out <= B & C; B <= D & !clear; D <= preset | !F; F <= reset & enable; C <= !clear & E; E <= G | preset; G <= out | H; H <= enable & set; end endmodule \$\endgroup\$ – Ali Ramezanian Nik Jul 27 '19 at 22:28
  • \$\begingroup\$ A simple sr latch can be written in gate level with two nor gates (or two nand with active low inputs). A typical sr latched with enable pin is often down with four nand gates. Your design has set/reset with and without an enable pin. It is not clear which conditions has priority then there is a conflict. \$\endgroup\$ – Greg Jul 28 '19 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.