( DAC 04 Item 29 ) --------------------------------------------- [ 02/09/05 ]
Subject: Manhattan Routing, Inc.
ANOTHER DRIVER -- Manhattan Routing 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's nearest rival appears to be ReShape.
We regularly use the Manhattan Physical Window tool. We are more of a
front end design house and we sub-contract the physical design to
outside design services companies. Manhattan Physical Window is quite
literally our only window into the physical design.
During the physical design cycle, we use Manhattan to view each
iteration of the placed DEF file. By highlighting the components
in each of the various functional blocks and looking at general
routing congestion, we can get a very good idea of the issues with
the floorplan. We have also used the tool to generate rough
suggested floorplans (placed large macrocells, and created keep-in
regions for the various functional blocks) and then generated
def output to send to our layout house. This worked well.
We are also able to highlight specific critical paths and trace them
through the layout to identify anomalies in placement or buffering or
routing. In fact we used Manhattan to find a critical bug that existed
only in a scenic route in one layer of metal. We've used it to review
pad ring assignments, power distribution grids, and clock gate
placement and clustering. In fact I have used it to highlight various
blocks in different colors and then used screen capture to generate
bitmaps that can be included in Powerpoint slides and Word files.
One of the features I wish they'd add is a built-in "Print Screen"
button that both prints and saves to bitmap files. Manhattan says
they're capable of annotating the DEF data with timing analysis data
from PrimeTime or even netlist data from the original Verilog, but we
have not yet used these features.
For the price, and in the absence of complete layout tools at companies
like ours, I think Manhattan Physical Window is a bargain and a
terrific addition to our design flow. The only bug we've encountered
with the tool in the last year was a problem reading in DEF files with
lef files that have mismatching units. The guys at Manhattan Routing
are very eager to support the tool, and provided a fix within a day or
so. In general they have been very responsive.
- Cary Robins of ChipWrights, Inc.
Working with Manhattan PW:
We worked with PW as a graphic viewer in our design environment. Our
main motivation was to better use of our P&R licenses, since before
Manhattan we were using a Silicon Ensemble license just to view/ manual
editing of a design.
Main advantages of Physical Window are:
- very fast loading of DEF database, more than X10 than loading it in
Cadence Silicon Ensemble.
- good graphics
- fast redraw
- have all needed analysis features such as:
- highlight
- find /select
- zoom to ..
- parse timing reports and see them visually.
- VERY good support
- most of the minor issues were responded in 1 day
- more complicated issues were responded to us in a timely manner
(usually few days)
- strong scripting - supports TCL/TK scripts.
Main disadvantages:
- documentation (at least few months ago) was partial so a lot had to
be learned from AEs or by "playing with the tool".
- still, you have to go out from your P&R environment, then to load to
PW, and if you are doing any manual editing (need to have the OC
license) write DEF and load again to your P&R environment. This is
compared to viewing and editing in your original P&R environment.
We found the Manhattan Routing tool to meet our expectations and above.
- Oren Katzir of Silicon Design Systems
We have been using MRI PW as a viewer, mainly loading LEF/DEF to view
design, search objects, highlights and the like. Manhattan is much
faster than Silicon Ensemble, which we used before for such purposes.
For example, loading LEF/DEF for a 570 K cells design is 160X faster
(1:30 minutes in PW, vs. almost 4 hrs in SE for only loading LEF/DEF).
Also panning and zooming through large designs is very fast, with
minimal redraw time (as opposed to SE, where it may take few seconds
just to redraw).
It also has a cool feature where you can read an external timing report
(supports several common report formats, we used PrimeTime reports),
and then highlight and zoom to paths reported in the report.
Things we didn't like - you can't keep highlights, while selecting
objects (once you click an object in order to select it, all previously
highlighted objects dehighlight); Limited ruler options. We haven't
use any of its analysis capabilities, since, as I mentioned, we used
Manhattan only as a viewer.
- Shamai Eisenmann of Silicon Design Systems
We recently taped out a very large chip at Azul Systems. We ran into a
lot of issues trying to understand complex timing issues, and then how
to represent those issues back to the logic designers. Putting a logic
designer in front of First Encounter or Astro is pretty intimidating;
and for just debugging, timing is a pretty expensive exercise in
license consumption.
We tried to use SoC Encounter, which would represent it's own data well,
but does not read the data out of PrimeTime (which we use for signoff.)
Manhattan is "format agnostic" and can read PrimeTime output as well as
CTE/FE reports from Encounter. It's also a good, lightweight and fast
interface that is not be intimidating to people not 100% comfortable
in the backend environment.
We brought in Manhattan for two reasons
1. help in backend timing debug and visualization for pure backend
purposes, and
2. present backend information & timing to the logic designers in
a more copasetic environment, without consuming very, very expensive
backend tool licenses.
It's very early days for Manhattan in our flow. (We just bought it.)
The backend team is only just getting engaged, and the tool is in
active use to debug timing problems on one of our more timing-critical
and difficult blocks. Both the logic designer of the block and the
backend engineer are using the tool to visualize and understand timing
and physical issues.
- Sam Appleton of Azul Systems
I am very impressed with its timing fix on a post-placement netlist.
Showing bad nets, bad paths, bad routes and area span analysis are
extremely beneficial for timing analysis. PW/OC abilities to update
slacks after timing fixes helped me as a guide whether further
improvement were needed. It keeps Verilog and DEF in sync while
fixing timing. Once the fixes are done, these are written out from
PW/OC and brought back in SoC Encounter. The ECO tool I used heavily
for manual fix timing.
The negative side is PW/OC does not have routing/extraction. However
post-routed designs can be easily be loaded to see where there are
violations in the design.
I understand that they have CPR (Power Router) to do manual fixes.
Since I have not used it I will not be able to comment on it. Route
analyses associated with parallel nets are very handy to identify nets
that are candidate for crosstalk.
On logical side, the Logical Cone Trace is very handy to trace entire
design through sequential, combinational and I/O pins. Designers can
see if cells are logically connected. Logic Depth analysis counts the
number of combinatorial cells between sequential elements. This helps
to see paths that are deeper than specified threshold even before
physical data available.
Overall PW/OC is a very good tool that can be used for timing fixes
after floorplanning even in post-routed designs.
- Ahmad Haque of Sandbridge Technologies
Index
Next->Item
|
|
