( ESNUG 377 Item 2 ) -------------------------------------------- [09/19/01]
Subject: ( ESNUG 372 #13 ) Users Complain About Sleazy Synopsys Licensing
> Dan's experience isn't unique. "Just don't heap too much praise upon
> Avanti until you get to know them," warned Dale Lomelino of Philips
> Semiconductors. "If anything, they have more warts and blemishes than
> Synopsys and Cadence combined. Avanti does not want to support standard
> formats like PDEF or LEF/DEF. Instead, they prefer to lock you into
> their 'unified binary Milkyway database' -- and hold you hostage."
>
> What use is any Best In Class P&R tool if you can't interface to it?
>
> - from "That Other Avanti Issue" ( EE Times 5/07/01 )
From: Tom Loftus <tloftus@intrinsix.com>
John,
I have an interesting thing I noticed about Synopsys license usage. In
certain circumstances, during a compile -scan command, it will apparently
perform optimizations which require the VHDL-Compiler or HDL-Compiler
license features, in addition to the Test-Compiler and Design-Compiler
features it already uses.
I find Synopsys licensing tactics like this ridiculous and I told the
support people that when I talked with them.
They really provided no avenue for me to express my opinion that gobbling
up multiple license features during execution of certain commands starts
to get ridiculous at some point.
I like to use batch type jobs and need to know the necessary license
features ahead of time for the jobs to succeed.
I probably waste more time in script development worrying about license
feature management than I do on other more important synthesis issues.
When some Synopsys tool doesn't work the way you think it should, the
Synopsys support response isn't "We'll fix it" -- the response is more
often than not, "That's the way the it is".
- Tom Loftus
Intrinsix
---- ---- ---- ---- ---- ---- ----
From: Romas Rudis <rudis@intrinsix.com>
John,
Synopsys seems to grab a VHDL-Compiler license for no apparent reason
during compile. I am running a Verilog-only synthesis with no DesignWare
(or other VHDL originated components):
read -f verilog srom_cntrl.v
...
remove_license HDL-Compiler
1
list -licenses
Design-Compiler
LUCENT-HL160C
LUCENT-LV160C
1
compile -map_effort medium
...
Optimization Complete
---------------------
Transferring design 'srom_cntrl' to database 'srom_cntrl.db'
Current design is 'srom_cntrl'.
1
list -licenses
Design-Compiler
LUCENT-HL160C
LUCENT-LV160C
VHDL-Compiler <<<<<*** Where did this come from?
1
Of course, I'm sure that Synopsys would prefer that we buy a copy of
VHDL-Compiler and HDL-Compiler for each copy of Design-Compiler that we
have. This would certainly solve the problem...
But, as you know John, I am a Verilog bigot, so the problem is even worse.
If anyone checks license usage, people will think I'm doing VHDL synthesis
runs and start making fun of me. IMAGINE IF THIS SITUATION HAPPENED TO
KURT BATY, WHAT PEOPLE WOULD SAY! Seriously though, I really have a problem
buying more VHDL-Compiler licenses just because, for some unknown reason,
my Verilog synthesis run grabs a VHDL-Compiler license.
So even though our LSF batch queues wait for a VHDL-Compiler licenses to
become available before execution starts, the fact the my Verilog job can
grab one randomly screws things up. If someone knows of a workaround please
let me know. The only workaround I know of is for VHDL users to ping for a
license like this inside their dc_shell script (pretty silly isn't it!):
/* Ping for license */
get_license VHDL-Compiler
/* Retry every 5 minutes (5*60=300) until license is obtained */
while (dc_shell_status == 0) {
echo "Couldn't retrieve VHDL-Compiler license. Retrying..."
sh sleep 300;
get_license VHDL-Compiler;
}
echo "Successfully Retrieved VHDL-Compiler License."
/* Now you can safely read in your VHDL code and be sure that you */
/* actually get a VHDL-Compiler license */
read -f vhdl filename.vhd
Of course this now ties up a Design-Compiler license until a VHDL-Compiler
license becomes available...
- Romas Rudis
Intrinsix
|
|
