synchronous reset/set or asynchronous reset/set
Quote:
> what if you take the reset pin of the chip, synchronize it using two dffs and the
> connect the output to all the asynch reset inputs of all dffs ? Is this an OK use
> of the asynch reset ?
This could be OK, see below for
more info (plus I have to add some lines to get the news server to
accept my message.. I hate when
I have to do that...)
Quote:
> >> Hi,everyone:
> >> I have heared that it is better to use synchronous reset/set than to use
> >> asynchronous reset/set,
> >> Why? And when I must use asynchronous reset/set, what do I need to be
> >> attention?
> >Asynchronous chip design should be avoided because:
> >- It complicates the static timing analysis
> >- It complicates the automatic scan test insertion
> >- It may lead to very risky race condition
> >- Automatic reoptimizing after layout is difficult and risky
> >- portability is not ensure
> >In fact all tools used in a design flow works very well when
> >the design is synchronous and MANY MANY problems appears when
> >the design is partially asynchronous.
> >A single clock, a single clock edge, no latch, no async
> >set/reset pins on FF, no internal bidir, no internal tri state,
> >no gated clock is a way for success.
> >With today technology, gates count is non longer an issue
> >(20000 g/mm2 in 0.35 um, 35000 g/mm2 in 0.25 um) so in my
> >opinion, there are no good reason at all to use the asynchronous
> >FF reset/set pins.
> >Bye
> muzo
With regard to async and sync reset... In general as was mentioned above, its good
to have everything syncronous, but sometimes you run into situarions were you need
an async reset (if you don't have a clock, for instance), if you're doing a design
with multiple clocks, and some aren't always available (if you get a clock from
an external IO chip that doesn't provide clocks for some time after power up
for instance), you might need to use an asyncronos reset. In anycase, 99.9% of the
time the reset pin of a FF (sync or async) should be connected to a chip reset line.
If you use the async reset line, and sync it to the clock , its ok, but scan can't
test those reset syncroniser flops well...(as was mentioned before, when the
active level of reset scans through them, it'll reset all the FF's connected to
it, but there are ways around this that aren't too painfull, like forcing the
reset output deasserted when in scan mode....).
There are times when you might want to functionally use the async reset line of a
FF (as a armable edge detector for instance..). When your dealing with lots of
clocks in a design, you have to break the 'good design practices' rules sometimes.
But if you only do it when its absolutely necessary, it usually doesn't impact
DFT, too much (plus there's always partial scan...).
Ken
