Editor's Note: There I was flying home from a consulting job in Silicon
Valley catching up on my back reading when I saw in the July issue of
ASIC & EDA (OK, some I'm a little late in my reading) an article on
"Third Party ASIC Design Services." I was happy to find myself listed
on pg.58 until I saw the phone number! (Yikes! That AIN'T me!) After I
got off the plane, I immediately called the number and got a kind elderly
woman who answered the phone saying: "I'm sorry, John Cooley doesn't live
here. You must have the wrong number." Aaaaaargh! I'm at (508) 429-4357!
- John Cooley
the ESNUG guy
( ESNUG 201 Item 1 ) ---------------------------------------------- [11/94]
Subject: (ESNUG 199 #4) "Silly dc_shell/Environment Variable Question"
> I have a script in which I want to:
>
> sh ls -l netlist.v | Mail -s \"Netlist-completed\" $USER
>
> I want to mail to $USER instead of "designer" since we do not always
> have this variable set from user to user. $USER does not work, I can't
> seem to get access to Unix environment variables or get them into a
> dc_shell variable. Can it be done?
From: poorna@S3.COM (Poorna Rao)
I was able to do the above with a very small modification, i.e. enclose the
argument to sh in quotes:
sh "ls -l netlist.v | Mail -s \"Netlist-completed\" $USER"
The reason you have to do this is because of the phrase Netlist-completed
in quotes. The following will also work:
sh ls -l netlist.v | Mail -s Netlist-completed $USER
- Poorna Rao
S3 Incorporated
( ESNUG 201 Item 2 ) ---------------------------------------------- [11/94]
From: Sean_Atsatt@notes.seagate.com (Sean Atsatt)
Subject: Design Compiler Producing Beaucoup Overdriven Nets
John, We have a problem with Synopsys inserting extremely powerful buffers
to drive nets with small loads (i.e. a buffer designed to drive a fan
out of 180 or more driving a fanout of 1 or 2). The tool appears to do this
in an attempt to meet timing constraints. When you work out the delay
calculations for the instances where the strong buffers are inserted the
stronger buffers may be marginally faster than a normal buffer by a only few
picoseconds. (This turns out to be the case because the intrinsic delays of
the stronger buffers are less than that of the simple buffers, and the drive
strength of the device driving the buffer is enough to overcome the added load
from the strong buffer.)
Synopsys is technically correct for choosing the stronger buffer and our
library is also correctly representing the characteristics of the device.
The problem is that we can't simply not use the strong buffers as
we have many cases where they are actually required (so we can't just put a
dont_use on the strong buffers in the library) -- but we end up with
literally hundreds of overdriven nets (which also costs us significant area).
We have developed scripts which reduce the number of overdriven nets by
iteratively compiling with and without a dont_use on the strong buffers -- but
we still end up with dozens of overdriven nets. Has anyone else, had this
problem? Does anyone know of a good work around ?
- Sean Atsatt
Seagate Technology
( ESNUG 201 Item 3 ) ---------------------------------------------- [11/94]
Subject: (ESNUG 200 #6) Concerns About SolvIt Solution To CMOS2 Long Runtimes
>I am seeing excessively long compile times with ver. 3.1b for sequential
>logic. The suggested workaround (SolvIt QA-008611):
>
>> Workaround:
>>
>> read -f vhdl design.vhd
>> read h4c.db
>> set_attribute find(library, h4c) delay_model "generic_cmos" ......
From: [ A Synopsys Apps Engineer ]
Hi John -- the SolvIt article, QA-008611, does not exist. (We've had people
polling SolvIt trying to download it. The text he quoted is actually
from article QA-009985.) The workaround explained in article QA-009985 only
works with the CMOS2 delay model.
Concerning the user's question of:
>This is a method of reverting back to 3.0 compatability and it makes me
>wonder what the new release brings to the party. The following variables
>(that weren't mentioned in this SolvIt write-up) reduce the compile time,
>but I wonder if there's some unseen penalty I'm paying using them...
I'd like to point out SolvIt article QA-010021. (Which can also be found in
the v3.1b release notes.)
"In v3.1b and v3.2a, improvements have been made to the compilation
time with non-linear delay model libraries and CMOS2 libraries,
respectively. If you feel your runtimes are still too long, the
following workarounds will still be effective.
WORKAROUNDS:
FOR NON-LINEAR DELAY MODEL:
1. Compile with compile_use_low_timing_effort = "true". This switch
only affects compile, your timing reports will be produced using
exact timing. During compile, approximate delays will be used for
input transitions.
2. Set the variable new_seqmap_effort = 1 before compilation. This
runs the v3.1a sequential mapping algorithms at a lower effort level.
3. Before reading in or analyzing the VHDL, set the variable
hdlin_seq_device_v30_mode = true. Then before compilation, set
improved_seqmap = 0 and disable_sequential_degeneration = 0. This
will completely turn off the v3.1a sequential mapping algorithms and
revert back to v3.0x method of sequential mapping.
Try the workarounds in the following order: #1 alone, #1 and #2, #1 and #3.
FOR CMOS2 DELAY MODEL:
1. Set the variable new_seqmap_effort = 1 before compilation. This
runs the v3.1a sequential mapping algorithms at a lower effort level.
2. Before reading in or analyzing the VHDL, set the variable
hdlin_seq_device_v30_mode = true. Then before compilation, set
improved_seqmap = 0 and disable_sequential_degeneration = 0. This
will completely turn off the v3.1a sequential mapping algorithms and
revert back to v3.0x method of sequential mapping."
NOTE: hdlin_seq_device_v30_mode is a v3.1b variable.
- [ A Synopsys Apps Engineer ]
( ESNUG 201 Item 4 ) ---------------------------------------------- [11/94]
Subject: (ESNUG 198 #1 199 #1 200 #4) "Hotline Refuses To Help Via E-mail"
>Our experience has been that the performance of Hotline took a nose dive
>early this year and they have never recovered from it. (My guess is that
>they drastically cut down the staff.)
>
>I personally prefer e-mail. But my experience has been that they usually
>take about a week to 10 days to get back to you by e-mail. (Imagine having
>to wait a week to resolve a bug when you are in the middle of a hot project.)
>
>In most cases I found that hotline did not answer my question. Instead they
>answered soemthing that I did not ask. Also they tell you to look up SolvIt
>which often does not have anything on the subject (it has all the old stories
>but every new release usually has "new" set of bugs that have not made it to
>SolvIt yet.) In my company we now do not use the Hotline any more. (No
>one wants to slip project schedules while waiting for Synopsys to respond.)
>If we have a serious problem we call the Application Engineer who handles
>our account. In most cases that is faster and the answer is correct.
From: [ Bob Dahlberg - Synopsys V.P. of Application Services ]
John,
This user is correct that the U.S. Synopsys Support Center has suffered a
degradation in service capacity over the past several months. Our
performance drop occurred when skilled application engineers transferred to
new positions in different parts of the company combined with not replacing
them fast enough. It was *not* due to a decision to reduce Support Center
capacity. Since July, we have successfully returned the staffing level of
early '94. We are now working to train them, and to increase the staff an
additional 50%. It will take a few months for these new engineers to
become fully competent in the Support Center, but we expect email/telephone
service to return to satisfactory levels in the December time-frame.
Our goal is to put the solutions directly into our customer hands. In
other words once when we have solved a problem for an engineer in Japan, we
don't want to have to solve it again in Germany. With SolvIt we are
endeavoring to publish the *worldwide Synopsys tool experience*, put this
knowledge directly into our customer's hands, and update it in real time.
In short: timely information with no human bottleneck front end!
We are now very confident that SolvIt will go well beyond an individual FAE's
ability to keep up with the latest information. We just completed a survey
of 83 SolvIt users. Respondents told us that 48% of their issues were
*directly* solved, and another 38% of respondent issues were solved because
SolvIt gave enough information to enable the engineer to solve their own
problem faster than the return phone call from an FAE or the Support Center.
In addition to automating problem solving, we are *definitely* committed to
building a competent team to solve the problems we haven't seen before.
SolvIt reduces the repetitive nature of a Support Center tasks, so we can
now attract people that enjoy solving challenging problems. To improve
access to this resource, we are now testing a low cost alternative to on-site
consulting called On-Call Consulting. This service enables customers to
access to a competent, specific Support Center engineer who sticks with you
throughout your design process. This engineer will come to understand the
customer's design style in-depth and will be a committed customer resource
(i.e., she won't leave to attend trade shows, or disappear to support the
pending big sale.) This will deliver even better service to the customers
that recognize its value and are willing to pay for it.
As always, we encourage Synopsys customers to share their ideas on how we
can improve our support effectiveness.
- Bob Dahlberg, Vice President of Application Services
Synopsys, Inc.
( ESNUG 201 Item 5 ) ---------------------------------------------- [11/94]
From: mkphilli@netcom.com (Mike Phillips)
Subject: Can't Get Rid Of "_architecture" !
Does anyone know how to get Synopsys to not append
_architecture, architecture_2, architecture_3, etc.
to the architecture name when writing structural VHDL netlists? (We are back
annotating delays from our ASIC vendors tools (LSI Logic), which requires the
architecture name to be "structural_view". I have changed the variable:
vhdlout_architecture_name to "structural_view"
but Synopsys appends _architecture, _architecture2, etc. to the architecture
names.
Example:
architecture structural_view of TOP is
[ stuff deleted ]
end structural_view;
architecture structural_view_architecture of SUBMODULE is
[ stuff deleted ]
end structural_view_architecture;
^^^^^^^^^^^^^ ---- > I don't want this!
architecture structural_view_architecture2 of NEXTSUBMODULE is
[ stuff deleted ]
end structural_view_architecture2;
^^^^^^^^^^^^^^ ---- > I don't want this!
- Mike Phillips
E-Systems
( ESNUG 201 Item 6 ) ---------------------------------------------- [11/94]
From: jmott@atmsys.com (James Mott)
Subject: Seeking User Wisdom On Floorplanning Tools
John,
I'm trying to decide the best approach to floorplanning, and I've never used
the Synopsys floorplanner, though I've used vendor floorplanning tools before.
Can anyone comment on the relative merits of Synopsys floorplanner vs.
vendor supplied floorplanners? I think it shapes up like this:
Vendor floorplanners:
You must have a vendor specific netlist to use a particular ASIC vendor's
floorplanner, which implies that the backannotation from the floorplanner
would not feed back to Synopsys at the RTL level (prior to the mapping to
vendor specific cells). Consequently some timing problems (those requiring
re-synthesis, as opposed to buffering) might not be solvable this way.
I think backannotation from a vendor's floorplanner would only work for
sizing buffers & outputs driving block to block in a design's top level.
Synopsys floorplanner:
Are there any ASIC vendors who support feeding the data forward to the
vendors placement tools from the Synopsys tool? Does Synopsys translate
to the ASIC vendor's coordinate system? Does it compute block utilization
levels for each vendor? What does it do when it doesn't know the target
vendor?
Has anyone used this tool, and did it reduce their design time? If so, is
it worth the admission price?
Which is the better route for timing analysis (Synopsys or vendor)? Is a
combined approach (both tools) best, or are they redundant or incompatible?
Please either write publically or anonymously to ESNUG on this!
- Jim Mott
ATM Systems
|
|
