VHDL and Latch

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:QPcHh.3095$iw4.17@newssvr23.news.prodigy.net...
>

> 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.
>

So, just making sure I understand this. The synthesis tool may or may not 
choose to generate a "latch inference" warning, depending on whether a latch 
is natively supported by the target device.

And the reason for this warning is that it is not possible to reliably 
implement a latch, unless the target device has built-in support for it.

Is the above correct?

-Michael.

Michael J�rgensen wrote:
> "KJ" <kkjennings@sbcglobal.net> wrote in message 
> news:QPcHh.3095$iw4.17@newssvr23.news.prodigy.net...
> 
>> 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.
>>
> 
> So, just making sure I understand this. The synthesis tool may or may not 
> choose to generate a "latch inference" warning, depending on whether a latch 
> is natively supported by the target device.
> 
> And the reason for this warning is that it is not possible to reliably 
> implement a latch, unless the target device has built-in support for it.
> 
> Is the above correct?
> 
> -Michael.

That is pretty much it.

If you look at Xilinx's FPGA datasheet, most families' slice FFs have an FF/latch 
configuration bit, which I presume (I do not remember trying to infer latches on FPGAs) 
means slice FFs can be configured as latches. The problem then becomes one of generating a 
suitable latch enable pulse. To prevent disorderly feedback (as you would in a latch-based 
counter) while the latches are enabled, this enable pulse needs to be very short and will 
be problematic on FPGAs since FPGAs are not particularly good at generating, distributing 
(on anything other than clock nets) and handling sub-nanosecond signals.

You are better off sticking with FFs in FPGAs/CPLDs and even ASICs (unless extreme power 
and area conservation are primary preoccupations) unless you have very specific/unusual 
reasons to do otherwise - in programmable logic, the whole FF is there and using power 
either way.

In news:1173392175.030094.327500@h3g2000cwc.googlegroups.com
timestamped 8 Mar 2007 14:16:15 -0800, "KJ"
<Kevin.Jennings@Unisys.com> posted:
"[..]
> > #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);
>
[..]
[..] 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. [..]
[..]"


True.

"[..]

Also keep in mind, that latches do not need to fit into a single
equation, [..]  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 [..] loop
because 'Q' depends on 'Y' and 'Y' depends on 'Q'. [..]"

This is a good point.


"[..]

[..] 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. [..]

[..]"

Perhaps an unfortunate homonym of "combinatorial" has been used: do
people use "combinatorial" in this way? A circuit which is described
as "combinatorial" or its "combinational" in literature is one which
does not have an output of its as an input of its, unlike a
"sequential" (not in the VHDL sense) circuit.

Regards,
Colin Paul Gloster

On 14 Mar 2007 17:17:03 GMT, Colin Paul Gloster
<Colin_Paul_Gloster@ACM.org> wrote:

>
>[..] 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. [..]
>
>[..]"
>
>Perhaps an unfortunate homonym of "combinatorial" has been used: do
>people use "combinatorial" in this way? 

Most definitely, yes.

> A circuit which is described
>as "combinatorial" or its "combinational" in literature is one which
>does not have an output of its as an input of its, unlike a
>"sequential" (not in the VHDL sense) circuit.

No-one was calling the *circuit* combinational; it's the
*loop* that Kevin was so describing.  In doing so he
was conforming to long-established usage in the synthesis
community for the description of any cycle in the network
that is not broken by an explicit storage element.

Of course, if you concern yourself with asynchronous
state machines of any kind then you expect to deal with
such cycles and you no longer speak of "combinational"
circuits.  But in the purely synchronous world of mainstream
design, every storage element should have its synchronous 
inputs fed by the output of a purely combinational circuit.
In such a context it is neither unreasonable nor ambiguous
to use "combinational loop" to describe a specific and
pernicious kind of design error.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Mar 14, 1:17 pm, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

> Perhaps an unfortunate homonym of "combinatorial" has been used: do
> people use "combinatorial" in this way? A circuit which is described
> as "combinatorial" or its "combinational" in literature is one which
> does not have an output of its as an input of its, unlike a
> "sequential" (not in the VHDL sense) circuit.

If something is 'combinatorial' it does not imply anything about how
it is used (i.e. whether or not the output is fed back to one of the
inputs).

As far as whether this combinatorial feedback gets used or not in
designs...absolutely.  Depending on just what you're designing you're
either very aware of it or it is something happening behind the
scenes.  To the person designing the flip flops that go into the FPGA,
you bet that they are very aware of the combinatorial feedback loop
that they are in fact designing and it's characteristics.  To the
person writing code that will eventually get downloaded into that
exact same FPGA, probably not...even though they should be aware of
this (from the standpoint of avoiding ever creating such a thing in
their own designs).

Kevin Jennings

On Wed, 14 Mar 2007, Jonathan Bromley wrote:

"On 14 Mar 2007 17:17:03 GMT, Colin Paul Gloster
<Colin_Paul_Gloster@ACM.org> wrote:

[..]

> A circuit which is described
>as "combinatorial" or its "combinational" in literature is one which
>does not have an output of its as an input of its, unlike a
>"sequential" (not in the VHDL sense) circuit.

No-one was calling the *circuit* combinational; it's the
*loop* that Kevin was so describing.  In doing so he
was conforming to long-established usage in the synthesis
community for the description of any cycle in the network
that is not broken by an explicit storage element.

[..]"


Thanks for the information.