( Post 67 Item 1 ) ---------------------------------------------------------
From: victor@truevision.com (Victor J. Duvanenko)
Subject: Re: ESNUG Posting Number 65
Synopsys has published a application note on the 'synthesizable-but-unsimula-
table' problem. If you're using the latest version of the synthesizer you
should have gotten a copy of this app-note. The problem occurs when you use
synchronous reset on synchronous state machines and is especially bad for
counters with synchronous reset. You should always try to use asynchronous
reset, which is contradictory to all present Synopsys documentation.
-Victor J. Duvanenko (victor@truevision.com)
( Post 67 Item 2 ) ---------------------------------------------------------
From: black@devnull.mpd.tandem.com (David C. Black)
[ Editor's Note: I cut some lengthy quotes here. See Post 66 - Item 2 ]
> From: Paul Micheletti 3774 <pm1@ws081.torreypinesca.NCR.COM>
>
> Again, I must assert that this is a Synopsys bug. Instead of
> requiring every simulation model vendor (and/or user) on earth
> to write simulation models that will make Synopsys happy,
> Synopsys should allow the user to specify that a particular
> signal is used for synchronous reset, and should respect the
> users wishes by not generating unsimulatable logic.
I need to comment here that this problem does not always show itself so
simply as a multiplexor. We have had this problem also, and find that
it is very complex. Sometimes in order to solve timing problems,
Synopsys injects the reset into the circuit very early in the logic
cloud to allow time critical signals to get closer to the flip-flop.
This results in fast though redundant logic in some cases. It also
causes real problems for simulators. In order to solve this problem,
it would be necessary that the simulator track every unknown uniquely
through the logic and monitor inversions. This implies multi-valued
unknowns of an enormous size for some designs.
Talking with a resident simulation expert, I discovered that this is a
very old simulation problem and is likely NP-complete. There is
apparently some literature on this problem that goes way back (pre-70's
even).
The solutions:
A) set timing constraints to force synopsys to place the reset equation
close to the register
B) hand instantiate your circuit (easier to do than A), but time consuming
C) get vendor to provide synchronously resetable register primitive
D) use asynchronous reset
E) initialize registers before simulation begins to a value opposite of the
reset state if your simulator allows (ie. don't start with unknown) - not
recommended
David C. Black black@mpd.tandem.com
( Post 67 Networking Section ) -------------------------------------------
Should ESNUG have a small part of it devoted to keeping it's readers employed?
How would you feel about the creation of a small limited section that consists
of two line contributions from readers in companies that are looking to hire
Synopsys experienced engineers?
Please tell me what you think about this issue! - John
|
|
