Editor's Note: OK, I've got to admit it. Earlier this week I was sooooo
proud of myself for managing to switch ESNUG over to majordomo without
anyone's help. Cool. It was classic Lone Wolf engineering: me, the
documentation, and a UNIX prompt -- and I it conquered all! "John, you're
good. You're *really* good.", my inflated ego told myself when my final
test ESNUG post went out without a hitch. Cool. Cool, that is, until God
decided it was time to remind me of my place in the Universe....
Remember that Vonnegut/MIT Commencement speech I sent with my proud ESNUG
test post? Well, it turns out that I am the only person left on the
planet who didn't know this was a hoax. Vonnegut never wrote the speech
and he's never even spoken at MIT! That "speech" was written by Mary
Schmich, a Chicago Tribune columnist, in a column about how easily hoaxes
are propageted on the Internet. (I just *love* the irony here...)
How do I know this? Within 48 hours of sending out that proud test ESNUG
post, I received 116 replies from my engineering peers informing me "Uh,
John, you've been snookered. That speech was a hoax and it has even been
reported as such in the newspapers for about 3 weeks now. Where have you
been for the past month?" To add insult to injury, 6 of these e-mails
came from engineers in India -- guys 10 Time Zones away who knew more about
what was really going on at MIT than I did. (And I live less than 20 miles
from MIT!) Kurt Baty phoned my home and left on my answering machine
"Hi, John, this is Kurt Baty. You're guilty of commiting Internet garbage
reproduction. Read my e-mail." Even Joe Costello, the CEO of Cadence
(who, over the years, I'll admit, I've exchanged more than a few choice
words with) took the time to (gleefully, I'm sure) inform me of my "error."
<Aaargh! Even *JOE* caught me on this one! Aaargh!>
So... if you're serving up Humble Pie, make mine a BIG piece with some
majordomo documentation on the side. Just make sure it's a really BIG
piece. <Damn!> :^)
- John Cooley
the ESNUG guy
( ESNUG 263 Item 1 ) -------------------------------------------- [8/97]
Subject: (ESNUG 262 #4) Tell Me Names! *WHO* Is Using Behavioral Compiler?
> "How come there were no papers on Behavioral Compiler at SNUG'97? At the
> Applied Behavioral Compiler Tutorial (which was _excellent_ btw) they
> mentioned about 50 companies worldwide using BC. Yet only one chip taped
> out so far! How can this be? Do companies really spend $150K on a tool
> and then not use it? Does it really reduce the time to market?"
From: [ Thinking Of Jumping ]
John, please have me be anon because I don't want my boss to know I'm
thinking of jumping.
Yes, there really _are_ companies that shell out the big bucks for BC
and not use it. I interviewed recently at General Instrument, and the
manager was impressing on me the fact that they are one of the most
EDA-rich companies around. They had loads of DC licenses, Test
Compiler licenses, simulation tools, and BC. I was surprised, since I
had never personally met somebody who used BC, and asked how what
their results were with it. The reply was "well, nobody has actually
done a design with it, but we have it" Turns out that no designer was
comfortable compiling a design with BC since they felt they couldn't
really control the results. Until that attitide changes, I doubt BC
will be a success. Here, our company's attitude is, "well it looks
great, but for the price we'll wait and re-evaluate if it starts to
catch on in the industry." It surely hasn't yet.
- [ Thinking Of Jumping ]
---- ---- ---- ---- ---- ---- ----
From: David Barda <davidb@vast.unsw.edu.au>
Dear John,
I do not believe the synopsys advertisements about the performance and
results of its behavioural compiler.
- David Barda
CAST laboratory
University of New South Wales
---- ---- ---- ---- ---- ---- ----
From: "Victor Duvanenko" <victor_duvanenko@truevision.com>
John,
I've been eye-ing Behavioral Compiler (BC) for the last 3 years, and
have just been through training on BC. However, I'm still not convinced
that a clear productivity gain (or coding reliability improvement), as
there is with Design Compiler, which I've been happily using for the last
5 years. This uncertaintly may just be due to the domain of my design
space. Would any BC users share there experiences and thoughts of
applicability of BC to their design domain?! I have seen the David Black's
of Apple example in Synopsys's "Impact!" mailer, but would like to here
more specifically and in all of their goury technical details where BC
helped a user over RTL design methodology! I would also love to see
positive and negative comments about BC.
- Victor J. Duvanenko
Truevision
---- ---- ---- ---- ---- ---- ----
From: ANTONIO@atitech.ca (Antonio Asaro)
Hi John,
Help!!
I'd like to know what you think of BC (Synopsys's Behavioral Compiler). Our
Synopsys rep has been touting the tool as the "wave of the future" - the
analogy being how language compilers reduced/eliminated the need for
low-level assembly language. They've gotten all sorts of software-type guys
aroused who now think they can design hardware!!
- Antonio Asaro
Atitech
---- ---- ---- ---- ---- ---- ----
From: Dwayne Bennett <Dwayne.Bennett@Matrox.COM>
John,
Up until just recently I worked at HP. I used the BRT feature of Behavioral
Compiler on a design we called "OX" which was subsequently signed-off in
Nov/96.
My experience with BRT was very positive. I had a circuit which needed an
extra stage, but adding this extra stage would have seriously affected
performance of the circuit and this could not be tolerated (the chip was
for a giga-bit Fibre Channel Switch and operated at 53Mhz.) The solution
was to better make use of the stages I had by optimally placing them along
the critical path. Unfortunately this path involved indexing into arrays
and so changing the placement of stages in verilog RTL would have been a
mess and would have been time-consuming. This is when I turned to BC. The
change to the synthesis script was trivial; I just added the command
"optimize_registers" and let it run. It resolved the problem and the
circuit was able to meet our timing goals. The cost in gates was minimal.
I might add that a change to the verilog not only would have taken up my
time, but also would have forced a slew of regression simulations to have
to be re-run. I think it is clear that BC/BRT saved me significant time
and effort.
- Dwayne.Bennett
Matrox
( ESNUG 263 Item 2 ) -------------------------------------------- [8/97]
From: kurt@wsfdb.com (Kurt Baty)
Subject: DC w/ DesignWare Builds Incorrect Logic Via Bad Parameter Passing
John,
Public service warning!
Synopsys builds incorrect logic by passing parameters incorrectly to
DesignWare library parts. This bug occurs in at least Revs. 3.4b
and 1997.01 of Design Compiler. This bug occurs when Design Compiler
is passing the parameter to a DesignWare library part, not when you're
using a DesignWare part locally nor when you're using a template part
locally. (If the parameter problem occured on a port width, Design
Compiler will inform you that you have a port width mismatch. )
I use a lot of instances of DesignWare parts in my designs because they
save me lines of code, thus making my time more productive.
I found this bug using my own DesignWare part, which is in the libary.
This bug has been assigned to the HDL Compiler, the "read -format
verilog" command.
parameter j = 'h1f;
parameter k = 8'h1f;
// working cases
DW03_reg_s_pl #(8,31) xgood1(data_in,clk,!reset,wr,good1);
DW03_reg_s_pl #(8,'h1f) xgood2(data_in,clk,!reset,wr,good2);
// parameter passed as 31
DW03_reg_s_pl #(8,j) xgood3(data_in,clk,!reset,wr,good3);
// parameter passed as 31
test_reg_s_pl #(8,8'h1f) xgood4(data_in,clk,!reset,wr,good4);
// local DesignWare part works
flop #(8,8'h1f) xgood5(data_in,clk,!reset,wr,good5);
// local template part works
// not working cases
DW03_reg_s_pl #(8,8'h1f) xbad1(data_in,clk,!reset,wr,bad1);
// parameter passed as 8! NOT 31 !!!
DW03_reg_s_pl #(8,k) xbad2(data_in,clk,!reset,wr,bad2);
// parameter passed as 8! NOT 31 !!!
DW03_reg_s_pl #(8,7'h1f) xbad3(data_in,clk,!reset,wr,bad3);
// parameter passed as 7! NOT 31 !!!
DW03_reg_s_pl #(8,9'h1f) xbad4(data_in,clk,!reset,wr,bad4);
// parameter passed as 9! NOT 31 !!!
DW03_reg_s_pl #(8,10'h1f) xbad5(data_in,clk,!reset,wr,bad5);
// parameter passed as 10 NOT 31 !!!
It appears the Synopsys parcer is using the first integer it sees!
- Kurt Baty
WSFDB Consulting
( ESNUG 263 Item 3 ) -------------------------------------------- [8/97]
From: [ A Synopsys DC CAE ]
Subject: Tips In Managing Runtime W/ Design Complier NOT IN DC 1997.01
John, here's a tip that users won't find in the DC 1997.01 release that
they should know about.
At times, designers would like Design Compiler to bypass the area recovery
or downsizing steps. This can be useful when designers are exploring their
design architecture in the early stages of their design cycle. With the
interim release of DC 1997.01-44683, Design Compiler has a new variable
which allows the designer to tradeoff between runtime & quality of results.
This variable is only available in the 1997.01-44683 release.
compile_limit_down_sizing = true/false
Why this variable? You may be familiar with the log file where you have
seen that the delay cost comes down very rapidly and then at a point, you
only see very small changes in the delay and area cost function. This is
an indication where Design Compiler is spending some CPU cycles trying to
downsize gates to reduce the load seen by the critical path. At times, this
may have no major impact in improving the delay. This variable limits the
down sizing or area recovery step which is causing the extra runtime. This
variable should be used as a tradeoff between runtime and quality of
results. It is ideal for use during the exploration phase.
Cost | *
function | *
| *
| *
| *
| *
| * /Assuming the delta in
| *********** / cost function is very
| ********** / small at this step.
| **************
+----------------------------/-------------
/ Runtime
/
By setting this variable,
DC will bypass the area
recovery step thereby reducing
the runtime of your compile runs.
Another variable which can also be considered is:
compile_use_fast_sequential_mode = true/false
This variable prevents reoptimization of sequential cells off the critical
path. Typically used as a trade-off between runtime and quality of results.
Ideal for use during the exploration phase. An example:
analyze/elaborate
....
....
include constraints
compile_limit_down_sizing = true
/* Can also consider compile_use_fast_sequential_mode = true */
compile
...
....
/* When ready to do a final run... */
analyze/elaborate
....
....
include constraints
compile_limit_down_sizing = false
/* Can also consider compile_use_fast_sequential_mode = false */
....
....
compile
....
...
- [ A Synopsys DC CAE ]
( ESNUG 263 Item 4 ) -------------------------------------------- [8/97]
Subject: (ESNUG 261 #1) Synopsys "bk" DesignWare Adders Are BROKEN!!!!
> In the new release of Synopsys 1997.01, the designware foundation library
> has new architectures for adders called "bk". I guess the synonym means
> Broken. ... We found that these adders were not functioning as advertised
> and 4 MSB bits of the 52 bit adder were producing incorrect output
> results. Actually Chryalis symbolic verifier found this out for us. ...
From: gilbert@aluxs.micro.lucent.com (Gilbert Nguyen)
Hey John,
If you do a report_synlib dw01.sldb then yes there is the reason for the
52 bit BK adder with a bug -- It is legal only if the bit width is < 48 .
Attributes/Parameters:
v - verify_only
u - dont_use
r - regular_licenses
l - limited_licenses
d - design_library
s - priority_set_id
p - priority
leg - legal
Module Implementations Attributes/Parameters
----------------------------------------------------------------------
DW01_absval clf l = SynLib-Eval
r = DesignWare-Foundation
DW01_add bk l = SynLib-Eval
r = DesignWare-Foundation
d = DW01
leg = "(width < 48 )"
^^^^^^^^^^^^^^^^^^^^^^^^ LOOK!!!
Keep up the good work!
- Gilbert Nguyen
Bell Labs / Lucent Technologies
( ESNUG 263 Item 5 ) -------------------------------------------- [8/97]
From: "Clifford E. Cummings" <cliffc@europa.com>
Subject: Seeking Synopsys/Coding Tips For Efficient Adder Carry Out Designs
John -
A question for ESNUG readers. In February, at SNUG, I learned about the
"hdlin_use_cin = true" switch to coerce Design Compiler to use the carry-in
input on synthesized adders. Is there a similar switch to coerce Design
Compiler to use the carry-out output on adders? How do ESNUG readers get
better carry-out results when HDL coding for adder-inference?
- Cliff Cummings
Sunburst Design
( ESNUG 263 Item 6 ) -------------------------------------------- [8/97]
From: Pat McCabe <mccabe@eng.paradyne.com>
Subject: Seeking Secret "Design Space Explorer" Script
John,
I've heard through a couple of other Synopsys users about the existence
of a Perl script called Design Space Explorer (DSE), which allows a user
to evaluate different optimization techniques in a semi-automated
manner, producing a summary of results so that the user can see what
effects different optimization options have on a piece of logic.
Trying to get a copy of DSE has proved very difficult. Even some
Synopsys AC's I've talked to have never heard of this potentially very
useful script. It doesn't appear to be an "official" Synopsys tool, and
I've also heard that the DSE Perl source code has made it's way out into
the design community.
What do you know about this script? How can one obtain it?
- Patrick McCabe
Paradyne Corporation
( ESNUG 263 Item 7 ) -------------------------------------------- [8/97]
From: sam@zeppelin.abl.ca (Marc-Alain Santerre)
Subject: (ESNUG 258 #3) Pipelines, Latches, Test Compiler & Flip-Flopping
> I've been dealing with the question: "How do you avoid using latches in a
> design when they're so darned convenient for holding control bits?" a lot
> lately. .... A latch presents a problem for ATPG because the LATCH
> ENABLE input prevents the flow of data from D to Q. So, it has to either
> figure out how to properly open and close the latch during scan test such
> that all of the faults are testable.
From: sam@zeppelin.abl.ca (Marc-Alain Santerre)
John,
First, I have never used TC. But in a previous design I had the same problem
here. The solution was to made the latch transparent in test mode. The
input of your pipeline then become controlable from a primary input. The
latch enable input can be observed by adding a shadow register. But this
increase the gate count. Since the output of the latch can be read back with
the CPU interface. You can test the decoding logic with an proper sequence
of read/write to the latches just like you would do for testing an internal
RAM without BIST. I dont know if this other way of doing things is
compatible with TC.
- Marc-Alain Santerre
ABL Canada Inc.
( ESNUG 263 Item 8 ) -------------------------------------------- [8/97]
Subject: (ESNUG 259 #1 261 #4) dc_perl: dc_shell Using a Perl Wrapper
> Is anyone running dc_perl on the HP platform. Specifically HP-UX 10.2.
> Any problems?
>
> Paul LaBerge
> Micron Electronics, Inc
From: sgolson@trilobyte.com (Steve Golson)
John,
I don't know of anyone. Lots of folks tried under Solaris, and had the
problems mentioned in ESNUG 261. (I have a fix for this, but I won't be
able to get to it for another month or so.)
Meanwhile, you can get a copy of dc_perl and my paper from my ftp site
ftp://ftp.ultranet.com/pub/sgolson/dc_perl
Also have a look at
http://www.primenet.com/~greggl
- Steve Golson
Trilobyte Systems
( ESNUG 263 Item 9 ) -------------------------------------------- [8/97]
From: Srikanth M <msrao@india.ti.com>
Subject: Test Compiler Inserting Inverters In Scan Path & SolvIt's Wrong
Hello John,
We have a real bad problem with Synopsys Test Compiler. Test Compiler
inserts inversions in the scan path. This is something that our product
engineers find unacceptable for silicon debug/diagnosis. The solution to
the problem that is mentioned in the Solv-It article TEST-375350 doesn't
work and there has been no response to our query to Synopsys. Could you
please include this in the ESNUG forum ?
- Srikanth Rao
Texas Instruments India ( Pvt ) Ltd.
( ESNUG 263 Item 10 ) ------------------------------------------- [8/97]
From: buehlems@ise.uni-stuttgart.de (Markus Buehler)
Subject: Problems Modeling Tristates With Library Compiler v3.5a
Hello, John:
I'm trying to model a tristate buffer with complementary enable signals
(e, _e) for the SYNOPSYS library compiler v3.5a. In the manuals I have
found an example for a D-flip-flop with dual clocks (application notes).
However, I can't apply this solution for my buffer and latches also.
I have tried several possibilities, but they always result in warnings.
Does there exist any solution?
- Markus Buehler
University of Stuttgart
( ESNUG 263 Networking Section ) -------------------------------- [8/97]
Spokane, WA - Hewlett-Packard seeks R&D ASIC manager. 3+ yrs; HDLs/
Synopsys/Verif. RF Comm exp pref. No agencies. "conley@spk.hp.com"
Cupertino, CA -- Apple Computer seeks ASIC Engineer with 2+ years exp. w/
Verilog & Synopsys. No agencies. "winner@apple.com"
|
|
