( ESNUG 380 Item 13 ) ------------------------------------------- [10/25/01]
Subject: ( ESNUG 379 #14 ) DC Behaves Badly Without Synch Set/Reset Flops
> We currently use synchronous resets in our ASIC designs. We are finding
> a lot of time is spent meeting timing on synchronous resets, especially
> at clock speeds 200+ MHz. We are considering switching to asynchronous
> resets so that the logic connected to the D pin is not impacted by reset.
>
> Can someone list the pros and cons of sync vs. async resets? Are there
> RTL versus gate simulation issues? What are the PrimeTime and test
> issues? How do you avoid them?
>
> - Siegfried Weidelich
> McDATA Corporation
From: Jon Harris <jharris@siroyan.com>
Hi, John,
We have recently taped-out a design with synchronous resets, which were
favoured over asynch resets mainly to decrease circuit susceptibility to
possible noise on the reset lines. However I did encounter one problem
in DC during the flow development:
My prefered flow was to use commands like set_driving_cell, set_ideal_net,
set_dont_touch_network, etc., on my design's reset port and then insert
a reset tree in the layout. However, what I found was a problem in DC's
elaboration stage due to the fact that some of the design's flops needed to
be RESET to logic low and some needed to be SET to logic high.
To describe the problem more fully, consider an active low reset signal,
rst_n and a block with 100 flops. 51 flops are to be SET when rst_n is low
and 49 are to be RESET when rst_n is low. The UMC 0.15 technology we were
using had no synchronously set/reset flops in the library, and so DC had to
create the reset logic by placing a gating element just before the 'D' input
of each flop.
For the 49 flops to be RESET when rst_n goes low, this gating is simply
achieved with an AND gate, and for those 51 flops to be SET when rst_n
goes low, an OR gate is used with the rst_n input inverted. It was this
latter case which caused the problem, because DC would elaborate the required
OR gating but would do it by inverting rst_n ONCE, and then fanning this out
to all 49 flops with OR gates. Similarly a non-inverted rst_n would be
fanned-out to the 51 flops with AND gates.
This approach meant for each block being synthesized there were effectively
2 reset trees, one with an invertor as its driver. Consequently it was not
possible to simply apply the "set_ideal_net" type commands and expect DC to
not put buffers in the inverted reset tree, as the invertor protected the
inverted-tree from such constraints.
So, I was stuck with all these invertors, which were needed for the
functionality but which got in the way when trying to constrain the trees.
In the end it WAS possible with some fiddling around using commands like
clean_buffer_tree to strip out all reset buffers, but I still had the problem
that the layout tool had to cope with a few dozen invertors midway down the
reset network. What I really wanted was one tree fanning out to every flop,
each flop with it's own gating element and invertor (if required).
I do not believe I would have seen this problem if UMC had had synchronously
set/reset flops in their library, but given that they did not (like other
vendor libraries that I know of) I think there is a requirement here for some
kind of "invertor proliferate" switch so that in elaboration every flop to be
SET on rst_n low gets its own invertor along with the gating element.
Although this does introduce extra logic and therefore a little extra area,
it would save a lot of time and effort on the reset tree, allowing it to be
effortlessly put in by either synthesis or layout tools without any rogue
invertors stuck in the middle.
- Jon Harris
Siroyan Reading, Berkshire, UK
|
|
