( ESNUG 143 Item 1 ) ---------------------------------------------- [8/93]
Subject: (ESNUG 139 # 5) "Want Opinions on Synopsys Training"
>
> Also, I was thinking that maybe you could pass on some objective evaluation
> of Synopsys' training classes.
[ Editor's Note: Because of the possible personal nature of any
response to this question, I'm making each response anonymous,
no names and gender neutral. - John Cooley, ESNUG Moderator ]
-- -- -- -- --
From: [ First Reply ]
I took a class with some of my associates from Synopsys a few weeks ago
taught by [ XXX ]. We were all very impressed. Although I felt that some
of the information should have been included in the manuals, it was still
well worth the tuition fee for the class. Our instructor knew his stuff
and if we asked something he didn't know, he checked on it later and got
back to us. The class helped fill in a lot of the "gaps" (ie. little
questions about features/philosophies that I had).
The bad news is, you'll probably want to re-synthesize a bunch of your
stuff after attending this class because you've probably been doing some-
thing wrong.
-- -- -- -- --
From: [ Second Reply ]
John, this should be posted as anonymous.
We have not used Synopsys training for a couple of years (since the early
days of version 2.0). At that time, we found the training sessions to
be more of a marketing tool than something that would prepare the user
for the problems you encounter when you push the limits of an ASIC design
technology. In that Synopsys training, only basic capabilities were taught.
And, if it was hard to do - it wasn't in there.
We created our own Synopsys training that taught the basics contained in the
vendor's training - but also stressed translation strategies, hierarchial
design methodologies, and identifying & resolving timing violations.
Since more than two years has passed, the Synopsys training may be more
realistic than it was at that time. I cannot comment on the current
training available from Synopsys. But, if everything is easy and push-button
in the training... beware.
( ESNUG 143 Item 2 ) ---------------------------------------------- [8/93]
From: Synopsys Hotline & Corporate Applications Engineering Teams
Subject: With 2.2b, 3.0a with 3.0b, Use The 3.0b Licencing Daemon!
There has been a significant amount of call activity on the Synopsys Hotline
on the v3.0b license management software and the compability of v3.0b
software executables with older releases.
V3.0b's license management software is compatible and supports v3.0a and
all v2.2 releases of software. HOWEVER, your v3.0b executables will
only work with v3.0b's license management software. NOTE: Only the network
license software changed; NO new keys are required. To clarify: In order
to run v3.0b executables with network licensing, you MUST use the license
managment software provided with v3.0b release.
Let's assmue you wish to install v3.0b and still want to use v3.0a or v2.2.
(This example assumes a single license server setup.)
1.) Install v3.0b (after reading the installation guide that comes with
the v3.0b release first!).
2.) Copy the key file from the v3.0a release to the admin/license
directory of your v3.0b installation. Edit the "DAEMON" line of
the key file so that the directory path points to the v3.0b synopsysd.
3.) Shutdown your v3.0a license daemon. CAUTION: Since you will be
switching license management software versions and the daemon directory
path will be in a different location, any currently running Synopsys
jobs may not re-establish a license connection to the license daemon!
4.) Invoke the v3.0b license daemon. Check the license log file to make
sure all the licensed features are up and running. Be sure to test the
invocation of the license daemon by invoking one of the Synopsys tools.
5.) Edit the DAEMON path of the v3.0a (or v2.2b ) key files to be the same
as the v3.0b key file -- you could do this by copying the v3.0b key
file you edited or by creating symbolic links to the 3.0b key file.
NOTE: If you are running a multi-server network licensing configuration,
all the license servers must be running v3.0b network licensing software to
support v3.0b. If you have any questions regarding this ESNUG posting,
please send them to John Cooley for posting here.
- Synopsys Hotline & Corporate Applications Engineering
( ESNUG 143 Item 3 ) ---------------------------------------------- [8/93]
From: greg@cqt.com (Greg Bell)
Subject: Characterize Letting Submodules Inherit Big Wire Loading Models
John :
Do you know why the characterize function places the top module's wire
load module on the cell you're characterizing?? This seems wrong to me.
It means that if I have a 40K gate die size on the top level, and I
characterize a 100 gate sub-module, that sub-module ends up with delays
for the 40K gate die! I have been undoing this "feature" after every
characterize (big pain in the butt). Any suggestions?
- Greg Bell
CommQuest Technologies, Inc.
( ESNUG 143 Item 4 ) ---------------------------------------------- [8/93]
> Subject: ( ESNUG 141 #1 ) "Inconsistant References Problem During Synthesis"
>
> I am having a lot of problems synthesizing a particular design. I get the
> following message:
>
> Error: Inconsistent references found for cell '*SELECT_OP_1_1_1'. (OPT-205)
>
> Has anybody seen this and understand whats causing it. I think its something
> to do with asynchronous resets on latches/flip-flops. I have this problem
> with 3 out of 5 sub-blocks in a design I have. (As best I can tell)
From: bobv@hwcae.az.honeywell.com (Bob Valicenti)
You probably have a dont_touch_network on your async reset pin. Some people
do this so that the Reset net will not have any buffering or design rule
improvements, and the timing analyser will not time from the reset pin and
give you unnecessary timing results.
The dont_touch_network causes synopsys to have problems in the mapping phase,
but will eventually map to the desired flip flops.
If you remove the dont_touch_network, you probably won't get the error.
- Bob Valicenti
Honeywell Commercial Flight
( ESNUG 143 Item 5 ) ---------------------------------------------- [8/93]
From: Axel Jantsch <axel@inmic.se>
Subject: Synthetic library component DW01_OR2 and its attributes?
John,
With version v3.0a-10063 I get the following errors during mapping:
Error: The entity 'DW01_OR2' depends on the package 'ATTRIBUTES'
which has been analyzed more recently.
Please re-analyze the source file for 'DW01_OR2' and try again. (LBR-28)
Error: size : Can't get model for 'DW01_OR2'
in parameter 'area_estimate'
in module 'DW01_add', implementation 'cla'. (SYNL-13)
Error: The entity 'DW01_OR2' depends on the package 'ATTRIBUTES'
which has been analyzed more recently.
Please re-analyze the source file for 'DW01_OR2' and try again. (LBR-28)
Error: size : Can't get model for 'DW01_OR2'
in parameter 'area_estimate'
in library specification for module 'DW01_add', implementation 'cla'.
(SYNL-13)
I have to use the files: types.vhd, arithmetic.vhd, attributes.vhd and
synopsys.vhd of the synopsys_old directory.
I couldn't find any file where the component DW01_OR is defined, and I do not
quite understand what the error message really means. Can anybody give me a
hint, what the problem is and how to solve it?
- Axel Jantsch
KTH-Electrum
|
|
