( DAC 03 Item 37 ) ----------------------------------------------- [ 01/20/04 ]
Subject: Manhattan Routing, Inc.
DRIVEN: One newbie this year was Manhattan Routing, Inc. Other than a
clever name, MRI sells what I can best describe as a "driver" for backend
designers. It lets you look at your LEF/DEF output, reads the timing
reports, and lets you find the problem and then lauches the Cadence backend
tool you were using to fix that problem.
Manhattan Routing, Inc. sells a debugging tool that is intended to bridge
the front end and back end. It takes logical data, physical data and a
timing report and helps designers correlate all three. For example, it
can help fix bad repeaters. The tool keeps Verilog and DEF in sync as
you fix problems. It can correlate hierarchical Verilog to flat DEF
(hierarchical DEF is coming). It can also do clock analysis.
- John Weiland of Intrinsix
I have been using Cadence Silicon Ensemble and the Manhattan Physical
Window/Optimization Cockpit on my current project. I have not seen
other tools that works well with our in-house libraries based on Cadence
DF II. I work with MMIC mostly, which require delicate manual
treatments for analog blocks to go into.
When my expensive Cadence SE licenses are tied up for routing, I use
Manhattan OC to view the routing progress. If my routing has problem
due to cells or floorplan, I could modify in OC on the fly, write
updated data and continue routing.
I am still a novice user; haven't fully utilized their Optimization
Cockpit or Clock Analysis capability.
- Michelle Lee of Guidant Corp.
Let me describe the Manhattan Physical Window/Optimization Cockpit
presentation from two perspectives.
First, the advantages that were described were interesting. The basis
for the PW/OC tool was to operate in a more efficient way -- that is to
use the P&R tools in a batch flow (where they were intended to run) as
opposed to a "viewing" or convergence flow. In these flows, using a
$200K+ P&R tool to "see" where timing problems are introduced is not
cost effective. The Manhattan tool provides a low cost way to annotate
timing (PrimeTime, Pearl) info into a viewer that can show the physical
implementation problems, especially on critical nets. This can be
distributed to a number of engineers (something you cannot do if you
have a limited number of P&R tools) to work concurrently on solving
problems without tying up P&R capacity. I thought this had merit.
Another aspect that has value is the ability to send a view of the
physical domain to others for informational purposes. Examples of this
are sending a viewer along with the LEF/DEF info and timing files to the
architect or to management to identify progress, problems and such
related to timing closure for example. Strong ties to with a schematic
and Verilog display would be beneficial here.
On the negative side, there are no capabilities to edit the routes or to
verify them. This editing capability would enable independent
convergence flows and solve a problem seen by higher-end ASIC designers.
Another issue is the competition. There can be efforts that extract
this capability from existing tools like Apollo, Silicon Ensemble, First
Encounter, SoC Encounter, and others that would provide other
advantages. I think the price point would be too low for the big guys
to consider doing this though. From the PC viewpoint, viewing placed
gates is not that interesting unless there is a floorplanning issue to
address.
Overall I think there is value in this tool.
- Richard Nordin of Silicon Design Systems
I did visit Manhattan and took a Physical Window/Optimization Cockpit
demo. I'm not qualified to compare it to other viewers, but I can tell
you I thought it was one of the better demos I've seen in a long time.
- Rich Davenport of Provis Corp.
We use PKS as our synth-opt and viewing tool, so I can give you my
impressions of Physical Window/Optimization Cockpit (PWOC) vs. PKS.
It's been a while since I've analyzed Physical Window/Optimization
Cockpit, but there are some key strengths that I remember and took
notes on. The way Physical Window/Optimization Cockpit analyzed the
timing slack numbers and categorizes the timing problems into bad nets,
bad paths, bad cells, and bad routes is a real standout feature that I
think would save design time (I know I'd like to use it on my own
designs).
Our current backend design flow is that we do the RTL and pre-placement
synthesis and timing closure, then we give the gate netlist to our
process vendor for placement and final timing closure. For that flow,
Physical Window/Optimization Cockpit is a great tool because it lets us
work better with our vendor when post-placement timing issues come up.
We currently use the PKS viewer to read DEF and SDF files to take a look
at critical timing paths, then we figure out why the paths are a timing
problem.
Another strength of Physical Window/Optimization Cockpit is the timing
fix analysis. I like that we can take a post-placment netlist, look
over the timing violations, and run fix scenarios. Once we have a
potential fix, we would forward that to our process vendor and show them
a potential solution.
There is a clear advantage to using the Physical Window/Optimization
Cockpit tool in our design flow. In our flow, we aren't using much of
the power of PKS. Cadence Ambit would do the same job in pre-placement
synth-opt. The benefit that PKS gives us is the ability to view the
design and stay in sync with the engineers doing the placement and final
timing closure. We would have a much more cost efficient solution and a
better viewer with an Ambit/Physical Window/Optimization Cockpit
combination than we do with PKS.
That said, I'm pushing to get more of the backend design work done in
house so I don't want to get rid of PKS. I want this design group to do
the floorplanning and initial placement and post-placement timing
closure to take time out of that feedback loop.
Those are my thoughts on Physical Window/Optimization Cockpit. I think
it's a nice design tool and I've asked for it as part of our tools
suite.
- Alan Danielson of F5 Networks
I like Manhattan Routing's enthusiasm and persistence and youthful
exuberance, but that does not amount to much technical credibility.
People seem to like what they do in our shop... quite a bit.
- Naeem Zafar of Silicon Design Systems
I found the Physical Window/Optimization Cockpit to be an invaluable
part of the floor planning flow. It actually would enable me to lay
down the cells myself, but I didn't do this. I specified placement of
the I/O pads, analog IP, and critical cells the way I usually do, (in a
layout guidelines document), but then was able to view the actual
results to decide if I was happy with them. If I wanted a piece of IP to
be pushed over a bit, I could identify the exact coordinates I wanted
and give very specific instructions to the Manhattan guys.
I also like to place certain cells close to the I/O, or group certain
cells tightly, and it was a simple matter to pull up these cells, check
their placement and even trace the nets associated with them to make
sure all cells that were part of the critical circuits were placed
appropriately. After floorplanning, I was able to view the results of
each placement by highlighting cells from each of the functional sub-
blocks in different colors. From this, we could correlate steering the
placements and keepouts to the routability and resulting timing. We
ended up specifying regions for a large number of the sub-blocks, and
contrary to what you'd think, this ended up working better even with a
timing driven placement flow. Instead of oscillating on placement
requests, or even worse, having no feedback at all if the requests were
followed, we were able to converge quickly and accurately. The tool
also provides a capability for tracing critical timing paths across the
layout and looking at the delays on the subnets. This information is
also available in the Primetime reports but using the graphical
interface made it painfully clear where the problems were.
However, I cannot speak to the fact that this may be general goodness
associated with all of the tools you mention and not specific to
Manhattan Routing's tools. I am wildly enthusiastic about the value of
this category of tools. As far as a rational view of the tool compared
to other similar viewing tools in other categories, I would say that it
is not the most intuitive tool I have ever used, and I did require some
help from the Manhattan guys. But on the other hand, I never opened the
manual and got done what I needed to. Their scripting interface that
allowed me to open the chip in a particular state and with particular
cells highlighted in various colors each time was a nice touch. The
fact that this highlighting wasn't sticky was a little annoying. I
think this may be the best I can do for you but if you have other
specific questions feel free to ask.
- Cary Robins of ChipWrights
I did in fact get a chance to see the Manhattan products in action at
the DAC convention in Anaheim. I cannot comment on how well their
Physical Window/Optimization Cockpit, CA, and CPR tools stack up to the
latest P&R tools without doing some sort of evaluation. But I was not
looking at the Manhattan tools to compete directly against those
markets. I believe the real value in the tools is the flexibility it
offers to the design team. These tools are designed to work on multiple
platforms, which is great for eclectic computing environments. Their
tool suite can also support designs employing different combinations of
front-end and back-end engines while retaining a common work environment
which looks and feels the same every time you use it. I was not only
quite impressed with the user interface GUI that Manhattan has created
for their product but I really appreciate the ability to stay within one
environment for data input, clock analysis, power routing, placement,
and routing.
Of course this is my opinion after viewing the product demo and does not
reflect any hands-on evaluation.
- Peter Van Hoesen of Texas Instruments
The Manhattan Physical Window/Optimization Cockpit suite follows a
similar concept that Synopsys PhysOpt does; get the tools into the
engineers' hands so they can solve the issue. Although the synthesis
flow is "blind", i.e. schematics are not usually used, Manhattan's
Physical Window/Optimization Cockpit adds visibility into what the
front-to-back end tools are actually doing.
Their Physical Window shows the engineer why certain routes are not
meeting timing. Systematic problems can be quickly countered, or
specific timing paths can be closed quickly. The Optimization Cockpit
interfaces with most of the typical industrial tools to provide timing
correction and closure.
The Physical Window/Optimization Cockpit tool that was demoed was very
fast. It could read the data and display it very quickly. The tools
looked very easy to install and use. We were more interesting in the
Window tools. Their Clock Analysis option had appeal, as we struggle
with clock trees on about every design. The Power Routing looks like a
good tool, we do not have that many issues with power at the moment.
Their ECO tool looked very appealing as well as we had been doing most
ECOs manually.
The cost was also low so that the tools could be affordable. We would
probably use just a few of the Physical Window tools and probably just
one of the OC tool.
- Steve McKinnis of Texas Instruments
I've just had my first chance to use Manhattan's Clock Analysis on a
very messy customer netlist. Although they claim to be open enough for
other tools, but I've only used it with Cadence's Silicon Ensemble
environment.
The bottom line is it can help you analyze a messy clock tree to build a
CTGEN constraint file. It will take the I/O pin, and track down
crossing paths, leaf pins issues, etc. It will list the bad paths, but
I still find myself bring Debussy up to decide what to do with the
problem. (They claim a future version will interface with Debussy.)
The interface is still a little messy, but getting better in the last
few versions.
Although I found a few bugs, its much better than run CTGEN, wait 15
minutes till it fails, fix one problem, repeat...
I'm actually more interested in trying out Manhattan's Optimization
Cockpit, which fits around the rest of the Silicon Ensemble flow. Does
all kinds of histograms, and I thought the ECO hook looked pretty slick.
Having seen someone in our group spend several days hand swapping a 16
bit register from negedge to posedge, this feature would have saved us
much time.
- Jay Wasserman of Analog Devices
I am currently using Manhattan's Optimization Cockpit but my use is
minimal at this time. I can say, thus far, that I am very impressed
with its capabilities and user friendliness.
- Scott Gannon of Analog Devices
|
|
