Velocity Reviews

Velocity Reviews (
-   VHDL (
-   -   Re: Why doesn't this situation generate a latch? (

Ed McGettigan 03-10-2010 07:24 PM

Re: Why doesn't this situation generate a latch?
On Mar 10, 10:06*am, Andy <> wrote:
> On Mar 9, 12:15*pm, Ed McGettigan <> wrote:
> > I would strongly encourage you to change the RESET function from
> > asynchronous to synchronous.

> On what basis do you make this recommendation, and what does this have
> to do with latches?
> Andy

Synchronous versus asynchronous resets have been discussed at length
in other threads.

Asynchronous resets have their place in a designer's toolbox, however
they should be used sparingly. Some reasons to use these are for
handshakes crossing clock domains, anticipated loss of clock and
asynchronous inputs to the synchronous domain.

In a synchronous domain, such as the original state machine example,
the asynchronous functionality offers no additional benefit in FPGAs
as the area cost is identical for both.

Asynchronously asserting and de-asserting a reset across multiple
registers may/will result in the registers being released before and
after a clock edge due to large net delay and skew on the reset net.
This will result in different parts of a design coming out of reset
across clock boundaries and being out of sync with each other.

Synchronous resets simplify timing analysis and timing closure without
having to worry about the consequences of the asynchronous functions
and how to correctly constrain them.

I often see problems with FPGA designs that are built with
asynchronous resets, but I have yet to see a problem with a FPGA
design that was traced to a synchronous reset.

In an FPGA there is no downside to a synchronous reset, but there are
many pitfalls with an asynchronous reset.

None of this has anything to do with a latch, which you also want to
avoid using in an FPGA.

Ed McGettigan
Xilinx Inc.

All times are GMT. The time now is 03:52 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.