Editor's Note: Just when I finally get used to my native Boston time zone,
I once again find myself flying back to Silicon Valley next Monday on a
consulting job. My girlfriend knows that I'll be gone all next week and
does she plan a romantic weekend for two before I go? Not hardly!
Instead, she informs that we *WILL* be spending Friday afternoon and all
day Saturday & Sunday standing next to traffic intersections holding
"Ted Kennedy '94" signs while waving *cheerfully* at the strangers
in the passing cars. (Note: "cheerful" isn't an option; it's an order!)
(She's very involved with the Kennedy campaign.) I tell her I'm returning
on Nov. 6th and she's ecstatic because I'll be back in time to vote!
Talk about romance. :^o
- John Cooley
the ESNUG guy
( ESNUG 200 Item 1 ) ---------------------------------------------- [10/94]
Subject: (ESNUG 197 #3 198 #4 199 #5) "Static vs. Dynamic Power Analysis"
>>To increase your chances of getting things right, remember to use
>>asynchronous stimulus (i.e. not all of the signals of a data bus arrive
>>at the same time.)
>This may be exactly why an analytical (static) rather than an empirical
>(dynamic) power analyzer is needed: you *want* to hit the circuit with just
>the right timing so that the power spike is at its maximum. Any other
>scenarios are not as interesting.
From: [ No Name, No Nothin ]
Hi John,
You know me, no name, no address, no nuthin. I suffer from Synopcosis, fear
of corporate reprisals from you know who.
There is generally nothing interesting in a single power spike, except from
the EMI/EMC standpoint. I've had designs with 60W-100W power spikes in the
1-2 ns range and the result is 'so what'.
Remember the point of power analysis is to find the normal operation power,
not some theoretical maximum. In reality, a dynamic analyzer will show you
the biggest spike; it always occurs when you hit the first master reset in a
simulation. The analyzer will consider each unknown to known transistion to
be both a power consuming and power non-consuming event and then it will give
the min and max for that time. In my opinion, power analysis cannot be
accurately achieved via any static tool.
- [ No Name, No Nothin ]
( ESNUG 200 Item 2 ) ---------------------------------------------- [10/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: jiml@qualis.com (James W. Lewis)
Hi John, it does not seem to be a problem with understanding $USER as the
following does work:
sh ls my_file | mail $USER
I tried several other things but did not seem to be able to get it to work.
It looks strange. Could be a bug or a lack of support for some sh features.
To answer the other part of your question, to get an environment variable
from UNIX, use:
SYNOPSYS_DIR = get_unix_variable("SYNOPSYS")
Now use it just like another synopsys variable:
system_cache = SYNOPSYS_DIR + "/libraries/syn"
As far as finding this in the on-line doccumentation, check out the
application notes section. In particular, dc_shell Scripts for Synthesis.
- Jim Lewis
Qualis Design
---- ---- ----
From: macauley@vnet.ibm.com (Kevin Macauley)
A friend of mine found the answer to this one. We use the following inside
of our ".synopsys_dc.setup" files so it should work fine for you.
synopsys_setups = get_unix_variable("DSP_SYNOPSYS_SETUPS")
include synopsys_setups + "/techi.synopsys_dc.setup"
Just change the DSP to USER. (Of course, to be really smart you could then
set designer to be the USER variable).
- Kevin Macauley
IBM
---- ---- ----
From: Hiroshi Kawashima <kei@sm.sony.co.jp>
Hello John, Maybe this is what you want:
get_unix_variable("USER")
user_name = dc_shell_status
sh ls -l netlist.v | Mail -s "'Netlist-completed'" user_name
- Hiroshi Kawashima
Sony Corporation
( ESNUG 200 Item 3 ) ---------------------------------------------- [10/94]
Subject: (ESNUG 199 #6) "Is 1993 VHDL Syntax FULLY Supported in VSS?
> Question 1:
> Does Synopsys ver 3.1b fully support 1993 syntax VHDL ? (YES/NO)
> If NOT fully supported, then WHAT other syntax should I be aware of?
>
> Question 2:
> Do I have to code using only 1987 syntax to be on the safe side ? (YES/NO)
From: John.Messenger@proteon.com (John Messenger)
To question 1: No, VSS version 3.1b doesn't fully support ANSI/IEEE Std
1076-1993 and does not claim to.
To question 2: Yes, you have to code only in 1987 syntax to stay on the
safe side. Even then, if you're a purist, watch out because (like most
simulators) there are some differences. The most annoying is that it
restricts the range of universal integer to 32bit values (which is not
allowed). So if you say USE_LONGTIME = TRUE and then say (NOW / 1 fs),
you may get a crash.
- John Messenger
Proteon International
( ESNUG 200 Item 4 ) ---------------------------------------------- [10/94]
Subject: (ESNUG 196 #6 198 #1 199 #1) "Hotline Refuses To Help Via E-mail"
Synopsys Support writes:
> In reality, the engineers at the Synopsys Support Center prefer the use of
> email when resolving issues ... Currently, 15% of our issues are initiated
> and resolved via email and for the above the reasons we would like to take
> this opportunity to encourage its use when working with the Support Center.
From: zkhan@pcocd2.intel.com (Zia Khan)
John:
This note from Synopsys (ESNUG 199 #1) describes a very good policy.
Unfortunately, it is not followed at all! 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 via 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 Solv-it
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
Solv-it 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.
- Zia Khan
Intel Corp.
---- ---- ----
From: Aedan Coffey <coffey@toucan.ie>
Hi John,
Keep up the good work; yours is the only regular newsletter that always gets
read here.
Regarding the email apps support issue, I can only say I've had no problems
dealing with the Synopsys UK apps people by e-mail. I've been delaing with
them electronically for about three years now.
- Aedan Coffey
Toucan Technology
---- ---- ----
From: david@subasic.sciatl.com (David Burleson)
I have submitted several questions to Synopsys by e-mail that were answered
by e-mail. In every case I got a phone call a few days after the e-mail
to verify I was satisfied with the results and close the issue. This method
has worked for me and avoids the annoying game of telephone tag.
- David Burleson
Scientific Atlanta
( ESNUG 200 Item 5 ) ---------------------------------------------- [10/94]
From: brooks@dvs.com (Walter Brooks)
Subject: Altera, FPGA Compiler & Design Compiler
Concerning Synopsys and Altera devices... The FPGA compiler does not work
any better than Design Compiler. This is due to Altera not shipping a
'FPGA Compiler' version of the libraries, only 'Design Complier' style.
This may change in the future.
Another side note if you decide to use Altera: make sure you turn of ALL of
Altera's re-synthesis options. I have found that the results are much better
if Synopsys does ALL of the synthesis, and Altera just does the routing.
- Walter Brooks
Scientific Atlanta Canada
( ESNUG 200 Item 6 ) ---------------------------------------------- [10/94]
From: d_pinvidic@qlc.com (Dan Pinvidic)
Subject: Concerns About SolvIt Solution To CMOS2 Long Runtimes Issue
John,
I am seeing excessively long compile times with ver. 3.1b for sequential
logic. The suggested workaround (SolvIt QA-008611):
> Workaround:
>
> /* Sample Script File */
>
> read -f vhdl design.vhd
> read h4c.db
> set_attribute find(library, h4c) delay_model "generic_cmos"
> link -all
> compile
> remove_design h4c
> read h4c.db
> link -all
> compile -incremental
> write -f db -hier -o design.db
>
> The above example script reads a library called "h4c" into memory.
> The delay model is then changed from CMOS2 to generic cmos
> using the set_attribute command. This step forces Design
> Compiler to use the Generic CMOS delay model although the
> library uses the CMOS2 modelling attributes.
>
> Compile the design with the generic CMOS model. The timing
> values will not be correct during the first compile since a
> different delay model is being used. However, they are close,
> because the intrinsic and transition delays are similar
> between the Generic CMOS and CMOS2 delay models.
>
> Then do an incremental compile with the original library (using
> the CMOS2 delay model) to clean up any remaining violations.
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...
Workaround #1
compile_use_low_timing_effort = "true"
new_seqmap_effort = 1
Workaround #2 (This reduced it from 5 1/2 hrs to 50 minutes)
hdlin_seq_device_v30_mode = true
improved_seqmap = 0
disable_sequential_degeneration = 0
- Dan Pinvidic
QLogic Corp
|
|
