[ A "CAD" At LSI Logic ] in ESNUG 279 #3 wrote:
> ...
> TeraPath supports the standard synthesizable RTL that fits into the ASIC
> based sign-off flow, & does not change your use of RTL formal/functional
> /accelerated verification tools in any way. Tera Systems also supports
> standard library/placement interfaces that automate the gate-level
> implementations that LSI Logic's custom designers have previously been
> doing manually. Many of us here at LSI Logic find the marriage of
> standard top down design with custom bottom up physical design to be the
> coolest thing. ...
From: Del Cecchi <dcecchi@vnet.IBM.COM>
Gee, John, nice commercial for LSI logic and some tool from some startup.
Hey, if I write up some spiffy thing about IBM Microelectronics and IBM
EDA and how wonderful it is will you send it to the world for me? That
would be really cool. Think of all the advertising dollars we could save.
Seriously, this started out kind of interesting but turned into a massive
LSI plug. Somehow it doesn't really seem appropriate.
- Del Cecchi
IBM Rochester Minnesota.
[ Editor's Note: Del, I agree that you could have read that post by the
anonymous "CAD" at LSI Logic as being infomercial-ish, but I beg to
differ. How I judge whether something is worth publishing is by two
criteria. First: is there legitimate technical information in the
letter? That's fairly self-evident in most letters. Secondly, if
there are opinions, are they genuine, non-marketing oriented views?
That's a little harder to judge sometimes. What it boils down to for
me is that I generally don't let people "pitch" their own products
(unless it's in defence of some horrendeous error), but they're quite
free to discuss how *other* products work *or* how other products work
within their own product offering. I judged "CAD" did this by
discussing TeraPath within his experiences at LSI Logic. I judged that
Wayne Bell of Nortel was doing the same thing when he wrote about
Summit Design's tools in #3 below.
I would like to point out that this doesn't mean that I agreed or
disagreed with "CAD's" (or Wayne's) viewpoint -- how I personally feel
about what's being discussed is irrelivant -- just that users are
getting *useful* technical info and *useful* opinions. (I constantly
ask myself while editing ESNUG: "Is this *useful*?")
I'd also like to point out that ESNUG is an on-going discussion. Posts
like "CAD's" triggered interesting rebuttals and spin-off threads like
ESNUG 280 #5, & #8 below. Again, giving users *useful* technical info &
*useful* opinions is my goal. "Is it useful?" I like to think so.
So, Del, if you want to write about how certain comercially available
EDA tools work within the publically available IBM design flow (*warts*
and all!) -- send it in! And if it's *useful*, I'll publish it!
- John Cooley
the ESNUG guy
( ESNUG 281 Item 1 ) ------------------------------------------------ [2/98]
Subject: (ESNUG 280 #7) Need Help Doing Synopsys-HSPICE Correlation
> First of all, thanks for all the great information presented in the ESUG
> postings. We are doing some Synopsys to hspice correlation. I am
> interested if anyone has an idea of how to automatically generate the input
> vector that correlates to the report_timing static analysis. In my
> particular case I am dealing with an asynchronous logic block, so there are
> no flip flops to disturb the path. Any ideas anyone?
>
> - Dave Schaefer
> Logical Silicon Solutions
From: rramsay1@ford.com (Rodney Ramsay)
John,
I think "report_timing -true -justify" is supposed to do what you're asking
for but it's pretty worthless for multipliers and other complex circuits.
- Rod Ramsay
Ford Microelectronics Colorado Springs, Colorado
---- ---- ---- ---- ---- ---- ----
From: krag@lsil.com (Kevin R. Grotjohn)
John,
This is easy IF you have a DesignTime license, otherwise it could be real
difficult. Try report_timing -true. This searches the critical path for
the input vector meeded to exercise the path -- pruning those paths that
cannot be exercised. It reports the vector for the most critical true
path that it finds.
- Kevin Grotjohn
LSI Logic
( ESNUG 281 Item 2 ) ------------------------------------------------ [2/98]
Subject: ( ESNUG 278 #7 280 #4) Synchronous Resets Combined W/ Random Logic
> What is the "proper" format for a clock-enabled DFF with a synchronous
> reset. The trick is to insure that the synthesizer (Synopsys) doesn't
> combine the synchronous reset with other logic that results in the
> classic "I can't get out of reset, my circuit is all Xes" problem.
>
> - Eric Ryherd
> VAutomation Inc. Nashua, NH
From: jychen@njrs.com (Joey Chen)
Hi, John,
To get around the simulator's limitation, I usually just have:
compile_preserve_sync_resets = TRUE
set in my .synopsys_dc.setup file, and DC will not synthesize combined
reset logic as long as you put the reset signal as the highest priority
condition.
- Joey Chen
NJR Corp.
---- ---- ---- ---- ---- ---- ----
From: <koehler@dechub.lkg.dec.com> (Jeff Koehler)
John,
In response to (ESNUG 278 #7), I have another related warning for designers.
As a VHDL user, I quickly recognized the situation spelled out by Sean
Atsatt (ESNUG 280 #4):
> process (clock, reset)
> begin
> If reset = '1' then
> A <= '0';
> elsif clock = '1' and clock'event then
> A <= Input1;
> B <= Input2;
> endif;
> end Process;
What I recently discovered is that you must take heed that the default
setting of the 'hdlin_ff_always_async_set_reset' variable is "TRUE"
(see the VHDL Compiler reference manual: search for that variable name).
If you elaborate the above design without adding process-specific attributes
or changing the default value, you will find that design compiler DOES NOT
NECESSARILY recognize either a synchronous or async reset. The reason for
this is the code attempts to infer a synchronous reset, but the variable
precludes it. This perpetuates the X problem since the compiler doesn't
even know you want the term to be a reset, and may feel free to rearrange
the gates for other reasons.
Rather than assume I know what a later user will set these dc variables to,
I think I will now choose to embed the process-specific attributes in my
code to ensure the intended reset is synthesized correctly. This, of
course, makes for unportable synthesis -- but gives a clear suggestion to
a later user of the code (reuse, reuse, reuse).
- Jeff Koehler
Cabletrons Systems Littleton, Massachusetts
( ESNUG 281 Item 3 ) ------------------------------------------------ [2/98]
Subject: (ESNUG 278 #2) Coding State Machines With Graphical Entry Tools
> I used to code in text-only VHDL and Verilog. I found using a graphical
> entry tool such as Summit's Visual or Mentor Graphics' Renoir increased
> productivity quite a bit.
>
> Visual HDL from Summit ( www.summit-design.com ) is a VHDL front-end tool
> using graphical design methods such as block diagrams, state machines,
> flow charts and truth tables to generate synthesizable HDL code that is
> optimized for specific synthesis tools (Synopsys, etc.)
>
> - Frederick K. Best
> Lockheed Martin
From: "Wayne Bell" <wbell@nortel.ca>
Hi John.
I've used Summit's tool (Visual HDL for Verilog) fairly extensively in the
last year and I have mixed feelings about the whole thing. It is *very*
easy to generate a signicant amount of 'dead' gates (conditions that cannot
be evaluated) using Visual HDL. This stems from the way state transitions
are generated into Verilog, with implicit default conditions added to the
code. These can be implied from the priority of the transactions and don't
show up on the state diagrams, but can be found on code inspections (which
I *strongly* recommend until you're very familiar with the tool!). The
superfluous code can impact Synopsys compile times, although I don't have
direct numbers for the compile time difference (the additional problem of
untested gates is a whole other issue). Having said all this, once the tool
behaviour is understood, it is extremely easy to generate complex behaviour
quickly, and more importantly, it is trival to make changes (graphical editor
and all that). I don't want to make this into a Visual HDL critique, but it
is also worth noting that I did find a few significant bugs in earlier
releases (4.1.058 to be precise) and in uprevving to 5.1, mostly in the
version control stuff, but to their credit, Summit support staff did get
things straightened out pretty quickly.
- Wayne Bell
Nortel
( ESNUG 281 Item 4 ) ------------------------------------------------ [2/98]
Subject: (ESNUG 276 #8 278 #6 280 #3) Tech & Business Issues With Cascade
> We are a 3+ year customer of Cascade for our internal Fab. ... We are
> finding DRC problems, off-grid problems, verilog model versus actual
> silicon functionality problems, etc. ...
From: jcooley@world.std.com (John Cooley)
Concerning Cascade's problems with Verilog modeling, I've heard indirectly
that it's wise to not use the "-hierarchy" switch in their verilog_out
functionality. Apparently they're not translating the hierarchy correctly
in the output.
On the business side, I've also heard a rumor that Cascade has been bought
out by Duet Technologies, what I though was mostly a consulting agency that
specialized in design & testing services, so you might be calling elsewhere
soon for tech support if you're currently using Cascade tools.
- John Cooley
the ESNUG guy
( ESNUG 281 Item 5 ) ------------------------------------------------ [2/98]
Subject: How To Convert FPGA Gate Count To An Equivalent ASIC Gate Count?
> I am involved with a design that will go first into an FPGA and later it
> will be part of an ASIC. As FPGA, we selected an Altera Flex10K10 (or if
> required we could go to a Flex10K20). Higher sizes were not possible due
> to the package that we selected (144TQFP) and the voltage on the board
> (only 5V). Our estimates initially were about 8K gates (of which 400
> flip-flops) and 1.8 kbit of ram (single port). The device runs at 4MHz.
>
> Synthesis for an ASIC tells me that the current design has:
>
> - 663 FFs -> 3656 equivalent gates (nand2's)
> - combinatorial logic -> 2869 equivalent gates (nand2's)
> - some RAM, but this is mapped into the 3 EAB blocks.
>
> I got somewhere the info that on the average, a LE (logic element) is
> equivalent to 6 to 12 gates. If this is the case, my design would (in
> worst case) need only 472 LE's for the combinatorial part. Flip-flops
> and logic could share the same element in most of the cases, so for a
> 10K20, there should be no problem for routing. (A 10K20 has 1152 LE's;
> each LE is a 4input LUT, some extra logic, a FF.)
>
> The current status of my design is that it needs about 1080 LE's (report
> of MaxPlus2) but we can't get it routed. It complains on fasttracks that
> are all used somewhere in the design. Is this 6 to 12 gates per LE with
> or without the flip-flop gates? Are there others with similar problems
> with either routing or in estimating the size of the target device ??
>
> - Koenraad Schelfhouts
> Alcatel Bell Antwerpen, Belgium
From: s_clubb@netcomuk.co.uk (Stuart Clubb)
Concerning the 6 to 12 gates per LE, I think you'll find that includes the
register. But it's a finger in the air against other FPGA's, not really
against ASIC. Your mistake was when you assumed that this 6 to 12 gates is
actually "combinatorial". Never assume. It's what FPGA Marketeers rely
on you to do. You'll forget things like non-sharable inputs, inefficient
cascading of multiple levels of logic, mutual exclusion of flipflops and
logic, routing limitations, etc., when trying these conversions.
Simple crude approximation:
Take ASIC gates, and multiply by 2. That should put you in the ballpark for
FPGA gates. You might then need a "wiggle factor" based on the typical
utilisation you can expect from an architecture and still have it route.
Say 60% to 80%. Your 94% fill sounds very unlikely to be acheivable even
given the low 4MHz speed.
You have your 6525 ASIC gates, multiplied by 2 gives 13K FPGA gates. Divide
by 0.6 or 0.8 and you get 16K to 22K. EPF10K20 usable (FPGA) gates 15,000
to 63,000, but 63K is counting RAM, so combinatorially say 15K (FPGA) gates.
Even with the rough rule of thumb, the estimate says you have two hopes: Bob
Hope & No Hope.
- Stuart Clubb
---- ---- ---- ---- ---- ---- ----
From: z80@digiserve.com (Peter)
I recently did an ASIC which was prototyped in a XC3090 FPGA where it
filled 80% of it. That's about 5k-6k FPGA gates.
When the XNF netlist was given to the ASIC firm, and translated, it came
out "equivalent" to only 1900 gates. In the XC3090 it would not route (not
quite) with APR and I had to purchase XACT6 (about £2500) to route it.
The lesson is that when prototyping ASICs one should buy the biggest
FPGA around.
- Peter
Digiserve
---- ---- ---- ---- ---- ---- ----
From: "Charles F. Shelor" <charles@efficient.com>
Hmm, the number of Flip-Flops increased by 60%+ over the initial estimate.
Not atypical. 8^) Just as an exercise, I'd pass this circuit to some
other synthesis vendors as a benchmark for them to evaluate. I've seen
differences in logic usage of 1.5 to 2 X (with a couple of designs even
going 3X) between the largest and smallest sized results.
- Charles F. Shelor
Efficient Networks Dallas, Texas
( ESNUG 281 Item 6 ) ------------------------------------------------ [2/98]
Subject: (ESNUG 278 #9) Synch Probs W/ 2 Clock Domains W/ Close Freqs
> In one of our designs we are synchronizing a fifo across 2 clock domains.
> The write to the fifo is through one clock & read is through another clock.
> We use gray coding and 3 stages of flip-flop to synchronise the write
> and read pointers to the fifo. The problem we see in the lab is when
> the 2 oscillators have the same frequency some data is getting lost. When
> the 2 clocks are different frequencies we don't see any problem.
>
> We are suspecting that it is because of meta-stability caused by using 2
> clocks of similar frequencies. The problem cannot be reproduced in
> simulations. The synchronizing circuit looks something like this.
>
> _______ ______ _______
> in1 --->|D Q|---------->|D Q|---------->|D Q |---> out1
> | | | | | | (synchronized)
> wr_clk --|>______| rd_clk --|>_____| rd_clk --|>______|
>
>
> We have similar synchronizing circuits in our earlier ASICs. Any ideas
> as what exactly is happening?
>
> - Shashi Aluru
> FORE Systems, Inc
From: Jim Dahlberg <jad42958@fulmar.cdev.com>
John,
In the resync circuit posted to ESNUG, if wr_clk is shorter than rd_clk,
AND the output of the F/F being clocked by wr_clk is only one wr_clk long,
then it is possible for the rd_clk circuit to miss the wr_clk signal. In
other words, in order to resync a signal, the sample rate must be faster
than the signal you are trying to resync.
- Jim Dahlberg
General Dynamics Information Systems
---- ---- ---- ---- ---- ---- ----
From: "Ross Swanson" <swan000@erols.com>
Let me and hundreds of others say, "add delay's between the D flip flops to
prevent Q to D race with the clocks", because of your induced skew between
(or within) wr_clk and rd_clk domains.
- Ross Swanson
---- ---- ---- ---- ---- ---- ----
From: sgolson@trilobyte.com (Steve Golson)
John,
Just because this designer has two flops running on the destination clock
(rd_clk in his diagram) doesn't make metastability problems go away. The
first flop does all the work of synchronization. The second flop just
ensures that you wait "long enough" for the first flop to stabilize before
you look at its output. One clock period may not be "long enough".
Have you asked your ASIC/library vendor about the metastability
characteristics of their flops? What frequency are you running at?
What is the normal CLK->Q delay of your flops? When you run at a lower
frequency, does the problem go away?
An alternative to gray coding is to send a single bit "flag" indicating
that the input bus has changed. Then only this "flag" signal needs to
be synchronized.
The safest way is to have bi-directional synchronization. Imagine that
signal out1 gets sent back across to the wr_clk domain (with proper
synchronization, of course). Then only allow in1 to change when you
know that the previous change has been received at the other end.
- Steve Golson
Trilobyte Systems
---- ---- ---- ---- ---- ---- ----
From: Kelly Fromm <kellyf@packetengines.com>
John,
A lot of us have been bitten by similar problems at one time or another.
As your oscillators approach same frequencies, period variation and duty
cycle jitter begins to affect your synchronizer. Two independent
oscillators, will vary in frequency and clock pulse width within their
spec'd tolerance, and this is enough to make your synchronizer not work
with real logic. Simulation will not find it unless you model your
clocks for it (+/- 0.5ns variation of both clock periods will generally
find this). The double flops on rd_clk in your example provide the
required metastability coverage, but as the two clock frequencies
approach each other your real logic begins to violate the Nyquist
sampling rule. (Remember that one?) I break synchronizers into three
separate areas: (1) Sampling criteria (2) metastability and (3) Other
Circuit considerations. If you don't handle the first, the other two
don't matter. In your case, I am assuming the gray code provides a
single pulse 1/2 the frequency of wr_clk. Sampling requires that rd_clk
maintain greater than 2X the data frequency to reliably capture the
input. Exact relationships require that you understand the wr_clk FF's
clk-Q timing and the rd_clk FF's hold time requirements, but in general,
if you can't insure that your rd_clk period is 2-3ns less than your
wr_clk period, you need to pulse stretch in the wr_clk domain. I believe
this is what is missing in your circuit. The two rd_clk ff's you have
cover the second part, metastability. I think of these as the sample
and caputure pair. Sample is unreliable, but Capture is valid. Once the
sampling and metastability are covered, you need to consider the effects
of the wr_clk domain's pulse stretching logic when rd_clk runs at higher
frequencies. Perhaps you need to add a pulse reducer to the other side
of the capture FF. Keep the three areas independent, and you seldom
run into problems. As to your earlier ASICs, I would suspect that for
some reason the sampling rule wasn't violated. We need a bit of luck
once in a while too...
- Kelly Fromm
Packet Engines
---- ---- ---- ---- ---- ---- ----
From: "Steven Murphy" <steven.a.murphy@lmco.com>
John,
It really depends on what the rest of the circuit is expecting. In the
presence of meta-stability or clock jitter even though the input write
counter is a gray code the output won't be a gray code. However, this is
also true when the clock frequencies are different, but there may be a
hole in your pipeline logic when the clocks are similar.
I suggest doing a simulation where the clock frequencies and phases are
the same and there is a large amount of jitter on the read (or write)
clock. You will have to write a clock process that injects jitter. This
will simulate a meta-stable condition where the output can jump around.
You may want to have the clock frequencies be just slightly different so
that the phases will slip by each other and then the jitter will
sometimes cause a jump and sometimes not cause a jump in the output. You
might also try random jitter. Run the simulation a long time to make
sure all possible data relationships are hit by the random jitter.
A few things to remember: As I said above, don't expect the output to be
a continuous gray code. Be sure to delay the read pointer 2 stages
before comparing it to the synchronized write pointer so that you are
comparing the read and write pointer at the same time instance. If you
don't match the delays in the read and write pointer then you would be
comparing an old write pointer with a new read pointer. When I say 2
stages I am assuming that the register shown above that is clocked by
wr_clk is the register that is actually producing the write pointer. If
it is an additional delay on the write pointer then the read pointer
would have to be delayed an additional clock before the comparison is
made. It really depends on what you are trying to do in the end as to if
these delays are necessary.
Have you done the meta-stability calculations for the ASIC process you
are currently using? Have you allowed enough walk-out time?
- Steven Murphy
Lockheed-Martin
---- ---- ---- ---- ---- ---- ----
From: "Bruce Nepple" <brucen@imagenation.com>
John,
The circuit drawn above is certainly suseptable to errors caused by
meta-stable operation of the middle flipflop (call it D2, Q2). One cause of
Meta-stable operation is violation of the setup or hold specification at D2.
A small meta-stable window exists within the setup and hold window that will
cause the output of the flipflop to be unstable. It could oscillate, or
change states twice, or just take a long time to reach a stable value.
There is no doubt that you will get metastable operation with asynchronous
clocks. The question is how often.
The solution to metastable operation is wait a while and re-synchronize with
the same clock (as you are doing). Theoretically the oscillation can take
infinite time to stabilize, but the probability of that is infinitely small.
The longer you wait, the safer you are. If you wait long enough that the
probability of failing is less than the probability of your part failing,
then that's probably long enough. There are several good references and
past ESNUG articles that discuss this process. My favorite reference (most
practical) is:
Chaney, Thomas J. "A Guide to More Reliable Synchronizer Designs "
Technical Memorandom No. 207, January 1974 Computer Systems
Laboratory, Washington University, St.Louis, Mo. 63110
A more rigorus treatment(not so practical, for me anyway) is:
Marino, Leonard R. "General Theory of Metastable Operation"
IEEE transactions on Computers Vol C-30, No 2 Feb 1981
(good list of references though)
So, where this takes me is if you have metastability induced errors, the
time allowed to resample (rdclk period) is critical (probaility is
exponential).
If you slow down your read clock (and your write clock with it) and
the problem goes away, then it's probably due to metastability. If
you speed up both clocks, it should get much worse.
Settling time, ground bounce, crosstalk, etc can all cause what
appears to be setup and hold violations or clock violations which
cause metastable operation (clock glitches, for example).
- Bruce Nepple
Imagenation Corp. Portland, Oregon
( ESNUG 281 Item 7 ) ------------------------------------------------ [2/98]
Subject: (ESNUG 279 #1) Seeking A User-Friendly GUI Revision Control System
> I have a friend who works on a big project and would like to get a user
> friendly graphical revision control system program to manage his
> project. Does someone know any good one?
>
> - Steven Twu
> Cirrus Logic
From: [ An Engineer In Motorola ]
John,
Apparently I'm "not allowed" by my company to make product endorsements, so
please leave my name off this post.
I spent a long time looking at several such products, from RCS and SCCS,
through CVS and on to the bigger commercially-supported tools.
I chose ClearCase from Rational (formerly PureAtria, formerly Atria).
It is an extremely powerful tool, and not only does revision control, but
also build/release management and workspace management. I use it for
HDL-based chip design, and it has completely transformed our management of
that sort of work.
It's downside is that it does require a degree of admin. If you have
sysadmin or CAE resource already, then it won't add a great deal to that.
But if you are in a, "Joe-the-layout-guy-does-the-sysadmin" situation,
then Joe's going to have to do a bit less layout.
However, even given that, I would strongly recommend this tool. Put it this
way, if a group *isn't* using a tool like this, then they probably don't
have a sufficiently robust configuration management strategy. ClearCase
won't provide that strategy, but it will allow you to implement it, in a
way that things like RCS and CVS simply can't approach.
Oh, it does have a GUI, but that's for wimps :-)
- [ An Engineer In Motorola ]
( ESNUG 281 Item 8 ) ------------------------------------------------ [2/98]
From: [ A "GAD" (Grunt ASIC Designer) at Hewlett-Packard ]
Subject: LSI Tools Are Poorly Documented & Have Crappy Tech Support
John,
Better not include my name. I work directly with both Synopsys and LSI.
[ A 'CAD' at LSI Logic ] wrote about the new Module Compiler. I have no
experience with this tool, but I do have experience with many LSI tools
and Synopsys tools. While I agree that DesignTime may not always produce
the best possible design, many times the design is good enough -- epsecially
in a buisness where the fastest and smallest is less important than
quick and reasonable.
Anyway, after using both synopsys and LSI tools for a while, here are my
observations:
o In general Synopsys tools are well documented and their support web
page has answered many of our questions without having to enter a
support call.
o In general LSI tools (lsidelay, lsimemory, lsilbs) are poorly documented,
difficult to use, and the lsi web page is largely a copy of what is in
their data book, which is imcomplete. The lsi application engineers are
good folks and work hard to answer our questions, but many times I feel
like the question I have should of been answered by using the
documentation rather than entering a support call.
In my humble opinion, LSI has a long way to go towards producing well
documented usable tools.
- [ A "GAD" (Grunt ASIC Designer) at Hewlett-Packard ]
( ESNUG 281 Item 9 ) ------------------------------------------------ [2/98]
From: Philemon John Chose <philemon@engr.mun.ca>
Subject: Why Does Design_Analyzer Work Much Faster In The Background?
Hi John,
I have run optimization of my design (written in VHDL, works fine) using
Design Analyzer in the background. Why? Because it ties our machine
for at least 2 days if I execute it in the foreground. DA's graphics
aren't that involved; why does it chow so much time?
When I do a report_area, I get the following messages.
Information: This design contains unmapped logic. (RPT-7)
Information: This design contains black box (unknown)
components. (RPT-8)
The online documentation doesn't provide a solution to this. Or is it
always recommended to optimize designs in the background?
- P.J. Chose
Memorial University (Canada)
( ESNUG 281 Item 10 ) ----------------------------------------------- [2/98]
From: rramsay1@ford.com (Rodney Ramsay)
Subject: HELP! Synopsys Online Viewer "Page-Up" Gets Drunk! Very Annoying!
John,
Has anyone else experienced this strange condition with the online
documentation viewer? Sometimes the Page-Up key flips the pages one way,
but other times the pages go backwards! This is kinda petty but it's
starting to really bug me. I can handle the tooth-paste thing and the
changed-my-mind syndrome in other people but this is too much! If you
know the solution or cause of this please respond!
- Rod Ramsay
Ford Microelectronics Colorado Springs, Colorado
( ESNUG 281 Item 11 ) ----------------------------------------------- [2/98]
From: Rick Weiss <rickw@nablewest.com>
Subject: Problems Cleaning Up Dangling Gates In A Purchased IP Core
John,
In my design, I have a bunch of gates whose outputs are not being used. (A
purchased core that has functionality -- and thus outputs -- that I don't
need is a common way that I get dangling gates.) Are there any switches in
Design Compiler to tell it only to remove extra gates & no further optimize?
I tried "-incremental". I tried "-incremental -only_design_rule". But
DC always insists on further "optimizing" other logic. I added
"compile_no_new_cells_at_top_level = true"
(for flat designs), which was successful on some modules, but optimized-out
needed buffering on other modules. Any ideas, anyone??
- Rick Weiss
NABLE Technologies Cupertino, CA
|
|
