Subject: "Political Correctness" On ESNUG Loses 23 to 2!
It appears I accidently triggered a referendum on Political Correctness
when I gave Burt Christian equal time when he objected to my comments about
Power Compiler being as good as "being stranded on an island with 20 Miss
Nude Universes". Burt Christian wrote:
> John, while I know that you were only being light-hearted, I find the
> above words excessively abhorrent and therefore feel compelled to exhort
> and check you.
A total of two letters (like bellow) supported a Politically Correct ESNUG.
> Burt, I agree with you. My parents, and my upbringing in the faith have
> taught me that this type of language is not right, is not constructive,
> etc. To me, this type of language only reflects the confusion,
> disorientation, and corruption in a human mind. It definitely provided
> the wrong information. I am glad you spoke against it.
>
> -- Yolanda M Pirez
> Motorola
But a surprizing 23 letters came in opposing a Politically Correct ESNUG!
> John: Oh no! Not another person reinforcing the notion that engineers
> are dull, stodgy, and ultra-conservative! I enjoyed your colorful review
> of Power Compiler, although I can see why a "reputable" publication
> would edit it. I look forward to reading your intros to ESNUG and can
> always expect something funny or interesting before jumping into the
> dry, technical stuff. If your posts weren't lighthearted, personal,
> and opinionated, it would just be another Solvit-Scout. Please don't
> censor yourself just because Mr. Christian and others "check" you.
>
> -- Brian Walkington
> CommQuest Technologies, Inc.
And two letters came in (humorously ?) complaining that I "sullied" the
Miss Nude Universe office by comparing it to EDA tools! :^O
- John Cooley
the ESNUG guy
( ESNUG 240 Item 1 ) ---------------------------------------------- [5/9/96]
Subject: ( ESNUG 239 #7 ) It's Not Wise To Synthesize ROMs
> You should not be trying to synthesize ROM or RAM from RTL. Small register
> files, maybe, but for anything beyond a few hundred gates, you may be MUCH
> better off with a memory generated by your Silicon vendor. Many provide
> memory compilers that generate the specific configuration you want from a
> set of architechtural choices.
From: neuman@lsil.com (Darren Neuman)
John, We have had a lot of luck with synthesized ROM's. However, there are
some guidelines to follow when choosing whether to synthesize or not:
1) Do not synthesize anything which may change the ROM code. This is
particularly applicable to ucode which may be updated in a later rev.
2) Smaller ROM's synthesize better. Larger ROM's do not. The useful cutoff
point is dependant upon a number of items: routing layers, ROM contents.
3) It's good if a ROM's contents are predominantly 0's or 1's. We've had
some DSP coefficient ROM's which was 2/3 0's in the ROM code (it was
512 x 25 bits) and it was actually smaller in synthesized *gates* in
layout than in ROM form (3 layer metal)!
The code was a huge "case" statement. Not elegant, but it works.
- Darren Neuman
LSI Logic
( ESNUG 240 Item 2 ) ---------------------------------------------- [5/9/96]
Subject: (ESNUG 228 #9 229 #1 230 #3) Synopsys DesignWare PCI Sucks
>My company has had considerable experience with Synopsys's DesignWare PCI
>product, most of it quite bad. Their basic problem was using a group of
>software developers to essentially design hardware while learning hardware
>design on the fly. They clearly had no experience with logic design at this
>level of complexity and this shows in the quality of their current product,
>as it is far from functionally correct. ....
From: Chuck Gollnick <chuckg@arnet.com>
Wow, Deepthroat there really had some valuable comments. I'm sure glad that
I asked ESNUG. Thanks for the help. With the growing popularity of PCI and
its several variants, perhaps some others found that valuable too. Poor
Synopsys, though. Nobody reported a positive experience with PCI DesignWare.
Ah well, it's a brutal, demanding market.
- Chuck Gollnick
Digi/Arnet Corporation
---- ---- ---- ---- ---- ---- ---- ----
From: Simon Davidmann <simond@vchips.com>
Hi John, Have you heard any more about Synopsys staying out of the PCI core
business? I heard they are still persevering, though they only have one
customer left (in Europe of course) - do you know of the US situation?
- Simon Davidmann
Virtual Chips, Inc. (formerly RAVIcad Inc.)
[ Editor's Note: After the ESNUG/PCI thread that ran last December, EE
Times ran an article stating that Synopsys had pulled the DesignWare
PCI part off the market. I did a little snooping around at the time
and found that the main problem with the Synopsys PCI part was that it
tried to be all things to all customers. That is, it had something
like over 200 parameters in it and therefore took as long as 40+
hours to synthesize -- a real nightmare. I think it was the right
thing to do in pulling the part at the time. That was six months ago.
I don't know if Synopsys has been reworking the part or is quitely
trying to forget about it; we'll just have to wait & see... - John ]
( ESNUG 240 Item 3 ) ---------------------------------------------- [5/9/96]
From: nickb@alpine.asic.sc.ti.com (Nicholas Barbieri)
Subject: What Does Power Compiler Really Get Us Power-wise?
John,
I'm mystified, so I need some assistance. I don't see why Synopsys is
putting so much effort into marketing Power Compiler. My experiments with
many designs (>20) show that core power typically accounts for less than
25% of the total chip power, with I/O and clock macro power the two
biggest consumers. If that is true, what difference will a few percent
saving from the core make? Is it worth buying an expensive tool? Are
there design examples that show a significant overall power savings? Not
being a battery-equipment designer, can anyone inform me by stating
definitively that such small savings make a difference in battery life?
When asked about this apparent disparity in demand for PC, Synopsys replied
that the other factors, such as external bus standards and RAM types, need
to be optimized to make power optimization of core logic more of a factor.
This seems after-the-fact to me, and frankly, unlikely to happen in most
cases. Do we have to redefine a PCI specification, for example, and spend
months optimizing custom RAM design to get any benefit out of PC? The
economics are unclear here.
On a related issue, I'm a bit disappointed in Synopsys' low-power design
methodology. It requires a significant amount of code modification by hand
to get low-power logic. Why can't they automate some of the techniques?
(As far as your comments about being edited, perhaps you should have added
a Java animation showing your tongue firmly planted in your cheek to your
message. I'm not a sexist, but I got the spirit of your humor.)
- Nick Barbieri
Texas Instruments
( ESNUG 240 Item 4 ) ---------------------------------------------- [5/9/96]
From: rainer@mucsun.sps.mot.com (Rainer Makowitz)
Subject: Backannotated Data Isn't Used By The Synopsys Floorplan Manager?
Hi John,
There was some brief coverage of Floorplan Manager in ESNUG earlier -- I hope
to get some comments on how to 'reoptimize_design' inside a hierarchy.
My problem: I read in cluster files (PDEF) and 'set load' scripts and select
a custom wire load model. When I do 'report_timing' from the *top level*
of the hierarchical design I get indication about the clusters in the report
and negative slack time. Yet when I do 'report_timing' *inside* a big module
that I want to reoptimize (the whole design takes days) there is no
indication that the report is using any backannotated information leaving
my slack time is positive!!?? (Likewise, 'reoptimize_design' on the sublevel
finishes without doing much. I have the feeling that the backannotated data
is not considered on any level other than the top level.) Has anybody out
there in ESNUG land have any idea how this works?
- Rainer Makowitz
Motorola Embedded Systems Group
( ESNUG 240 Item 5 ) ---------------------------------------------- [5/9/96]
Subject: (ESNUG 238 #1 239 #2) The Change_names v3.3b Command Is A Real Dog!
> John, when we run the change_names command in Synopsys on our whole chip
> (somewhere in the neighborhood of 60K - 100K gates), it goes *very* slowly.
> ... When I say very slowly, I mean that it renames 1 net every 3 or 4
> seconds! The command takes roughly 24 hours to complete. ... The best
> workaround for this is...
From: David Ellement <ellement@sdd.hp.com>
Hello John,
ESNUG 239 arrived just at the right moment. We had just waited about thirty
hours for change_names to finish on our 110K gate design. I tried out the
suggestions, and the time to finish dropped to fifteen minutes! I tried both
'change_names_update_inst_tree = false' with writing out verilog,
'remove_design -all', then reading in the verilog net list rather than the
'db', and just the 'remove_design -all'. For our design, almost all the
improvement come from removing the design and starting again without
constraints. (I later re-apply the constraints to generate reports).
I couldn't be more pleased with ESNUG!
Finally, with respect to the comments by Mr. Christian, freedom of speech
is rather hollow without the freedom to offend. I'm glad there still
exists at least one forum where both you and Mr. Christian can express
yourselves, regardless of whether or not some may find it offensive.
- David Ellement
Hewlett Packard
( ESNUG 240 Item 6 ) ---------------------------------------------- [5/9/96]
From: sgolson@trilobyte.com (Steve Golson)
Subject: (ESNUG 237 #4 238 #4) 2-D Arrays & Using "alias" To Mimic Functions
Hi, John,
David Ellement in ESNUG 237 #4 (and ESNUG 238 #4) gives a way to simulate
dimensional arrays in dc_shell. Dc_shell actually supports multi-dimensional
arrays, by using lists of lists. Here's an example:
dc_shell> row1 = {r1c1 r1c2 r1c3}
{"r1c1", "r1c2", "r1c3"}
dc_shell> row2 = {r2c1 r2c2 r2c3}
{"r2c1", "r2c2", "r2c3"}
dc_shell> row3 = {r3c1 r3c2 r3c3}
{"r3c1", "r3c2", "r3c3"}
Now combine these together into a list of lists:
dc_shell> array = {row1 row2 row3}
{{"r1c1", "r1c2", "r1c3"}, {"r2c1", "r2c2", "r2c3"},
{"r3c1", "r3c2", "r3c3"}}
If you want to add another row, be sure and put {} around the row when
you add it to the array:
dc_shell> row4 = {r4c1 r4c2 r4c3}
{"r4c1", "r4c2", "r4c3"}
dc_shell> array = array + {row4}
{{"r1c1", "r1c2", "r1c3"}, {"r2c1", "r2c2", "r2c3"},
{"r3c1", "r3c2", "r3c3"}, {"r4c1", "r4c2", "r4c3"}}
If you do a foreach on array, each element is itself a list:
dc_shell> foreach (element, array) { list element ; }
element = {"r1c1", "r1c2", "r1c3"}
element = {"r2c1", "r2c2", "r2c3"}
element = {"r3c1", "r3c2", "r3c3"}
element = {"r4c1", "r4c2", "r4c3"}
David also asks if there is a way to emulate functions without using global
variables to pass parameters. One technique is to use dc_shell_status to
pass arguments to an alias. The results can be returned in dc_shell_status
as well. Here is an example that extracts a specified element from a 2-D
array such as the one above:
alias get_element " \
foreach (element, dc_shell_status) { \
if (! list(row_index) ) { row_index = element ; continue ; } ; \
if (! list(col_index) ) { col_index = element ; continue ; } ; \
/* element contains the array */ \
remove_variable therow ; \
foreach (therow, element) { \
if (row_index==1) { break ; } ; \
row_index = row_index - 1 ; \
} ; \
/* now have therow */ \
remove_variable item ; \
foreach (item, therow) { \
if (col_index==1) { break ; } ; \
col_index = col_index - 1 ; \
} ; \
/* now have item */ \
/* clean up */ \
remove_variable row_index ; \
remove_variable col_index ; \
remove_variable therow ; \
/* leave item in dc_shell_status */ \
item = item ; \
} > /dev/null \
"
To get the third item in the second row of an array, pass a list of arguments
to the "function" get_element in dc_shell_status:
dc_shell> foo = {2 3 array}
{2, 3, {{"r1c1", "r1c2", "r1c3"}, {"r2c1", "r2c2", "r2c3"},
{"r3c1", "r3c2", "r3c3"}, {"r4c1", "r4c2", "r4c3"}}}
dc_shell> get_element
"r2c3"
dc_shell> the_answer = dc_shell_status
"r2c3"
The result is returned in dc_shell_status. Unfortunately any variable inside
your "function" are globally visible, so be sure to use remove_variable
whenever possible to keep things clean.
- Steve Golson
Trilobyte Systems
( ESNUG 240 Item 7 ) ---------------------------------------------- [5/9/96]
From: Eric Ryherd <eric@vautomation.com>
Subject: Sheep Dip! -- Synchronous Reset Thru An ALU Still Gives Xes!
Hi John,
I've run across another "FEATURE" of Synopsys that has landed me into a large
heap of Sheep DIP! I have a design that has a number of registers that are
all fed by a simple ALU. Rather than have all of the registers use an
asynchronous reset (at a cost of 1-2 gates per D FF), I simply have the ALU
perform the following operation:
0 "AND" X
And then load the resulting 0 in all of the registers by simply enabling all
of their clock enables. Now, 0 "AND" X normally would produce 0 on any
output of the ALU. After all, 0 "AND" *anything* should be 0, right?
-- well, *not* according to Synopsys! I still get Xes out of my ALU!
Naturally when I try to run my gate-level simulation I never even get out of
reset!
From reading various SOLVIT, app notes and online docs, I see where I could
add the attribute sync_set_reset if there were some registers to attach it
to. But since the block in question is purely combinitorial, what can I do?
(BTW: The code is in VHDL and I'm using V3.4a and targeting the CCL .6 um
CMOS library.)
- Eric Ryherd
VAutomation Inc.
( ESNUG 240 Item 8 ) ---------------------------------------------- [5/9/96]
From: pccmf@attme.cnet.att.com (Cameron Forbes)
Subject: How Do You Do Incremental Synthesis On SRAM Based FPGA's?
John !
Burt Christian should really chill out, though I sincerely hope you don't
relinquish your first-born for a hot new EDA tool, John! :)
On a more serious note, have you heard of any way to perform incremental
synthesis for SRAM based FPGA's ?
- Cameron Forbes
Lucent Technologies
( ESNUG 240 Networking Section ) ---------------------------------- [5/9/96]
Allentown PA - Lucent Technologies, seeks App Engrs. well versed in Synopsys
synthesis. NO HEADHUNTERS! "gilbert.nguyen@lucent.com" or 610-712-2928.
|
|
