( ESNUG 353 Item 5 ) --------------------------------------------- [5/24/00]
Subject: Techie Physical Design Talk Overheard On The Yahoo CDN Chat Board
[ Editor's Note: Usually the Yahoo EDA stock chat boards are a sea of
anonymous letters from people pushing very obvious agendas to get a
specific stock price to change in their favor. But sometimes even a
broken clock is right twice a day. Enclosed below is a very rare
meaty tech conversation that I saw yesterday in the Yahoo CDN chat
board on the current issues around physical design tools. - John ]
From: [ Tall Thin Dude ]
I have to agree with [ EDA Veteran ] in terms of the longer term potential
for physical/logical tools.
The potential strength of Cadence or other full RTL2GDS solutions in this
area is much better than Synopsys.
Synopsys real problem is they have never been able to make any headway in
the physical backend and are instead piggybacking on Avanti for the real
block based P&R. Sure they bought a top level bus router with Everest, and
a firesale of the Gambit remains, but still no story on block designs.
When we get into dealing with real problems in the future like Signal
Integrity having a common infrastructure between frontend and backend will
allow some vendors to pace themselves laps ahead. I am involved in some
very high speed designs and the designers are panicked about being able to
control noise in 0.18 at about 400 MHZ. For future process noise, noise,
and noise, will be one of the biggest challenges.
Another key area is in achieving concurrent timing/noise closure. While we
hear stories of success in correlation between the Synopsys frontend and
backend Avanti tools the bottom line is different estimation, timing, and
routing engines never will correlate unless they are the same piece of
code. Sure we will hear of the few cases where it was "close enough".
Trust me on this one _your_ design will not be one of them.
While Cadence still has numerous timing engines (despite their vapor claims
of a common timing engine), at least the products are owned by the same
company and attempt to share some pieces of code.
Concerning all these stories about IC Craftsman and FlexRoute being the next
generation tools for hierarchical designs, I think these tools are not going
to even be players. The key issues with these tools are multiple.
One key issue (and perhaps the biggest) is the impact on Signal Integrity.
Bus routes are a nightmare from a Signal Integrity perspective and offer
little in the way of repeater insertion methodology. In terms of the noise
issue, the companies try to sell the idea that for most busses matching
characteristics are desired. In most cases a random routing as obtained by
SE is much better in terms of noise. Repeater insertion is also easier in
a random route approach.
Another key problem is that both these solutions lack true timing/noise
engine hooks and are standalone tools. They have their own db and all
constraints are pre-translated to physical constraints rather than being
able to look at timing/noise on the fly. Also has anybody out there tried
using SE & IC Craftsman together? It seems to me IC Craftsman integrates
with Opus, but on the SE side they seem to be lacking synergy. Don't know
that much about the FlexRoute but it still seems to be a mostly physical
constraint based stand alone tool.
I plan on using my current Cadence SE/DP solution. I still hope Cadence
gets their act together in getting a PKS/DP/SE flow working soon but
somehow I have a feeling it will not be soon!!
- [ Tall Thin Dude ]
---- ---- ---- ---- ---- ---- ----
From: [ nilgiri94 ]
Your concern about how signal integrity is crucial when the operating speeds
go up is well taken. I often hear people working at the back-end dismiss
any front-end physical tools which do not have a proper router or do not
take into consideration detailed physical information. Coming from the
front-end side, I find this "summary dismissal", amusing. The purpose of a
physically sensitive front end tool is to provide a better starting point
for the back-end tool; any tool which tries much more than that is offering
a solution which most front-end designers are not trained to use; and hence
will not use unless it becomes a bread and butter question.
More so, the value of a front-end tool which is "highly consicious" of the
back-end decisions, IMHO, not clearly proven. I understand why signal
integrity, cross-talk, noise considerations are important; what I do not
understand is what front-end tool needs to do to tackle this problems.
Present generation of physical front-end tools do some estimates of
congestion, top-level detailed routing etc. to get a picture of physical
design to guide them. That is an attempt to distill out enough information
to permit a hand-off to the back-end tools which is much more likely to
converge. The other option is to actually go into detailed physical desing
issues during front-end design itself. IMHO that is an overkill: the
complexity of the tool goes up exponentially, the run-time and capacity of
the tool is severly degraded; plus there is not enough evidence that it is
better to spend so much time on the integrated flow rather than go through
a few iterations of the FrontEnd plus BackEnd flow in the same time. The
last point is significant because in the real-world it rare to get a design
absolutely right the first time; iterative refinement is the norm rather
than the exception. In the present flow iterations were being driven by
timing closure; but there are a host of other considerations which drive
iterations (test, power, Clock Tree skew issue, reliability, cross-talk,
etc.) True, a truly integrated front-end plus back-end may eliminate some
of the causes; but I very much doubt if it can eliminate iterations not
because of technical causes but because of human factors. Given this "real
world" environment, I personally feel that a loosely linked flow with a
fast enough turn-around time to permit some iterations would be more
acceptable than a tightly linked one-shot flow where it would not be
possible to iterate since it takes too much time.
Of course, then there are market driven concerns (who will convert Avanti
licenses to Cadence licenses; who will convince Synopsys faithfulls to dump
Synopsys, etc...) which load the dice against the "super integrated" flow.
- [ nilgiri94 ]
---- ---- ---- ---- ---- ---- ----
From: [ Tall Thin Dude ]
The problems we have seen in the nonintegrated solution have to do with
lacking Signal Integrity feedback early in the back end physical synthesis,
and P&R. Perhaps combining RTL integration does not offer much, but
current flows are clearly lacking in providing correction at the logic
optimization and early routing stages. We found many problems could not be
fixed with detail routing alone & required iterations to early in the flow.
The lack of a tight extraction/DC/STA/Noise analysis capability were major
limiting factors in making our flow work and required the most integration
effort. Aside from the mechanics, lack of real time on the fly analysis
severly limited us in the effectiveness of each iteration and what could be
done.
Bottom line, a backend post P&R fixup as is currently offered as vaporware
by the big vendors sounds good on slides but would never have worked for us
in 0.18 um.
In most homebrew Signal Integrity flows I have seen, obtaining even a good
noise report and knowing which nets are victims involves writing out the
design in DEF/GDS, getting design LVS final routed, LVS clean, running
extraction, STA (perhaps iterate to get proper timing windows), feed all
into a homebrew analyzer. This is only for one iteration to find out the
problem victim nets. Using this flow it may take numerous iterations to
finally converge on a noise free design. If you throw other issues like
timing closure IPO iterations, antenna, this process can easily take months.
If you look at any available "Signal Integrity Options" beware to read the
fine print. Most are overpriced vaporware. While there is some truth that
setting them up is difficult and justifies a more expensive option, in most
cases I think the big price tag is to scare away potential users until the
solution actually (if ever) works.
Also be sure to see if and how the "Signal Integrity options" will work with
and integrate to your other point tools, libraries, and data files. Below
are the point tools I have seen in most homebrew Signal Integrity flows.
o) Synthesis (Ambit BG, DC)
o) Floorplanning (DP, Apollo, Aristo)
o) Advanced routing (ARO, DP, ICC)
o) PhysOpt Saturn, PKS, QPopt
o) P&R (SE, Apollo)
o) Extract (Star-RC, QP, Hext, Simplex, Columbus)
o) Delay Calc (Ultima, CDC, Pearl, PrimeTime, proprietary in house)
o) STA (Ambit, PrimeTime, DC, Pearl, QP, Motive)
o) Noise Analysis (Cadmos, Simplex, Apollo)
If you think putting together such a flow was easy, think of how much
hacking is required just to even make tools from the same vendor work
together in a flow :-)
Given the progress of the big three, I think I will be finding many future
contracting opportunities when sub 0.18 um becomes mainstream.
- [ Tall Thin Dude ]
---- ---- ---- ---- ---- ---- ----
From: [ nilgiri94 ]
I empathize with you regarding the problems you guys are facing. So many
different tools from so many different vendors must be hellish.
I guess it all boils down to whether you can model UDSM effects at a
high-enough level so that they can be addressed early enough in the design
flow and cut down on the iteration you can need to go through. As you
mention, the current tools are nowhere close to achieving that even at the
physical level; forget about modeling the effects dynamically or at a high
level. Cadence is better positioned in this area than Synopsys due to their
back-end expertise. However, this is a challanging, if not an infeasible
task; plus the market window of opportunity is not too large. I am not
aware of how the dynamics inside Cadence are, but I am curious to how much
are the back-end folks willing to yield to the newer front-end guys (Ambit);
it would require a very well focused, synergistic effort to get this to work
well. It has to work much better than the Synopsys solution to be an
effective challanger. Unless Cadence comes up with something good and fast,
the Synopsys front end domination may lead to their Physical Front End
domination also.
This gap in the capability of tools will lead to a greater value to
experience and good engineering decision-makers (and I guess will make you
rich).
- [ nilgiri94 ]
---- ---- ---- ---- ---- ---- ----
From: [ firfilter ]
You smell like a Cadence consultant, [ Tall Thin Dude ]. This is obvious
from the way you order your lists:
> point tools I have seen in most homebrew Signal Integrity flows.
>
> o) Synthesis (Ambit BG, DC)
> o) STA (Ambit, PrimeTime, DC, Pearl, QP, Motive)
knowing that 90% of designers can't even spell Ambit...
- [ firfilter ]
---- ---- ---- ---- ---- ---- ----
From: [ Tall Thin Dude ]
I am in not a Cadence employee, but I do end up doing alot of consulting
work around Cadence tools. It seems the Cadence tools need the most "glue"
to put together a working flow.
I am continually amazed at how the Cadence Sales droids try to sell their
collection of non-integrated point tools to customers making it sound like
you can buy them all and use them together. I love to hear "we just bought
DP, SE, PBopt, PKS, and OPUS", Cadence is going to send somebody out to
show us how to use the "flow". I just leave them my card and say "call me
if you need any help".
We all hear the marketing crap. "We will take the best features of all the
tools and merge them together into a super duper nano genesis flow".
Translated: "We will put together an ugly file translator system behind the
scenes to make it look like the tools share a common database/timing engine,
we will encrypt all the hidden files so if we corrupt the data along the
way, the user will not know. We will pray that the vapor story will delay
customers from purchasing other solutions until we can aquire and kill some
more new technology when we fail to deliver. If you do have somebody that
knows how to integrate the tools into a working flow, please let us know,
cause we don't."
So as you can see, I believe Cadence has it's issues, too. Many of the
customers in the most pain are Cadence customers. Avanti has done a much
better job of wrapping together its point tools in a more seamless flow.
Because of the legal/ethical issues with Avanti, many people are stuck with
Cadence flows. To be honest, after Costello left and the heirs "sold out
the company", I have my doubts Cadence is any more ethical. In any case
this means more glue business for me.
I still doubt Synopsys will be able to enter the backend area and be able to
recruit good people in this area. The internal politics of a company with
front-end guys in all the upper managenent levels conflicts with this goal.
Front-end guys (don't get me wrong their intentions may be good) will not
understand and appreciate the difficulties in backend. When things don't
go well, the back-end guys will take the fall. When rewards are handed out,
the front-end guys who are visible to management will reap the rewards.
Eventually any good back-end guys will go to a company "where they are
appreciated". This is just the fact of life in a front-end company.
- [ Tall Thin Dude ]
|
|
