Editor's Note: I just wanted to thank the 46 engineers, the 14 EDA industry
  employees (especially the 4 from Cadence) and the 2 industry press editors
  for contributing 345 lbs of dry dog food and 137 cans of dog food to
  present to Joe Costello at the end of his keynote address during the recent
  Cadence Users group meeting in Boston.  (There's a photo of a grimacing Joe
  being loaded down by dog food on pg. 16 of this week's [Oct. 16] EE Times.)
  Thanks for making this "Dog Food Drive For Joe" a reality!  B^)

                                           - John Cooley
                                             the ESNUG guy

( ESNUG 228 Item 1 ) ---------------------------------------------- [10/95]

From: sonksen@dt.wdc.com (Brad Sonksen)
Subject: How To Piss Off Your Synopsys Salesman By Minimizing DW Useage

John,

Here's an example way to minimize usage of DesignWare licenses (in this case
"SynLib-ALU") that may be of interest to ESNUG readers.  When compiling for
the first time, HDL-Compiler may call up a SynLib-ALU license to get the job
done.  Under many circumstances the compiled design is then written out in a
hierarchical format, with DesignWare components written out as separate
submodules in the compiled netlist.  The problem comes when you want to
re-optimze the design for timing, or whatever.  Ideally you don't want to
have Synopsys call up the SynLib-ALU license again for the re-compile.  These
licenses are expensive (~$15K), and are most likely in short supply compared
to the standard Design-Compiler licenses.  However, when the previously
compiled hierarchical design with DesignWare components is read in, it will
automatically tie up SynLib-ALU license and potentially cause other designers
to wait, or pay more money for another license!

To get around this, simply write out all designs to be re-compiled as *flat*
netlists.  This eliminates the DesignWare component reference in the module
names and also stops Synopsys from calling up the "SynLib-ALU" license on a
re-compile of structural code inside these designs.

  - Brad Sonksen
    Western Digital Corp.


( ESNUG 228 Item 2 ) ---------------------------------------------- [10/95]

