Editor's Note: I've been a little distracted today. It's been kind of
hard to concentrate on my work for the past two days. Four years ago,
while taking a personal growth seminar, I met this great woman who was
taking the same seminar and we instantly hit it off. Our personalities
"clicked" perfectly. Her name was Sue and if she was 20 years younger, I
probably would have made her my girlfriend at the time. But, with the
large age difference remaining, we became good friends and we evolved into
being "hunting buddies". That is, Sue and I both love going dancing.
Sometimes we'd bring a crowd of friends along; other times is was just she
and me. Either way we'd be going out to some biker bar that had great
blues, or to a bar with great reggae, or to a singles dance filled with
the jittery newly-divorced, or to a house party, or giving a house party.
As hunting buddies, my job was to scope the room for eligible men in the
late 40s early 50s age range who could dance, had some sort of income,
and no serious personal "problems" (like being married for instance!);
and then arrange for her to "accidently" meet the good ones. She did the
same for me with the ladies in the late 20s early 30s age range. Our
secondary hunting buddy duty was to provide a "sanity check" for each
other concerning who we found ourselves flirting with near the end of an
evening. (Sometimes beer goggles or just plain being dumb can cause you
to consider matching up with someone you know you shouldn't match up with.)
I also can't tell you the number of times at the end of an evening of
dancing where Sue walked up to me and said (depending on what man she met
that night) "Pretend you're my son, John!" or "... you're my housemate!"
or "... my possesive boyfriend!" or "Pretend you don't know me!"
We've shared some really fun (and sometimes bizzare) adventures over the
years. :^)
Ten days ago (and two weeks after the big surprize 50th birthday we held
for her), Sue went to the doctor and found out she has an ovarian cyst
the size of a large orange. And the tests have indicated cancer. So
now, ten days later (today), Sue is in the hospital having surgery.
And I've found myself somewhat distracted today.
- John Cooley
the ESNUG guy
( ESNUG 313 Item 1 ) ---------------------------------------------- [3/99]
From: "Terry Ragsdale" <ragsdale_terry@jpmorgan.com>
Subject: Bigwig Wall Street Analyst Wants To Connect With Engineers
John,
I am a securities analyst covering semiconductors at J.P. Morgan, and I
spend a fair bit of my time on Altera, Xilinx, Lattice, and LSI Logic.
Somebody recently suggested to me that I would probably learn a lot from
ESNUG. Is it as simple as just asking to be added to the mailing list? If
so, please do.
Separately, I'd like to develop some contacts among designers so that I
have some live people that I can ask about things like whether Xilinx's
Spartan is truly a useful device or too de-featured to be of any use and
whether Lattice's new BIG family (8000 I think) is going to make it. Also
about things like whether the minimum order quantities for ASICs are
getting so big that PLDs are indeed likely to take a larger share of
low-gate-count ASICs. Virtex vs. APEX, etc.
Do you have any suggestions about how I might find such people? I honestly
don't know what their incentive to talk to me would be, other than the
minor ego gratification of educating a Wall Street analyst on what's really
going on out there. I do find most engineers that I come across are quite
willing to talk, as long as the conversations are brief. I try to attend
PLDCon every year, but I'm often trying to do 12 things at the same time,
and my networking nevers seems to work very well.
Anyway, thanks for any counsel you can give me.
- Terry Ragsdale
J.P. Morgan
( ESNUG 313 Item 2 ) ---------------------------------------------- [3/99]
From: [ "Sam, I Am" ]
Subject: Synopsys Issues Vague Warning About VCS 4.2.2/5.0.1 Encryption Bug
John,
Please keep me anonymous. Hey, have you seen this?
verilog_simulation-232.html
VCS Encryption Bug
VCS 4.2.2 and VCS 5.0.1 contain a number of bug fixes, including a fix for
a source encryption bug which could compromise the security of an
encrypted model under certain unusual circumstances. This situation could
only arise in the 4.2, 4.2.1 or 5.0 versions of the product. Corresponding
versions of VCSi could also exhibit the same problem.
The updated releases of VCS namely VCS 4.2.2 and 5.0.1 will be available
for ftp download by February 26, 1999. The corresponding VCSi versions
will be available by March 5, 1999.
Synopsys highly recommends that all VCS users upgrade to the newer
versions when they are available, especially if users distribute encrypted
models. The new versions introduce a new encryption algorithm available
under a command line switch "+newprotect". Model distributors will need to
re-encrypt their existing models using the new versions of VCS while
specifying the +newprotect switch to take advantage of the improved
security and re-ship them to their end users. End user's of these new
models will also need to upgrade to the new version of the VCS software.
The new encryption algorithm will be made default by the next VCS release,
namely VCS 5.1.
Source encryption is one of the options VCS provides to distribute models
to end users. Source encryption is inherently less secure than VMC & IPX
technology which VCS also provides. Since last year Synopsys has been
supplying IPx technology free of charge to VCS customer under maintanance.
More information on IPx is available at:
http://www.synopsys.com/news/announce/press/ipx_pr.html
If you would like ftp download instructions for the new releases or if you
have any questions, please send an email to "VCS_support@synopsys.com".
Does this mean that all my source code encrypted with VCS 4.2.2 and 5.0.1 is
now readable by others???!!
- [ "Sam, I Am" ]
( ESNUG 313 Item 3 ) ---------------------------------------------- [3/99]
From: [ A Different Cisco Kid ]
Subject: "We Liked Verisity's Specman" But This Was Before "e" 3.0 Changes
John,
Please withold my name and email address.
I had a chance to use Specman for the first time on a project a few weeks
ago and I wanted to report my experiences with the tool. Our group had
evaluated both Vera and Specman as alternatives but decided on using
Specman based on:
- a strong endorsement from another group at Cisco that has been
successfully using the tool for over two years.
- the constraint-based vector generation features
- a good demo of the OO-based layering capabilities that addressed
the way we believed the environment should be partitioned
- Verisity support to help build our first project's environment
Our chip in question already had a suite of directed tests and some random
tests in Verilog, written over a year's time. The goal of our exercise
was to build a sophisticated random environment that could wring out some
more bugs. We hoped to re-use most of this work subsequent projects.
Circumstances beyond our control necessitated that the effort conclude in
five weeks.
Our experience with Specman have been very positive. With the AE's help,
we had the environment up in two weeks and, over the next two weeks, found
some serious bugs that the existing Verilog tests hadn't found.
The constraint generator is very powerful.
It allowed us to generate many different kinds of random traffic with
elegant and compact extensions to the core set of constraints. This is
one of the best parts of the tool.
The OO-derived approach allowed us to build a core set of modules that
can be used for other projects. The extensions and constraints to the
core modules were well isolated in device specific files and tuned
the behaviour of the environment to the use at hand.
As we became more familiar with the "e" language, we found a wealth of
well-thought out primitives that made the job of building the environment
much easier. In particular, the "list" primitive, with its many predefined
methods seemed a natural fit for building many stubs driving stimulus
as well as for monitors that checked correctness of the chip's behaviour.
The GUI-based debugger is well integrated with the tool and was both
powerful and easy to use. It allowed us to find the causes of failure,
either programming or RTL, very quickly because of the intuitive
representation of the data structures and thread tracing. Windows where
breakpoints are set or thread status examined show the actual source code
written with the appropriate sections highlighted.
I think you can deduce that we were rather pleased to find the tool better
in practice than in the "advertisements", a rare occurrence these days.
There are some drawbacks to using Specman, primarily the learning curve,
but they weren't such a big factor for our group:
the unique language -- it takes a while getting used to the
peculiarities of the syntax & naming conventions
selection of constructs -- we got a jumpstart on this issue because
the field engineer provided a lot of help while
our environment was being built.
In general the Verisity field support has been very quick in responding to
questions and having issues resolved. Verisity is alpha-testing a set of
methodology guidelines that layer over the normal documentation. It seems
to cover one of our areas of concern.
- [ A Different Cisco Kid ]
[ Editor's Note: Recently, a Synopsys/VERA salesman (VERA is Specman's
rival) told me that Verisity has fundamentally changed the Specman "e"
language such that "e" 3.0 is no longer backward compatable with its
pre-3.0 versions. The VERA salesman bragged that he was getting a good
number of angry Specman customers switching over to VERA because of this
lack of backward compatibility. Can any users out there confirm or deny
Verisity did this and, if yes, has it had as dramatic an impact as this
obviously biased Synopsys/VERA salesman is claiming? - John ]
( ESNUG 313 Item 4 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 308 #9 ) Forcing DC To Choose Better DesignWare Parts
> To force Synopsys to use a much faster "Booth-coded Wallace tree" or
> "wall" model, you have to do this:
>
> constant R0: resource :=0;
> attribute map_to_module of R0: constant is "DW02_mult";
> attribute implementation of R0: constant is "wall";
> attribute ops of R0: constant is "mul1";
>
> begin
>
> A <= B * C; -- pragma label mul1
>
> Ugly, isn't it? But it works. And it's fully debugged.
>
> - [ Kenny from South Park ]
From: Gzim Derti <gderti@intrinsix.com>
John,
If you want a way to perform DW component selection without mucking up your
RTL, this is a method that worked for me (plus a comment on how I've always
thought Synopsys should handle this using pragmas.)
The way that I did this on another job to increase speed on a part was
to first
1. Analyze and elaborate the design as normal.
2. Applied all of the constraints that I wanted.
3. compile -no_map
Once this is complete, you have a design which is in GTECH and unmapped
to gates.
4. report_resources
5. find the cell names of all of the adders in the design.
Let's say that an adder was names add_157 for instance. Then you perform...
set_implementation cla add_157 OR
set_implementation clf add_157 OR
set_implementation clf add* if you want to cover all the
adders in the current design.
This should leave you with a cla or clf representation for your adder, and
is much easier than the long winded way Synopsys wants you to do it with
attributes et. al.
I've been telling Synopsys for years that they need a: "-- pragma use" or
"// pragma use" option which can be coded in line and the compiler could
understand to you could enter:
c <= a + b; --pragma use clf
But talking to Synopsys about this is like talking to a wall...
- Gzim Derti
Intrinsix Rochester, NY
( ESNUG 313 Item 5 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 311 #4 ) Comparing Verilog Cycle-Based Simulators
> We are looking for a high performance (> 300 cps) Verilog Cycle-based
> simulator. We are evaluating Speedsim but don't have time to evaluate all
> others, especially Cobalt, the Cadence alternative. Our verification
> environment compares responses from our C reference model simulation and
> Verilog models in parallel using IPC and PLI.
>
> Our full chip environment uses lots of PLIs.
>
> Can anyone point out pros and cons and recommend a well proven, high
> performance, easy-to-use Verilog cycle-based simulator ?
>
> - [ The Budweiser Lizard ]
From: [ A Cadence Marketing Guy ]
John,
The gentleman seems to be referring to Cobra (and not Cobalt) here. And
though this might sound like I have my company hat tightly on, it is worth
evaluating. Please keep my name anon. I know that you will have to quote
my co. name because of the nature of my recommendation.
- [ A Cadence Marketing Guy ]
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys FAE ]
John,
Anything with a lot of PLI is going to be hard to cycle accelerate as most
simulators take a 'generic' approach to the problem in implementing PLI
(not a custom cycle acceleratable approach).
"Bud-wise-ur" didn't specify which product they are using now but there are
a few things that could be done to see where the time is being spent during
simulation (profiling) Especially when using PLI and C models, it's pretty
simple to run something like "gprof" and figure out where the simulation is
taking the most time.
If there is a high amount of intereaction between the C reference model and
Verilog (over IPC) the performance is going to be less than optimal. Faster
machines, multiprocessing, 100Mbs or Gigabit ethernet might help here?
There are some new options/switches in the latest version of Synopsys VCS
that will perform cycle-based optimizations on the Verilog code.
Unfortunately, due to the nature of the PLI, you cannot turn the most
aggressive of these VCS optimizations on.
On the other hand, what I've seen in many cases is changes in verification
methodology can give you a greater speed increase than just throwing a new
set of tools at the problem.
- Are there different levels of abstraction for the "C" model?
- What is the activity across the IPC boundary?
- What level of detail is needed in the interactions between the
"C" environment and Verilog?
- Can the methodology be changed? (Might be a must for using
a hardware approach like Cobalt, Mercury, Axis, etc.)
Lots of things to consider, also knowing the type of design... graphics,
dsp, processor, networking would help with more detailed recommendations.
It's hard to give much more than a "generic" answer given the amount of
info in the posting.
Again, simulator performance is a very design dependent thing. Giving
blanket recommendations on cycles per second is not that useful.
- [ A Synopsys FAE ]
( ESNUG 313 Item 6 ) ---------------------------------------------- [3/99]
From: "lchao" <linl.l.chao@intel.com>
Subject: "Intel Tech Journal" Issue On EDA Tools/Meths Used For Intel Chips
John,
The 1st Quarter 1999 issue of the Intel Technology Journal focuses on
Intel's current EDA tools used to design Intel's microprocessors. You’ll
get a preview into the tools used to design, validate, and test each and
every generation of Intel’s leading-edge microprocessors. You’ll also gain
insights into Intel’s large development effort surrounding a new generation
of microprocessors. http://developer.intel.com/technology/itj/
- Lin Chao, Editor
Intel Technology Journal
( ESNUG 313 Item 7 ) ---------------------------------------------- [3/99]
From: "Robert K. Yu" <robert@yu.org>
Subject: Free Cell Characterization Software That Creates Synopsys Models
John,
I have written some automatic cell characterization software & am releasing
it under GNU Public License in hopes that it may be useful to people. Grab
it at www.yu.org/robert. It does load delay, input cap, setup/hold,
clock-enable setup/hold, and clock-q delays, works with hspice/smartspice,
and creates Synopsys models.
- Robert K. Yu
Transmeta Corporation
( ESNUG 313 Item 8 ) ---------------------------------------------- [3/99]
From: [ Kenny from South Park ]
Subject: Bug Alert Concerning The hdlin_use_cin Design Compiler Switch
John,
Way back in ESNUG 264 we learned about a neat switch in Synopsys for
optomizing logic. The switch was "hdlin_use_cin = true" which allows you
to use the carry in input of an adder if you are doing an "a + b + 1"
operation. (Why Synopsys doesn't do this automatically I have no idea....)
This saves you an entire adder in your design, and can really speed up
your arithmatic.
However, recently a bug has surfaced. If you have any logic associated
with the "a" and "b" inputs which moves bits in the buss around (like a
simple shift to multiply by 2) then that logic gets "eaten" by the adder,
and you wind up with something that doesn't add up. I've actually gone
to the point of removing this variable from all of my .synopsys_dc.setup
files because of this.
- [ Kenny from South Park ]
( ESNUG 313 Item 9 ) ---------------------------------------------- [3/99]
Subject: Cadence BONes Designer Suite Chows Enormous Amounts Of CPU Cycles
> Does anyone have any experience with Cadence BONes Designer suite,
> Coware's N2C, or SES's workbench? Any comments regarding good or bad
> things you have to say about the above titles would be greatly
> appreciated.
>
> - Chris Power
> Lucent
From: Rohit Sharma <sharmar@ssd.comm.mot.com>
I have some experience with BONeS Designer. It is a good tool and seems
to output pretty accurate results and good predictions. The problems are
these:
(1) Long learning curve - advisable to take training from Cadence
(2) Enormous amounts of processing power required. Our model takes
about a couple of months to run all the simulations when it is run
on 20 Ultra -2 Sparcstations. You can imagine. :-)
We are planning to upgrade our model to run on Ultra-30s which are supposed
to be 5 times faster. Even then, running all the simulations would take
a week.
- Rohit Sharma
Motorola Schaumburg, IL
( ESNUG 313 Item 10 ) --------------------------------------------- [3/99]
From: doron nisenbaum <doron@chipx.co.il>
Subject: Has Anybody Made A Verilog Model Of An Analog Phase-Locked Loop ?
Hi.
I am trying to build a Verilog model of an analog pll. Has anybody done
this? It's suppose to have the same characteristics of a real analog pll
including the loop-filter and Vco.
My model is almost done, but I have control problems in some situations.
Help is needed !!!
- Doron Nisenbaum
Chip Express (Israel) LTD. Haifa , Israel
( ESNUG 313 Item 11 ) --------------------------------------------- [3/99]
Subject: Programming FPGAs Via A JTAG Port & An On-board Microprocessor
> Does anyone know if there are any embedded tools or apps available to
> program FPGAs via the JTAG port? Instead of programming the FPGAs (Xilinx,
> ORCA, etc) from the normal registers, can't you program them via the
> JTAG port via an on-board microprocessor? Has anyone done this and is it
> faster to program via JTAG or the "normal" way ? Any other benefits?
>
> - Steven A. Zedeck
> Ascend Communications Westford, MA
From: edick@hotmail.com (Richard Erlacher)
I believe that ALTERA has been ramrodding the effort to standardize JTAG
FPGA programming processes. They have a tool called JAM (?) which handles
all their devices capable of this mode of programming.
I would be surprised if ALTERA is out there all alone. If you search out
current data on JAM, which is a method for JTAG programming, your questions
should be answered.
I regret that I haven't kept up with this mode, but it holds out much
promise for programming devices, particularly volatile types which must be
reloaded on power-up.
- Richard Erlacher
---- ---- ---- ---- ---- ---- ----
From: daveb@iinet.net.au (David R Brooks)
There's an example on my website for Xilinx 4K parts.
http://www.iinet.net.au/~daveb/tricks/fpga-ldr/loader.html
- David R Brooks
iiNet Technologies
---- ---- ---- ---- ---- ---- ----
From: "Steven K. Knapp" <sknapp@optimagic.com>
You can find the JAM Home Page at http://www.jamisp.com/. It, along with
countless other programmable logic links, is listed on The Programmable
Logic Jump Station at http://www.optimagic.com.
- Steven K. Knapp
OptiMagic
---- ---- ---- ---- ---- ---- ----
From: steve@rsn-tech.demon.co.uk (Steve Rencontre)
JAM does have its problems in the real world. I recently did a program for
a client to configure Altera FLEX devices via JTAG without using JAM,
because Altera's JAM code can't handle >64k configuration data on a 16-bit
platform.
This isn't a fundamental limitation of JAM per se, but the client was
effectively told by Altera, "Don't hold your breath".
The spec for the JAM language is freely available, so it would be
perfectly possible to do another implementation without this problem, but
TTBOMK, Altera's version is the only one around ATM.
- Steve Rencontre
Design Consultant
( ESNUG 313 Item 12 ) --------------------------------------------- [3/99]
Subject: Nicely Reformatting Synopsys Output Via "vi" Editing Tricks
> This may seem a bit silly, but it's been obthering me. How do I control
> the line length of netlists written out by Synopsys Design Compiler. It
> wraps lines at about 80 columns. For those times when I need to dig
> through the gates it would be much easier to have each cell on its own
> line. I've looked through the docs but can't find the magic variable.
>
> - David Rogoff
From: Don Devine <devine@cadence.com>
I'm assuming you're on a unix system. This is something someone sent me
some time ago. The idea is to do some post processing in vi. I know its
not in Synopsys but may help you anyway if you play a bit.
1) Open your vhdl or verilog netlist in vi.
2) Place your cursor at the beginning of a paragraph.
3) Press the escape key.
4) Enter the command to run UNIX /usr/ucb/fmt (default 72 columns) on
a complete paragraph: !}fmt
5) Press the return key. This will format that paragraph to 72 columns,
wrapping intelligently. To format to different column widths, e.g.,
50 columns, use: !}fmt -w 50
To format the whole page, use the from-line-1-to-the-end syntax:
:1,$!fmt -w 78
Or, another way to format the whole page is to use the whole-page syntax:
:%!fmt -w 78
It's an idiots guide just in case you don't know vi. Hope this helps.
- Don Devine
ACCENT srl / Cadence Vimercate (Milan), Itay
( ESNUG 313 Item 13 ) --------------------------------------------- [3/99]
Subject: ( ESNUG 311 #14 ) A List Of The Hidden Synopsys Variables
> As we all know Synopsys DC has many hidden variables and switches for
> different purposes. A few years ago someone published them on ESNUG.
> Could you send a list of hidden variables and switches again for review,
> so we don't have to do so much research to get those information.
>
> - Steve Hwang
From: David C Black <dcblack@qualis.com>
John,
I would like to make several observations on this:
1. Synopsys hidden variables are hidden because they are typically:
a. Only for very specify purposes which are very infrequent
b. Can ruin or cause havoc to most designs
c. Invoke beta-level (or perhaps even alpha-level) code
d. Require other knowledge and must be used in conjunction with
other variables in a very specific manner.
2. These hidden variables change from one release to the next and are
NOT SUPPORTED by Synopsys. If you use one and the next version of the
tools don't support it, too bad.
3. You can extract a list of all ASCII strings from any executable file
in UNIX with the 'strings' command, thusly:
% strings NAME_OF_EXECUTABLE_GOES_HERE | sort -u >SAVED.txt
Information extracted via the above has several characteristics:
a. It is large (possibly a megabyte or more)
b. It will expose all the variables, commands and messages used
by the program examined.
c. The information has no documentation.
d. Nobody in their right mind would use this on a real design.
e. It may violate your licensing agreement.
Bottom line: Don't use this information unless directed to by Synopsys
personnel, and even then USE EXTREME CAUTION. Finding alternatives to
using hidden variables/switches is much better.
NOTE: You could use this technique on other vendors tools with the same
warnings.
- David Black
Qualis Design Austin, Texas
---- ---- ---- ---- ---- ---- ----
From: Peter Kamphuis <kamphuis@hl.siemens.de>
John,
What I have tried is the following:
strings dc_shell_exec | grep hdlin_
This will generate a list of "hdlin" variables. Same can be done with
"compile_", "bc_", etc. Of course, some lines will contain data that
have nothing to do with the variables. A problem that I see, however,
is how do I set a variable that I have found but that is not
documented? "false", "true", "low", "high", "0", "1"
... and what will the effect be?
- Peter Kamphuis
Siemens AG Munich
---- ---- ---- ---- ---- ---- ----
From: [ Bit Mole ]
John,
Please keep this anonymous. Should you use this, sign me [ Bit Mole ].
Steve Hwang's post about finding hidden variables got me thinking. I
went into mole mode and burrowed into dc_shell to see what I'd find.
The result is the following list of undocumented variables and their
default values, which might be useful. "Undocumented" here means that
they exist when dc_shell starts up, but have no man page exists. Whether
this indicates hidden features or spotty documentation is unknown. Whether
the variables do anything useful is left as an exercise for the reader.
This was done with dc_shell 1998.08.
activate_boi : false
allow_newer_db_files : false
annotation_control : 64
arch_init_path : $SYNOPSYS/sparcOS5/motif/syn/uid
bc_create_assign_op_activation : false
bc_create_busses : true
bc_create_logic_op_activation : true
bc_create_read_op_activation : true
bc_create_write_op_activation : true
bc_dont_group_logic : false
bc_enable_logic_data_select : true
bc_force_balanced_branches : never
bc_group_logic_size : small
bc_name_eql_logic : true
bc_use_old_group : false
bin_path : $SYNOPSYS/sparcOS5/syn/bin
channel_width_denominator : 7
channel_width_numerator : 4
checkout_feature_list :
combine_vertical_logic_groups : true
compile_characterize_black_boxes : false
compile_clean_inverters : false
compile_dst_optimization : default
compile_new_gate_sizing : false
compile_preserve_sync_resets : false
compile_promote_delay_cost : false
compile_restrict_down_sizing : false
compile_resyn_duplicate_logic : false
compile_resyn_new : false
compile_routing_utilization : 0.000000
compile_use_fast_sequential_mode : false
current_fmgr_file : 26c5557
current_highlight_layer : <<undefined>>
current_instance : <<undefined>>
current_reference : <<undefined>>
db_database : 3we45d5
dcm_calc_mode : W
dp_prob_analysis : false
eco_allow_hierarchical_names : true
eco_connect_resource_cell_inputs : true
eco_find_trails : false
eco_output_isomorphic : false
eco_output_name_aligned : false
eco_recycle_verbose : true
fast_partitioning : true
filter_check_real_by_default : true
font_library : 1_25.font
gen_ignore_bus_bit_order : false
hdlin_dont_check_param_width : false
hdlin_enable_analysis_info_for_analyze : true
hdlin_latch_synch_set_reset : false
hdlin_minimize_tree_delay : TRUE
hdlin_reg_test_print : FALSE
hdlin_report_resource_costs : FALSE
hdlin_resource_sharing_mode : AUTOMATIC
hdlin_share_common_subexpressions : TRUE
hdlin_share_effort : LOW
hdlin_tdrs_script_source :
hier_dont_trace_ungroup : 0
init_path : $SYNOPSYS/auxx/syn
lbo_lfo_enable_at_pin_count : 3
left_justify_logic_constants : false
level_sensitive_startpoint_close_active_edge : 0
link_path : {class.db}
logic_group_height_percent : 95
logic_group_width_percent : 95
man_path : $SYNOPSYS/doc/syn/man
mgi_disable_server_mode : false
mgi_scratch_directory : .
mgi_server_mode_timout : 48.000000
motif_files : $SYNOPSYS/admin/setup
motorola_input_edge_rate : 0.000000
output_order : {}
port_edge_rate : 0.000000
power_clock_gating_dont_check_library : false
power_dont_hookup_testports : false
power_gated_clock_logic : and buf
power_reg_size_threshold : 3
power_test_enable : false
power_test_enable_pin : TEST_MODE
power_test_obs_logic : false
power_test_obs_logic_depth : 5
preserve_subshells : {hdl_shell_exec}
prioritize_link_order : true
product_build_date : Jun 25, 1998
product_version : 1998.08
report_product_version :
sc_check_file_existence : false
scc_execute_sh_command : false
scc_print_usage_message : false
sheet_fill_percent : 100
sheet_hard_limit : true
sheet_orientation : landscape
sheet_size : infinite
sheet_sizes : {A, B, C, D, E, infinite, mentor_maximum, sge_maximum}
synlib_debug_mode : {}
synlib_preferred_library : {}
synlib_wait_for_design_license : {}
synopsys_program_name : dc_shell
synopsys_root : $SYNOPSYS
target_systems : {}
test_allow_clock_convergence : false
test_enable_post_capture_checks : 3
test_force_bidir_pads_inwards : -2
test_force_capture_clocks : false
test_no_three_state_conflicts_after_capture : 0
test_synchronization_elem_support : 1
test_user_test_data_register_naming_style : UTDR%d
text_threshold : 6
text_unselect_on_button_press : true
tsdrc_bidir_port_checks : 7
user_home_path : $HOME
verilogout_time_scale : 1.000000
verilogout_top_instance_name : u1
vhdllib_unigen_first : true
vhdlout_upcase : FALSE
view_banner_font : 9x15
view_busy_during_selection : true
view_designs_set : 0
view_draw_text_breakpoint : 0.010000
view_extend_thick_lines : true
view_icon_font : 8x13
view_icon_path : $SYNOPSYS/auxx/syn/icons
view_independent_dialogs : {test_report, Test Reports, report_print,
Report, report_options, Report Options, report_win, Report Output,
manual_page, Manual Page }
view_maximum_route_grids : 0
view_pixels_per_route_grid : 0
view_select_default_message : Left Button: Select - Middle Button:
Add/Modify Select - Right Button: Menu
view_select_separator : -
view_set_cursor_area : 5
view_use_integer_scaling : false
view_watcher : $SYNOPSYS/sparcOS5/syn/bin/da_watcher_exec
view_win_height : 500
view_win_width : 600
working_path : (current working directory)
Some of the variables above include "$SYNOPSYS", "$HOME", or "(current
working directory)" in the default value. Really they all have an
absolute path, but I edited them to stay anonymous.
- [ Bit Mole ]
[ Editor's Note: I changed the values for current_fmgr_file & db_database
because I take requests for anonymity *very* seriously. Although I'm
unsure, these two mysteriously encoded numbers looked like they might
have IDed "Bit Mole". Rather than risk it, I changed them. - John ]
( ESNUG 313 Item 14 ) --------------------------------------------- [3/99]
From: Rich Katz <rich.katz@gsfc.nasa.gov>
Subject: Help! Installing Synopsys 98.08 Messes Up 98.02 Access! Ouch!
hi john,
we have a license server running on a unix host, currently 1998.02. we
want to install 1998.08 software on a pc/nt system and have access to the
unix license server over the network. we are told by our in-house people
that upgrading the license server, on unix, to 1998.08 (necessary for pc/nt
access) will disrupt 1998.02 software access. synopsys says it will work
fine and suggests we do exactly that. does anyone have any experience that
they can share?
- Richard B. Katz
NASA Goddard Space Flight Center Greenbelt, MD
( ESNUG 313 Item 15 ) --------------------------------------------- [3/99]
From: Baris Aksoy <baksoy@usa.alcatel.com>
Subject: Need A Working Copy Of The Olde VLSI Tech VGT350 Synopsys Libraries
John,
Does somebody have Synopsys library (core + symbol) for VLSI 1um gate array
technology(VGT350)? Actually, I have them but when I try to do a link
it gives lots of LINK-1 and LINK-5 messages. It seems that the library and
netlist have different names for every pin of every cell. I verified the
netlist with the databook, it's correct. Then I made report_lib and I got
the message that library is corrupted. If anybody can provide me working
version of this libraries, it will help a lot.
- Baris Aksoy
Alcatel-USA
( ESNUG 313 Item 16 ) --------------------------------------------- [3/99]
From: "Vijay S. Patri" <zoeL@ti.com>
Subject: What's The Dirt On The Synopsys/EPIC AMPS Tool? Is It Useful?
John,
I am trying to use EPIC's tool AMPS for critical path optimization. Is
there anyone in the ESNUG family who can recount her/his experience with
the tool? I'd appreciate it if you could publish a review of the tool in
one of your issues.
- Vijay Patri
Texas Instruments
( ESNUG 313 Item 17 ) --------------------------------------------- [3/99]
From: Greg Bell <gregbell@znet.com>
Subject: Should I Spend My Money Going To SNUG'99 Or To DAC'99?
John -
I'm a self-employed consultant who has to pay his own way to any conference
I attend. Should I spend my money going to the upcoming SNUG'99 or on
DAC'99 in June? I'm interested in "technical", not "industry" stuff. Are
either of these conferences worth it?
- Greg Bell
( ESNUG 313 Networking Section ) ---------------------------------- [3/99]
Westboro, MA -- Engineering Technician w/ 15 years exper. troubleshooting
analog protypes, LANS, RF, plus some digital. "door2dor@ma.ultranet.com"
|
|
