Re: Avoiding latches

Discussion in 'VHDL' started by Jan De Ceuster, Jul 15, 2003.

  1. > > > Dout is also generated by other processes. I could clock the process
    > > > but then the latency would not be good. Can I add "dout <= (others =>
    > > > 'Z')" to the "WHEN OTHERS" part? BTW, it works good with the latch but
    > > > since I always heard a latch is bad I'm not really sure what to do
    > > > besides adding a clock(which timing wise, would not be good). Thanks
    > > > a lot.

    > >
    > > If you are sure that you never (should) reach the "others" state than
    > > you can also use a don't care statement instead of a high impedance.

    >
    > I disagree. A 'Z' is a synthesizable value in many logic families.
    > I've never seen a real '-'. Perhaps it'll work in simulation, but it
    > won't match the logic. The simulator doesn't know the logic can never
    > reach this state.
    >
    > > This will tell the synthesis tool that it can do anything with the
    > > "others" state.

    >
    > If you allow the synthesizer to do "anything" with the others state
    > then use the "null" others, though you'll get a latch. IMO, incorrect
    > to use an unrealizable logic state.


    You should always be aware of the fact that writing HDL is NOT like
    writing software. The WYSIWYG factor in hardware design is much lower
    than in software design. It isn't the tools that do the design, it is
    you and only you. Tools just help you but they are utterly completely
    stupid.

    As you should know: std_logic contains much more signal states than
    possible in real life. These are usefull for implementing a correct
    behaviour. So plainly taking std_logic values as 'real' values is
    stupid. You need to understand what they mean in real life. '-' means
    "I don't care if the value is logic '1' or logic '0'" Using this in
    certain cases (and of course knowing what you're doing) will release
    some constrains on the synthesis tool.

    Let me take an example similar to the previous one:
    architecture rtl of test1 is
    begin
    process (state, din)
    begin
    case state is
    when "00" =>
    dout <= din;
    when "01" =>
    dout <= '1';
    when "10" =>
    dout <= '0';
    when others =>
    end case;
    end process;
    end rtl;

    This is a simple example with a latch on dout. After synthesis you'll
    get something like this:
    module test1 ( din, dout, state );
    input [1:0] state;
    input din;
    output dout;
    wire n_31, n_30, n11, n12, n13;
    ND2 U10 ( .A(state[1]), .B(state[0]), .Z(n_31) );
    ND2 U11 ( .A(n11), .B(n12), .Z(n_30) );
    IV U12 ( .A(state[0]), .Z(n11) );
    IV U13 ( .A(state[1]), .Z(n13) );
    ND2 U14 ( .A(din), .B(n13), .Z(n12) );
    LD1 dout_reg ( .D(n_30), .G(n_31), .Q(dout) );
    endmodule

    You see some logic to control the latch and the latch itself (LD1)
    You have 3 NANDS, 2 invertors and 1 latch.

    Now you don't want a latch and use tri-state instead:
    architecture rtl of test2 is
    begin
    process (state, din)
    begin
    case state is
    when "00" =>
    dout <= din;
    when "01" =>
    dout <= '1';
    when "10" =>
    dout <= '0';
    when others =>
    dout <= 'Z';
    end case;
    end process;
    end rtl;

    The synthesis now does this:
    module test2 ( din, dout, state );
    input [1:0] state;
    input din;
    output dout;
    wire n15, n16, n17;
    tri dout_wire;
    assign dout = dout_wire;
    ND2 U10 ( .A(state[1]), .B(state[0]), .Z(n17) );
    AO6 U11 ( .A(din), .B(n15), .C(state[0]), .Z(n16) );
    IV U12 ( .A(state[1]), .Z(n15) );
    BTS5 dout_tri ( .A(n16), .E(n17), .Z(dout_wire) );
    endmodule

    The logic is a bit more simple and still safe (but a tristate buffer
    which is huge and slow). Here are 1 NAND, 1 ANDOR, 1 invertor and the
    tristate buffer. This is already simpeler.

    Now you *know* that state (should) never have value "11" (or else the
    system fails anyway). In this case you can use the '-' thingy :

    architecture rtl of test2 is
    begin
    process (state, din)
    begin
    case state is
    when "00" =>
    dout <= din;
    when "01" =>
    dout <= '1';
    when "10" =>
    dout <= '0';
    when others =>
    dout <= '-';
    end case;
    end process;
    end rtl;

    No latch, no buffers, supperfast and supper simple:
    module test ( din, dout, state );
    input [1:0] state;
    input din;
    output dout;
    wire n8, n9;
    AO7 U7 ( .A(state[1]), .B(n8), .C(n9), .Z(dout) );
    IV U8 ( .A(din), .Z(n8) );
    IV U9 ( .A(state[0]), .Z(n9) );
    endmodule

    Just a AND/OR gate and 2 invertors... 'bout 1.5 a 2 times smaller than
    the tri-state version...

    Works perfectly in the valid states. The output is also a valid
    signal, you just don't care what that value might be (in this case it
    will be 'not din'). These kinds of things are very good for adress
    decoders where you expect to always receive a valid address (or your
    system is screwed anyway), for n-bit statemachines with less than 2^n
    possible states and so on. Yes I know you can use type enumerations
    but I hate using those things in RTL cause it is not flexible enough
    (I tend to optimze my state encoding WITHOUT worrying about what the
    synthesis tool will do with it). Another way I like to use this is in
    shift registers with load/shift-out operation.

    Now in simulation a '-' will propagate into active logic if something
    does go wrong and then you can easily backtrack it. So no: I don't
    expect to use '-' as a 'real' value because you shouldn't...

    BTW, I don't realy see the difference between using a latch and a
    tri-state buffer. Both (at least in my example) have a level sensitive
    enable. So if the input data changes, so does the output (when en is
    active).

    Anymore questions? Does everybody understand this?

    Kind regards,
    Jan
    Jan De Ceuster, Jul 15, 2003
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Keith R. Williams

    Re: Avoiding latches

    Keith R. Williams, Jul 14, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,175
    Keith R. Williams
    Jul 14, 2003
  2. Ken Smith

    Re: Avoiding latches

    Ken Smith, Jul 15, 2003, in forum: VHDL
    Replies:
    3
    Views:
    2,568
    Tim Hubberstey
    Jul 17, 2003
  3. Paul Baxter

    style for coding latches

    Paul Baxter, Aug 10, 2003, in forum: VHDL
    Replies:
    7
    Views:
    1,114
    Mike Treseler
    Aug 15, 2003
  4. Martin Bammer
    Replies:
    0
    Views:
    610
    Martin Bammer
    Nov 17, 2003
  5. Carl
    Replies:
    11
    Views:
    1,216
    Mike Treseler
    Feb 2, 2006
Loading...

Share This Page