( Post 50 Item # 1 ) ----------------------------------------------------------------
[ From: Neil Barrett <nbarrett@synoptics.com> ]
This problem may be peculiar to me only but here goes anyway:
Most vendors require a purely structural netlist.
i.e. Only instantiations of gates with no "assign statements"
well, according to the Synopsys manual setting the the variable
verilogout_equation = "false"
should take care of most cases EXCEPT:
1) if you have tri-state lines due to bi-directional or tri-state logic
then the synopsys tool inserts assign statements
FIX- use variable: verilogout_no_tri ="true"
2) if you have multiple output ports connected together
FIX- use the compile variable: compile_fix_multiple_port_nets = "true"
3) if you have feedthroughs, i.e a module that has one or more ports
tied to logic 1 or logic 0, and this module is a submodule of some other
one
FIX -- there is no fix, according to the synopsys AE you have to hand
edit the netlist and put in power and ground cells.
example
synopsys gives
assign foo = foo1;
cvdd Uxx (.Q(foo1));
change to
cvdd Uyy (.Q(foo));
cvdd Uxx (.Q(foo1));
Well that is my 2 cents worth, I got this after talking to the AE at the
hotline). Hope someone out there doesn't pull their hair out trying to
figure this out.
later
neilB
SynOptics Communications Inc.
( Post 50 Item # 2 ) ---------------------------------------------------------------
[ another interesting subscription request I've received - John ]
I have a burning desire for more info and biased flames about Synopsys.
Please include me on your mailing list.
Thanks,
Bob
( Post 50 Item # 3 ) --------------------------------------------------------------
[ From: cindy@ca45.zoran.hellnet.org (Cindy Eisner) ]
1. John Auer (jaa@mongoose.ess.harris.com) writes:
> I've found what seems to be a real problem for Synopsys and 2 phase
> clock regimes. Synopsys indicates that the "set_clock -mult 0 phase_b"
> be used for the phase_b clock. However, if you do this, timing paths
> from phase_b to phase_b are not optimized.
almost correct. timing paths from phase_b to phase_b are NOT ALLOWED. that
is, the equations work in such a way that you will always get a timing
violation (setup) for a path from phase_b to phase_b.
> On the other hand, if you use the "set_clock -mult 1 phase_b" command,
> phase_b to phase_b paths ARE optimized, but now phase_a to phase_b AREN'T.
this is more of a problem. the paths from phase_a to phase_b get 1.5 clock
periods (i.e., three times more than they should), and you get no warning or
error message.
> I took a look at the formula Synopsys uses to generate the setup constraints
> for sequential elements, and it makes sense that things behave as they do.
> It appears to be a fundamental flaw in the constraint method Synopsys uses;
yes. i've considered this quite thoroughly and i believe that assuming one
delay statistic per node, there is no set of equations that will work. of
course, if someone can prove me wrong, there would be cause to submit a bug
report and hope for the future.
> with 2 phase clocks, one set of constraints (A -> B or B -> B) is always
> missed. Unfortunately, Synopsys takes advantage of this and pushes alot
> of the chip delay into this unconstrained "space", allowing Synopsys to
> artificially improve performance.
well, if you use a phase multiplier of 0, you will simply have to disallow
(B -> B) paths. that is, there is no danger if you can live with this
restriction. if you use a phase multiplier of 1, timing analysis is wrong,
and your actual clock is three times the clock you want. i guess this is
what you meant by "artificially improve performance"? b.t.w., it will do no
good to give synopsys a clock 1/3 of the real one, because the (A -> A) paths
will then be pressed too hard.
> Has anyone out there optimized 2 phase circuits (especially those
> containing latches and flops, with communication between the regimes) and
> run into the same problem? Any workaround ? (Incremental mapping hasn't
> helped much, BTW).
no. we have not used two-phase circuits because of these problems, although
i know of a company that intends to, and live with the restriction of no
(B -> B) paths. i see no reason why incremental mapping should help in this
case.
2. Michael Parkin (parkin@ultrasparc.Eng.Sun.COM) writes:
> I have had poor success using the state machine compiler. In most cases I
> have tried, a normal compile produces better results. I suspect that if
i am glad to hear this. i have just started to look into the state machine
compiler, and i am seeing exactly the same behavior. it was very
frustrating, since others have reported good results.
> are automatically extracted. I have obtained the best results by using
> a pla description as input. This can also be obtained by extracting the
> state table and replacing the state names with their corresponding values.
> I do not understand why a PLA which is equivalent to the state table,
> should produce significantly better results.
please elaborate. does this give better results than a straight compile? do
you have a synopsys parallel case directive on your case statement? if not,
then this could explain the improvement. i would assume that a pla description
would use mutual exclusiveness that the normal case statement does not.
i have seen best results by doing a straight compile, with the synopsys
parallel case directive on the case statement, although i have not tried your
way.
Cindy Eisner
Zoran Microelectronics LTD
|
|
