Latches

Omitting an else here is fine if you ask me.

Cheers, Jon

=_NextPart_000_0012_01C7BA35.B8CFAF00 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: quoted-printable

Top posting because of the long rich text format post.

It *is* safe to assume that no latch is inferred when there's already a = flop that stores the value.

The latches in combinatorial equations are because the LHS or = combinatorial output relies on itself as a combinatorial input in the = RHS. In sequential logic, the new register value depends on the onld = register value and nowhere tries to assign the new value based on the = new value which *would* generate a latch.

Your figure B always holds true always because the implied "q

Thanks

=_NextPart_000_000C_01C7BA8F.6C374680 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: quoted-printable

It *is* safe to assume that no latch is inferred when there's already = a flop that stores the value.

The latches in combinatorial equations are because the LHS or = combinatorial output relies on itself as a combinatorial input in the = RHS. In sequential logic, the new register value depends on the onld = register value and nowhere tries to assign the new value based on the = new value which *would* generate a latch.

Your figure B always holds true always because the implied "q

devices schrieb:

For most target libraries this will result in a D-Flipflop and a multiplexer controlled by ce. The multiplexer selected d or q as input to the D-FF.

That is correct.

Yes. Because you did not model a latch.

A latch is a storage element. A D-latch has an enable signal and a data input.

process(en,data) begin if (en='1') then latch

Yes, and thanks for fixing the font.

The combined structure could also be viewed as a latch with a synchronous delay rather than a wire in the feedback loop.

This example is also the limit case in the one vs two process debate.

-- Mike Treseler

Thanks for your reply. In any case, avoiding the double branch is what i was looking for. I wanted to omit the "else" and safely hand data to a flip flop.

Actually, most FPGA synthesizers will implement the register and mux as a clock enabled register (which incorporates the mux and the register as you stated, but is a primitive that does not consume a LUT for the mux).

I really wish the advise "don't use an if without an else" in combinatorial logic had never been given. There are a couple of much more effective and verifiable ways to eliminate the possibility of inferring a latch:

First, use clocked processes for everything, and include the logic in the clocked process. No combinatorial processes, no latches. There are lots of ways to avoid using combinatorial processes in virtually any circumstance (except when an entity has a completely combinatorial path from input to output), and using variables helps a lot.

Second, if you HAVE to use a combinatorial process, assign a default value to every signal driven by the process, right up front in the process, before anything else happens. It is MUCH easier to see and verify that every driven signal is in that default list, than it is to verify that every if contains an else AND that anything assigned in the if is also assigned in the else.

Example:

process(ce,d,q) begin q_next