Editor's Note: Last Friday, Boston got its first taste of Old Man Winter
with a miserable, sleeting snowstorm that dropped about 6 inches of wet
snow on its hapless citizens. Because this type of weather is about 6
weeks early this year, quite a few people were extra grumpy when they had
to spend an extra half hour clearing the snow & ice off of their cars.
Oddly, I found myself thinking "Those poor, silly, silly Californians!".
Why? Because being an engineer I've always found it an advantage to live
in tundra regions. There's a certain low-grade depression/malaise that
comes from living in a region where it gets dark at 4:PM and there's a
brutally cold wind blowing outside. I oddly find that with this comes a
clarity and focus that makes for some great ASIC design work. And given a
choice of freezing in the dark versus staying in a nice warm cubical...
well, let's just say I tend to get a lot of work done during these times.
Conversely, I can't see how those silly, silly Californians can get *any*
work done. Who wants to sit in a cubical and pour through 20,000 lines of
source code chasing some obscure pain-in-the-ass design and/or EDA bug
when you have "BayWatch" going on right there??? How do they do it?
Hmmm.... 6 weeks early. Hmmm. 6 weeks. Ugh. It looks like I'm going
to be *mighty* productive & brilliant this year. Ugh. :^(
- John Cooley
the ESNUG guy
( ESNUG 272 Item 1 ) -------------------------------------------- [11/97]
Subject: Homegrown EDA Benchmarks from INDUSTRY GADFLY "Drool, Drool, Drool"
jcooley@world.std.com ( John Cooley ) wrote:
>
> It was in this climate of intimidation that I learned from an old Motorola
> CAD manager how to make homebrew, quick & dirty EDA benchmarks. "To
> compare workstations for EDA purposes, take 70 percent of its integer SPEC
> mark and 30 percent of its floating point SPEC mark, normalize it, and
> you'll know how they relatively stand for most Cadence and Synopsys tools."
>
> Workstation SPECint SPECfp 70/30 Normalized
> ----------- ------- ------ ----- ----------
> DEC Alpha 15.22 24.22 17.92 2.14
> HP J282-XP 10.80 17.20 12.72 1.52
> Sun Ultra 30 10.20 16.20 12.00 1.43
> SGI Octane 10.50 7.00 10.63 1.27
> IBM RS6000 43P 9.40 5.99 8.38 1.00
From: silbey@colnago.engr.sgi.com (Alex Silbey)
John, not that it makes that much of a difference (since SGI isn't in the
EDA market), but the correct specint95 and specfp95 for the SGI Octane are
9.4 and 17.4, respectively. That changes the 70/30 score to 11.7 and the
normalized score to 1.396.
The Origin 2000 has specint and fp numbers of 11.4 and 19.1, for a 70/30
score of 13.6 and a normalized score of 1.62.
Data is from "http://www.sgi.com/Octane/products/benchmarks/index.html" and
"http://www.sgi.com/Headlines/1997/November/mipspro_release.html"
- Alex Silbey
Silicon Graphics, Inc.
---- ---- ---- ---- ---- ---- ----
From: Curtis McAllister <curtismc@cup.hp.com>
John,
Well, it was a courageous attempt at keeping yourself out of hot water, but
you failed nonetheless. You didn't mention HP's highest performance
workstation -- the HP Visualize Model C240. It has a SPECint95 number of
17.3 and a SPECfp95 number of 25.4 -- giving it a normalized 70/30 score of
2.35! More information on this product can be found on HP's web site at
http://www.hp.com/wsg/launch/products/cclassspec.html
To be fair to you, I thought that maybe this product wasn't listed on the
SPEC web site, but a quick search of the SPEC site showed that it was indeed
listed. Here's what I did to show all products that you might be interested
in viewing:
1. Go to the SPEC query page:
http://www.specbench.org/cgi-bin/osgresults?conf=cpu95
2. Under "Other Requests" select the link
"Configurable Query form in HTML3.2 Tables"
3. In the "CPU95 Results -- Form", I specified my criteria as the
following:
Request
Criteria
Result is greater than 9
HW Avail is since Jan-96
Ordering
1.Company
2.Result
3.System
I then got a table for all CINT95 results listed by manufacturer, followed
by all CFP95 results, etc.
- Curtis McAllister
Hewlett-Packard Co.
---- ---- ---- ---- ---- ---- ----
From: Shiv Sikand <sikand@mti.mti.sgi.com>
John,
Don't know where you got your numbers for the SGI Octane. If you check:
ftp://ftp.cdf.toronto.edu/pub/spectable, you will observe that the Spec
numbers for an Octane with 195 MHz R10K are 9.3 Int and 17.0 FP.
Either way, your numbers are self inconsistent in the SGI row.
Cheers,
- Shiv Sikand
Silicon Graphics, Inc.
---- ---- ---- ---- ---- ---- ----
From: anderson@acuson.com (Brien Anderson)
Hi John,
Gosh *thanks* for the homebrew benchmark formula. But do they still port
Synopsys tools onto the DEC Alpha platform?
- Brien Anderson
Acuson
---- ---- ---- ---- ---- ---- ----
From: BRIAN_W_LOWE@HP-USA-om31.om.hp.com ( Brian Lowe )
John,
Interesting & informative article. In fairness to Sun (from their web page)
I believe the Ultra 30 comes in at 1.67 normalized, up from 1.43 (12.1
specint95 and 18.3 specfp95). However the competitor from HP to this box is
the C240 which from HP's web page (www.hp.com/technical) comes in at 2.35
normalized (17.3 specint95 and 25.4 specfp95) placing it ahead of DEC.
- Brian Lowe
Hewlett-Packard Co.
---- ---- ---- ---- ---- ---- ----
From: Jerry Case <jacase@ix.netcom.com>
So John,
Do you have the numbers for the Pentium II for comparison?
- Jerry Case
---- ---- ---- ---- ---- ---- ----
From: "Wilbur Harvey" <wnh@sinewave.com>
John,
One thing which is often not understood, is that in many EDA applications,
such as PCB routing and most logic simulations, the primary performance
factor is *memory bandwidth* and not CPU performance. Most modern CPU's
have cycle times much faster than main memory access so in most situations
where lots of memory is what you need, you also need the best memory bandwith
possible.
I did some tests a couple of years ago w/ a DEC Alpha used for PCB routing.
On a 1 hour route, increasing the L2 cache size by a factor of 4 slowed down
the route by 6 seconds (the larger cache had one extra wait state),
increasing the clock speed from 166Mhz to 233Mhz decreased the route time
by 3 seconds and removing a wait state from DRAM accesses decreased the
route time by about the amount of time that overall memory performance was
increased.
This is one reason which relatively slow Pentium systems with SDRAM perform
so well, and why the new Alpha systems using 128Bit wide SDRAM accesses have
benchmarked so well in PCB routing.
- Wilbur Harvey
Sinewave
( ESNUG 272 Item 2 ) -------------------------------------------- [11/97]
Subject: Choice Of C Compiler And Problems With The Synopsys VSS C Interface
From: Fabian Wolf <fabian@vergil.ida.ing.tu-bs.de>
>
> Hi there, after working a lot with the SYNOPSYS C Language Interface CLI
> we are currently encountering problems with the C compiler used. The cc
> does not fit our needs, so we are interested in using the gcc. Does anyone
> know where set the default C compiler for the CLI or the parameters for
> the call as this is not explained in the manual. Renaming the gcc to cc
> helps, but this still does not solve the problem with the fixed parameter
> set in the compiler call.
>
> Any experience on that subject? We would be really grateful for any help.
>
> - Fabian Wolf
> Institut fuer Datenverarbeitungsanlagen
From: ryan@dogbert (Ken Ryan)
I have never used the Synopsys CLI with gcc, but the cli command itself is
merely a shell script. Typing "cli" by itself provides a rundown of
switches and debugging aids (I've found setenv CLIECHO 1 useful). Beyond
that, poring through the cli script itself there seems to be places where
compiler switches are define. This is machine-dependent, so I can't help
you beyond that.
- Kenneth Ryan
Orbital Sciences Corp.
---- ---- ---- ---- ---- ---- ----
From: Chris.Brown@arm.com ( Chris Brown )
You can chose which C compiler VSS uses by editing the following file:
admin/setup/.synopsys_vss.setup
- Chris Brown
Advanced RISC Machines Ltd.
---- ---- ---- ---- ---- ---- ----
From: "Mihai T. LAZARESCU" <mihai@ccmserv.polito.it>
Have you tried to set the environment variable CC=gcc, like:
csh and alike> setenv CC gcc
sh and alike> export CC; CC=gcc
Maybe it helps out.
- Mihai T. LAZARESCU
Politecnico di Torino - Italia
---- ---- ---- ---- ---- ---- ----
From: Jon Connell <jon.connell@hl.siemens.de>
Create a script called "cc" (which works fine for Solaris) like this:
#! /usr/local/bin/perl
$ENV{PATH} = "/opt/gnu_2.0/bin:$ENV{PATH}";
foreach $arg (@ARGV)
{
$arg =~ s//;
$arg =~ s/-*PIC/-fPIC/;
}
exec("gcc @ARGV");
Make sure it's in a directory which is at the beginning of your search path,
and away you go! Other platforms will use different options for the PIC
stuff. Another idea is to edit the cli script (as mentioned in this thread).
- Jon Connell
Siemens HL, Microcomputer ICs
( ESNUG 272 Item 3 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 270 #9 271 #7) Seeks DesignWare Foundation Licensing Tricks
> We have less DW Foundation licenses than DC licenses. Currently we have
> the designers not point to any of the advanced DW architectures unless
> their design is not meeting timing. Does anyone know of a way to only
> check out the DW Foundation license when you want to write out the design
> and maybe run everything else in eval mode?
>
> - Russ Ray
> Mitsubishi
From: [ The Man In The Iron Mask ]
John, please keep me anon. To disable the DW foundation licenses use:
synlib_dont_get_license = {DesignWare_Foundation}
Then use:
synlib_disable_limited_license = FALSE
To trick Synopsys into thinking its using it in Evaluation mode. When
you're done, at the last minute, you can switch back to non-Evaluation
mode to then write out your working design by using:
synlib_disable_limited_license = TRUE
along with a get_license for DW license.
- [ The Man In The Iron Mask ]
( ESNUG 272 Item 4 ) -------------------------------------------- [11/97]
Subject: (ESNUG 271 #4) A Workaround For How BC Handles System Stalls
> The trouble with my design space is that a destination FIFO (where my
> results go) gets full and must tell the rest of the logic/pipe to stop
> (stall). BC needs to support simple VHDL constructs as follows:
>
> wait until clk = '1';
> go_registered <= go;
> if ( go_registered = '1' ) then
> all of my pipe logic goes here...
> end if;
>
> Currently BC generates such gobble-gook when it sees this... The result
> need to work not only with DesignWare components, but all BC constructs
> (such as memories, FIFOs, and random logic). Otherwise, the designer is
> more productive not using BC. Keep in mind, this is the case of "my design
> space". BC may work perfectly fine for other "design spaces", and the only
> frustration that I'm expressing is that of not being able to use a more
> powerful tool, to be more productive, when BC is so close to being able to
> handle "my design space".
>
> - Victor J. Duvanenko
> Truevision
From: [ A Synopsys BC CAE ]
Hi John,
This sounds like a great chance for me to get some great customer feedback,
from Victor and other interested parties. The way BC currently supports
this type of system stall is by setting a command:
set_behavioral_stall_pin "pin_name" -active high/low
This directs BC to set the stall pin to a specific signal for a specified
process or for all processes within the design, e.g.
set_behavioral_stall_pin go -active low
would cause an active high signal on the input port "go" to stall the BC
design.
This methodology does not presently work for memories or sequential
designware parts, that have to be stalled. Why? The problem with these
parts is that there was no way of specifing which pin on the memory or
sequential designware part is the stall pin. This functionality has been
added to the Designware Developer product and BC now has plans to use this
information to directly hook up the memories and sequential DW parts which
have the existing stall functionality specified. Random logic works as of
today.
Q: Is this going to fulfill your needs as a user? (I'd like to hear what
users think about this approach.)
OK, as to a workaround you can use today:
As you already know by default BC does not support stalling pipelined parts
and memories, if you try to run it you will get the following message:
WARNING: Pipelined parts and memories are not stalled by the stall pin.
This can cause incorrect behavior: you must correct
the circuit manually by adding a stall function to all such parts,
and then connect them to the stall signal.
Here's the workaround:
a) Set the following UNIX environmential variable before starting dc_shell
unix> setenv "bc_seq_stall" "true"
b) When you call the designware part connect a '0' to the stall port, i.e.
result <= mul_add_fl_p_s(clk, mant_1, exp_1, mant_2, '0');
c) Schedule the design
d) Remove the net attached to the stall pin and connect it to the stall
port instead. Here's a sample script which you can modify and use:
cnl = {}
ref_list = find(reference, *_state_*)
foreach(ref_member, ref_list) {
cnl = cnl + filter(find(cell,"*") "@ref_name == ref_member")
foreach(cn,cnl) { }
all_connected find(pin, cn + "/stall*")
disconnect_net dc_shell_status find(pin, cn + "/stall*")
all_connected find(port, stall[0])
connect_net dc_shell_status find(pin, cn + "/stall*")
}
(The part of the script you may need to change are *_state_* and
stall[0] depending on the names you've used for them.)
e) Levelize the output for simulation
vhdlout_levelize = true
verilogout_levelize = true
f) compile
I hope this helps, Victor.
- [ A Synopsys BC CAE ]
( ESNUG 272 Item 5 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 269 #5 270 #2 ) Design Compiler & Removing Gated Clocks
> 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
From: landmh@taec.toshiba.com (Howard Landman)
Hey, John,
I actually had a go at that problem myself, a couple of months back. Our
conclusion was:
1. You *must* set the "clock : true ;" attribute on the clock input pins
of every enabled latch in the library. Otherwise, dc_shell will create
gated clocks feeding into normal latches, regardless of coding style.
(This isn't too unreasonable; since the clock and enable inputs are
functionally equivalent, there's no reason for synthesis to treat them
differently except for that attribute.)
2. There's a bug in dc_shell; even after we had the clock attribute, we
still got gated clocks for:
if (CLK && ENABLE)
Q <= D;
but everything worked fine for:
if (CLK)
if (ENABLE)
Q <= D;
and also for:
if (ENABLE)
if (CLK)
Q <= D;
even though all three forms are logically identical. So, we ended up
changing all our RTL to the second or third forms. We never use the
else clause, since it's redundant.
- Howard A. Landman
Toshiba America Electronic Components
( ESNUG 272 Item 6 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 271 #3 ) DC 97.08 & Problems With Parameterized Sub-modules
> Our fatal errors with 1997.08 are related to the use of parameterized
> sub-modules. If you analyze/elaborate a design that instantiates
> a parameterized block, dc_shell croaks just as it tries to build
> the sub-module. So far I've observed this on two separate designs.
> Since we make heavy use of parameterized blocks, this is a major
> roadblock for us.
>
> We're using Verilog, although I'm not sure yet if that's significant.
> Unlike Howard Landman, we don't use connection_class at all. For
> now, 1997.08 has been declared unfit for human consumption around
> here while I try to find a work-around.
From: "Tom Harrington" <tharring@ford.com>
John,
Since discovering problems with 1997.08, I've received a work-around from
Synopsys support. If we set the undocumented variable "dont_clean_design"
to "true", our fatal errors disappear. I've added this to our system-
wide setup script for dc_shell verion 1997.08. It's my understanding
that this variable only needs to be "true" when reading or elaborating
RTL code, but I wanted to make it as simple as possible for our users
to avoid the fatal errors we saw.
Results with this work-around are very similar to those produced by
1997.01; designs are either slower or faster, larger or smaller, by very
small amounts. Execution time seems to be 15-20% longer, though.
I've re-released 1997.08 to our users, but with the long execution times
I don't expect that many of them will use this version of Design Compiler.
Other tools may get used, though.
- Tom Harrington
Ford Microelectronics, Inc.
( ESNUG 272 Item 7 ) -------------------------------------------- [11/97]
Subject: ( ESNUG 270 #6 271 #2 ) I Miss The SOLV-IT Puns!!! :(
> I'm very glad Ted enjoyed the results of my somewhat bizarre sense of humor
> as much as I enjoyed writing the Scout. However, when looking at the Scout
> as created by Catherine, the new SOLV-IT! editor, I urge you to remember a
> couple of things: 1) ... She has a wonderful sense of humor, but is
> rightfully cautious with it until she knows her customer base and the
> company atmosphere. ... 2) We got as many complaints about my puns as we
> got compliments, and I was several times cautioned to tone down my writing.
> You just can't please everyone. Again, having verbal customer support is
> essential to taking risks, so by all means, mail your feedback to ESNUG.
>
> - Janet Kaul
> Past Editor Of The Synopsys "Scout"
From: tboydsto@su102s.ess.harris.com (Ted Boydston)
Hi, John,
Boy, I must of rattled the cage with my comments about SOLV-IT in ESNUG,
because I have received numerous messages about it. Let me make a few
points about my comments in ESNUG:
1. First, let me unequivocally state that I never said the new owner,
Catherine Starr-Young, was incompetent or was not performing her job --
quite to the contrary. I believe that Catherine does an EXCELLENT job
in disseminating information to SOLV-IT users.
2. I realize with a new list owner comes a new style. I relate this point
to reading a comic-strip. Say you read Dilbert every day, and United
Features Syndicate decides to have Charles Schultz write Dilbert, instead
of Scott Adams. Well, the next day, when you read Dilbert & he is acting
like Snoopy, you would be surprised! That describes my state when reading
the first few SOLV-ITs. As would be in the comic strip case, I voiced my
opinion on putting a bit more fun into SOLV-IT.
It was my intent to get the opinions of others on this subject, allowing
me to see if I was being absurd in my feelings towards the new list's
style. I know that many may prefer an information-intensive approach to
the list, and if they are the majority, then great, let them "have there
cake and eat it too". But if many people felt that a bit of fun helped the
list, then maybe a small changes to the list could improve it for
everyone. A good example is when Catherine mailed that hilarious "Phrases
you would overhear if a Klingon was on your software team", which I have
posted on my cubicle wall.
- Ted Boydston
Harris Government Aerospace Systems Division
( ESNUG 272 Item 8 ) -------------------------------------------- [11/97]
From: Dyson.Wilkes@swi055.ericsson.se (Dyson Wilkes)
Subject: "Dali", BC, & High Level Descriptions Of Interfaces
John,
I have been following the BC theme with interest. One dimension seems to be
about how one BC block communicate with another BC block.
I have two questions:
1. Has anyone been using DALI/PC (Protocol_Compiler) in tandem with BC?
2. How important do the readers of ESNUG think the high level description
of interfaces is?
My motivation comes from the fact that I think the description of interfaces
(protocols, mapping of data, timing, etc.) is one important area not yet
addressed at the "behavioural level". As far as I know, DALI is very much a
stand-alone tool and not all that well advertised by Synopsys.
- Dyson Wilkes
Ericsson UK
( ESNUG 272 Item 9 ) -------------------------------------------- [11/97]
From: Xerxes Wania <xentec@ican.net>
Subject: DC Creating Floating DW Inputs & Other Weird Stuff
John,
I am using Design Compiler for my synthesis in VHDL. I have a matrix
multiplication in my design. It is a 3 by 3 matrix. My coefficients as
well as the inputs are signed. For one sum of partial products I use:
a <= signed(c1) * signed(in1) +
signed(c2) * signed(in2) +
signed(c3) * signed(in3);
Q1) DC does not recognize "signed" and thus when it uses designware for
the mutlipliers, it does'nt connect the "TC" (two's complement) to high
-- it just lets it float. (Floating inputs??!!!) The way I got around
it is to instantiate the DW02_mult and "force" the TC bit high. Is
there any other, more automatic way to solve this problem beyond hand
instantiating & baby-sitting DW parts?
Q2) When I use the above equation, I break it up into partial products, i.e.
wait until clk'event and clk='1';
a1 <= signed(c1) * signed(in1);
a2 <= signed(c2) * signed(in2);
a3 <= signed(c3) * signed(in3);
a <= a1 + a2 + a3;
And I don't meet my timing.
Although if I take the sum of the partial products ( a1, a2, a3) and
optimize them seperately in another file, I seem to achieve my timing:
VHDL file_1:
wait until clk'event and clk='1';
a1 <= signed(c1) * signed(in1);
a2 <= signed(c2) * signed(in2);
a3 <= signed(c3) * signed(in3);
VHDL file_2:
wait until clk'event and clk='1';
a <= a1 + a2 + a3;
Why is Design Compiler croaking on such a small magnitude design ??
- Xerxes Wania
Xentec Inc., Canada
( ESNUG 272 Networking Section ) -------------------------------- [11/97]
Newton, MA -- start-up Adaptive Networks seeks an ASIC design eng. w/ C,
Verilog, Synopsys & Verification exp. No headhunters. "jallen@vhfcom.com"
|
|
