( ESNUG 366 Item 11 ) -------------------------------------------- [02/23/01]
From: Maynard Hammond <maynard@subasic.sciatl.com>
Subject: Customer Tells What It's Like To Use Module Compiler With PhysOpt
John,
Thought I would let you know about my experience using Physical Compiler in
conjuction Module Compiler. I am an engineer with Scientific-Atlanta. We
build set-top boxes for cable companies. One of our ASICs has a CPU in it.
Our goal has been to get this to run as fast as possible. This has not been
easy.
In our previous flow, I went through numerous iterations of dc_shell,
Primetime, rewriting source code and extracting key data path and coding it
in Module Compiler. Over several months I had a system that still didn't
meet timing goals. I wrote code to take Module Compiler's .layout and a
.lef to placed cells. My counterpart at the foundry spent 3 months hand
placing cells and routing to get the design closer to specs. When all was
said and done, we had increased the CPUs speed from what dc_shell alone
and push-button routing produced to a design that was 37% faster. This was
good but still didn't meet our specifications.
Several months ago, we started working with Synopsys and their physical
tools. Synopsys provided great support. I had multiple FAEs to help me
when problems appeared -- and they did! I went through several versions of
code. Initially, I wasn't able to read in the raw Verilog or Module
Compiler code and go to placed gates. I had problems with Module Compiler
datapath. With their 2000.11 release, these issues have been resolved.
Today I am able to go from RTL to placed gates in less than 24 hours. My
design is 67% faster than dc_shell alone and push-button routing produced.
You can view the datapath in the design! It works great!
It did take effort to get the scripts working right, though. I found out
the hard way that you can't diverge from the flow shown in the Synopsys
Physical Compiler User Guide. Initially, my flow was different (I had to
work around several bugs in the beta code). Once I transitioned to their
suggested flow, it all worked. I was forced to move our scripts to Tcl.
(Something I needed to do for a long time). I found that if I grouped the
adders, shifters, muxes, etc., from the data path in separate groups,
PhysOpt was able to produce better results. I did this by using the "rpgen"
and "group" directives. Connecting up the scan chains has also given me
some headaches. Again, following the flow specified in the Users Guide is
key. My flow is:
* read in .mcl modules.
* compile with scan ( dp_keepscan +, dp_scanmode +, dp_physical +)
* dont_touch .mcl blocks
* read in Verilog modules
* apply constraints, ungroup, etc.
* compile -scan
* remove dont_touch from .mcl blocks
* setup scan parameters
* read in physical layout
* physopt -scan_order
* physopt -inc (Physopt -scan_order, doesn't buffer scan chains as
needed)
With a 1 day turn-around, I was able to try many different "layouts" and
find what worked best. When I submit placed designs to the foundry, they
are able to quickly insert clock trees, route and extract timing. My timing
numbers from PhysOpt have always been within 3% of the extracted timing
numbers from the foundry. We will be taping out our CPU in the next couple
of months.
- Maynard Hammond
Scientific-Atlanta Inc. Lawrenceville, GA
|
|
