The latch in Synthesis?Thanks

[Lee]

Hi,

I got the following rules. I am wondering what is wrong if I don't
follow them. Just latch is produced?So what is wrong with the latch
produced?The synthesized circuit is still working, right?Why do I need
to care of the latch?Thanks,

Golden Rule 1:

To synthesize combinational logic using a process, all inputs to
the design must appear in the sensitivity list.


Golden Rule 2:

To synthesize combinational logic using a process, all objects
must be assigned under all conditions.

 

[Eyck Jentzsch]

Lee wrote:

Hi,

I got the following rules. I am wondering what is wrong if I don't
follow them. Just latch is produced?So what is wrong with the latch
produced?The synthesized circuit is still working, right?Why do I need
to care of the latch?Thanks,

Golden Rule 1:

To synthesize combinational logic using a process, all inputs to
the design must appear in the sensitivity list.

If you dont follow this rule you may have mismatches in behavior for

your RTL and your synthesized netlist. This is simply because the
simulator activates your (RTL) process upon changes of the signals in
the sensitivity list while the gate level netlist runs 'continous'.

Golden Rule 2:

To synthesize combinational logic using a process, all objects
must be assigned under all conditions.
Violating this rule leads to latches. In general this is not bad but

there are target technologies not supporting latches (e.g. some FPGA's)
and you allways have trouble with static timing analysis and/or DFT
(scan chains).

-Eyck

 

[Ralf Hildebrandt]

Lee wrote:

Just latch is produced?So what is wrong with the latch
produced?The synthesized circuit is still working, right?Why do I need
to care of the latch?

Latches a as half as big as flipflops and consume less power (no
clock-in, that switches permanently). For low-power design they are a
good choice.
You have to take care about the asyncronous behavior - e.g.: If you
design a "muxed latch" (latch that has more than one input that is
selected by select signal(s)), make shure, that mux-switch and
latch-enable are not the same. Otherwise your latch may buffer the wrong
value (when mux-switch changes short before latch-enable turns off).

Latches often have glitches at output, that have to be filtered (e.g. by
a flipflop buffer). No scan path is possible with latches and some
target libraries do not support them (well), e.g. FGPAs.

It depends on you requirements, what is "bad". Flipflops a bad for
low-power designs, latches are bad for fully syncronous designs.


Ralf

 

[Joe]

Lee wrote:

Hi,

I got the following rules. I am wondering what is wrong if I don't
follow them. Just latch is produced?So what is wrong with the latch
produced?The synthesized circuit is still working, right?Why do I need
to care of the latch?Thanks,

Golden Rule 1:

To synthesize combinational logic using a process, all inputs to
the design must appear in the sensitivity list.


Golden Rule 2:

To synthesize combinational logic using a process, all objects
must be assigned under all conditions.

Having latches in your design can be risky. It might not work if the
enable pin of your latch have glitches. Consider the following case
(sorry for writing in verilog, working on a project in verilog at this
moment and forgot how to write VHDL ;-)

assign latch_en = A ^ B;

// Rule 2 (data_in not assigned when latch_en is 0)
always @(latch_en or data_in)
begin
if (latch_en)
Q <= data_in;
end

Now if A and B toggle at the same time, you can get a glitch on
latch_en. Will the data_in be latched in real circuit?
It could be latched in simulation, depends on whether A change
first or B change first, but in real circuit the glitch pulse
might be too narrow to trigger the latch.

Another problem with latches is that automatic test pattern generation
(ATPG) tools doesn't like it. Therefore it "can" reduce test coverage in
scan tests. (not always true if handled carefully)

Joe