Well it's time to do the annual SNUG/OVI pilgrimage to California this
  and next week.  I've put out a mountain of hay for the sheep and packed
  up the SNUG papers for reading on the plane.  I'm actually pretty excited
  about this year's SNUG because it is going to be an extremely technically
  oriented meeting.  I've been told that there won't be any Synopsys Sales/
  Marketing people giving speeches at this SNUG; so if you happen to run
  into any of these types I give you carte blanche to say "Verilog! Verilog!
  Verilog!" and enjoy pained looks on their faces.  (But then again, you
  might trigger a VHDL-is-the-wave-of-the-future-because-I-get-a-sales-
  commission-for-each-copy-of-VSS-I-sell-but-nothing-for-Verilog motivated
  sales pitch.  Legal disclaimer: say the Veri-word at yer own risk.)

  On Thursday, 1:00 of SNUG, I'll be doing a breakout session on the how's &
  why's of ESNUG plus some of the behind-the-scenes stories of running ESNUG.

  For those of you going on to the Open Veri-word International, Stuart
  Sutherland managed to twist my arm at the last minute into helping him do
  the synthesis part of his "Behavioral Modeling Styles With The Verilog
  HDL" tutorial.  I'll also be making noise on one of the OVI panels for fun.

  All throughout these next seven or so days I look forward to meeting some
  of the many people I know electronically, sharing a few war stories and
  then encouraging you to e-mail them to me for publishing in ESNUG!  But
  remember: I'll probably recognize you better if you tell me your e-mail
  address first!  ;^)
                                      - John Cooley
                                        the ESNUG guy

( ESNUG 181 Item 1 ) ---------------------------------------------- [3/8/93]

