Editor's Note: Damn. I'm stuck. It used to be easy to get a Christmas
present for my parents in Vermont because they live 20 years "later" than
I do. For example, two years ago I got them a telephone answering machine.
It was a lot of fun, let me tell you, coaching them over the subsequent
months to check the machine every day. Last year I got them a microwave
oven. Again, in that timeless role reversal where children become parents
and parents become children, I had all sorts of fun patiently teaching
them how to use a microwave oven. "Ma, if you cook a piece of chicken
for 45 minutes in a microwave, you'll burn it *and* the house down! Think
seconds, not minutes." "OK, repeat after me: Metal? BAD! Paper, glass,
plastic, ceramic? GOOD! Metal BAD!" "Yea, Dad, I thought microwave
popcorn fun until I gained 10 lbs from it." "OK, what's Aluminum foil
made of? Let's say it again. Metal? BAD! Paper, glass, plastic, ... "
(What fond Christmas memories.) :^)
Anyway, it's 7 days before Christmas and I don't know what to get them.
Damn. I'm stuck. :^(
- John Cooley
the ESNUG guy
( ESNUG 275 Item 1 ) --------------------------------------------- [12/97]
From: [ "Intel Inside" ]
Subject: Initial User Impressions Of Synopsys Module Compiler
John, please no names, OK?
I am completely impressed with the Synopsys Module Compiler. You can tell
it isn't an in-house Synopsys job (was acquired thru Silicon Architects).
The language that is used to describe the operations is a cross between
Verilog and C, with a smattering of extra operands and syntax. However,
this is a small annoyance and takes a few hours to get the hang of coding.
The speed of the thing is *fast*, where compiling up a FIR or multiplier
was in the order of 2-3 minutes tops (including reports).
We evaluated it here for a "math-intensive" project I'm working on. This
tool is cool. We came up with 8 different variants of a mammoth pipelined
multiplier (*really wide*) within a week including 1 day of instruction and
a day of learning curve. Something like this would have taken months to
develop and we were able to go back to management and say "here's a matrix
of size vs. performance with our various implementations". Never saw a
manager's jaw drop so fast when we were able to provide a real close gate
count and performance eval. That really helps when the architects have no
clue as to how fast we should run our part to get the math op results back
in X time. The verilog netlist that MC spits out actually has comments
in the code where the basic operations are taking place. Way cool for
debugging! The only drawback is that I wish the input code was more
behavorial so the design could be pushed thru formal verification, assuming
that the formal tools available today could deal with it. Neato stuff.
- [ "Intel Inside" ]
( ESNUG 275 Item 2 ) --------------------------------------------- [12/97]
Subject: FSM Extraction / Synthesis with Synopsys FSM Compiler
> Has anybody compared the synthesis results of Synopsys for Finite State
> Machines using:
>
> - high-level HDL code (e.g. Verilog with casex)
> - above + extracting the FSM into Synopsys-internal format, using
> all that "extract_fsm, reduce_fsm, set_fsm_encoding, ..." stuff ?
>
> Do we get better results with the second approach or are they
> comparable?
>
> - Lars Rzymianowicz
> University of Mannheim
From: "Frederick K. Best" <fbest@slr.orl.lmco.com>
Lars,
I have not done that exact comparision, but I assume they would be the same
if you used binary encoding. Here is an example of an one-hot extraction:
/* EXTRACT FSM */
current_design = MCH_ENCODER
set_fsm_state_vector {"VISUAL_S0_CURRENT_reg<5>" \
"VISUAL_S0_CURRENT_reg<4>" \
"VISUAL_S0_CURRENT_reg<3>" \
"VISUAL_S0_CURRENT_reg<2>" \
"VISUAL_S0_CURRENT_reg<1>" \
"VISUAL_S0_CURRENT_reg<0>"}
group -fsm -design_name MCH_ENCODER_FSM
current_design = MCH_ENCODER_FSM
extract
reduce_fsm
write -format st -output ./MCH_ENCODER_FSM.st
set_fsm_encoding_style one_hot
set_fsm_minimize true
I get much better timing results in both ASICs and FPGAs when I extract the
FSM and use one-hot encoding. Of course, the area grows.
- Frederick K. Best
Lockheed Martin Electronics and Missiles
( ESNUG 275 Item 3 ) --------------------------------------------- [12/97]
Subject: How To Integrate Design Compiler Output To MAGIC Layout
> I am looking for ways to integrate Synopsys synthesis resuults with
> MAGIC. Any info regarding this will be appreciated.
>
> - Junaid Ahmed Zubairi
> International Islamic University Malaysia, Kuala Lumpur, Malaysia.
From: lager@cam.org (Athmane Lager)
Hi Junaid
For a layout in a standard cells way(raw of cells), and if the synthesised
result is in structural VHDL, you can use the MSU library(public domain and
magic layout). You must have two tools: SIS and OCTTOOLS from UCB(Berkeley).
1 -use vst2blif: structural VHDL to Berkeley Interchange Format
2 -read the resulting blif file with SIS
3 -map it to MSU library with SIS
4 -store the mapped file in octtools format
5 -use TimberWolf from the OCTTOOLS for the place and route
6 -use oct2mag to convert your layout from octtools to magic format.
Good luck.
Athmane Lager
Silicon Compiler
( ESNUG 275 Item 4 ) --------------------------------------------- [12/97]
Subject: Converting Synopsys ".db" Files to ASCII
> By using Library Compiler, ASCII source file to ".db" Synopsys library
> file can be made. How can I convert ".db" file to ASCII file?
>
> - Tetsuji Oguchi
From: rohm@cayman.engr.sgi.com (Matthew Rohm)
The closest thing to what you want is the report_lib command. I think you
need a library compiler license to actually get any useful information out.
- Matthew Rohm
SGI
( ESNUG 275 Item 5 ) --------------------------------------------- [12/97]
Subject: (ESNUG 271 #0) Learning Japanese Vs. Learning Behavioral Compiler
> ... I never knew how much of a slave to English I was until I tried to
> learn and understand the Japanese language. It hurt! It made no sense
> to me, constantly keeping track and chasing down those little words like
> "na", "ga", "wa", "no", "yo" that are sprinkled around Japanese sentances
> and that have no direct English translation whatsoever! Ugh. At night I
> would dream that I had died, gone to Hell and all the demons spoke Japanese
> to me as they tormented me. ...
>
> Last week I just finished taking a week-long course in behavioral synthesis.
> Oh, and it was simply brutal! The unnatural, sadistic things they do
> with clocking statements and loops on your source HDL defies any human
> RTL-style synthesis understanding. To make matters worst, for Synopsys old
> timers like myself, you have to do all sorts of unlearning and relearning
> on the concept (and even catch-phrase) level, too! Ugh. And all that
> additional Designware Developer bullshit obfuscates the learning process
> so much so it makes IRS tax codes seem easy, logical and friendly! Ugh!
>
> - John Cooley
> the ESNUG guy
From: Hesham El Adly <hesham@cae.ca>
Hi John,
I have to disagree partially with your statement comparing the complexity of
learning BC vs. learning Japanese.
I just presented a paper on applying BC to high performance designs at Japan
SNUG. So as an experienced BC user and as a "gaijan" returning from Japan,
a few comments:
On targeting high performance datapaths, use BC's BOA/BRT. Designers can
code in RTL when targeting BOA/BRT -- just let the tool perform the
arithmetic transforms and register placement. BOA/BRT does not require much
time to learn for RTL designers. Coding for BC's scheduler does require a
lot of effort to adjust to its required "style". BCView at least helps on
understanding the results of scheduling.
If you use DesignWare Developer, and designers must when targeting high
quality schedules, taking up Japanese is probably easier and will do more
for one's career.
Synopsys must put some resources into improving DW Developer -- it's tedious,
hard to use, and has limited reporting. I can almost guarantee that a
designer will run into problems using this beast.
As a long time BC user, I cannot see BC's scheduler being successful
commercially without Developer becoming automated. If Synopsys does not
improve Developer, perhaps they should simply offer BOA/BRT as part of
DC Expert and drop BC's scheduler.
- Hesham El-Adly
CAE Electronics Ltd., Quebec, Canada
( ESNUG 275 Item 6 ) --------------------------------------------- [12/97]
Subject: ( ESNUG 274 #4 ) Call Synopsys On-Line Help W/O Tying Up A Licence
> I don't know if this was discussed before, but a while back I got tired of
> typing the explicit path to the Synopsys On-Line help (and chewing up a
> Synopsys license just to start the help viewer). Anyway, I thought this
> script might come in handy to others; it's not much but it works.
>
> #!/bin/csh -f
> set ileaf = iview1/bin/iview
> if (${?SYNOPSYS} == 0) then
> set root = $0
> set root = ${root:h}
> set root = ${root:h}
> set root = ${root:h}
> set root = ${root:h}
> else
> set root = ${SYNOPSYS}
> endif
> set viewer = ${root}/${ileaf}
> ${viewer}
>
> It should optimally be installed in the user's ${SYNOPSYS}/${ARCH}/syn/bin
> directory.
>
> - Mark A. Indovina
> Motorola
From: "Russell Ray" <rray@msai.mea.com>
Mark,
Maybe I'm missing something with what you are doing with the online docs,
but why not just run it directly without going through Synopsys. This
method does not use the license at all. Here is what I do to start the
online documentation:
#!/bin/csh
setenv XFILESEARCHPATH .
pushd /3rdpty/synopsys_online_doc/worldview
bin/iview
popd
I run this script & the online docs startup. I've also changed the startup
points so that the synthesis page starts instead of the online doc page.
- Russ Ray
Mitsubishi
( ESNUG 275 Item 7 ) --------------------------------------------- [12/97]
Subject: Joe Costello Leaving Cadence And The EDA Industry Altogether
> My first, gut reaction to hearing the news that Joe Costello, the long
> standing CEO of Cadence, was leaving Cadence was one of saddened shock.
> ... But I can keep my machismo and at the same time publically say that
> we (note: not "I", but the royal, emotionally distancing, safe "we") will
> miss what Joe did in the EDA industry. That is, while there's always been
> EDA CEOs galore who were eager to talk to the Press about whatever issue
> of the day that was bothering them, Joe had a charasmatic knack for making
> these issues immediately accessable to the average engineer. ... Last
> year's DAC CEO panel was a true-blue sleep in. Nobody who attended
> remembered one thing that was said 20 minutes after the DAC CEO panel was
> done because it was all nicey-nice CEO-speak. Ugh. And with Joe leaving
> the industry, I fear this "safe" mindset might prevail, leaving a
> horrible, sleepy vacuum in the industry.
>
> Oh, God, I hope not. We'll miss you, Joe. - John Cooley
From: Helmut Eder <eder@Cadence.COM>
Hello John!
I read your article "An Abhorrent Vacuum", and felt compelled to write you.
I'm a senior consultant engineer for Cadence in Munich, Germany. I've been
with Cadence now for 1 1/2 years.
It is needless to say that Joe's leaving was a shock for all of us here in
this office. However, we all recovered very quickly (in Cadence style).
What Joe brought to the company, as you have mentioned, was a certain spirit
of 'unconventionality'. And the great thing is that this was not just one
of his inherent traits, but it was passed all the way through the hierarchy
down to (almost) every last employee. Because of this, I personally have no
worries about a continuation of Cadence being risk-oriented, non-linear,
and focussed -- whether it be from Cadence managers or employees. And that
goes doubly for myself!
Cheers!
- Helmut Eder
Snr. Consulting Engineer
Cadence Design Systems GmbH, Haar, Germany
( ESNUG 275 Item 8 ) --------------------------------------------- [12/97]
Subject: ( ESNUG 274 #3 ) Synopsys Products & Their Revision Schedules
> Now they are making a _BIG_ deal out of the new "PrimeTime" product.
> They admit that the timing analyzer in Design Compiler just isn't good
> enough for 0.25 micron and beyond. So they are working to fix it, right?
> WRONG, silicon breath, they are providing a _NEW_ tool for new licensing
> fees and leaving the old timing analyzer in DC.
>
> - [ You've Hit My _HOT_ Button ]
From: catapano@anasazi.sps.mot.com (Patrick Catapano)
John,
Nice HOT button letter from "[ You've Hit My _HOT_ Button ]".
oe's media
insuring that the features we currently use are up to date and that
"evolutionary" improvements (improved static timing is a good example) are
part of that money. Revolutionary features (placed-based synthesis for
example) can, and should, be price-listed.
What I'd like to see is the notion of Infra-structure in the EDA industry.
Infra-structure is NOT a line-item... no matter how a salesperson envisions
it! They have a new database for speedup and data management and <put
feature here>? Fine. It won't, and shouldn't be, in the pricelist.
Now the hard part! Convincing the EDA company that static timing in a
synthesis tool is infra-structure, as is autoplacement in a P&R tool.
I think we can convince them, btw. We were successful in removing
performance-based pricing. Remember the days when licenses for faster boxes
cost more? Turns out we COULD'VE done more chips, but, we always did ALL
the chips.
- Patrick Catapano
Motorola
---- ---- ---- ---- ---- ---- ----
From: [ Anon E. Mouse ]
John, pls call me Anon E. Mouse.
Re Comments from "You've Hit My _HOT_ Button", I feel much the same when I
read the recent press releases and brochures for Module Compiler. The
Synopsys brochures & sales pitches have always given the impression that
Design Compiler / FPGA Compiler / Behavioral Compiler are capable of (and
responsible for) synthesizing datapath logic as well as random/control logic.
So I expect improvements in synthesis of any type of logic to be ADDED to
DC/BC. If it is an evolutionary improvement, then add a small price
increase to DC/BC. If it is a revolutionary improvement, then add a
substantial price increase to DC/BC.
I suspect that the problem is that Synopsys is afraid that a revolutionary
feature won't look so revolutionary if it is tagged onto the same old
DC/BC, so they may feel the need to emphasize its' worth by marketing it
as a new tool. The problem is that this demonstrates a lack of respect for
their customer's other main cost driver: learning new tools and languages.
- [ Anon E. Mouse ]
> In 1996 we received 4 software releases. In 1997 there are going to be
> only 2 software releases: 1997.01 and 1997.08. Are we paying 1/2 the
> maintenance? No, we are just getting 1/2 of the updates. Then again,
> maybe this isn't all bad. They'll have time to test the software instead
> of having the users do it.
>
> - [ You've Hit My _HOT_ Button ]
From: landmh@taec.com (Howard Landman)
John,
I'd guess I'm a couple of revs behind. I must be cutting edge. :-)
But seriously, it takes time to catch the whole methodology up. Our library
guys in Japan should probably be using Unigen ("4.0") library format, but
they're not, because they need to rewrite all their library generation
scripts. You *can't* jump blindly on the latest rev of everything,
*especially* if you have to pay for it. HAL got burned by moving onto the
latest Mentor software too quickly -- a lot of it just flat didn't work
yet -- and they shelled out "mondo dollars" for it, too. You think Mentor
is going to give them their money back just because the software is broken?
And what little time I do have for learning new Synopsys features has
to be spent on the most important problems. For me, that means evaluating
PrimeTime and ECO Compiler.
I have no time for a new rev every 3 months.
- Howard Landman
Toshiba
( ESNUG 275 Item 9 ) --------------------------------------------- [12/97]
From: rmehler@netcom.com (Ron Mehler)
Subject: Ron Mehler's Quickie Hierarchical "Characterize" Tutorial
John,
I don't suppose I've discovered anything that isn't already well known, but
for what it's worth, here's my "characterize" tutorial I used successfully
at Alcatel. The methodology:
1: compile designs up the tree
2: characterize down
3: compile from the top for design rule changes only
A
________|________
| B | C
------ --------
| | | |
D E F G
For example, a design consisting of the above tree would have the script:
compile D
compile E
compile F
compile G
compile B
compile C
compile A
characterize{B C}
current_design = B
characterize {D E}
current_design = C
characterize {F G}
current_design = A
compile -only_design_rule
This methodology does not produce the desired results. Design constraints
applied at the top level were not applied to lower levels, resulting in
unacceptable fanout and other design rule violations.
It was decided to implement the approach illustrated by Glenn Dukes in
"Synopsys dc_shell Scripts for Synthesis Application Note" of February 1993.
Scripts were written to perform the following operations automatically on
any design hierarchy:
current_design = A
characterize B
write_script B.wscr
characterize C
write_script C.wscr
current_design = B
characterize D
etc. through the entire hierarchy... then compile from the bottom up:
current_design = G
include G.wscr
compile -only_design_rule
. . .
current_design = B
include B.wscr
compile -only_design_rule
current_design = A
compile -only_design_rule
This appears to produce the desired results, after patching them up to work
around Synopsys bugs.
David Moreland (David.Moreland@Eng.Sun.COM) also has noted that timing
constraints are not always pushed down when blocks are characterized. He
has proposed the following script to ensure that all submodules get
default constraints:
find(design,"*")
des_list = dc_shell_status
foreach (DES, des_list) {
current_design = DES
filter all_inputs() "@max_transition==0"
if (dc_shell_status != "") {
set_max_transition 3.0 dc_shell_status
}
}
Another problem we have noted here is Synopsys putting in delay lines on
flip-flop feedback lines when using clock uncertainty. To get around this
problem, an engineer here proposed adding the following script:
foreach(dummy, all_registers()) {
set_false_path -hold -from dummy -to dummy
}
and then compiling incrementally.
This appears to produce the desired results on small files, but causes
large ones to spin, more or less, forever. For now, we have decided that
we can live with those extraneous delay lines.
I invite more discussion about hierarchical synthesis on ESNUG.
- Ron Mehler
Consultant
( ESNUG 275 Networking Section ) --------------------------------- [12/97]
Atlanta, GA -- Scientific-Atlanta seeks Verilog/Synopsys ASIC Designer.
Principals only. No third party referrals, please. "jim.avant@sciatl.com"
Spokane, WA - Hewlett-Packard seeks ASIC manager/designers. HDLs/Synopsys/
Verification. RF test a plus. No agencies. "conley@spk.hp.com"
|
|
