VHDL and Latch

[Weng Tianxiang]

On Mar 8, 4:18 pm, Jim Lewis <j...@synthworks.com> wrote:

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 <j...@synthworks.com> 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- Hide quoted text -

- Show quoted text -

Hi KJ, Jim and Peter,
Thank you for your response and help.

Anyway now I understand the latch a little more than before the
posting.

In coding experiences, when writing code equations, a reasonalble FPGA
engineer will never generate a situation that leads to a signal
appearing in both sides of logic equation in concurrent area. Because
most of time the odd behavior equations would be fully beyond the
acknowledgable. And there is no reason to generate an oscillator
neither.

Jim correctly repeated my question and both of you gave me a right
answer.

Weng

 

[Jim Lewis]

Weng,

2. Is there any general algorithm to change such an
equation to a latch equation?
I have not seen any evidence of one you can expect different

tool vendors to support.

For RTL code, if you want a synthesis tool to reliably
create a latch library part, only use #1 or #2 (below from
KJs post). Going further, if you want to avoid portability
issues with some of the ASIC synthesis tools, then use
only #1.

#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');

If you use other forms, a synthesis tool may generate
logic that implements latching behavior without using
a latch part. If you use these to deliberately create
a latch, good luck.

Generally people accidentally create the other forms
when two separate pieces of logic communicate.

Cheers,
Jim

 

[Weng Tianxiang]

On Mar 8, 4:30 pm, Jim Lewis <j...@synthworks.com> wrote:

Weng,
2. Is there any general algorithm to change such an
equation to a latch equation?
I have not seen any evidence of one you can expect different
tool vendors to support.

For RTL code, if you want a synthesis tool to reliably
create a latch library part, only use #1 or #2 (below from
KJs post). Going further, if you want to avoid portability
issues with some of the ASIC synthesis tools, then use
only #1.

#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');

If you use other forms, a synthesis tool may generate
logic that implements latching behavior without using
a latch part. If you use these to deliberately create
a latch, good luck.

Generally people accidentally create the other forms
when two separate pieces of logic communicate.

Cheers,
Jim

Hi Jim,
I am not going to write an odd equation to confuse VHDL compilers that
would be stupid, but just wondering about how can a VHDL compiler
figure out its inherent complex structures.

The best way to do FPGA design is to follow rules. No exceptions.

From this posing, I have learned how to write a latch correctly in
standard VHDL form, how to use a new possible attribute to let VHDL

compiler to generate an error information, instead of a warning
information, and the last and not the least, how to avoid confusing
VHDL compiler by using a signal name in both side of "<=" in
concurrent area.

Thank you.

Weng

 

[Michael Jřrgensen]

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

 

[Jonathan Bromley]

On Tue, 13 Mar 2007 13:27:20 +0100, "Michael Jřrgensen"
<ingen@ukendt.dk> wrote:

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:QPcHh.3095$iw4.17@newssvr23.news.prodigy.net...
....
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?

I agree 100%. The only caveat is *when* you get a warning;
synthesis proceeds in at least two main phases - inference of
functions from RTL, and mapping of those functions on to target
hardware. It may be only in the latter phase that a warning
should appear, since the RTL latch template is perfectly well
defined and, at the stage when it's making these inferences,
the tool doesn't necessarily know anything about the target.

FPGAs provide a classic example of this problem. Many FPGAs
have real latch structures on I/O pads, but can't build
useful latches in the fabric. Presumably, a synthesis tool
must happily accept *all* latches at RTL-inference time,
because it *may* be possible to map any or all of those
latches on to I/O blocks; this mapping can be determined
only much later in the synthesis process.

You would certainly expect any tool to report the latches
and FFs it finds, though.
--
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.

 

[Daniel S.]

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.

 

[Colin Paul Gloster]

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

 

[Colin Paul Gloster]

Someone made such a not particularly unique claim in this thread as:
"[..]

[..] Latches are only half as big as flipflops [..]

[..]"

A latch is a type of flip-flop.

 

[Jonathan Bromley]

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.

 

[Jonathan Bromley]

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

A latch is a type of flip-flop.

Please desist from nitpicking. Ralf's meaning was entirely
self-evident. Common usage being what it is, when describing
any kind of bistable element (not "flip-flop" please) that is *not*
an edge-triggered D-type flip-flop, it is necessary to qualify the
phrase "flip-flop" with something such as "S-R flip-flop".

There is a tiresomely large lexicon of names for the different
flavours of bistable element:

bistable
multivibrator
flip-flop
latch
register
Eccles-Jordan relay

Save for the last one, I can easily find examples of multiple
and overlapping meanings of all these. To disambiguate
them we must rely either on tiresome and wordy qualification
of each usage, or intelligent inference from context.

Only the most irritatingly pedantic would insist on such
blindness to context as your comment exhibits.
--
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.

 

[KJ]

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

 

[Colin Paul Gloster]

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.