( ESNUG 375 Item 14 ) ------------------------------------------- [06/28/01]
Subject: ( ESNUG 373 #6 ) DC 99.10-6 Putting 2 Inverters In My Reset Paths!
> I am using DC 99.10-6. We are doing a million gate bottom up synthesis.
> We are planning to use CTS both for the reset and clock networks. We put
> following constraints on clk and reset:
>
> set_drive 0 clock_grp
> set_dont_touch_network clock_grp
>
> set_drive 0 rst_l
> set_dont_touch_network rst_l
>
> But still DC puts 2 inverters in the reset path. Also there is no logic
> between reset and flop in my design. Is there any issue with this version
> of DC? (Interestingly it doesn't put any buffers/inverters on the clock
> network path though its treated exactly like reset.)
>
> - Rajendra Marulkar
> Marconi Communications
From: Siegfried Weidelich <Siegfried.Weidelich@McDATA.com>
Hi, John,
I had the same problem w/ my synchronous resets (driven by a clock buffer).
DC does not treat resets and clocks the same. Clocks are ideal, so it knows
not to buffer them up no matter what. Adding this command:
set_ideal_net "reset_net_name"
worked for me in DC 1999.10, but I have heard of cases where it doesn't
(depends on DC version, and which design rules are violated).
DC 2000.11+ versions have a new command (clean_buffer_tree "driver.pin") to
remove buffers from a net across hierarchy (I assume to get around this DC
"feature"), but I haven't tried it.
- Siegfried Weidelich
McDATA Corporation
---- ---- ---- ---- ---- ---- ----
From: JEAN-MARC.CALVEZ@st.com
Hey, a question I may have an answer for!
I have already seen a similar behaviour. In my case, here is what happened:
all STMicro flip-flops with async reset that I know of/use have an active
low reset; however some designers, believing that the One True Standard is
the active high signal, code their RTL accordingly. Post-elaboration, one
will get a reset signal connected to the reset pin of a generic register
(Synopsys's seqgen); post-mapping, the generic register will have been
replaced by a real one and an inverter will be inserted in the reset path
to preserve functionality.
If there is a dont_touch_network set on the reset, DC will pick whatever
inverter is available in its library and, once the initial mapping is done,
will leave it at that, no matter how many DRC violations it causes (after
all, there is a set_dont_touch_network on the reset, which implies that
there will be a dont_touch attribute set on whatever combinational cell
on the reset path).
Now, consider that this design is actually a sub-block of a larger design,
where the active-low reset convention is adhered to: when the 1st design is
instantiated, the reset port will be connected to the opposite of the
top-level reset: post-elaboration, the gtech inverter will be inserted;
post-mapping, that inverter will be mapped on whatever inverter is available
in the library, and the comment above on set_dont_touch_network will apply:
hence, 2 inverters, poorly chosen, back to back on your reset signal.
In general, I have always found out the hard way that set_dont_touch_network
had a lot of unwanted side effects, and thus I advocate against its usage,
unless the designer really knows what she/he is doing.
- Jean-Marc Calvez
STMicroelectronics
---- ---- ---- ---- ---- ---- ----
From: Ansgar Bambynek <a.bambynek@avm.de>
Hi John,
I had a similar problem with DC inserting inverters into the reset path. I
contacted the ASIC vendor and Synopsys. They told me that they filed a STAR
since it should have something to do with the library. Unfortunately I
didn't hear anything about.
The problem arose when synthesizing FFs which have only a low active reset.
Here's the original constraint (different then the one used by Rajendra):
set_driving_cell -none reset
set_dont_touch_network reset
What helped was the following instead
set_drive 0 find (port, reset)
set_max_fanout 1000 reset
The fanout load on the reset port of my block is much smaller than 1000. I
used the 1999.10-4 release of DC when facing this problem.
- Ansgar Bambynek
AVM Computersysteme GmbH Berlin, Germany
---- ---- ---- ---- ---- ---- ----
From: Dave Smith <Dave.Smith@st.com>
This appears to be a bug. I noticed it on one of my designs, and here is
the summary:
I have noticed a problem using set_dont_touch_network on reset trees, on
versions prior to 2000.11:
If a net has set_dont_touch_network applied, and goes to a number of cells
without an inverter, but also feeds an inverter somewhere, then all the
uninverted cells will have two inverters connected to their input, to form
a buffer, and all of these buffers will be connected together.
An example of this is as follows:
Consider a design "top", with two sub-designs "sub_a" and "sub_b".
"top" and "sub_a" have active-low reset inputs (not_reset), but "sub_b"
has an active-high reset input (reset).
Each of the sub-designs have 500 flip-flops, all using the same
asynchronous reset input.
set_dont_touch_network is applied to not_reset at the top level, but
the signal is inverted before going in to "sub_b", in order to preserve
the function at the hierarchy boundary.
After synthesis, the reset tree will be as follows:
not_reset will feed one inverter at the top level, which will connect
down in to "sub_b". In the "sub_b" block, reset will connect to one
inverter, which will then connect directly to the reset input of every FF.
not_reset will also feed in to the "sub_a" block. However, in this case,
the not_reset input of the sub block will connect to 500 individual
inverters, and each of these inverters will connect to another inverter,
and then to a FF reset input. As a result, every FF in "sub_a" will have
two inverters bufferring its reset input.
This problem takes no account of hierarchical boundary - provided there
is an inversion somewhere in the dont_touched network, all of the
non-inverted cells will get 2 inverters added.
The good news is that this bug is fixed in 2000.11 (but not in 2000.05)
Alternatively, I've had a mail from Synopsys support, suggesting the
'remove_buffer_tree' command.
- David Smith
STMicroelectronics Bristol, UK
---- ---- ---- ---- ---- ---- ----
From: Robert Wiegand <RWiegand@NxtWaveComm.com>
Hi John,
I have had other problems in the past with resets, and I condition them
slightly differently. Instead of using set_dont_touch_network, I do the
following:
if (find(port,all_reset_ports)) {
set_drive 0 find(port,all_reset_ports)
set_resistance 0 find(net, all_reset_ports)
set_dont_touch find(net,all_reset_ports)
set_ideal_net find(net,all_reset_ports)
}
Where all_reset_ports is a user variable listing all possible port names
for reset. The construct find(net, all_reset_ports) is valid when the
net names attached to the port match the port name. I believe this is
the default behavior, but might be effected by:
write_name_nets_same_as_ports = "true"
This seems to work for me.
- Bob Wiegand
NxtWave Communications Langhorne, PA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
