( SNUG 03 Item 10 ) ---------------------------------------------- [05/14/03]
Subject: Behavioral Compiler, Module Compiler, Power Compiler, ECO Compiler
LAZARUS REVISTED: It didn't surprise me one iota that Gary Smith reported
that the entire 2001 behavioral synthesis market was only $2.5 million.
Behavorial Compiler has been fading away for years in ESNUG. Gary's 1999
to 2001 numbers just confirm what we users already knew. What caused me to
laugh last week was Gary's crazy ass prediction of how the behavioral
synthesis market is going to make a vengeful comeback.
Dataquest FY 2001 Behavioral Synthesis Market Estimates (in $ Millions)
1999 ########### $10.5
2000 ######## $7.8
2001 ### $2.5 <----------- YOU ARE HERE NOW
2002 ### $2.5
2003 ##### $5.0
2004 ############ $12.0
2005 ######################## $24.2
2006 #################################### $36.0
So in 5 years, according to Gary's market trends report, this market will
grow almost 15x. I called him on this and he replied:
"The second generation behavioral synthesis tools failed as did the
first generation. They had no language standard and limited
control logic generation ability. Synopsys did the best job it
could for this, but once you get into a datapath heavy design,
Behavioral Compiler broke.
Behavioral synthesis is going to come back for three reasons:
1.) We have a standard language in SystemC.
2.) We're in the middle of a crisis of design complexity and
the power users are screaming for higher level tools.
3.) Once we get the planning & estimation tools fully debugged,
we'll be able to check the QoR of the SystemC behavioral
synthesizers.
I expect this to be real by the end of 2004."
- Gary Smith, Chief EDA Analyst at Dataquest
In short, he thinks that SystemC will be why behavioral synthesis makes its
comeback. Ask me and I'll tell you that Gary was obviously smoking some
world class ganja when he wrote this! My gut says that Behavioral Compiler
will die off because its functionality is already being absorbed into
DC-Ultra and that Module Compiler will neither grow nor shrink much. But
hey, I could be wrong on this one.
On the power optimization front, Power Compiler and Sequence's Wattsmith are
the only two tools in town.
Dataquest FY 2001 Power Reduction Synthesis Market Share
Synopsys ################### $9.2 (81.4%)
Sequence ##### $2.1 (18.6%)
There seems to be a lot of user interest in anything that can help cut power
consumption in chips, so this market will probably grow considerably over
the next few years. The increased number of attendees at the SNUG'03 Power
Compiler sessions also confirm this.
On ECO Compiler, there's noticable user interest in reviving it, but whether
its financially viable for Synopsys to do this is another question. If
PhysOpt/DC/Astro significantly speed up their run times, it would kill off
any need for a reincarnated ECO Compiler. It's all about run times here.
"We have no need for Module Compiler or Behavioral Compiler, and I've
never seen their benefit. We don't use Power Compiler but we've
evaluated it. Clock gating doesn't work well in our vendor's flow
currently."
- Lance Flake of Maxtor
"Will be purchasing Power Compiler soon. Would like to try BC, but no
time or bucks."
- Ross Swanson of Flextronics
"Power Compiler. They shouldn't charge for this. It should be a
feature of DC at no charge. It saves you some power (little), but it
gives you lots of headaches in other parts of the design: timing, clock
generation, placement, libraries (new gating cells), handling of
neg-edge flops, and I guess also in DFT."
- Santiago Fernandez-Gomez of Pixim, Inc.
"We have some experience with Power Compiler, and we feel that it is a
useful tool. The RTL clock-gating feature, and the power optimization
flows for Dual Vt libraries are all useful. The only pain is Power
Compiler's restriction as far as integrated clock-gating cell models
are concerned. All models have to conform to Synopsys' template,
otherwise these cells cannot be used as intended in the Compiler suite
of tools. Our hope is that Synopsys will allow any type of integrated
clock-gating cell model definition, and these models can be understood
by all their Compiler tools."
- [ An Anon Engineer ]
"Our designs aren't really focused on algorithms, so I didn't perceive
an advantage to MC or BC. Power Compiler might be helpful if it works
well. I don't know if we ever used ECO Compiler."
- [ An Anon Engineer ]
"We tried Power Compiler on a design of about 300 K gates. It ran for
several days and died."
- [ An Anon Engineer ]
"MC is a good tool, but has severe limitations, especially w/ simulation
and formal verification. Synopsys needs to put some serious effort
into upgrading and enhancing MC, and integrating the data path
capabilities into DC using standard Verilog or VHDL. Better support
for preserving partial sums, resolve latency that doesn't abort if MC
doesn't think it can make the specified number of stages. Handling all
of this transparently using dual engines within DC would be a great
solution. It's also the way all the other synthesis engines have been
going -- Ambit, Get2Chip, Magma, Monterey.
Power Compiler, at least the clock gating aspects of it, are excellent,
and save us a great deal of area, along with some cycle time. Resource
isolation is generally not used, and is of marginal value, unless the
resource will be idled for a long time. Power Compiler also should
give DC a leg up in mixed Vt synthesis.
ECO Compiler was definitely a good idea. I think the development team
was given an impossible task of having the handle any arbitrary ECO.
Most ECOs late in the game, when this would generally be used, are
modifying particulars within a state machine, or modifying control
equations. It should have been acceptable to report that an ECO was
too difficult, and require resynthesis/P&R. ECO Compiler, tied in with
Formality, and PhysOpt would have been an incredibly powerful
combination, and saved the design community huge amounts of time."
- [ An Anon Engineer ]
"Module Compiler and Behavioral Compiler are a great idea, however they
need more tools backing them. Where is the formal verification? Where
is the Debussy? Where is the... (OK, it has been a few years since I
looked at either of them.)
Power Compiler is a good idea, but I need to get the function correct
first. By that time I am usually out of schedule time to even consider
looking at power. Also, in my mind, power conservation usually means
sacraficing chip timing by stretching the timing to the limit, which
means that timing margins become tight at LOTS of places, rather than
just a few critical paths. This means more timing analysis, which
means more schedule... Also means that if a fabrication fault slows
a path, there is a larger chance that it becomes critical, so likely
yield will take a hit. (Actually, yield takes a hit in our case
because we run LogicBIST at-speed or 90% on some blocks.) In slower
clock SCAN testing this would mean that a bad part gets to customer
== returns, or system fault at some future time.) I think the odds are
higher when LOTS of the timing is at the edge.
Do I miss ECO Compiler? Well, it was never able to handled scanned
netlists very well, and it's capacity was not too big. I loved the
concept, and it did work the few times I tried it on no-scan netlists.
For my current ECO, I planned to try it again to see if it improved
over the years, and lo-and-behold it had been cancelled. I got an
old license to see if I could use it as a 'gate-comparitor', but
again capacity is an issue, and I could not get it to spit me a
dc_script of what if saw the differences as. I think we need
something to replace it, but that works for scan and large blocks.
Anything out there?"
- Bob Lawrence of Agere Systems
"Regarding your question on ECO Compiler, YES, I do miss it certainly.
And most surprisingly none of the EDA vendors are offering a similar
tool. It seems now a days the definition of ECO has changed (even for
Synopsys.) They all talk from the viewpoint of doing ECO in the
netlist stage (as in PhysOpt) but not the way ECO Compiler used to do
that (rtl to netlist).
ECO Compiler used to do it like compare oldRTL-vs-newRTL, get the logic
cones which are different and apply that to an oldGate-vs-newGate
comparison. The output was an ECO-ed netlist. We have used it and got
benefits from it during our metal ECO respin thus saving us $$$ as well
as design cycle time.
If you remember, in the SNUG'02 keynote address this issue was raised
and Aart said "they will reinvestigate this" and in future it may come
out of end-of-life. We are still waiting!"
- Indranil Ganguly of Fujitsu Network Communications
"Isn't Module Compiler dead? Or at least the great pieces of its
functionality (BOA, BRT, etc) are integrated into Synopsys
DC Super-Expert-Ultra-Plus-Whiz-Bang?
I wish that SNPS would announce an ECO Compiler ressurection of a
formidable tool that links in DC and PhysOpt capabilities all while
utilizing the Milkyway database technology. That's truly a need not
solved, especially in the sub .15 um, high transistor count designs."
- Gregg Lahti of Microchip
"ECO Compiler may be a good idea."
- Rex Tung of InProComm
"We got PhysOpt as part of a package deal. It allowed significant
power reduction when used together with Power Compiler."
- [ An Anon Engineer ]
"Session 2 - 10:45 - 12:00 - Leakage Power Optimization Using Power
Compiler and Multi-Threshold CMOS Technologies
Basic idea is to compile the design with a mixture of high and low Vt
cells. Low Vt have higher leakage than high Vt. Low Vt (fast) cells
for critical paths, and High Vt (slow) cells for non-critical paths.
Power Compiler would do that for us (ain't nice this Power Compiler?)
Then he goes into several benchmarks to show the reduction on leakage.
None of the benchmarks are convincing, as they have flaws in their
basic assumptions.
Q. Does PhysOpt optimize timing, and it forgets about power-optimizing
non-critical cells?
A. Let's discuss that off-line
Lots of questions in this session. Mostly shows that Synopsys didn't
make a good case here."
- Santiago Fernandez-Gomez of Pixim, Inc.
"I want a replacement for ECO Compiler. Module Compiler and BC are
useless. Give me System Verilog any day."
- [ An Anon Engineer ]
"Will be investigating low power design, and clocktree synthesis issues.
And obviously Power Compiler will be one area of investigation. No
comments at present."
- Alan Duffy of Motorola
"Module Compiler is good in what it can do, but the creating process of
libraries for MC is extremely painful. I hope there is a simpler way
to do it. ECO Compiler should definitely make a come back in one
format or another. It should definitely be equipped with not just
functional ECO capabilities, but also physical location knowledge."
- [ An Anon Engineer ]
"Module Compiler? Behavioral Compiler? They are dead. I tried both
Compilers when they came out years ago, but nobody is actually working
with them now.
Power Compiler: clock Gating will be a must! The power optimization
feature - as far as what we have seen so long - takes too much time
for bigger designs, thus I'm not sure we'll switch it on by default."
- Markus Schutti of Infineon
"Don't have the need for MC or BC. Power Compiler is useful and ECO
Compiler is something that I am glad it disappeared since I am a much
bigger proponent of proper verification instead of an iterative
approach that ECO Compiler might encourage."
- Gregg Shimokura of STMicroelectronics
"Behavioral Compiler is awful. We have used it for several years,
and we have had lots of issues. It does take the original coding and
changes to that code more efficient, but you lose lots of that in the
physical design issues. It's pretty hard to rewrite BC code to make
it routable, while you at least have a fighting chance with RTL code."
- Curtis Jones of Hewlett-Packard
|
|
