«

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

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

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

"KJ" <> wrote in message
news:QPcHh.3095$. ..
>

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

On Tue, 13 Mar 2007 13:27:20 +0100, "Michael Jørgensen"
<> wrote:

>"KJ" <> wrote in message
>news:QPcHh.3095$ ...
....
>> 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

http://www.MYCOMPANY.com

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

Michael Jørgensen wrote:
> "KJ" <> wrote in message
> news:QPcHh.3095$. ..
>
>> 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: ups.com
timestamped 8 Mar 2007 14:16:15 -0800, "KJ"
<> 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

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.

On 14 Mar 2007 17:17:03 GMT, Colin Paul Gloster
<> 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

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 14 Mar 2007 17:21:12 GMT, Colin Paul Gloster
<> 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

http://www.MYCOMPANY.com

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