( ESNUG 349 Item 4 ) --------------------------------------------- [4/18/00]
Subject: ( ESNUG 348 #1 ) Two DC Bugs That Cause Bad Logic To Be Created
> We are right in the middle of taping out a 1.3 million gate design and
> we discovered that incremental compiles in DC 99.10 is synthesizing bad
> functionality in our design! Yes, I am saying that incremental compiles
> in DC 99.10 is creating broken netlists. The problem involves something
> messy with boundry optimization.
>
> - [ The Great Gatsby ]
From: Paul Gerlach <paulge@mdhost.cse.tek.com>
Hi, John,
Has anyone had problems or received notice from Synopsys that:
simplify_constants -boundary_optimization
is similarly flawed? We use this command to remove many dangling gates that
compile seems to leave around.
- Paul Gerlach
Tektronix Beaverton, OR
---- ---- ---- ---- ---- ---- ----
From: Longyin Wei <lwei@sdd.hp.com>
Hi John,
Do he mean DC 99.10 or DC 99.10-4 here? I was trying to use DC 99.10 once,
and the problem I had was that DC 99.10 hangs while building some blocks
with map_effort high. So I had to back down to DC 99.05-2 instead. I
haven't tried the DC 99.10-4 yet. I am ready to try DC 99.10-4 in next
few weeks. But if what he meant about is DC 99.10-4, I'll wait. Which
is it?
- Longyin Wei
Hewlett Packard
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys DC Technical Marketeer ]
Hi, John,
What [ The Great Gatsby ] has reported is what we at Synopsys call a Class 4
bug. These are bugs that we stop everything for because they involve DC
synthesizing bad logic. I work in Technical Marketing for DC and since
ESNUG 348 went out, I've received a lot of calls on this issue. Enclosed is
the write-up of the research I've done on these bugs. Ten Synopsys people
(six of whom who are in R&D) have been involved in making this write-up as
detailed and accurate as possible. I apologize for the inconvenience for
Synopsys customers on this issue.
There are actually 2 related STARs which have similar symptoms and effects.
STAR 100465 was filed by [ The Great Gatsby ] but STAR 99006 is related to
this matter as well. Bad logic can be created when boundary optimizations
are performed on DW parts AND the implementation of DW part changes as
part of optimization performed during successive compiles AND some other
complex conditions are present.
You can not generalize the issue by stating that it is boundary optimization
on an incremental compile. This would imply a command such as:
compile -incr -boundary_optimization
or
set_boundary_optimization true
causes this problem. NOT TRUE!!!!
Some boundary optimizations are performed on all DesignWare parts REGARDLESS
of the setting of the switch. Boundaries around inferred DW parts are
"soft". It is not incremental compiles which cause problems; but the
interaction between ANY boundary optimization and the optimization which
changes DW implementations. This can happen on ANY compile, incremental or
not, in which implementations actually get changed. Pay careful attention
to the conditions which _may_ cause bad logic.
Symptoms
--------
The symptoms may seem to apply to many designers but the actual probability
of bad logic is very low. We've seen bad logic only in very, very few real
life cases. There is also a solution that avoids the problem completely.
STAR 100465 symptoms:
- The design MUST contain DW parts at some point during synthesis.
- The DW parts must have equal or opposite inputs. Example:
Equal Inputs Opposite Inputs
-------- --------
-----------| DW | --------------| DW |
| | part | | | part |
-------| | ---|>o----| |
-------- --------
- The implementation is changed during optimization.
STAR 99006 symptoms:
- The design MUST contain DW parts at some point during synthesis.
- boundary optimization must be on via "compile -boundary_optimization"
OR via "set_boundary_optimization true" on the design.
- The DW implementation must change on a secondary or later compile.
- You're using Design Compiler version 99.05 or earlier.
The Cures
---------
STAR 100465 cure:
BEFORE your FIRST compile set
compile_implementation_selection = "false"
This flag should also be set to "false" before any successive compiles.
STAR 100465 will be fixed in 2000.05
STAR 99006 cure(s):
You have a choice of 3 cures for STAR 99006:
On any secondary compile set
compile_implementation_selection = "false"
OR
perform the secondary compile without invoking
boundary_optimization
OR
upgrade to Design Compiler 99.10 or later.
STAR 99006 has been fixed in 99.10
Side-Effects of the Cure(s)
---------------------------
The side-effect of not using the boundry optimization technique is lowered
quality of synthesis results. You design won't have broken logic, but it
also won't be the most optimal logic you could have created. In the case
where
compile_implementation_selection = "false"
DC will not perform a specific optimization, Incremental Implementation
Selection (IIS).
Although IIS can be a very powerful optimization for a few users, in most
cases it should not have a significant impact on design performance. Some
power users use this flag to improve their run-time at the expense of
circuit performance. Again the performance degradation varies by design
and should not even be noticeable for most customers.
If your circuit shows significant performance degradation after switching
off IIS optimization then you may want to try the antidote.
Antidote to the Side-Effects
----------------------------
Manually set the implementation of the DW part using "set_implementation".
Once you have identified the DW parts whose implementations need to be
different, use the following steps to report the existing implementations
and then change it during a subsequent compile.
/* Identify the DW parts & implementations */
report_resources
/* force DW instance U1 to "carry-look-ahead" */
set_implementation cla U1
/* compile design to force implementations */
compile [-incr]
/* verify that selected implementation was used */
report_resources
If you are not sure which implementations are available for a particular
designware part then run the following command on your designware library.
report_synlib
Hopefully this will help the ESNUG readers avoid these two Class 4 bugs in
Design Compiler.
- [ A Synopsys DC Technical Marketeer ]
|
|
