ADMIN NOTE: e-mail at my company is going to be messed up for the next
two weeks because we're moving to another building. As a consequence,
ESNUG will be down for 9 days from Monday, Sept. 7 to Wednesday, Sept. 16.
( Post 70 Item 1 ) --------------------------------------------------------
From: rfall@mv.us.adobe.com (Richard Fall)
Subject: Re: ESNUG Posting Number 67 Item 2
>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.
Even in cases where timing is not tight, I have had Synopsys place a
synchronous reset into FSM logic in a fashion that creates the problem
described.
>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).
Agreed--in the general case, this is probably a practically insoluble
problem.
My (limited) experience with this problem leads me to question the
practicality of some of the proposed solutions:
>A) set timing constraints to force synopsys to place the reset equation
> close to the register
Timing constraints are not always the reason that Synopsys creates this
problem, as noted above. I have some FSMs in which this problem appears,
and the timing constraints for these FSMs were very loose. I think the
problem is actually created for a different reason (see below).
>B) hand instantiate your circuit (easier to do than A), but time consuming
You've got to be kidding! --as a practical solution, this would be hell for
some of the designs I am currently working on. They're mostly FSMs, and
if I hand instantiated them, Synopsys would then be virtually useless as
a design tool.
>C) get vendor to provide synchronously resetable register primitive
Possible, but if the target technology doesn't already have these, it can
take months for a vendor to design and validate such primitives--not
at all desirable for short design schedules.
>D) use asynchronous reset
Well, it'll work, but it's often not an acceptable solution for many designs,
and it defeats the entire purpose of doing completely synchronous designs.
>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
As noted, not recommended, as this will rarely test the initialization
conditions that are likely to cause problems in the design. To test the
design thoroughly, one would have to test all 2^^n possible starting states
for the n registers in the design.
I believe this "problem" may have a more fundamental cause, and solution,
than noted to date. Some experimentation on my part leads me to believe
that the problem can be caused when Synopsys uses "Boolean" (non-algebraic)
optimizations to reduce the circuit complexity.
In effect, if I have a synchronous reset in an FSM, I am trying to make
the FSM next state a fixed value when the reset is active. If I were doing
a hand-instantiated design, I would force this to occur by gating a fixed
value into the FSM registers when reset was asserted.
However, Synopsys attempts to use identities of the form "a * !a = 0" to
simplify the circuit. In doing so, it may inadvertantly make the next state
inputs to the FSM a function of the FSM outputs, rather than a fixed 0 or 1
value. While this is functionally correct for the physical circuit (since
when it does this, it uses true and complement forms of the current state
value to achieve the 0 next state value), it creates the simulation problem
described, because the simulator sees unknowns propagating to the FSM
inputs, even when reset has been asserted.
The solution I used for this problem is simple--tell Synopsys not to do
Boolean optimization through the "set_structure -boolean false" command.
The downside? For circuits I've tried this on to date, a 10% to 15%
increase in gate count, but the design becomes fully simulatible. In my
case, this is acceptable, while for others it may not be.
I'd be interested in hearing if anyone else has tried this, or other
"fixes" for this issue.
Richard Fall, Adobe Systems
( Post 70 Networking Section ) --------------------------------------------
Wanted: 2->6 Experienced Verilog/Synopsys Design Engrs &/or VLSI CAD Engrs.
At Motorola, Phoenix, AZ. Contact: davidf@digital.sps.mot.com (602)962-3329.
Hewlett-Packard in Roseville, California is seeking an experienced
Verilog/Synopsys designer. Send email resume to alana@hprnd.rose.hp.com
|
|
