( ESNUG 353 Item 1 ) --------------------------------------------- [5/24/00]
Subject: ( ESNUG 343 #1 344 #7 ) More On The "set_dont_touch_network" Bug
> The following is from the Synopsys Support Center on logid 100418:
>
> The problem with set_dont_touch_network not working correctly in 99.10
> has been recently reported. The STAR number for your reference is
> 95299. Here are the 2 possible Workarounds for the problem.
>
> Workaround #1
>
> Do NOT specify set_dont_touch_network at all. Starting with DC 99.05,
> DC will infer the clock net as ideal. By default, Design Compiler
> treats all clock networks as ideal nets. Ideal nets are networks of
> nets that are free from max_capacitance and max_fanout design rule
> constraints. (For more info see command set_ideal_net)
>
> No buffers are added on the clock network.
>
> As a Side Note: ideal_net attribute by default does not propagate through
> gating logic. So if you had a gated clock, you would have to explicitly
> set the ideal_net attribute at the output of the gate.
>
> Workaround #2
>
> There is another workaround provided by the R&D team. You can keep the
> set_dont_touch_network in your script and set:
>
> compile_map_for_delay = true
>
> This is a hidden variable, so use it with caution.
>
> I chose Workaround #1, since I am phobic of hidden variables that have no
> documentation in SOLD. I noticed a new Solvit aritcle that says to use
> Workaround #1, but doesn't mention the hidden variable.
>
> I'm told they have fixed this bug in 1999.10-5 plus Star 95299 and 93201.
> I have not been able to confirm this since our DesignWare libraries go
> toes up with this release.
>
> - Kayla Klingman
> Tektronix, Inc. Somewhere, Oregon
From: Robert Wiegand <rwiegand@nxtwavecomm.com>
Hi John,
I have a few tidbits to add about the set_dont_touch_network bug. On a
recent design, I was running with workaround #2, and found a particular
module that wound up with a buffered clock tree. I decided to bite the
bullet and variablize my scripts to exclude the set_dont_touch_network on
clocks when using version 99.05 or newer, effectively implementing solution
#1. I removed solution #2. This change fixed the problem with that module.
HOWEVER, another module which had previously compiled successfully with
solution #2, now had a buffered clock tree! Huh? So I put solution #2
back, and kept solution #1 as well. NOW, all my clock buffering problems
were fixed.
If the intent is to bag the usage of set_dont_touch_network for clocks in
favor of the ideal_net attribute, I'm not happy about it. As Kayla explains
in her side note about solution #1, ideal_net wont propagate through clock
gating elements. You have to explicitly set the ideal_net downstream of any
clock gating logic.
I found another limitation of the ideal net attribute on a recent very large
COT project I was involved in. As of the 9905-2 version, ideal_net makes
max_capacitance and max_fanout violations go away, but not max_transition.
Without a special cell to drive the high fanout clock net,
set_clock_transition must be used to overcome the max_transition violation.
Same as it ever was. The problem is that this command only works on clocks.
What about internal resets, scan enables, and other high fanout nets that
could also be taken care of in layout tools. I have self-buffered scan
enables and resets in the past, or had the benefit of a library macro to
drive the high fanout nets. Here, the desire was to let the layout tools
deal with the high fanout nets, but a driver macro cell was not available
do to schedule pressure, etc. The ideal net command won't overcome the
max_transition problem, especially when thers signals are driven from
internal gates. In order to run compile -top to fix other things, these
bogus problems have to be out of the way. I tried set_load 0 on the high
fanout net, but that doesn't overcome the load of all the input pins
attached to the net, so the transition time is still outrageous. In order
to get around the problem, I had to get ugly and resort to "scratch and
sniff" techniques. I created a bogus input port, disconnected the high
fanout net from it's source, and connected it to the new bogus port. I
could then set_drive 0 on the bogus port and eliminate the transition time
problem. After performing the compile -top, I had to restore the original
connections and clean up the mess. Here's a script example:
create_port bogus_test_se -direction in
disconnect_net test_se clkmux/test_se
connect_net test_se find(port,bogus_test_se)
set_drive 0 find(port,bogus_test_se)
set_resistance 0 find(net,test_se)
set_dont_touch_network find(port,bogus_test_se)
set_dont_touch clkmux/U38
compile -top
disconnect_net test_se find(port,bogus_test_se)
all_connected find(pin,clkmux/test_se)
if (dc_shell_status) {
temp_net = dc_shell_status
disconnect_net temp_net find(pin,clkmux/test_se)
remove_net temp_net
}
connect_net test_se find(pin,clkmux/test_se)
I had to set_dont_touch on the cell that drives the net to prevent it from
being optimized away(I was using compile_top_all_paths = true, I wanted to
be sure), but somehow a net was attached to the output pin of clkmux where I
disconnected the test_se net. I had to remove this bogus net before I could
re-attach the test_se. There must be a better way, anyone?
- Rob Wiegand
NxtWave Communications Langhorne, PA
|
|
