From: Tommy Kelly <tommyk@mekb2.sps.mot.com>
In an EE's review of the Usenet hardware newsgroups John Cooley wrote:
> "alt.cad" ( 180 posts/week, 100 percent garbage )
>
> A hotbed of AutoCAD & TurboCAD discussions, machine tool drawings, and
> mechanical drafting software insights. Completely useless for EEs.
John,
This "CAD == guy who draws engine blocks" problem has caused us
recruitrment problems. We have been trying for over 18 months now to get
a what we now call EDA engineer. Until now, although our ads mentioned
synthesis, verification, and "unix wizard" they have also had "CAD" in
them. As a result our applicants are either technician-level unix
administrators, or people who can draw toilet seats with MacDraw. (Not
that I'm trying to drop any hints that anyone out there should send me
their resumes. Particularly given that although rain is not unknown
in Scotland, neither is excellent whisky, and it does have some of the
best ice climbing on the planet. And none of the ESNUG readers would be
EDA-specialists, with a strong HP-UX bent, and keen on moving to Glasgow,
Scotland, to work in an ASIC/Motorola-cores design group...)
Would they?
- Tommy Kelly
Motorola, Scotland
[ Editor's Note: A job where your only off hours fun is to be a drunken,
ice climber? Gee, Scotland sounds like *sooo* much fun! :^) - John ]
( ESNUG 269 Item 1 ) -------------------------------------------- [10/97]
Subject: ( ESNUG 268 #8 ) HP, DEC, SUN Workstation Benchmarks w/ Synopsys
> At our company we have historically used SparcStations and UltraSparcs as
> our Verilog and Synopsys engines. Given the nosebleed prices of *certain*
> EDA tools, we are curious if other hardware platforms might deliver better
> Synopsys performance and, as a result, improve the utilization of our
> Synopsys licenses. Sooo.... Has anyone out there benchmarked HP,
> Dec-Alpha, and Ultra Sparc's running Synopsys. Could you please share
> them with us on ESNUG?
From: zehentner@heidenhain.de (Zehentner Georg)
Hi John,
About a year ago we had the same idea. Buy a high performance hardware and
save the money for a further synthesis license. So we tried an HP-Station,
our Sparc-Stations and a new 300 MHz Sparc with Synopsys 1997.08 Version.
The results:
Ultra 1 / 300 MHz: 47 min = 1.60 * Ultra1/200
Ultra 1 / 200 MHz: 73 min = 1.00 * Ultra1/200
HP C 180: 135 min = 0.54 * Ultra1/200 !!!!
Hypersparc, Sparc 20: 152 min = 0.50 * Ultra1/200
Our synthesis-jobs run now on the Ultra1/300MHz.
With the Version 1997.01 the performance of Ultra/200 and HP is the same.
- Georg Zehentner
Heidenhain GmbH
---- ---- ---- ---- ---- ---- ----
From: Brian Arnold <bka@hpesbka.fc.hp.com>
John,
Someone asked for a platform performance comparison and here is what I could
come up with. Performance comparison of HP -vs- Sun. The numbers have been
normalized to an HP C110. All platforms have been configured with a minimum
of 256MB RAM, 512 MB SWAP, 4GB DD and running either HP-UX 10.20 or
Solaris 2.5.
Application: Synopsys Design Compiler rev. 1997.01
Machine Normalized performance
------- ----------------------
HP C110 1.00
HP B132L 1.16
Sun Ultra 200 1.45
HP J282 1.48
HP B180L 1.54
HP C180 1.51
HP C200 1.81
HP C240 2.20
Sun Ultra 300 2.20
HP K-class @240 MHz 2.28
Application: Synopsys Cyclone rev. 1.1c
Machine Normalized performance
------- ----------------------
HP C110 1.00
Sun Ultra 200 1.70
HP J282 1.90
HP B180L 1.15 !!!!
HP C180 1.89
HP C200 2.15
HP C240 2.53
Sun Ultra 300 2.44
HP K-class @ 240MHz 2.58
- Brian Arnold
Hewlett Packard
( ESNUG 269 Item 2 ) -------------------------------------------- [10/97]
Subject: (ESNUG 264 #3) 1.5 Hrs "Design Rule Compile" Now Takes 24 Hrs!
> I have a design, the top level of which compiled under synopsys 3.4b in
> roughly 1.5 hours. ... In both 97.01 and 97.01-01_44683, that same
> compile takes over 24 hours (basically 24 hours fixing design rule
> violations). I have tried this using vendor libraries which were designed
> for 3.4b and new vendor libraries designed for 97.01. Again, most of the
> time (basically 24 hours) is spent fixing design rules. I've tried a
> number such as always using "best case tree", turning off automatic
> wireload selection which chose a chip level wire load (enclosed mode) and
> instead chosing a very small wire load. Any ideas?
From: "Maureen L. S. Ashley" <mseils@btv.ibm.com>
Hi, John,
We've found that the transition degradation capability and that the setting
of max_fanout were impacting compile times in v1997.01 and v1997.08. Here's
some things we've found to help reduce compile time:
* We've removed transition degradation capability from our newer IBM
ASIC libraries. This meant removing transition degradation from
library source code and recompiling of ALL synopsys technology
libraries.
* As an alternative solution or a temporary work around, libraries with
transition degradation capability can be used in v1997.08 with
disable_transition_degradation = "true"
(This will cause a marginal increase in run times, compared with
totally removing transition degradation from the library.)
* To help avoid longer run times, the designer could set a max fanout
on the library (in case it is not set in the library). When a
default max fanout is NOT set in the library and a designer applies
a max fanout to the top level design, then this max fanout is applied
to ALL nets in the design. This includes any Synopsys generated nets.
Synopsys will then try to fix the max fanout constraint on these virtual
nets. During the design rule compile Synopsys spins on the virtual
nets. To avoid the problem caused by setting the max fanout on the
design, the customer should use the set_attribute command to set
the default_max_fanout on the technology library. (Note: The
difference here is that setting the attribute on the library
does NOT set the fanout on the virtual nets, where as setting max fanout
on the design does!) The max fanout setting is design dependent. For
example, the command to use to set the default library max fanout to
20 would be:
set_attribute LIBRARY_NAME default_max_fanout 20 -type float
Hope this helps your ESNUG readers, John.
- Maureen Seils Ashley
IBM Microelectronics
( ESNUG 269 Item 3 ) -------------------------------------------- [10/97]
From: eign@rdsc.wb.xerox.com (William G. Eign)
Subject: Designs with I/O Buffers & DC 1997.08 Need Power Analysis Key
John,
I have noticed that many of your readers have experienced FATAL ERROR
ENCOUNTERED when compiling with 1997.08. We were experiencing this problem
using the AMI 6G5 library.
We traced the problem to I/O buffers. If there was an I/O buffer in the
design, the compiler would crash.
We turned it in to the Synopsys support center and they could not
re-create the problem.
All of a sudden I received an email from Synopsys containing a Power
Compiler key and a note indicating that this would solve my problem. Sure
enough, the compiler completed without crashing on the design and our test
cases. I don't know what the plan is for a permanent fix, but this seems
to work fine so far.
- William G. Eign
Xerox Corporation
( ESNUG 269 Item 4 ) -------------------------------------------- [10/97]
Subject: (ESNUG 266 #5 267 #1 268 #5) *WHO* Is Using Behavioral Compiler?
> BC moves design to another level of abstraction which means you need to
> rethink how to capture a design - and that can't happen without effort
> and time: with the enormous time pressure and work load engineers are
> often under, there is little room for taking the necessary time to learn
> a new way to design.
>
> BC - and other application-specific synthesis tools like test synthesis
> and protocol synthesis - is a taste of how designs are going to be done
> in the future.
>
> - Janick Bergeron
> Qualis Design Corporation
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
Hi, John and the Gang,
On Behavioral Compiler... I took the BC class from Synopsys and even read
through half of the book that one of the BC designers published. I take
issue with anyone that says "It's going to take a while to switch engineers
from RTL to a higher-level." This is absolute rubbish. VLSI engineers are
a very clever and resourceful bunch and they would gladly do it a better
way. It also doesn't take that much of a mind switch to go to BC-style -
c'mon if they can teach it to you in a couple of days - it's definitely not
differential equations or sub-atomic physics!
BC is just not ready - plain and simple.
BC does not follow the fundamental design methodology of hierarchy - it's
hard to hook two BC generated blocks together. BC wants the freedom to
change the interface on each of the blocks (a very block-centric approach).
BC does not understand the concept of "stalling data pipes", such as when
your block is surrounded by FIFO's and there happened to be no data available
for the pipe to work on, so BC doesn't know how to design pipes that stop
for a while and wait for data to get there. Currently BC is really an
implementation compiler. When BC is ready I'll be the first to jump on
it - I've been ready to give up RTL-level coding since my first design with
Design Compiler 1.0.
- Victor J. Duvanenko
Truevision
---- ---- ---- ---- ---- ---- ----
From: Doug Warmke <doug@ikos.com>
John,
In the BC discussion, one thing that is really important to us that might
be worthy of public discussion is the risk-reduction point.
Our RTL FSM's simply got too out of hand. They are of the "pipelined FSM
form", where the FSM is simultaneously controlling several stages worth of
pipeline. This kind of FSM is necessary when you're dealing with a
synchronous resource like an external Late-Write SRAM, which has a couple
cycles latency on its results. (Too hard to explain in crystalline form
here.)
BC reduced our code substantially (3x less lines), and most importantly, we
could convince ourselves that we had the algorithm implementation
fundamentally sound by visual inspection.
In the RTL versions, we just couldn't tell, and we were continually running
into hard-to-find corner cases with difficult and risky eventual solutions.
It's an interesting philosophical point, I think.
- Doug Warmke
Ikos Systems, Inc.
---- ---- ---- ---- ---- ---- ----
From: Robert Hoffman <bobh@siforge.com>
Hi John,
Just a brief note on BC, since I didn't see anyone mention this.
About 6 months back, I evaluated the tool for use in a DSP modem asic
(QAM256). Previously, I had used verilog and found the use of parameterized
designs for handling datapath to be an incredible timesaver. Carrying this
forward, I concluded that the use of vhdl with its more robust generic
command (allowing for optional hw elements) in combination with BC would
result in excellent architectural flexibility.
Now the bad news, I found that BC was incompatible with the use of
parameterization. This to me was a fundamental flaw -- I would rather have
parameterization over scheduling.
Just wanted to forewarn others - and I never got a Synopsys commitment to
fixing this.
- Robert Hoffman
Siforge
( ESNUG 269 Item 5 ) -------------------------------------------- [10/97]
From: Thomas Tomazin <thomas.tomazin@analog.com>
Subject: Synopsys Design Compiler & Removing Gated Clocks
Hi John,
I am converting a 2-phase latch based gated-clock design into a non-gated
clock design. We're removing the gated clocks to avoid any surprises with
the clock tree distribution. Our proposed solution was to take the gated
clock, call it CKHLD, and break it into it's constituents, namely CK & HLD.
A latch that had
always @(CKHLD or D)
if (CKHLD) Q <= D;
would be rewritten to
always @(CK or HLD)
begin
if (CK) begin
if (!HLD) Q <= D;
else Q <= Q;
end
end
This looks a little funny, but consistently prevents Synopsys from gating
the clock and hooks CK up to the clock pin of the latch. We plan on adding
a "holdlatch" to the library that will prevent the latch from updating
unless !HLD, and hopefully HLD would be connected to the ENABLE pin on the
latch. There are a couple problems with this approach:
1) Synopys gets very confused when timing paths with Q<=Q feedback. It
borrows all the time it can from the latch somehow. Very strange.
2) I don't think it's possible to guarantee that Synopsys won't suck
HLD into the D pin of the latch and not use the ENABLE pin, and
if it allows borrowing, the latch will get corrupted before HLD
goes high, then feed back the improperly updated value.
So, my question is, how do people deal with these problems in latch based
designs? My background is primarily with flops, so this is new to me.
- Thomas Tomazin
Analog Devices, Inc.
( ESNUG 269 Item 6 ) -------------------------------------------- [10/97]
From: jonathan@ikos.com (Jonathan Liu)
Subject: DC 97.01 & 97.08 Are Inconsistant With Bussed VHDL Ports
John, When I first installed 1997.08, I did experience an inconsistency
(which I reported to Synopsys) in versus 1997.01 with respect to how the VHDL
writer handles bussed ports (with certain combinations of switch settings).
When I read into 1997.08 a source VHDL file containing a vector port in
which the LSB was non-zero, and then wrote out the same design as VHDL
output file, it changed the range of the vector such that the LSB was zero.
My VHDL input file ports, which should & does remain unchanged w/97.01:
entity vector_test is
Port (a: in std_logic_vector(7 downto 1);
b: out std_logic_vector(4 to 7));
end vector_test;
architecture structural of vector_test is
component sub_test
Port (c: in std_logic_vector(7 downto 1);
d: out std_logic_vector(4 to 7));
end component;
Original .synopsys_dc.setup settings:
vhdlout_preserve_hierarchical_types = "VECTOR";
vhdlout_follow_vector_direction = "TRUE";
Original dc_shell script:
analyze -f vhdl vector_test.vhd
elaborate vector_test
report_port
write -f vhdl -o vector_test_out.vhd
quit
Output file in 1997.08 (incorrect, note bus ranges):
entity vector_test is
port( a : in std_logic_vector (6 downto 0);
b : out std_logic_vector (0 to 3));
end vector_test;
architecture SYN_structural of vector_test is
component sub_test
port( c : in std_logic_vector (6 downto 0);
d : out std_logic_vector (0 to 3));
end component;
I originally worked around the problem by reverting to 1997.01 for steps
which needed to write VHDL output files. However, fortunately, our Synopsys
A.C. helped me find a superior solution, which was to change some switch
settings in my .synopsys_dc.setup to be as follows:
vhdlout_preserve_hierarchical_types = "USER";
vhdlout_follow_vector_direction = "FALSE";
(Originally those two settings had been "VECTOR" and "TRUE" respectively.)
With the new settings, I was able to obtain the desired result in 1997.08,
So it wasn't a serious problem. Nonetheless, people might want to be warned
of this inconsistency in behavior between the two versions.
- Jonathan Liu
Ikos Systems, Inc.
( ESNUG 269 Item 7 ) -------------------------------------------- [10/97]
Subject: ( ESNUG 267 #10 268 #4 ) Synopsys Vs. Altera Max-Plus II For FPGAs
> I wouldn't buy Altera's VHDL package since you already have Synopsys,
> and it won't give you the vendor independence that Synopsys does.
>
> The Synopsys sales rep. will want you to buy FPGA Compiler which is
> supposed to give better results than Design Compiler for Altera designs.
> Stick with good ole' Design Compiler. The extra expense and hassle of
> FPGA Compiler isn't worth it.
From: Mike Dini <mdini@dinigroup.com>
John -- I have used Synopsys FPGA Express/ Synplicity's Synplify/Exemplar's
Leonardo to do Altera 10k designs. Their Altera interfaces are quite easy.
This engineer is overlooking simulation, though. The Altera simulator is
primitive compared to a verilog/vhdl test bench, and this is where you spend
most of your time. Synthesis is the easy part.
- Mike Dini
The DINI Group
---- ---- ---- ---- ---- ---- ----
From: Geoffrey Brown <gbrown@hplms2.hpl.hp.com>
John,
Personally, I'm a big fan of Altera's tools. The synthesis for AHDL is
very fast and error free. While at Cornell, my students and I developed
synthesis tools for a protocol description language that generated AHDL.
This output always compiled flawlessly. In addition, we performed little
or no optimization before generating the AHDL -- the Altera tool did a
really good job of eliminating the chaff. At one point we did the same for
Altera's version of VHDL. Unfortunately, this package was slow and buggy
(3 years ago). My inclination would be to approach the VHDL route with
caution -- test a few simple designs to see if it's bearable.
On the other hand, AHDL is a "trivial" language. With a rigid coding
style, a future port to VHDL might not be such a problem.
- Geoffrey Brown
Hewlett-Packard
---- ---- ---- ---- ---- ---- ----
From: [ *I* Didn't Say This ]
Hi, John,
When I used some Altera parts about 3 years ago they didn't even offer VHDL.
AHDL is so similar to VHDL that I simply wrote my code in VHDL then
corrected to AHDL when the compiler complained.
I then wrote out the placed & routed design in VHDL and instantiated
several FPGA designs into a TestBench. We even figured out how to edit
the behavioral VHDL into synthesizable VHDL to feed into Synopsys to
translate to other formats.
And, Max-Plus II does the entire design-flow in one step. In using Altera's
tools, you're doing the right thing.
Because I'm in the Synopsys Inner-Circle program, please keep me anon.
- [ *I* Didn't Say This ]
( ESNUG 269 Item 8 ) -------------------------------------------- [10/97]
Subject: ( ESNUG 268 #7 ) DC's Flip-flops & Optimization Trashes Testablity
> I have a problem with Synopsys's logic optimisation. How do I stop it
> generating logic that is slightly faster than the stuff I want but breaks
> certain design rules we have. ... Sometimes, it calculates that a reset
> flip-flop with its reset tied off is faster than a non-reset flip-flop.
> This is also a testability no-no, so can we stop it doing this?
From: "Andrew Hulbert" <ah@bristol.st.com>
John, try the following:
set_attribute current_design no_sequential_degenerates true -type boolean
We had this problem with Hcmos5 and Hcmos6 standard cell libraries. We had
the problem of the Set/Reset flip flops being inferred with Set/Reset tied
to 1 or 0 as the timing was marginally better. This flag fixed that problem
because it stops Synopsys from creating logic with tied off FF's.
- Andrew Hulbert
SGS-Thomson Microelectronics
( ESNUG 269 Item 9 ) -------------------------------------------- [10/97]
From: mtoofan@asic.smos.com (Mehrdad Toofan)
Subject: Looking For Tips & Tricks Involving Asynchronous Synthesis
Hi John,
I am trying to learn and put into "real" practice synthesizing some
asynchronous logic using Synopsys. Do you mind giving me tips on the
general guidelines for such designs, how to avoid any possible pitfalls,
and any sample scripts?
- Mehrdad Toofan
SMOS
|
|