Subject: (ESNUG 180 #4)  Synopsys Test Compiler w/ LSI Logic

>Does anyone have experience using Test Compiler's Custom Test Vector tool for
>scan vector generation for LSI Logic ASICs?  Does it work?  What were the
>problems?  Please share experiences on ESNUG.  Thanks in advance.

                      ---   ---   ---   ---

From: victor@truevision.com (Victor J. Duvanenko)

John, the way I've dealt with this problem in the past is by requiring that
my ASIC vendor (such as LSI) deal with the problem instead of me.  I ask them
to support Synopsys scan vectors in Synopsys format.  Then the vendor buys
the format converter and can use it for all of their customers, instead of
you buying the converter for LSI, then another one for NEC, then TI, then
Toshiba, etc..  I'm sure LSI already has a converter and they would be
glad to convert the vectors for you at no cost (if you tell them that other
vendors are doing it - and they do!).  This way you have one less headache.

  - Victor J. Duvanenko
    Truevision

                      ---   ---   ---   ---

From: [No Name]

John, please remove all identifying marks before putting this on ESNUG.  The
politics involved if I were public with this isn't worth the trouble.

My company's experience with LSI as a small volume customer (1 or 2 ASICs/yr)
is that they like to lowball their initial price for a design so you'll lock
into their technology and then nickel & dime you to death for things like EDA
libraries and similar post sales support.

A few years ago we asked for a library for a non-Synopsys ATPG tool and their
response was "Sure, we'll create one for $10,000"  (We felt that was highway
robbery because even _if_ we were the first customer to ask for this scan
library -- we knew their would be others later on asking for this.  Why should
our R & D budget pay for LSI's library support?)  After some investigating
we found we could easily write our own ATPG library so we had an engineer
write one.  A few months later when LSI found out we did this the salesman
asked if he could get a copy.  We said "Sure, for $10,000."  (They never
got back us on this.)

Moral: What comes around, goes around.

  - [No Name]


( ESNUG 181 Item 2 ) ---------------------------------------------- [3/8/93]

From: rray@poci.amis.com (Russell L. Ray)
Subject: Lib w/ max_capacitance Plays "Hide & Seek" w/ Constrainst Violations

John,

I was wondering if anyone else has encountered an oddity that we have.  Our
library uses the max_capacitance constraint rather than the max_transition.
When we compile a design, Synopsys will sometimes say there is a violation
when a "report_constraint" is issued, but says there is no violation when a
"report_constraint -all_violators" is issued.  When this design is then
taken over to Verilog (Oh, No!, the Veri-word!) it warns of max capacitance
violations.  The only way we have found any way of making Synopsys resolve
*most* of the max capacitance violations is to use a wire_load that is two
times bigger than what we intend to use.  Has anyone else seen this?

  - Russell Ray
    American Microsystems, Inc.


( ESNUG 181 Item 3 ) ---------------------------------------------- [3/8/93]

From: jamint@bnr.ca (Jamin Tandiono)
Subject:  Output Redirect Not Working In 3.0b 

Hi, John.  In 3.0b, I don't seem to be able to redirect output file with the
following syntax:

               report -cell > ../report_cell/block1.report

I get the error message:

      "Could not write file '../report_cell/block1.report'" (EQN-11).

This redirect works when the output file is in the same directory.  This same
syntax works on 2.2b.  I appreciate any suggestions.

  - Jamin Tandiono
    Bell-Northern Research, Atlanta


( ESNUG 181 Item 4 ) ---------------------------------------------- [3/8/93]

From: sgolson@trilobyte.com (Steve Golson)
Subject: Be Careful With "Characterize" In 3.0b!  (It Doesn't Work!)

John, here's the "characterize" bug that you've been pestering me to write-up
and send in to ESNUG.

I've been seeing strange problems using "characterize" under Design Compiler
v3.0b-12954.  The symptom is that "characterize" doesn't put output delays on
some ports.  This means your subdesign is not constrained.  (Bad news!)

To detect this after you characterize push into the subdesign and do a
"report_port -verbose" and look at the output delays:

                    Output Delay                           External Fanout
                  Min             Max      Related  Fanout  Number  Wireload
Output Port   Rise    Fall    Rise    Fall  Clock     Load  Points  Model
----------------------------------------------------------------------------
asignal0      7.96    9.23    8.42   10.05  sysclk    0.31      2   10x10
signal[0]     6.46    7.02    6.86    7.40  sysclk    0.31      2   10x10
signal[1]     6.46    7.02    6.86    7.40  sysclk    0.31      2   10x10
bsignal       6.17    6.99    6.57    7.38  sysclk    0.31      2   10x10
bordeaux      --      --      --      --      --      0.31      2   10x10
mysignal      6.34    7.03    6.74    7.41  sysclk    0.31      2   10x10

Notice that output port "bordeaux" has NO timing constraints!

I was quite lucky to find this bug.  I discovered it checking out some 
subdesigns I was compiling.  When I first found the bug I had to send the
whole design to Synopsys for them to duplicate it.  About a day later they
called back and said: "Oh, it's _that_ bug.  We've seen it before."  They
went on to say this is not a "characterize" bug, but actaully a timing
analyzer bug and the fix is to use v3.0c.  See you at SNUG'94.

  - Steve Golson
    Trilobyte Systems


( ESNUG 181 Item 5 ) ---------------------------------------------- [3/8/93]

From: Paul Zimmer <prz@hprnd.rose.hp.com>
Subject: "My Synopsys Wish List"

John,

I meant to get this in before the SNUG '94 meeting as food for thought.

Somebody posted a request for input to a "wish list" a while back on ESNUG.
I never saw any follow-up, so I'll post mine.  Maybe some ESNUG'ers out
there know how to do some of these things already.  Oh well.


        "My Synopsys Wish List"    by Paul Zimmer, Hewlett-Packard

(In no particular order)

1. Support of ifdef/else/endif compiler directives in Verilog.

   How hard can this be?  My use for it involves handling instantiated
   logic while switching between multiple target libraries with a single 
   source file, but I've talked to other people who want to generate
   multiple versions of a chip without having to hack the source into
   little pieces.
 
   Don't tell me, let me guess.  "They have this in VHDL".

2. A way to get timing info into script variables.

   This has several uses.  One would be to have a script that would measure
   the compile results and muck with the constraints auto-magically.
   Another use is timing constraints that are difficult to describe, 
   like timing between an output and its output enable ("no path").
   You could have your script do the calculation and print a message 
   (or even re-compile) if you didn't hit the target timing.

3. A hierarchical all_connected

   How do you find all the nodes on a net in a hierarchical design?
   I usually either chase it madly around in design_analyzer, or write
   out the design in verilog or edif and awk/grep/sed.  What a pain.

4. set_wire_load on an INPUT port

   In a design using wire-loads, you need a way to tell the block that
   you're compiling what wire-load environment its inputs come from, so
   that it can accurately assess the cost of faning out that input.

5. A way to disable timing through a path in a circuit.

   Maybe ESNUG'ers can help me here.  As far as I can tell:

   set_false_path only works on path end points
   disable_timing only works (apparently) on arcs within a part

   I haven't found a way yet to just disable timing on all paths that
   pass through a sub-path.

6. Make report_port return ALL attributes on port (test_hold, user-defined).

   I run into this with test_compiler a lot.  "What funny little attribute
   on this critter is making test_compiler barf?"  Trouble is, I don't
   KNOW all of the possible attributes, so I can get_attribute for
   everything.

7. Have "help command" list all license requirements for a command.

   Maybe I shouldn't have mentioned licenses....
 
8. Have all tools echo the value when "performing ..."

   I assign values based on calculations all the time.  I may do a calculation
   to get the value for max_delay or set_arrival, and it would be 
   re-assuring to see it echoed.  I know, I could assign the value to
   a variable first so I can inspect it, but this would be cleaner.

9. A ksh-style command line interface for dc_shell.

   I know, real programmers use C-shell and enter their code via switches
   on the front panel.  But we weaker ones still need to EDIT as well as
   recall a command on occassion.

10. Add looping (foreach) to design_analyzer command window.

   I wonder why this is disabled?  I find myself pulling the design into
   an interactive dc_shell so I can use looping, then having to write
   it out so I can look at it with design_analyzer.  This tends to draw
   fire from adjacent cubes...

11. Function to return the number of items in a set, and a way to index 
    into the set.
   
    I could do this myself with a series of foreach loops and counters,
    but it's ugly.

12. unselect_all in the select box in design_analyzer.

13. Select ports without specifying direction in design_analyzer

    ("Whadayamean, you can't find port foo?!  It's right there, dummy.
     Oh yeah, its an output... or did I make it a bidir for test...")

14. A way to go directly to schematic, bypassing symbol in design_analyzer.

    Maybe esnug'ers know the magic flag?  For the once a year or so that
    a actually want to look at the symbol, I'll gladly punch the button.
    The REST of the time, when I open the design up, I want to see the
    SCHEMATIC.

15. Dump of mouse buffer to design_analyzer.  

    This may be an HP-UX issue, but I can't do the grab-and-spit trick 
    into a design_analyzer command window.

16. A way to constrain the memory allocation.

    Might be another HP-UX issue, but big operations on big chips cause
    "out of memory".  We've analyzed this, and it's because Synopsys is
    trying to allocate more that 640 MBytes of memory.  When it happens,
    you're dead...

I hope to see you at SNUG '94!

  - Pabul Zimmer
    Hewlett-Packard



 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)