Subject: (ESNUG 221 #2 227 #3) "Non-Linear Libs, Weird Delays & Clock Drives"

> Setting a drive on a clock port has problems.  With an "ideal" clock you
> get 0 ns propagation delay and thus the drive strength is ignored, however
> you *will* get a transition delay.  This transition delay will be *huge*
> because the load on the clock is large.  Creating weird large delays!


From: jaym@hpcvcdt.cv.hp.com  (Jay McDougal)

Hi John,

If you have access to a copy of Library_Compiler, here is one workaround for
the problem of transition delay on "ideal" clock networks.

You create a special cell in your synopsys lib that has a fixed transition
delay for all load and input slope cases.  This fixed value is simply the
expected transition delay you will get from your clock buffering scheme.
You can also include the intrinsic delay of your clocking scheme as a fixed
Intrinsic Delay.  This will model your complete clock buffer with a single
cell (except for skew which can be handled separately.)  Using this new cell,
it does not matter what your input drive is set to.   The "fake" cell should
be replaced by the actual clock tree during place and route.

  - Jay McDougal
    Hewlett Packard


( ESNUG 228 Item 3 ) ---------------------------------------------- [10/95]

Subject: (ESNUG 226 #4 227 #1) Funky Toshiba/VSS VHDL Gate Sim Methodology

> Synopsys modeling limitations.  Each ASIC vendor has developed their own
> delay calculation algorithms over the past 10 years or so.  Each method
> is considered by each company to be extremely proprietary.  In order for
> Synopsys to be as accurate as all of these other delay calculators,
> Synopsys would have to put many different algorithms in the software.
> ... Putting all of these delay calculators into Synopsys will also give
> ASIC vendors immediate access to each others algorithms, which they would
> not like.


From: [Somewhere in Europe]

Not true.  Synopsys only needs to allow ASIC vendors to link in their own
procedures to perform delay calculation, look at the methodology of the 
DCL project, or Cadence's CDC. As 'No Name, No Nothing' correctly points 
out, there is also the issue of wireload estimation and modelling, where
floorplan-based estimation would appear to be somewhat outside of the scope
of Synopsys' current capabilities. 

However, at the moment, Synopsys appears to be the standard for delay 
modelling amongst EDA vendors (how many vendors can translate timing
models from Synopsys?) and so Synopsys are unlikely to open up the format
when it appears to be giving them a competitive advantage. It does not
help the poor user, or the industry long-term!

Please keep me anonymous.

  - [Somewhere in Europe]


( ESNUG 228 Item 4 ) ---------------------------------------------- [10/95]

Subject: (ESNUG 225 #5) Synopsys & Two Sun SPARC 10's For Sale

> Hi, John, We have the following licences (complete w/ two Sun Sparc 10s):
>
>  1 x VHDL Compiler                        2 x VHDL System Simulator
>  2 x Simulation Graphical Environment     1 x Design Analyzer
>  1 x Design Compiler Expert
>
> Our total asking price is US $90,000.

 [ Editor's Note: After snooping around Synopsys on this topic, it turns
   out that reselling licences is expressly forbidden in all purchase
   agreements.  That is, everyone who bought Synopsys agreed to not resell
   it to anyone.  (Synopsys, Inc. isn't completely heartless, though -- if
   your company is going through bankruptcy *then* they've been known to let
   you resell Synopsys software as a capital asset.)  Therefore, because I
   think its unethical to help someone knowningly violate a sales agreement
   for no other reason than financial gain, I'm not going to run reselling
   ads in ESNUG -- unless you're going through bankruptcy.       - John  ]


( ESNUG 228 Item 5 ) ---------------------------------------------- [10/95]

From: jadams@fore.com (Jay Adams)
Subject: The Support Center Has Gotten Better, So Let's Bitch About Prices!

John,

   I hate to say this, but after my sarcastic evaluation of Synopsys's tech
support in ESNUG many months ago, I feel obligated to tell you that they are
showing remarkable improvement.  The telephone gets answered by a PERSON, in
under 5 MINUTES, and the person that answers actually KNOWS something.  Wow,
I wonder if it was MY complaint that turned the tide....

Hmmmmmmmmmmmm...  maybe...

Hey Synopsys!  Your products COSTS WAY TO MUCH and you don't have to license
EVERYTHING.   (Now lets cross our fingers and see what happens.) 

  - Jay Adams
    FORE Systems


( ESNUG 228 Item 6 ) ---------------------------------------------- [10/95]

From: greg@cqt.com (Greg Bell)
Subject: DC 3.3a Really Messes Up False Paths In Hierarchical Designs!

John,

A caveat:  There's a bug in 3.3a where the false_paths don't get written out
correctly if you do a characterize and write_script (not sure which command
was at false).  There's a STAR filed for this, and its been fixed in 3.3b.
The scary part: it would specify false paths in the script for the submodule
that WERE NOT FALSE PATHS.

  - Greg Bell
    CommQuest Technologies, Inc. 


( ESNUG 228 Item 7 ) ---------------------------------------------- [10/95]

From: agelman@metaflow.com (Anatoly Gelman)
Subject: "find" With "-hierarchy" Doesn't Work Like You Expect It To

John,

It turns out that -hier option for find(pin,*/*/CLK,-hierarchy) command does
not work if the search path is hierachical itself.

One would expect that using "-hierarchy" option will produce at least
the results of the command invoked with no "-hierarchy" plus all
additional pins found down the hierarchy.  Well, it returns an empty list!

Here is the dc_shell 3.2b output:

      dc_shell> find(pin,VB*/*/CLK)
      {"VBAC/VSREG_0/CLK", "VBK1C/VSREG_0/CLK"}
      dc_shell> find(pin,VB*/*/CLK,-hier)
      {}

  - Anatoly Gelman
    Metaflow Technologies, San Diego


( ESNUG 228 Item 8 ) ---------------------------------------------- [10/95]

From: jumana@tcs.com (Jumana Muwafi)
Subject: Lib Compiler Can't Model Clk & Scanclk Yet Test Compiler Needs It

Hi John,

Apparently Synopsys has a problem in modeling the scan equivalent of an
edge-triggered flip-flop using the clocked-scan methodology.

The problem rises from the fact that to model the next state of the register
you need to specify two clocks: the normal operation clock, and the scan 
clock, which the Synopsys Library Compiler cannot do.  Synopsys says that 
in this case the Test Compiler *assumes* the operation of the flip-flop 
during scan and operates based on that assumption.  The risk is that if the 
cell ends up behaving differently from the assumption there is no way to
test it.  Any insight into how much of a risk is using this type of test
methodology going to introduce would be greatly appreciated.

  - Jumana Muwafi
    TCSI


( ESNUG 228 Item 9 ) ---------------------------------------------- [10/95]

From: chuckg@arnet.com (Chuck Gollnick)
Subject: AMCC's PCI Is Junk; Is Synopsys's DesignWare PCI Part Worthwhile?

John,

In your travels, have you chanced to meet anyone using the new Synopsys
DesignWare Components PCI Macro Set yet?  My understanding is that this is a
collection of parameterized, synthesizable Verilog or VHDL models of various
building blocks from which one can assemble PCI controllers.  By configuring
the blocks and adjusting the parameters, one can tailor-build an
"application-specific" PCI controller.  This sounds like a great concept.

Arnet needs to do a couple of PCI-based products right now.  The PCI
controller we've been using (AMCC s5933) is a piece of junk.  By the time we
buy the Macro Set, another seat of DC to work with it, and a decent Verilog
simulator such as XL, we'll have spent about 150K$.  That's serious bucks and
a big commitment for us.  It'd be an uphill fight all the way to get our
management to fund this.  So I'd like to hear on ESNUG people who are using
this product and their experiences good or bad.

  - Chuck Gollnick
    Arnet Corporation

  [ Editor's Note: As always, if you want to be "anon" in replying to this
    request just say so and I'll honor it!              - John  ]


( ESNUG 228 Item 10 ) --------------------------------------------- [10/95]

From: mfp@hw.stratus.com (Michael Pannell)
Subject: Is The Synopsys Floorplan Manager Worth Its Price?

I would be very interested in hearing from people that have real-life
hands-on experience with the Synopsys Floorplan Manager.  For example, does
it really do something that I can't do myself by tweaking the constaints and
process by which I use the dc_shell?  If so, under what circumstances would
this extra something be worth the extra something Synopsys is asking for it?

  - Michael Pannell
    Stratus Computer


( ESNUG 228 Networking Section ) ---------------------------------- [10/95]

Mountain View, CA - Synopsys, Inc. seeks EDA developers w/ VLSI, Verilog,
VHDL exp. for logic synthesis R&D.  No Agencies.  "smeier@synopsys.com"

Julian Fields - Silicon Valley design/verification consultant, ASIC, IC, 15
years exp., Verilog, VHDL, Synopsys.  No job shops!  "fields@svpal.org"

Irvine, CA - Zycad seeks Field Applications Engineer familiar w/ Synopsys,
Verilog, VHDL & fault simulation.  No Agencies please. "mcnamara@zycad.com"

Mountain View, CA - Acuson ultrasound imaging seeks CAE engineer to support
FPGA/CPLD design, sim, Synopsys.  No recruiters! "mikem@acuson.com"


 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)