VHDL and Latch

Discussion in 'VHDL' started by Weng Tianxiang, Mar 6, 2007.

  1. Hi,
    I am very confused with latch generation in VHDL.

    1. I have been using VHDL for 7 years and I have never met a situation
    I need a latch.

    2. I want to know why VHDL let VHDL programmers guess what is to be
    generated in the following situation that I know is only case a latch
    may be generated:

    process(a, ...)
    begin
    -- signalA <= '0';
    case state is
    when A_S =>
    if(a = "000001") then
    signalA <= '1'; <--- a latch is generated, why not
    generating an error ?
    state_ns <= B_S;
    else
    state_ns <= A_S;
    end if;

    ....
    end process;

    Because the first line " Latch_A <= '0'; " is easily missed when the
    process content is big, signalA is generated by VHDL definition as a
    latch.

    Here are my questions:
    1. Latch is rarily used throughout all VHDL, why doesn't VHDL
    introduce a latch() statement to specially be used for this purpose
    while generating an error in the above process().

    2. Here is a latch function definition true table:
    Enable = 1:
    CLK = H, D = H, OUT = H
    CLK = H, D = L, OUT = L
    CLK = L, D = X, OUT = Q0 (latched data).

    It means when clock is high, data is transparent. Input is directed
    into output.
    When clock is low, the data is latched on falling edge of clock.

    In the above process(), there is no clock specified. Which clock will
    be used if there are multiple clocks in the design ?

    3. In the above example, condition: K = (state = A_S and a = "000001")
    should be true to set signalA. What is K role? If K is used as the
    latch enable signal, half clock the latch is transparent and its
    stored data would be destroyed if there is a glitch with K and could
    not keep signalA true value unchanged.

    4. I don't know how to design the latch for signalA with K input?

    If you know the answers, please help.

    Thank you.

    Weng
    Weng Tianxiang, Mar 6, 2007
    #1
    1. Advertising

  2. Weng Tianxiang

    KJ Guest

    "Weng Tianxiang" <> wrote in message
    news:...
    > Hi,
    > I am very confused with latch generation in VHDL.
    >
    > 1. I have been using VHDL for 7 years and I have never met a situation
    > I need a latch.
    >
    > 2. I want to know why VHDL let VHDL programmers guess what is to be
    > generated in the following situation that I know is only case a latch
    > may be generated:
    >
    > process(a, ...)
    > begin
    > -- signalA <= '0';
    > case state is
    > when A_S =>
    > if(a = "000001") then
    > signalA <= '1'; <--- a latch is generated, why not
    > generating an error ?
    > state_ns <= B_S;
    > else
    > state_ns <= A_S;
    > end if;
    >
    > ...
    > end process;
    >
    > Because the first line " Latch_A <= '0'; " is easily missed when the
    > process content is big, signalA is generated by VHDL definition as a
    > latch.
    >
    > Here are my questions:
    > 1. Latch is rarily used throughout all VHDL, why doesn't VHDL
    > introduce a latch() statement to specially be used for this purpose
    > while generating an error in the above process().
    >
    > 2. Here is a latch function definition true table:
    > Enable = 1:
    > CLK = H, D = H, OUT = H
    > CLK = H, D = L, OUT = L
    > CLK = L, D = X, OUT = Q0 (latched data).
    >
    > It means when clock is high, data is transparent. Input is directed
    > into output.
    > When clock is low, the data is latched on falling edge of clock.
    >
    > In the above process(), there is no clock specified. Which clock will
    > be used if there are multiple clocks in the design ?
    >
    > 3. In the above example, condition: K = (state = A_S and a = "000001")
    > should be true to set signalA. What is K role? If K is used as the
    > latch enable signal, half clock the latch is transparent and its
    > stored data would be destroyed if there is a glitch with K and could
    > not keep signalA true value unchanged.
    >
    > 4. I don't know how to design the latch for signalA with K input?
    >
    > If you know the answers, please help.
    >
    > Thank you.
    >
    > Weng
    >
    KJ, Mar 6, 2007
    #2
    1. Advertising

  3. Weng Tianxiang

    KJ Guest

    "Weng Tianxiang" <> wrote in message
    news:...
    > Hi,
    > I am very confused with latch generation in VHDL.
    >
    > 1. I have been using VHDL for 7 years and I have never met a situation
    > I need a latch.

    In FPGAs and CPLDs there is not much need for a latch because a flip flop
    will do just fine.

    >
    > 2. I want to know why VHDL let VHDL programmers guess what is to be
    > generated in the following situation that I know is only case a latch
    > may be generated:

    There is no guessing involved. Certain coding styles infer a latch, just
    like others infer a flip flop and still others infer a block of memory.

    >
    > process(a, ...)
    > begin
    > -- signalA <= '0';
    > case state is
    > when A_S =>
    > if(a = "000001") then
    > signalA <= '1'; <--- a latch is generated, why not
    > generating an error ?
    > state_ns <= B_S;
    > else
    > state_ns <= A_S;
    > end if;
    >
    > ...
    > end process;
    >
    > Because the first line " Latch_A <= '0'; " is easily missed

    Yeah, I missed it too. I don't even see anything called "Latch_A".

    > when the
    > process content is big, signalA is generated by VHDL definition as a
    > latch.

    That's why many people (myself included) discourage the use of processes
    that are not synchronously clocked (i.e. the sensitivity consists of one
    signal...'Clock'). Doing so completely avoids the above coding situation
    which can (if you're not careful) infer an unintended latch.

    >
    > Here are my questions:
    > 1. Latch is rarily used throughout all VHDL, why doesn't VHDL
    > introduce a latch() statement to specially be used for this purpose
    > while generating an error in the above process().

    Maybe you should read what you wrote again. "Latch is rarily used ..." and
    "introduce a latch() statement to...". The obvious questions here are
    - Why clutter the language for something you claim would rarely be used?
    - For those that do use latches, are you suggesting that there code should
    no longer be accepted, resulting in an error?

    My guess is that there would not be much support for a 'rarely used'
    addition that also breaks legacy code. If you want such a function then
    VHDL allows you to write it yourself and incorporate it wherever you like
    inside your own code.

    >
    > 2. Here is a latch function definition true table:
    > Enable = 1:
    > CLK = H, D = H, OUT = H
    > CLK = H, D = L, OUT = L
    > CLK = L, D = X, OUT = Q0 (latched data).
    >
    > It means when clock is high, data is transparent. Input is directed
    > into output.

    If you say so, it leaves a bit to the imagination, like why is the magic
    signal 'Q0' the latched version of 'OUT'....personally I find the following
    to be much more descriptive and easy to read if I ever did want to infer a
    transparent latch.
    if (CLK = '1') then
    Q <= D; -- Chose not to call it 'OUT' as you did so as to not use a
    VHDL keyword
    end if;

    > When clock is low, the data is latched on falling edge of clock.

    The falling edge of a clock that is low? There's another logic oddity.

    >
    > In the above process(), there is no clock specified. Which clock will
    > be used if there are multiple clocks in the design ?

    VHDL doesn't have 'clocks', it has 'signals'. The logic is almost
    completely specified by the plain text code that is written. The only thing
    VHDL leaves to the imagination (i.e. it's in the LRM and you must learn
    this) is that if you don't specify the value for a signal then it will
    remain at it's current value. In the above mentioned latch process that I
    wrote, if the 'if condition' is not met (i.e. "CLK = '1'" is not true),
    since I haven't specified anything for the 'else' branch, the VHDL LRM says
    that signal 'Q' would remain unchanged.

    Much like the say all software languages are defined I might add so it's not
    at all peculiar.

    >
    > 3. In the above example, condition: K = (state = A_S and a = "000001")
    > should be true to set signalA. What is K role? If K is used as the
    > latch enable signal, half clock the latch is transparent and its
    > stored data would be destroyed if there is a glitch with K and could
    > not keep signalA true value unchanged.
    >
    > 4. I don't know how to design the latch for signalA with K input?
    >
    > If you know the answers, please help.


    1. Don't use latches.
    2. Don't use coding styles that can result in unintended latches.
    3. Concentrate on the functionality and performance of your design while
    remaining within whatever I/O, logic resource, power, etc.constraints that
    your design might have.

    Kevin Jennings
    KJ, Mar 6, 2007
    #3
  4. Weng Tianxiang

    Jim Lewis Guest

    Weng,
    First, 1076.6-2004 introduces an attribute named combinational.
    For a compliant tool, when this attribute is applied to a
    process label and the process creates a latch then a synthesis
    tool shall generate an error.

    So request that your vendor implement the standard (if
    they have not already). Vendors will implement what their
    user community wants. If you want this, you must make sure
    you talk to your vendor.


    > 2. I want to know why VHDL let VHDL programmers guess what is to be
    > generated in the following situation that I know is only case a latch
    > may be generated:
    >
    > process(a, ...)
    > begin
    > -- signalA <= '0';
    > case state is
    > when A_S =>
    > if(a = "000001") then
    > signalA <= '1'; <--- a latch is generated, why not
    > generating an error ?
    > state_ns <= B_S;
    > else
    > state_ns <= A_S;
    > end if;
    >
    > ...
    > end process;
    >
    > Because the first line " Latch_A <= '0'; " is easily missed when the
    > process content is big, signalA is generated by VHDL definition as a
    > latch.


    OTOH, one simple rule for preventing latches:
    * Initialize all outputs (except state_ns) to their
    inactive value.
    * Either fully specify state_ns or assign it to state_reg.

    Or you can follow KJ's rule of always using clocked
    processes, however, this is not my preference.


    Cheers,
    Jim
    Jim Lewis, Mar 6, 2007
    #4
  5. On Mar 6, 1:25 am, "Weng Tianxiang" <> wrote:
    > 1. Latch is rarily used throughout all VHDL,

    That is not true.
    While latches are not supported in most modern FPGAs and where
    discouraged to use in older families,
    in ASIC design it is very common to split D-Flip-Flops into two
    latches distributed through
    the pipeline. Also, VHDL ist not only used for synthesis. It was
    intended to model systems and there
    clearly are systems that behave like a latch so there must be a way to
    model them.

    Most synthesis tools issue a warning in the cases that you describe
    which is an adequate reaction to
    the situation: The tool accountered legal code of which it knows that
    it is often written unintentionally.

    Kolja Sulimma
    comp.arch.fpga, Mar 6, 2007
    #5
  6. Weng Tianxiang

    KJ Guest

    "comp.arch.fpga" <> wrote in message
    news:...
    > On Mar 6, 1:25 am, "Weng Tianxiang" <> wrote:
    >> 1. Latch is rarily used throughout all VHDL,

    > That is not true.
    > While latches are not supported in most modern FPGAs and where
    > discouraged to use in older families,
    > in ASIC design it is very common to split D-Flip-Flops into two
    > latches distributed through
    > the pipeline.

    Kolja, good point.

    To follow up on this point a bit for the other readers. The reason that
    latches are discouraged FPGA/CPLDs but not so in ASICs is because in the
    ASIC world they actually have a hard set of logic that gets inferred from
    the code that generates a latch whereas in the typical FPGA/CPLD world you
    do not. Instead the latch gets created by cobbling together the LUTs or
    macrocells. The problem with the cobbling together approach is that you
    have virtually no control over the timing inside the FPGA/CPLD and yet a
    latch will have setup and hold timing requirements that you will have no way
    to guarantee.

    If FPGA/CPLDs cobbled together LUTs to create flip flops the same argument
    could be made for not using flip flops. But since FPGA/CPLD/ASICs all have
    flip flops implemented as hard logic you don't have this issue. Also, if
    the target device does have a hard latch as a resource that can be used then
    the use of latches is just fine also.

    Kevin Jennings
    KJ, Mar 6, 2007
    #6
  7. Weng Tianxiang schrieb:


    > I am very confused with latch generation in VHDL.
    >
    > 1. I have been using VHDL for 7 years and I have never met a situation
    > I need a latch.


    I do it every day. Latches are only half as big as flipflops and are not
    triggered by a highly active clock. They only need their enable signal.
    This makes them then 1st choice for small low-power circuits.

    Using latches means thinking very well about the behavior of the
    circuit. Hazards, the common muxed-latch-problem and other stuff has to
    be considered.


    > 2. I want to know why VHDL let VHDL programmers guess what is to be
    > generated in the following situation that I know is only case a latch
    > may be generated:
    >
    > process(a, ...)
    > begin
    > -- signalA <= '0';
    > case state is
    > when A_S =>
    > if(a = "000001") then
    > signalA <= '1'; <--- a latch is generated, why not
    > generating an error ?
    > state_ns <= B_S;
    > else
    > state_ns <= A_S;
    > end if;
    >
    > ...
    > end process;


    signalA is not assigned in the else-branch. Therefore you get a latch,
    because this process is not clocked.
    This is a bad way to code a latch (because you easily trap into the
    muxed-latch pitfall) but why this should be an error? All synthesis
    tools will report that signalA has inferred a latch.


    > Because the first line " Latch_A <= '0'; " is easily missed when the
    > process content is big, signalA is generated by VHDL definition as a
    > latch.


    If for the 1st line after the begin the comment "--" is removed you will
    get combinational logic for signalA. This is _totally_ different
    behavior, but if you want to avoid a latch a very clean and easy way to
    do it.

    Ralf
    Ralf Hildebrandt, Mar 6, 2007
    #7
  8. On Mar 5, 6:47 pm, Jim Lewis <> wrote:
    > Weng,
    > First, 1076.6-2004 introduces an attribute named combinational.
    > For a compliant tool, when this attribute is applied to a
    > process label and the process creates a latch then a synthesis
    > tool shall generate an error.
    >
    > So request that your vendor implement the standard (if
    > they have not already). Vendors will implement what their
    > user community wants. If you want this, you must make sure
    > you talk to your vendor.
    >
    >
    >
    >
    >
    > > 2. I want to know why VHDL let VHDL programmers guess what is to be
    > > generated in the following situation that I know is only case a latch
    > > may be generated:

    >
    > > process(a, ...)
    > > begin
    > > -- signalA <= '0';
    > > case state is
    > > when A_S =>
    > > if(a = "000001") then
    > > signalA <= '1'; <--- a latch is generated, why not
    > > generating an error ?
    > > state_ns <= B_S;
    > > else
    > > state_ns <= A_S;
    > > end if;

    >
    > > ...
    > > end process;

    >
    > > Because the first line " Latch_A <= '0'; " is easily missed when the
    > > process content is big, signalA is generated by VHDL definition as a
    > > latch.

    >
    > OTOH, one simple rule for preventing latches:
    > * Initialize all outputs (except state_ns) to their
    > inactive value.
    > * Either fully specify state_ns or assign it to state_reg.
    >
    > Or you can follow KJ's rule of always using clocked
    > processes, however, this is not my preference.
    >
    > Cheers,
    > Jim- Hide quoted text -
    >
    > - Show quoted text -


    Hi Jim,
    Thank you for your good information.

    If a compiler does have the attribute capability, it would greatly
    easy the trouble a lot. For almost any state machine, I have been
    always using 2-processe method, it is clear and very informative, the
    only drawback is the missing of signal initial value assignment. With
    your new definition, I am very encouraged that I expect Xilinx compier
    will have the ability soon.

    Weng
    Weng Tianxiang, Mar 6, 2007
    #8
  9. On Mar 5, 6:01 pm, "KJ" <> wrote:
    > "Weng Tianxiang" <> wrote in message
    >
    > news:...> Hi,
    > > I am very confused with latch generation in VHDL.

    >
    > > 1. I have been using VHDL for 7 years and I have never met a situation
    > > I need a latch.

    >
    > In FPGAs and CPLDs there is not much need for a latch because a flip flop
    > will do just fine.
    >
    >
    >
    > > 2. I want to know why VHDL let VHDL programmers guess what is to be
    > > generated in the following situation that I know is only case a latch
    > > may be generated:

    >
    > There is no guessing involved. Certain coding styles infer a latch, just
    > like others infer a flip flop and still others infer a block of memory.
    >
    >
    >
    >
    >
    >
    >
    > > process(a, ...)
    > > begin
    > > -- signalA <= '0';
    > > case state is
    > > when A_S =>
    > > if(a = "000001") then
    > > signalA <= '1'; <--- a latch is generated, why not
    > > generating an error ?
    > > state_ns <= B_S;
    > > else
    > > state_ns <= A_S;
    > > end if;

    >
    > > ...
    > > end process;

    >
    > > Because the first line " Latch_A <= '0'; " is easily missed

    >
    > Yeah, I missed it too. I don't even see anything called "Latch_A".
    >
    > > when the
    > > process content is big, signalA is generated by VHDL definition as a
    > > latch.

    >
    > That's why many people (myself included) discourage the use of processes
    > that are not synchronously clocked (i.e. the sensitivity consists of one
    > signal...'Clock'). Doing so completely avoids the above coding situation
    > which can (if you're not careful) infer an unintended latch.
    >
    >
    >
    > > Here are my questions:
    > > 1. Latch is rarily used throughout all VHDL, why doesn't VHDL
    > > introduce a latch() statement to specially be used for this purpose
    > > while generating an error in the above process().

    >
    > Maybe you should read what you wrote again. "Latch is rarily used ..." and
    > "introduce a latch() statement to...". The obvious questions here are
    > - Why clutter the language for something you claim would rarely be used?
    > - For those that do use latches, are you suggesting that there code should
    > no longer be accepted, resulting in an error?
    >
    > My guess is that there would not be much support for a 'rarely used'
    > addition that also breaks legacy code. If you want such a function then
    > VHDL allows you to write it yourself and incorporate it wherever you like
    > inside your own code.
    >
    >
    >
    > > 2. Here is a latch function definition true table:
    > > Enable = 1:
    > > CLK = H, D = H, OUT = H
    > > CLK = H, D = L, OUT = L
    > > CLK = L, D = X, OUT = Q0 (latched data).

    >
    > > It means when clock is high, data is transparent. Input is directed
    > > into output.

    >
    > If you say so, it leaves a bit to the imagination, like why is the magic
    > signal 'Q0' the latched version of 'OUT'....personally I find the following
    > to be much more descriptive and easy to read if I ever did want to infer a
    > transparent latch.
    > if (CLK = '1') then
    > Q <= D; -- Chose not to call it 'OUT' as you did so as to not use a
    > VHDL keyword
    > end if;
    >
    > > When clock is low, the data is latched on falling edge of clock.

    >
    > The falling edge of a clock that is low? There's another logic oddity.
    >
    >
    >
    > > In the above process(), there is no clock specified. Which clock will
    > > be used if there are multiple clocks in the design ?

    >
    > VHDL doesn't have 'clocks', it has 'signals'. The logic is almost
    > completely specified by the plain text code that is written. The only thing
    > VHDL leaves to the imagination (i.e. it's in the LRM and you must learn
    > this) is that if you don't specify the value for a signal then it will
    > remain at it's current value. In the above mentioned latch process that I
    > wrote, if the 'if condition' is not met (i.e. "CLK = '1'" is not true),
    > since I haven't specified anything for the 'else' branch, the VHDL LRM says
    > that signal 'Q' would remain unchanged.
    >
    > Much like the say all software languages are defined I might add so it's not
    > at all peculiar.
    >
    >
    >
    > > 3. In the above example, condition: K = (state = A_S and a = "000001")
    > > should be true to set signalA. What is K role? If K is used as the
    > > latch enable signal, half clock the latch is transparent and its
    > > stored data would be destroyed if there is a glitch with K and could
    > > not keep signalA true value unchanged.

    >
    > > 4. I don't know how to design the latch for signalA with K input?

    >
    > > If you know the answers, please help.

    >
    > 1. Don't use latches.
    > 2. Don't use coding styles that can result in unintended latches.
    > 3. Concentrate on the functionality and performance of your design while
    > remaining within whatever I/O, logic resource, power, etc.constraints that
    > your design might have.
    >
    > Kevin Jennings- Hide quoted text -
    >
    > - Show quoted text -
    Weng Tianxiang, Mar 6, 2007
    #9
  10. On Mar 5, 6:01 pm, "KJ" <> wrote:
    > "Weng Tianxiang" <> wrote in message
    >
    > news:...> Hi,
    > > I am very confused with latch generation in VHDL.

    >
    > > 1. I have been using VHDL for 7 years and I have never met a situation
    > > I need a latch.

    >
    > In FPGAs and CPLDs there is not much need for a latch because a flip flop
    > will do just fine.
    >
    >
    >
    > > 2. I want to know why VHDL let VHDL programmers guess what is to be
    > > generated in the following situation that I know is only case a latch
    > > may be generated:

    >
    > There is no guessing involved. Certain coding styles infer a latch, just
    > like others infer a flip flop and still others infer a block of memory.
    >
    >
    >
    >
    >
    >
    >
    > > process(a, ...)
    > > begin
    > > -- signalA <= '0';
    > > case state is
    > > when A_S =>
    > > if(a = "000001") then
    > > signalA <= '1'; <--- a latch is generated, why not
    > > generating an error ?
    > > state_ns <= B_S;
    > > else
    > > state_ns <= A_S;
    > > end if;

    >
    > > ...
    > > end process;

    >
    > > Because the first line " Latch_A <= '0'; " is easily missed

    >
    > Yeah, I missed it too. I don't even see anything called "Latch_A".
    >
    > > when the
    > > process content is big, signalA is generated by VHDL definition as a
    > > latch.

    >
    > That's why many people (myself included) discourage the use of processes
    > that are not synchronously clocked (i.e. the sensitivity consists of one
    > signal...'Clock'). Doing so completely avoids the above coding situation
    > which can (if you're not careful) infer an unintended latch.
    >
    >
    >
    > > Here are my questions:
    > > 1. Latch is rarily used throughout all VHDL, why doesn't VHDL
    > > introduce a latch() statement to specially be used for this purpose
    > > while generating an error in the above process().

    >
    > Maybe you should read what you wrote again. "Latch is rarily used ..." and
    > "introduce a latch() statement to...". The obvious questions here are
    > - Why clutter the language for something you claim would rarely be used?
    > - For those that do use latches, are you suggesting that there code should
    > no longer be accepted, resulting in an error?
    >
    > My guess is that there would not be much support for a 'rarely used'
    > addition that also breaks legacy code. If you want such a function then
    > VHDL allows you to write it yourself and incorporate it wherever you like
    > inside your own code.
    >
    >
    >
    > > 2. Here is a latch function definition true table:
    > > Enable = 1:
    > > CLK = H, D = H, OUT = H
    > > CLK = H, D = L, OUT = L
    > > CLK = L, D = X, OUT = Q0 (latched data).

    >
    > > It means when clock is high, data is transparent. Input is directed
    > > into output.

    >
    > If you say so, it leaves a bit to the imagination, like why is the magic
    > signal 'Q0' the latched version of 'OUT'....personally I find the following
    > to be much more descriptive and easy to read if I ever did want to infer a
    > transparent latch.
    > if (CLK = '1') then
    > Q <= D; -- Chose not to call it 'OUT' as you did so as to not use a
    > VHDL keyword
    > end if;
    >
    > > When clock is low, the data is latched on falling edge of clock.

    >
    > The falling edge of a clock that is low? There's another logic oddity.
    >
    >
    >
    > > In the above process(), there is no clock specified. Which clock will
    > > be used if there are multiple clocks in the design ?

    >
    > VHDL doesn't have 'clocks', it has 'signals'. The logic is almost
    > completely specified by the plain text code that is written. The only thing
    > VHDL leaves to the imagination (i.e. it's in the LRM and you must learn
    > this) is that if you don't specify the value for a signal then it will
    > remain at it's current value. In the above mentioned latch process that I
    > wrote, if the 'if condition' is not met (i.e. "CLK = '1'" is not true),
    > since I haven't specified anything for the 'else' branch, the VHDL LRM says
    > that signal 'Q' would remain unchanged.
    >
    > Much like the say all software languages are defined I might add so it's not
    > at all peculiar.
    >
    >
    >
    > > 3. In the above example, condition: K = (state = A_S and a = "000001")
    > > should be true to set signalA. What is K role? If K is used as the
    > > latch enable signal, half clock the latch is transparent and its
    > > stored data would be destroyed if there is a glitch with K and could
    > > not keep signalA true value unchanged.

    >
    > > 4. I don't know how to design the latch for signalA with K input?

    >
    > > If you know the answers, please help.

    >
    > 1. Don't use latches.
    > 2. Don't use coding styles that can result in unintended latches.
    > 3. Concentrate on the functionality and performance of your design while
    > remaining within whatever I/O, logic resource, power, etc.constraints that
    > your design might have.
    >
    > Kevin Jennings- Hide quoted text -
    >
    > - Show quoted text -


    Hi Kevin,
    In my first posting, there are 3 questions:
    1. Why doesn't compiler generate an error for unintended latch
    generation?
    This question is satisfactorily answered: there is a new attribute to
    give errors if an unintended latch is to generate. It says that some
    other people had already observed the situation long time ago.

    2. If the above error is given an error, VHDL may include a special
    statement to generate a latch.
    This is another big problem: I don't know how ASIC people generate a
    real latch using VHDL? I think they may most likely use latch library
    to generate special latch instead of using VHDL statements. I read an
    article about asynchronous FIFO written by two engineers one of whom
    is Pete Alfke of Xilinx (it is the best article I have read in my
    life). In the paper they say that they fail to generate two or 3
    latches in their design using Xilinx chip. If so, it seems to me that
    there is no reliable statement in VHDL to generate a latch for a FPGA
    chip.

    3. If the example would generate a latch for signalA, how it is
    generated?

    KJ answered the question. If the equation KJ suggested is true, it
    would like the following:
    if (state = stateA_S and a = "000001") then
    signalA <= '1';
    end if;

    Finally I realized KJ saying is correct.

    Thank you, KJ and Lewis.

    Weng
    Weng Tianxiang, Mar 6, 2007
    #10
  11. Weng Tianxiang

    KJ Guest

    "Weng Tianxiang" <> wrote in message
    news:...
    >
    > Hi Kevin,
    > In my first posting, there are 3 questions:
    > 1. Why doesn't compiler generate an error for unintended latch
    > generation?

    Simply put because it is not an 'error' to write code that infers a latch.
    To presume that every latch is 'unintended' would be wrong.

    > This question is satisfactorily answered: there is a new attribute to
    > give errors if an unintended latch is to generate. It says that some
    > other people had already observed the situation long time ago.
    >

    If you choose to use that attribute and find a tool that supports it then by
    all means use it. But keep in mind that if you forget to use the new
    attribute (because people are human) that you can still end up in the same
    situation. It's up to you if that's the coding style you prefer to use to
    avoid unintended latches, personally I prefer other coding styles but the
    attribute is at least an improvement and gives another method which is good.

    No matter which of these two methods you use, you can still get an
    'unintended latch' with the following type of code which infers a latch

    Q <= (C and D) or (not(C) and Q);

    This is obviously a very stripped down example, a 'real' design might be
    much more complicated, but you have to train yourself to look at every
    concurrent statement and make sure that you don't see the output on both
    sides of the equation.

    It gets worse though because the 'latch' could be a function of multiple
    concurrent statements that happen to loop back. The synthesizer report that
    it finds a combinatorial loop works to catch that but nothing in the
    language prevents it (nor should it, since it may not be 'unintended').

    > 2. If the above error is given an error, VHDL may include a special
    > statement to generate a latch.

    If you want a 'special' statement that creates a latch, then write one and
    instantiate it until your heart is content....but don't presume that
    everyone else agrees with you and that the language itself should only
    support your coding style for creating a latch and any other method should
    cause an error.

    > This is another big problem: I don't know how ASIC people generate a
    > real latch using VHDL? I think they may most likely use latch library
    > to generate special latch instead of using VHDL statements.

    That doesn't preclude them from inferring a latch in other ways.

    > I read an
    > article about asynchronous FIFO written by two engineers one of whom
    > is Pete Alfke of Xilinx (it is the best article I have read in my
    > life). In the paper they say that they fail to generate two or 3
    > latches in their design using Xilinx chip.

    No idea what you mean by this...but reading on

    > If so, it seems to me that
    > there is no reliable statement in VHDL to generate a latch for a FPGA
    > chip.

    Unless the underlying hardware has a hard latch available as a resource to
    use and most (if not all) FPGAs do not, then I would agree that there is no
    reliable way to generate a latch inside an FPGA in any language, not just
    VHDL. The lack of latches in FPGAs though has nothing at all to do with
    VHDL or any language it is simply recognition by the FPGA suppliers that
    there is very little demand for a hard latch inside the FPGA. A flip flop
    would have the exact same coding issues, the only reason it's not a
    'problem' is because there are hard flip flops inside the FPGA.

    The 'problem' with inferring any storage element (latch, flip flop, big
    hunk-o-memory, fifo, etc.) is when the underlying hardware doesn't directly
    support the inferred element and it needs to be cobbled together from basic
    logic blocks. In the FPGA/CPLD world, it is very difficult to meet internal
    setup, hold time and 'no glitching' requirements between two arbitrary
    signals.

    Remember also, that you can build ANY logical element strictly from NAND
    gates or NOR gates....so in theory you could write your code using only
    these two building blocks. Were you to do so and target an FPGA, it would
    most certainly fail if that design had any sort of storage.

    >
    > 3. If the example would generate a latch for signalA, how it is
    > generated?

    Same as any other logical description....it gets mapped to whatever internal
    resources exist in the device (LUTs, macrocells, flip flops, latches,
    whatever the target device supports).

    >
    > KJ answered the question. If the equation KJ suggested is true, it
    > would like the following:
    > if (state = stateA_S and a = "000001") then
    > signalA <= '1';
    > end if;
    >
    > Finally I realized KJ saying is correct.
    >

    You're welcome.

    Kevin Jennings
    KJ, Mar 7, 2007
    #11
  12. On Mar 6, 5:37 pm, "KJ" <> wrote:
    > "Weng Tianxiang" <> wrote in message
    >
    > news:...
    >
    > > Hi Kevin,
    > > In my first posting, there are 3 questions:
    > > 1. Why doesn't compiler generate an error for unintended latch
    > > generation?

    >
    > Simply put because it is not an 'error' to write code that infers a latch.
    > To presume that every latch is 'unintended' would be wrong.
    >
    > > This question is satisfactorily answered: there is a new attribute to
    > > give errors if an unintended latch is to generate. It says that some
    > > other people had already observed the situation long time ago.

    >
    > If you choose to use that attribute and find a tool that supports it then by
    > all means use it. But keep in mind that if you forget to use the new
    > attribute (because people are human) that you can still end up in the same
    > situation. It's up to you if that's the coding style you prefer to use to
    > avoid unintended latches, personally I prefer other coding styles but the
    > attribute is at least an improvement and gives another method which is good.
    >
    > No matter which of these two methods you use, you can still get an
    > 'unintended latch' with the following type of code which infers a latch
    >
    > Q <= (C and D) or (not(C) and Q);
    >
    > This is obviously a very stripped down example, a 'real' design might be
    > much more complicated, but you have to train yourself to look at every
    > concurrent statement and make sure that you don't see the output on both
    > sides of the equation.
    >
    > It gets worse though because the 'latch' could be a function of multiple
    > concurrent statements that happen to loop back. The synthesizer report that
    > it finds a combinatorial loop works to catch that but nothing in the
    > language prevents it (nor should it, since it may not be 'unintended').
    >
    > > 2. If the above error is given an error, VHDL may include a special
    > > statement to generate a latch.

    >
    > If you want a 'special' statement that creates a latch, then write one and
    > instantiate it until your heart is content....but don't presume that
    > everyone else agrees with you and that the language itself should only
    > support your coding style for creating a latch and any other method should
    > cause an error.
    >
    > > This is another big problem: I don't know how ASIC people generate a
    > > real latch using VHDL? I think they may most likely use latch library
    > > to generate special latch instead of using VHDL statements.

    >
    > That doesn't preclude them from inferring a latch in other ways.
    >
    > > I read an
    > > article about asynchronous FIFO written by two engineers one of whom
    > > is Pete Alfke of Xilinx (it is the best article I have read in my
    > > life). In the paper they say that they fail to generate two or 3
    > > latches in their design using Xilinx chip.

    >
    > No idea what you mean by this...but reading on
    >
    > > If so, it seems to me that
    > > there is no reliable statement in VHDL to generate a latch for a FPGA
    > > chip.

    >
    > Unless the underlying hardware has a hard latch available as a resource to
    > use and most (if not all) FPGAs do not, then I would agree that there is no
    > reliable way to generate a latch inside an FPGA in any language, not just
    > VHDL. The lack of latches in FPGAs though has nothing at all to do with
    > VHDL or any language it is simply recognition by the FPGA suppliers that
    > there is very little demand for a hard latch inside the FPGA. A flip flop
    > would have the exact same coding issues, the only reason it's not a
    > 'problem' is because there are hard flip flops inside the FPGA.
    >
    > The 'problem' with inferring any storage element (latch, flip flop, big
    > hunk-o-memory, fifo, etc.) is when the underlying hardware doesn't directly
    > support the inferred element and it needs to be cobbled together from basic
    > logic blocks. In the FPGA/CPLD world, it is very difficult to meet internal
    > setup, hold time and 'no glitching' requirements between two arbitrary
    > signals.
    >
    > Remember also, that you can build ANY logical element strictly from NAND
    > gates or NOR gates....so in theory you could write your code using only
    > these two building blocks. Were you to do so and target an FPGA, it would
    > most certainly fail if that design had any sort of storage.
    >
    >
    >
    > > 3. If the example would generate a latch for signalA, how it is
    > > generated?

    >
    > Same as any other logical description....it gets mapped to whatever internal
    > resources exist in the device (LUTs, macrocells, flip flops, latches,
    > whatever the target device supports).
    >
    >
    >
    > > KJ answered the question. If the equation KJ suggested is true, it
    > > would like the following:
    > > if (state = stateA_S and a = "000001") then
    > > signalA <= '1';
    > > end if;

    >
    > > Finally I realized KJ saying is correct.

    >
    > You're welcome.
    >
    > Kevin Jennings


    Hi KJ,
    1. Q <= (C and D) or (not(C) and Q);
    I have never seen such equation in my coding experiences and have no
    idea how this equation would be written. The logic result is beyond a
    reason. Could you please write it in equivalent latch equation in
    informal VHDL?

    2. FPGA of Xilinx chip really has latch primative and one may use it
    using latch primative to call it. But it is hard to refer to it in
    VHDL. I don't mean VHDL should have included latch statement, what I
    mean is VHDL really lacks the statement element to refer to a latch in
    a clear and reliable way and the lack can be easily corrected.

    Thank you.

    Weng
    Weng Tianxiang, Mar 7, 2007
    #12
  13. Weng Tianxiang

    Daniel S. Guest

    Weng Tianxiang wrote:
    > On Mar 6, 5:37 pm, "KJ" <> wrote:
    >> "Weng Tianxiang" <> wrote in message
    >>
    >> news:...
    >>
    >>> Hi Kevin,
    >>> In my first posting, there are 3 questions:
    >>> 1. Why doesn't compiler generate an error for unintended latch
    >>> generation?

    >> Simply put because it is not an 'error' to write code that infers a latch.
    >> To presume that every latch is 'unintended' would be wrong.
    >>
    >>> This question is satisfactorily answered: there is a new attribute to
    >>> give errors if an unintended latch is to generate. It says that some
    >>> other people had already observed the situation long time ago.

    >> If you choose to use that attribute and find a tool that supports it then by
    >> all means use it. But keep in mind that if you forget to use the new
    >> attribute (because people are human) that you can still end up in the same
    >> situation. It's up to you if that's the coding style you prefer to use to
    >> avoid unintended latches, personally I prefer other coding styles but the
    >> attribute is at least an improvement and gives another method which is good.
    >>
    >> No matter which of these two methods you use, you can still get an
    >> 'unintended latch' with the following type of code which infers a latch
    >>
    >> Q <= (C and D) or (not(C) and Q);
    >>
    >> This is obviously a very stripped down example, a 'real' design might be
    >> much more complicated, but you have to train yourself to look at every
    >> concurrent statement and make sure that you don't see the output on both
    >> sides of the equation.
    >>
    >> It gets worse though because the 'latch' could be a function of multiple
    >> concurrent statements that happen to loop back. The synthesizer report that
    >> it finds a combinatorial loop works to catch that but nothing in the
    >> language prevents it (nor should it, since it may not be 'unintended').
    >>
    >>> 2. If the above error is given an error, VHDL may include a special
    >>> statement to generate a latch.

    >> If you want a 'special' statement that creates a latch, then write one and
    >> instantiate it until your heart is content....but don't presume that
    >> everyone else agrees with you and that the language itself should only
    >> support your coding style for creating a latch and any other method should
    >> cause an error.
    >>
    >>> This is another big problem: I don't know how ASIC people generate a
    >>> real latch using VHDL? I think they may most likely use latch library
    >>> to generate special latch instead of using VHDL statements.

    >> That doesn't preclude them from inferring a latch in other ways.
    >>
    >>> I read an
    >>> article about asynchronous FIFO written by two engineers one of whom
    >>> is Pete Alfke of Xilinx (it is the best article I have read in my
    >>> life). In the paper they say that they fail to generate two or 3
    >>> latches in their design using Xilinx chip.

    >> No idea what you mean by this...but reading on
    >>
    >>> If so, it seems to me that
    >>> there is no reliable statement in VHDL to generate a latch for a FPGA
    >>> chip.

    >> Unless the underlying hardware has a hard latch available as a resource to
    >> use and most (if not all) FPGAs do not, then I would agree that there is no
    >> reliable way to generate a latch inside an FPGA in any language, not just
    >> VHDL. The lack of latches in FPGAs though has nothing at all to do with
    >> VHDL or any language it is simply recognition by the FPGA suppliers that
    >> there is very little demand for a hard latch inside the FPGA. A flip flop
    >> would have the exact same coding issues, the only reason it's not a
    >> 'problem' is because there are hard flip flops inside the FPGA.
    >>
    >> The 'problem' with inferring any storage element (latch, flip flop, big
    >> hunk-o-memory, fifo, etc.) is when the underlying hardware doesn't directly
    >> support the inferred element and it needs to be cobbled together from basic
    >> logic blocks. In the FPGA/CPLD world, it is very difficult to meet internal
    >> setup, hold time and 'no glitching' requirements between two arbitrary
    >> signals.
    >>
    >> Remember also, that you can build ANY logical element strictly from NAND
    >> gates or NOR gates....so in theory you could write your code using only
    >> these two building blocks. Were you to do so and target an FPGA, it would
    >> most certainly fail if that design had any sort of storage.
    >>
    >>
    >>
    >>> 3. If the example would generate a latch for signalA, how it is
    >>> generated?

    >> Same as any other logical description....it gets mapped to whatever internal
    >> resources exist in the device (LUTs, macrocells, flip flops, latches,
    >> whatever the target device supports).
    >>
    >>
    >>
    >>> KJ answered the question. If the equation KJ suggested is true, it
    >>> would like the following:
    >>> if (state = stateA_S and a = "000001") then
    >>> signalA <= '1';
    >>> end if;
    >>> Finally I realized KJ saying is correct.

    >> You're welcome.
    >>
    >> Kevin Jennings

    >
    > Hi KJ,
    > 1. Q <= (C and D) or (not(C) and Q);
    > I have never seen such equation in my coding experiences and have no
    > idea how this equation would be written. The logic result is beyond a
    > reason. Could you please write it in equivalent latch equation in
    > informal VHDL?


    That equation is written exactly as-is and would work in theory.
    Glitches on Q while C goes from 1 to 0 may break the feedback loop or
    make it metastable in practice.

    Another VHDL way of putting it would be:

    Q <= D when C = '1' else Q;

    An equivalent VHDL process would be:

    process(c,d)
    begin
    if(c='1') then
    q <= d;
    end if;
    end process;

    Exactly what each of these would actually infer is tool- and
    hardware-specific. The only thing you can do is check your synthesis
    reports to determine exactly what was synthesized. This applies to all
    matters of getting HDL to map onto specific FPGA resources.

    > 2. FPGA of Xilinx chip really has latch primative and one may use it
    > using latch primative to call it. But it is hard to refer to it in
    > VHDL. I don't mean VHDL should have included latch statement, what I
    > mean is VHDL really lacks the statement element to refer to a latch in
    > a clear and reliable way and the lack can be easily corrected.


    Latches: "if somesig='1' then ... end if;"
    Latches(2): see equations and process above

    FFs: "if clk='1' and clk'event then ... end if;"
    FFs(2): "if rising_edge(clk) then ... end if;"

    That seems like plenty straight-forward VHDL to me. Latches are active
    on levels, FFs are active on edges. Simple.

    Xilinx devices do not have dedicated latches BUT they do allow you to
    program a slice FF to bypass HALF of it so it can be used as a latch. As
    far as power is concerned though, the whole FF is still connected to the
    clock so you most likely won't be saving any power here. BTW, the
    configuration logic that goes behind FPGA FFs uses more surface area
    than the FF itself and the "latch bypass logic" probably uses nearly as
    much power as a pure FF.

    To reach high clock speeds, FPGAs and ASICs need their pipeline storage
    elements to be able to forward values from D to Q with as little setup,
    hold and settling time as possible to maximize timing margins between
    clock edges. This is most effortlessly and reliably achieved with FFs,
    hence the dominance of FFs in the world of high-speed digital systems
    and the FF-oriented nature of FPGAs even though they cost a little more
    surface area and power.

    Simply put, FFs are the path of least unnecessary pain.

    If you want lower power FPGAs, some flexibility has to be sacrificed. If
    Xilinx stripped the latch option from slice FFs, it would reduce the
    slice FF cells' power and size by 15-20% while making them a little bit
    faster. I wonder how many would have a problem with this.
    Daniel S., Mar 7, 2007
    #13
  14. Weng Tianxiang

    KJ Guest

    "Weng Tianxiang" <> wrote in message
    news:...
    > 1. Q <= (C and D) or (not(C) and Q);
    > I have never seen such equation in my coding experiences and have no
    > idea how this equation would be written. The logic result is beyond a
    > reason. Could you please write it in equivalent latch equation in
    > informal VHDL?

    It's the same old transparent latch that we've been talking about all along.
    The following forms are exactly equivalent logic and will result in the
    exact same synthesized result.
    #1 -- Traditional form of writing a latch
    process(C, D)
    begin
    if (C='1') then
    Q <= D;
    end if;
    end process;

    #2 -- Another traditional form of writing a latch.
    Q <= D when (C = '1');

    #3 -- Latch equations written as a sum of products
    Q <= (C and D) or (not(C) and Q);

    #4 -- Latch equation written in a sum of products form that includes a
    'cover' term
    Q <= (C and D) or (not(C) and Q) or (D and Q);

    Try all four of the above out and run them through synthesis and you should
    get the exact same fitted equations for all 4.

    Of the four different forms, only #4 is written in a way that will not have
    timing issues that are caused simply by the implementation (over which you
    have no real control in an FPGA). However, the last term ".. or (D and Q)"
    is redundant and any synthesizer worth a dime will 'optomize the logic' and
    implement it as form #3. This 'optomization' though creates a logic hazard
    when 'C' switches from '1' to '0'. This logic hazard will in turn show up
    as a failure in the latch operation. Specifically, what you'll run into is
    that even if you have 'D' set up oodles of time before 'C' switches from '1'
    to '0', the output 'Q' can latch itself at either '1' or '0' (depending on
    the targetted part) because of differences in prop delay in computing the
    first two or terms or glitches in 'C'. That last "D and Q" term is
    absolutely required in order to even have a shot at inferring a latch that
    will actually work but since it is logically 'redundant' it will always get
    optomized away. If you hark back to Boolean Logic 101, you may recall that
    adding redundant terms is the method you employ to get rid of logic hazards.
    The FPGA LUT implementation leaves even more to the imagination as you
    wonder just what those RAM outputs are doing with this combinatorial loop
    and whether 'Q' will glitch and cause even more havoc since it would feed
    back to the address input of the LUT.

    The bottom line is
    - There are various forms of writing source code that infers a latch.
    - Whether a latch is a 'good' thing or a 'bad' thing depends on the
    targetted device itself and whether that device actually has a hard latch
    and a way to guarantee the timing and glitch requirements of 'D' and 'C'.
    - Inferring any storage element (flops, latches, memory) needs to be done in
    such a way that the storage is not implemented as a collection of
    LUTs/macrocells but instead uses hard storage resources of the device.

    >
    > 2. FPGA of Xilinx chip really has latch primative and one may use it
    > using latch primative to call it. But it is hard to refer to it in
    > VHDL.

    You'll still have trouble meeting and guaranteeing the timing and glitch
    requirements on 'D' relative to 'C' in order to get it to work correctly for
    arbitrary signals 'D' and 'C'. If it does work, it likely won't scale well
    (i.e. if you try to infer thousands of these as you would like to)

    > I don't mean VHDL should have included latch statement, what I
    > mean is VHDL really lacks the statement element to refer to a latch in
    > a clear and reliable way and the lack can be easily corrected.
    >

    I've shown above four different forms for inferring the exact same latch
    (i.e. synthesizes to the exact same thing). Which form you prefer (or if
    you prefer to make up your own) to use is up to you. Making up a new method
    though will not prohibit the earlier forms from being used and outlawing the
    other forms gets in the way of people who do use latches and are doing so in
    a way that they can control the various issues so you're not helping them by
    outlawing their method.

    Kevin Jennings
    KJ, Mar 7, 2007
    #14
  15. On Mar 7, 3:02 am, "KJ" <> wrote:
    > "Weng Tianxiang" <> wrote in message
    >
    > news:...> 1. Q <= (C and D) or (not(C) and Q);
    > > I have never seen such equation in my coding experiences and have no
    > > idea how this equation would be written. The logic result is beyond a
    > > reason. Could you please write it in equivalent latch equation in
    > > informal VHDL?

    >
    > It's the same old transparent latch that we've been talking about all along.
    > The following forms are exactly equivalent logic and will result in the
    > exact same synthesized result.
    > #1 -- Traditional form of writing a latch
    > process(C, D)
    > begin
    > if (C='1') then
    > Q <= D;
    > end if;
    > end process;
    >
    > #2 -- Another traditional form of writing a latch.
    > Q <= D when (C = '1');
    >
    > #3 -- Latch equations written as a sum of products
    > Q <= (C and D) or (not(C) and Q);
    >
    > #4 -- Latch equation written in a sum of products form that includes a
    > 'cover' term
    > Q <= (C and D) or (not(C) and Q) or (D and Q);
    >
    > Try all four of the above out and run them through synthesis and you should
    > get the exact same fitted equations for all 4.
    >
    > Of the four different forms, only #4 is written in a way that will not have
    > timing issues that are caused simply by the implementation (over which you
    > have no real control in an FPGA). However, the last term ".. or (D and Q)"
    > is redundant and any synthesizer worth a dime will 'optomize the logic' and
    > implement it as form #3. This 'optomization' though creates a logic hazard
    > when 'C' switches from '1' to '0'. This logic hazard will in turn show up
    > as a failure in the latch operation. Specifically, what you'll run into is
    > that even if you have 'D' set up oodles of time before 'C' switches from '1'
    > to '0', the output 'Q' can latch itself at either '1' or '0' (depending on
    > the targetted part) because of differences in prop delay in computing the
    > first two or terms or glitches in 'C'. That last "D and Q" term is
    > absolutely required in order to even have a shot at inferring a latch that
    > will actually work but since it is logically 'redundant' it will always get
    > optomized away. If you hark back to Boolean Logic 101, you may recall that
    > adding redundant terms is the method you employ to get rid of logic hazards.
    > The FPGA LUT implementation leaves even more to the imagination as you
    > wonder just what those RAM outputs are doing with this combinatorial loop
    > and whether 'Q' will glitch and cause even more havoc since it would feed
    > back to the address input of the LUT.
    >
    > The bottom line is
    > - There are various forms of writing source code that infers a latch.
    > - Whether a latch is a 'good' thing or a 'bad' thing depends on the
    > targetted device itself and whether that device actually has a hard latch
    > and a way to guarantee the timing and glitch requirements of 'D' and 'C'.
    > - Inferring any storage element (flops, latches, memory) needs to be done in
    > such a way that the storage is not implemented as a collection of
    > LUTs/macrocells but instead uses hard storage resources of the device.
    >
    >
    >
    > > 2. FPGA of Xilinx chip really has latch primative and one may use it
    > > using latch primative to call it. But it is hard to refer to it in
    > > VHDL.

    >
    > You'll still have trouble meeting and guaranteeing the timing and glitch
    > requirements on 'D' relative to 'C' in order to get it to work correctly for
    > arbitrary signals 'D' and 'C'. If it does work, it likely won't scale well
    > (i.e. if you try to infer thousands of these as you would like to)
    >
    > > I don't mean VHDL should have included latch statement, what I
    > > mean is VHDL really lacks the statement element to refer to a latch in
    > > a clear and reliable way and the lack can be easily corrected.

    >
    > I've shown above four different forms for inferring the exact same latch
    > (i.e. synthesizes to the exact same thing). Which form you prefer (or if
    > you prefer to make up your own) to use is up to you. Making up a new method
    > though will not prohibit the earlier forms from being used and outlawing the
    > other forms gets in the way of people who do use latches and are doing so in
    > a way that they can control the various issues so you're not helping them by
    > outlawing their method.
    >
    > Kevin Jennings


    Hi KJ,
    Thank you very much for your points.

    Your answer really opens my eye and expand my knowledge range in FPGA
    and VHDL !!!

    Weng
    Weng Tianxiang, Mar 7, 2007
    #15
  16. On Mar 7, 3:02 am, "KJ" <> wrote:
    > "Weng Tianxiang" <> wrote in message
    >
    > news:...> 1. Q <= (C and D) or (not(C) and Q);
    > > I have never seen such equation in my coding experiences and have no
    > > idea how this equation would be written. The logic result is beyond a
    > > reason. Could you please write it in equivalent latch equation in
    > > informal VHDL?

    >
    > It's the same old transparent latch that we've been talking about all along.
    > The following forms are exactly equivalent logic and will result in the
    > exact same synthesized result.
    > #1 -- Traditional form of writing a latch
    > process(C, D)
    > begin
    > if (C='1') then
    > Q <= D;
    > end if;
    > end process;
    >
    > #2 -- Another traditional form of writing a latch.
    > Q <= D when (C = '1');
    >
    > #3 -- Latch equations written as a sum of products
    > Q <= (C and D) or (not(C) and Q);
    >
    > #4 -- Latch equation written in a sum of products form that includes a
    > 'cover' term
    > Q <= (C and D) or (not(C) and Q) or (D and Q);
    >
    > Try all four of the above out and run them through synthesis and you should
    > get the exact same fitted equations for all 4.
    >
    > Of the four different forms, only #4 is written in a way that will not have
    > timing issues that are caused simply by the implementation (over which you
    > have no real control in an FPGA). However, the last term ".. or (D and Q)"
    > is redundant and any synthesizer worth a dime will 'optomize the logic' and
    > implement it as form #3. This 'optomization' though creates a logic hazard
    > when 'C' switches from '1' to '0'. This logic hazard will in turn show up
    > as a failure in the latch operation. Specifically, what you'll run into is
    > that even if you have 'D' set up oodles of time before 'C' switches from '1'
    > to '0', the output 'Q' can latch itself at either '1' or '0' (depending on
    > the targetted part) because of differences in prop delay in computing the
    > first two or terms or glitches in 'C'. That last "D and Q" term is
    > absolutely required in order to even have a shot at inferring a latch that
    > will actually work but since it is logically 'redundant' it will always get
    > optomized away. If you hark back to Boolean Logic 101, you may recall that
    > adding redundant terms is the method you employ to get rid of logic hazards.
    > The FPGA LUT implementation leaves even more to the imagination as you
    > wonder just what those RAM outputs are doing with this combinatorial loop
    > and whether 'Q' will glitch and cause even more havoc since it would feed
    > back to the address input of the LUT.
    >
    > The bottom line is
    > - There are various forms of writing source code that infers a latch.
    > - Whether a latch is a 'good' thing or a 'bad' thing depends on the
    > targetted device itself and whether that device actually has a hard latch
    > and a way to guarantee the timing and glitch requirements of 'D' and 'C'.
    > - Inferring any storage element (flops, latches, memory) needs to be done in
    > such a way that the storage is not implemented as a collection of
    > LUTs/macrocells but instead uses hard storage resources of the device.
    >
    >
    >
    > > 2. FPGA of Xilinx chip really has latch primative and one may use it
    > > using latch primative to call it. But it is hard to refer to it in
    > > VHDL.

    >
    > You'll still have trouble meeting and guaranteeing the timing and glitch
    > requirements on 'D' relative to 'C' in order to get it to work correctly for
    > arbitrary signals 'D' and 'C'. If it does work, it likely won't scale well
    > (i.e. if you try to infer thousands of these as you would like to)
    >
    > > I don't mean VHDL should have included latch statement, what I
    > > mean is VHDL really lacks the statement element to refer to a latch in
    > > a clear and reliable way and the lack can be easily corrected.

    >
    > I've shown above four different forms for inferring the exact same latch
    > (i.e. synthesizes to the exact same thing). Which form you prefer (or if
    > you prefer to make up your own) to use is up to you. Making up a new method
    > though will not prohibit the earlier forms from being used and outlawing the
    > other forms gets in the way of people who do use latches and are doing so in
    > a way that they can control the various issues so you're not helping them by
    > outlawing their method.
    >
    > Kevin Jennings


    Hi KJ,
    I have another question for you.

    1. Is any combinational equation with target signal in both right part
    and left part of the equation a latch like your equations 3 or 4 show?

    2. Is there any general algorithm to change such an equation to a
    latch equation?

    Thank you.

    Weng
    Weng Tianxiang, Mar 8, 2007
    #16
  17. Weng Tianxiang

    Jim Lewis Guest

    Weng
    > Hi KJ,
    > I have another question for you.
    >
    >> Q <= (C and D) or (not(C) and Q);

    > 1. Is any combinational equation with target signal in both right part
    > and left part of the equation a latch like your equations 3 or 4 show?


    A latch is the most benign form.
    There are oscillators (however when they occur by
    accident, they are not necessarily this obvious):
    Q <= not Q ;

    There is also other strange latch-like behavior.
    I don't have an equation for you, but I do remember
    analyzing one - it was very interesting.

    Cheers,
    Jim
    Jim Lewis, Mar 8, 2007
    #17
  18. Weng Tianxiang

    Peter Alfke Guest

    I think we will agree that a latch needs positive feedback from the
    output to at least one of the inputs.
    If the feedback is negative (Qbar to D, for example) you end up with
    an oscillator.
    Peter Alfke

    On Mar 8, 9:49 am, Jim Lewis <> wrote:
    > Weng> Hi KJ,
    > > I have another question for you.

    >
    > >> Q <= (C and D) or (not(C) and Q);

    >
    > > 1. Is any combinational equation with target signal in both right part
    > > and left part of the equation a latch like your equations 3 or 4 show?

    >
    > A latch is the most benign form.
    > There are oscillators (however when they occur by
    > accident, they are not necessarily this obvious):
    > Q <= not Q ;
    >
    > There is also other strange latch-like behavior.
    > I don't have an equation for you, but I do remember
    > analyzing one - it was very interesting.
    >
    > Cheers,
    > Jim
    Peter Alfke, Mar 8, 2007
    #18
  19. Weng Tianxiang

    KJ Guest

    On Mar 8, 11:36 am, "Weng Tianxiang" <> wrote:
    > On Mar 7, 3:02 am, "KJ" <> wrote:
    >
    >
    >
    >
    >
    > > "Weng Tianxiang" <> wrote in message

    >
    > >news:...> 1. Q <= (C and D) or (not(C) and Q);
    > > > I have never seen such equation in my coding experiences and have no
    > > > idea how this equation would be written. The logic result is beyond a
    > > > reason. Could you please write it in equivalent latch equation in
    > > > informal VHDL?

    >
    > > It's the same old transparent latch that we've been talking about all along.
    > > The following forms are exactly equivalent logic and will result in the
    > > exact same synthesized result.
    > > #1 -- Traditional form of writing a latch
    > > process(C, D)
    > > begin
    > > if (C='1') then
    > > Q <= D;
    > > end if;
    > > end process;

    >
    > > #2 -- Another traditional form of writing a latch.
    > > Q <= D when (C = '1');

    >
    > > #3 -- Latch equations written as a sum of products
    > > Q <= (C and D) or (not(C) and Q);

    >
    > > #4 -- Latch equation written in a sum of products form that includes a
    > > 'cover' term
    > > Q <= (C and D) or (not(C) and Q) or (D and Q);

    >
    > > Try all four of the above out and run them through synthesis and you should
    > > get the exact same fitted equations for all 4.

    >
    > > Of the four different forms, only #4 is written in a way that will not have
    > > timing issues that are caused simply by the implementation (over which you
    > > have no real control in an FPGA). However, the last term ".. or (D and Q)"
    > > is redundant and any synthesizer worth a dime will 'optomize the logic' and
    > > implement it as form #3. This 'optomization' though creates a logic hazard
    > > when 'C' switches from '1' to '0'. This logic hazard will in turn show up
    > > as a failure in the latch operation. Specifically, what you'll run into is
    > > that even if you have 'D' set up oodles of time before 'C' switches from '1'
    > > to '0', the output 'Q' can latch itself at either '1' or '0' (depending on
    > > the targetted part) because of differences in prop delay in computing the
    > > first two or terms or glitches in 'C'. That last "D and Q" term is
    > > absolutely required in order to even have a shot at inferring a latch that
    > > will actually work but since it is logically 'redundant' it will always get
    > > optomized away. If you hark back to Boolean Logic 101, you may recall that
    > > adding redundant terms is the method you employ to get rid of logic hazards.
    > > The FPGA LUT implementation leaves even more to the imagination as you
    > > wonder just what those RAM outputs are doing with this combinatorial loop
    > > and whether 'Q' will glitch and cause even more havoc since it would feed
    > > back to the address input of the LUT.

    >
    > > The bottom line is
    > > - There are various forms of writing source code that infers a latch.
    > > - Whether a latch is a 'good' thing or a 'bad' thing depends on the
    > > targetted device itself and whether that device actually has a hard latch
    > > and a way to guarantee the timing and glitch requirements of 'D' and 'C'.
    > > - Inferring any storage element (flops, latches, memory) needs to be done in
    > > such a way that the storage is not implemented as a collection of
    > > LUTs/macrocells but instead uses hard storage resources of the device.

    >
    > > > 2. FPGA of Xilinx chip really has latch primative and one may use it
    > > > using latch primative to call it. But it is hard to refer to it in
    > > > VHDL.

    >
    > > You'll still have trouble meeting and guaranteeing the timing and glitch
    > > requirements on 'D' relative to 'C' in order to get it to work correctly for
    > > arbitrary signals 'D' and 'C'. If it does work, it likely won't scale well
    > > (i.e. if you try to infer thousands of these as you would like to)

    >
    > > > I don't mean VHDL should have included latch statement, what I
    > > > mean is VHDL really lacks the statement element to refer to a latch in
    > > > a clear and reliable way and the lack can be easily corrected.

    >
    > > I've shown above four different forms for inferring the exact same latch
    > > (i.e. synthesizes to the exact same thing). Which form you prefer (or if
    > > you prefer to make up your own) to use is up to you. Making up a new method
    > > though will not prohibit the earlier forms from being used and outlawing the
    > > other forms gets in the way of people who do use latches and are doing so in
    > > a way that they can control the various issues so you're not helping them by
    > > outlawing their method.

    >
    > > Kevin Jennings

    >
    > Hi KJ,
    > I have another question for you.
    >
    > 1. Is any combinational equation with target signal in both right part
    > and left part of the equation a latch like your equations 3 or 4 show?

    While Jim and Peter can debate whether or not it's a latch or an
    oscillator, suffice it to say that any time you have something of the
    form of equations #3 and #4 where you have the same signal on both
    sides of the '<=' in a concurrent statement you have some form of
    storage or memory being inferred that will cause you the exact same
    timing/glitch/hazard issues to deal with as you would if you have
    something that matches exactly #3 and #4.

    The important thing to take away is not whether it's a latch or an
    oscillator or anything else, just that red flags should go off in your
    head when you see the output being used on the right side of the
    equation. Whether this is a problem or not depends on what the target
    device is. In ASICs this will not be a problem, in FPGAs you have to
    be very careful or it will be a problem.

    >
    > 2. Is there any general algorithm to change such an equation to a
    > latch equation?

    Not sure what you mean....all four forms that I presented are exactly
    equivalent 'latch equations', they will produce the same synthesized
    result. Equations #1 and #2 involve less typing then #3 and #4.

    Also keep in mind, that latches do not need to fit into a single
    equation, any time that you form a combinatorial loop you have to be
    concerned about how this will get implemented. A combinatorial loop
    happens when you have multiple equations, none of which inherently
    shows any feedback but taken together the whole set does. A simple
    example of this would be

    #5
    Q <= (C and X) or (not(C) and Y); -- Eqn. 5a
    Y <= Q and Z; -- Eqn. 5b

    Equation 5a, on the surface appears to be a 2->1 multiplexer where 'C'
    is simply used to select between two signals 'X' and 'Y'.

    Equation 5b, on the surface appears to be a simple anding of two
    signals 'Q' and 'Z'.

    But when you put them together the two form a combinatorial loop
    because 'Q' depends on 'Y' and 'Y' depends on 'Q'. When you run
    through synthesis, these things generally get flagged as warnings
    somewhere. The nice thing is that it will find all these loops no
    matter how complex the equations or how spread out they are as long as
    they are totally self contained within the entire design. By that I
    mean, lets say that Equation 5a was implemented in some entity
    somewhere in some file and Equation 5b in a totally different entity
    in some other file. By themselves, each entity/file will synthesize
    just fine. But when you add the code for the entity that ties these
    two blocks together that new design and synthesize that new block,
    you'll have now formed the loop and the synthesizer should flag the
    warning for you. Take those warning seriously if you're designing in
    the FPGA/CPLD world.

    Kevin Jennings
    KJ, Mar 8, 2007
    #19
  20. Weng Tianxiang

    Jim Lewis Guest

    Peter,
    No argument from me as you seem to be saying the same
    thing I said.

    I interpreted Weng's question as being, when a combinational
    signal is on both the right and left side of an equation,
    is the only hardware solution a latch.

    The answer which we both observed is no and the simple
    case is an oscillator.

    Cheers,
    Jim


    > I think we will agree that a latch needs positive feedback from the
    > output to at least one of the inputs.
    > If the feedback is negative (Qbar to D, for example) you end up with
    > an oscillator.
    > Peter Alfke
    >
    > On Mar 8, 9:49 am, Jim Lewis <> wrote:
    >> Weng> Hi KJ,
    >>> I have another question for you.
    >> >> Q <= (C and D) or (not(C) and Q);

    >>
    >>> 1. Is any combinational equation with target signal in both right part
    >>> and left part of the equation a latch like your equations 3 or 4 show?

    >> A latch is the most benign form.
    >> There are oscillators (however when they occur by
    >> accident, they are not necessarily this obvious):
    >> Q <= not Q ;
    >>
    >> There is also other strange latch-like behavior.
    >> I don't have an equation for you, but I do remember
    >> analyzing one - it was very interesting.
    >>
    >> Cheers,
    >> Jim

    >
    >
    Jim Lewis, Mar 9, 2007
    #20
    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. dangerlee

    logical left shifter or latch ??

    dangerlee, May 5, 2004, in forum: VHDL
    Replies:
    4
    Views:
    845
    Egbert Molenkamp
    May 7, 2004
  2. Lee
    Replies:
    3
    Views:
    3,712
  3. Patrick
    Replies:
    5
    Views:
    578
    Thomas Stanka
    May 28, 2004
  4. afd
    Replies:
    1
    Views:
    8,324
    Colin Paul Gloster
    Mar 23, 2007
  5. Amit

    latch and flipflop

    Amit, Jun 8, 2007, in forum: VHDL
    Replies:
    12
    Views:
    928
Loading...

Share This Page