Editor's Note: For most of the summer, I & most of my friends have just
  been enjoying the weekends as a sort of laissez-faire type of thing -- go
  to the occassional friend's barbecue, pool party or whatever.  No rush.
  Relax... it's summmmmmer!  Weeeeee!

  Wham!  Suddenly with Labor Day less than two weeks away, the weird terror
  of freezing under three feet of snow in the middle of February is driving
  a mad rush to do as many last minute "summer" things as humanly possible.
  Last weekend consisted of (Friday) going to a bluegrass festival & picnic,
  (Saturday) going on a boat trip to an island in Boston harbor with a
  fort that was a prisoner of war camp during the Civil War which had a
  "troop" of Civil War solders camping there as a historical re-enactment,
  and (Sunday) going to Boston's Italian North End for the Fisherman's
  Festival.  All this entailed lots of planning and hours of driving to and
  from Boston.  This next weekend promises even more "fun"....

  Now, I can't wait for Summer to end so I can get some rest!  :^)

                                       - John Cooley
                                         the ESNUG guy

( ESNUG 248 Item 1 ) -------------------------------------------- [8/96]

Subject: ( ESNUG 246 #7 ) HDL Sign-off & 3rd Parties Using Synopsys

> John, the company I work for is small, so Paying 100K+ for a DC Expert, an
> HDL Compiler, an Analyzer plus Maintenance is a major investment.  We were
> considering an HDL hand off and let the ASIC Vendor do the synthesis and
> Layout (including P&R).  ... I have heard that some Silicon
> Vendors provide a design center that allows you to come in use their tool
> set, which may or may not include Synopsys.  ...  Synopsys says
> that a customer that purchases the Synopsys synthesis tools must output
> only HDL (no gates) otherwise they are breaking the licenses agreement.
> I also heard that LSI supposedly used Synopsys to develope some of their
> cores and sell the cores to customers that use their FAB.  Synopsys says
> this is unethical.  What are your feelings on these issues ?


From: [ The Mystery Motorola Man ]

John, please sign me as anon Motorola.  Too many politics here.

Anyway, this depends on what the user means by HDL hand-off.  If you want to
send in your HDL and get a guarantee that timing in silicon is matched, then
I guess that there are only a few silicon vendors that do this.  However,
there are numberous silicon vendors that provide design centers in centrally
located areas (San Jose, Chicago, Boston, etc.) to allow you to use their
tools / licenses for synthesis to their technology.  Also, if Synopsys
synthesis tools do not output to gates, then what are they supposed to
output?  Are you referring to only Behavioral Compiler?

Concerning the LSI not being able to sell their Synopsys synthesized cores:
Wow - that is something new!  Does this imply that Synopsys is making some
sort of legal claim to any design that makes the transition from HDL to
gates via their tools??  I don't think this is factually correct.  Plenty
of companies have been selling Synopsys synthesized designs for years.

  - [ The Mystery Motorola Man ]

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

From: ryan@fsd.com (Ken Ryan)

John,

Atmel advertises the capability to take an RTL description as database input.
I don't personally know anyone who's done this.  Perhaps Synopsys' lawyers
have a broad definition of "renting" software?  To me, a vendor taking HDL
as input is performing a turnkey design service based more on their expertise
than happening to use a particular synthesis program.  You're hiring them
as a design consultant or a subcontractor as well as a fab house.

Regarding LSI's cores, I can't comment on legality or license agreements but 
surely there isn't an ethical problem - it's like Microsoft having control 
over your publishing and selling a book written with Microsoft Office.
Especially in the case Steve described - LSI is really selling a piece of
silicon that has their design on it (the core) that happens to be integrated
with someone else's design (the customer).  Do they sell cores to competing
fabs?  I doubt it (though I don't see a problem with that either).

Thanks, John, for running a valuable service!

  - Ken Ryan
    Orbital Sciences Corp.

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

From: blogs@telxon.com (Brian Logsdon)

I know that LSI Logic has been working on some form HDL sign-off for years.
Seems to me that if LSI Logic developed the core, they sure aren't going to 
give you the source code to synthesize. T he source code (and the synthesis
scripts) are intellectual property.  Sounds like the olde pressure tactic 
by the Synopsys sales force.

Hmmm... Synopsys talking about ethics.  Does the term oxymoron mean
anything here?

  - Brian Logsdon
    Telxon Corporation

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

From: jcooley@world.std.com (John Cooley)

Concerning HDL sign-off and Synopsys cutting deals allowing various ASIC
foundries to let designers have free access to their synthesis tools, I've
always been kind of stumped by this.  Where's the "win" for an EDA developer
to let foundries effectively give away the use of their software for free?
Sure, I like bashing various EDA vendors when they technically screw up just
as much as the next guy -- but I'm fully aware that there is no such thing
as a free lunch.  I have this silly economic idea that those who provide
value (whether it be in the form of a hot EDA tool or in serving up a good
dish of Pad Thai noodles) should be directly rewarded for their work so
they continue to do what they do.  LSI doing HDL sign-off directly translates
into Synopsys losing synthesizer sales.  Why would Synopsys agree to this?  
It just doesn't make sense in my limited, sheep farming world view.  It
sort of reminds me of that Country Western song about divorce.  It's titled:
"She Got The Gold Mine, I Got The Shaft."

  - John Cooley
    the ESNUG guy


( ESNUG 248 Item 2 ) -------------------------------------------- [8/96]

Subject: ( ESNUG 247 #7 ) An Equivalent Function Found In Design_Analyzer

>In design_analyzer, under the Analysis menu, there is an option to "Show
>Net Load...".  When you select a net, it gives the capacitive load on that
>net as applied by the wire load model and the std cell pins connected to
>that net.  I need a analogous command in dc_shell to extract this info.
>Anyone know the ultra secret command that will do the same in dc_shell?


From: gilbert@aluxs.att.com (Gilbert Nguyen)

Smells like "report_net -verbose -connection net_name" to me, John.

  - Gilbert Nguyen
    Lucent Technologies

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

From: Steve Cochran <scochran@polecat.sr.hp.com>

John,

Doesn't design analyzer list the equivalent command line instructions in
its transcript file?  If so, execute from DA and then use in DC.

  - Steven Cochran
    Hewlett Packard 


( ESNUG 248 Item 3 ) -------------------------------------------- [8/96]

Subject: ( ESNUG 246 #8 247 #3) Benchmark & Opinions On Hardware Emulators

> Quickturn --  ... Designs in the ~500 kgate range take a full day + night
> to compile.  ("Compiling" means your netlist is partitioned into "logic
> modules" that hold about 250k gates each, followed by doing the Xilinx P&R
> on the 80 FPGAs in each "logic module".) ... Costs U.S. $1 to $1.3 per gate
> emulation.  They also give great DAC parties.
>
> Synopsys Arkos --  ... Has automatic partitioning into 200 kgate non-FPGA
> boards with supposedly fast compile times.  Don't know costs per gate.
> ... They have variable DAC parties.


From: [ Synopsys Arkos R&D ]

John, 

FYI: Quickturn gate capacity tends to be overstated from our experience;
"emulation gates" are typically 2-3X smaller than the design gates that
Design Compiler would tell you about.  I think experienced Quickturn users
understand this distinction, but it does tend to blur comparisons of
capacity.

  - [ Synopsys Arkos R&D ]

P.S. What are "variable" DAC parties?  Are others "constant"?

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

From: Don Monroe <Don_Monroe@synnet.com>

John,

The last sentence of [ Call Me Ishmael ]'s critique of emulation systems
suggested that emulation is usually 6X faster than simulation.  In my
experience  (4 to 5 yrs using Pie/Quickturn) I would say that emulation
approaches 1 million X of simulation!  If he's only getting 6X he's doing
something wrong.

  - Don Monroe
    3COM


( ESNUG 248 Item 4 ) -------------------------------------------- [8/96]

From: Iain Finlay <ifinlay@qualcomm.com>
Subject: Intermittent VHDL 3.3a Elaboration w/ Multiple Libraries

Hi John,

We have experienced intermittent problems with the following design
library setup (see below).  The "elaborate" command occasionally fails
to link in a component or two from a separate, but correctly
referenced, design library.

  Design library: "A" contains a VHDL package of constants.

  Design library: "B" references "A" and contains 
                  (1) a VHDL package of functions
                  (2) a VHDL component package and the corresponding
                      entity-architecture implementations - some of these
                      are parameterized (i.e. a fifo)

  Design library: "DEFAULT" contains the design source.
                  WORK points to this library.

Assume there is a design entity "D" in the design library default.

  1) the symptom:

       dc_shell> elaborate

     produces some message saying that it "can't find synthetic module
     "FIFO..." in library 'WORK'.

  2) FIFO exists in library "B":

       dc_shell> report_design_lib -lib

     reports that "B" is defined and points to the appropriate unix directory.

       dc_shell> report_design_lib B

     lists the contents of B showing that FIFO exists and is up-to-date.

  3) confirmation:

       dc_shell> elaborate FIFO -lib B

     works !

NOTE: this problem occurs for both parameterized and non-parameterized parts.

This problem has been lurking around for some time.  We've checked that
the VHDL source uses the appropriate "library" and "use" clauses; that
the design libraries are correctly defined and contain the correct,
properly analyzed source (and are on the search path).

Unfortunately, every time we try to extract a small test case from our
environment the problem evaporates.  Often the problem disappears after
deleting all analyzed files and re-analyzing everything.  We've just
been unable to isolate the factor(s) which trigger this problem.

We'd like to know if anyone else has experienced this and if they
have a better idea of the cause. Our only workaround is to throw
everything into the WORK library.

  - Iain W. Finlay
    Qualcomm, Inc.


( ESNUG 248 Item 5 ) -------------------------------------------- [8/96]

From: peer@iis.fhg.de (Dieter Peer)
Subject: FSM Treatment Doesn't Seem Consistant Or Coherent In Synopsys

John,

I am busy with state machine synthesis and I have been fighting with design
compiler some days in order to get the last picoseconds out of my FSM, that
is supposed to reach 66 MHz.

The fsm has 12 states and I get quite nice results using 4 or 5 bit for the
state coding. I am using a tricky synthesis script based on the strategy:

    5% overconstraining
    flatten effort high minimize multiple output
    compile effort high
    correct reconstraining
    compile incremental effort high

After playing around quite hard looking very close to the bits that define
my state transitions I ended with one state coding that finally fits my
design requirements. That part of my VHDL code looks like:

  attribute ENUM_ENCODING of sm_next_state_type : type is 
    "0011 0010 0001 1010 0000 0100 0101 1101 1100 1011 1111 1001"; 

I decided to check Design Compiler using an identical FSM coding by swapping
the columns of my state coding.  I was sure] to get an identical result,
where the synthesized flipflops (SIG_st_sm_next_reg[0][1][2][3]) just
changed their order.

  attribute ENUM_ENCODING of sm_next_state_type : type is 
  -- order ABCD
  --   "0011 0010 0001 1010 0000 0100 0101 1101 1100 1011 1111 1001";
  -- order ADBC
       "0101 0001 0100 1001 0000 0010 0110 1110 1010 1101 1111 1100";

I am very unhappy to see that the IDENTICAL synthesis script on an
IDENTICALLY coded state machine produces DIFFERENT results!  It violates
the constraints with a slack of 0.36 ns, which means that my FSM would
allow a maximum frequency of only 64.5 MHz instead of 66 MHz!

I understand that I get quite different results when using different state
assignments.  Do you know an explanation, why the results also differ, if
I change only the ORDER of my state vectors?  Could I perhaps also get
better or worse results, if I would change the order of my entity ports in
the VHDL description from alphabetically to (whatever)? 

  - Dieter Peer
    Fraunhofer Gesellschaft, Germany


( ESNUG 248 Item 6 ) -------------------------------------------- [8/96]

Subject: ( ESNUG 244 #4 246 #1)  Will Trade My Secret Switches For Yours!

> There is nothing very secret about the existance of synopsys switches.
> All an inveterate hacker needs to do is pass the dc_shell_exec executable
> through the UNIX "strings" command and "grep" for a suitable result.  For
> example, the following command gives an interesting output listing all
> compiler directives hidden or otherwise:
>
>       strings -a SYNOPSYS_PATH/dc_shell_exec | grep compile_
>
> ...also useful for hunting error messages, etc.


From: [ Synopsys Synthesis Marketing ]

Dear John,

There has been much discussion in E-SNUG lately about hidden variables in
Design Compiler.   Hidden variables are used for three main purposes:

  - To turn on software debugging (used by our R&D people) in dc_shell
  - To work around specific customer problems
  - To enable new but untested features for beta testing only

In the first case, the variables in question clearly have no usefulness to
the end user.  Such variables are used by Synopsys R&D to aid in debugging
new versions of Design Compiler.

The second set of variables are meant to work around specific customer
issues such as bugs or preserving backwards compatibility.  New features in
Design Compiler can often be disabled using such variables (in the event
that the new feature causes a problem with a specific customer's design
methodology.)

The third grouping of new variables is used during beta test of new
features in Design Compiler.  This set is by far the minority among hidden
variables.

By and large, most hidden variables will not be useful for production design.
Some variables have promising sounding names, but do nothing.  An example
is "compile_faster".  Some variables can be useful for working around
problems, as directed by the Support Center.  For example, in v3.1a the new
sequential mapping algorithm caused long runtimes.  Fortunately, a hidden
variable existed which allowed users to revert to the old algorithm when this
was causing a problem.

Other variables turn on experimental features which are either not useful
for production design or could actually have negative effects.  An example
is "compile_clean_inverters".  This feature is being tested and if it works
as planned, it will be turned on in the next version of Design Compiler.
But if there are problems with the feature in the current release, Synopsys
will not be able to support customers that use it on production designs!

The best rule of thumb is not to use an undocumented variable unless
directed to do so by the Support Center. If you don't know what it does,
don't use it.

  - [ Synopsys Synthesis Marketing ]


( ESNUG 248 Item 7 ) -------------------------------------------- [8/96]

Subject: ( ESNUG 247 #8 ) EDIF Properties & FPGA Compiler Name-Changing

> In the EDIF netlist reader documentation is described how an EDIF property
> field  has to look like to be interpreted as resource assignment by mp2.
> Now the question is, how do I force Synopsys to write these property
> constructs?  There is an EDIF variable edifout_write_properties_list.
> The man-pages say, that the corresponding properties will be written out
> in EDIF.  How do I set these properties?  Can I set a property like
> "clique" to "my_clique"?  I first assumed that user defined attributes and
> properties are the same, but the VHDL Compiler does not let me define
> attributes for a design for synthesis!


From: miller@symbol.com (Wayne Miller)

Hi John,

To read in, or write out edif properties, you need to set two variables
in your .synopsys_dc.setup file:  edifout_read_properties_list and
edifout_write_properties_list.  To set a property like "clique", there is a
Solv-it article that is available from the web or Solv-It-on-Site.

I did a search on "edifout_write_properties_list", and the top result is:

  DC v3.3a:current Reading in and writing out properties from EDIF
  SYNTH-848 1995:07:19 2K Synthesis A:01338 R:00502

  QUESTION: How do I use the edifout_write_properties_list variable?

  ANSWER: Here is a sample script to demonstrate the usage of the
  "edifout_write_properties_list" variable.
 
  The script creates two new variables 'cell_type' and 'output_load'. It
  checks all the cells in the design to see if they are black boxes,
  sequential elements or non-sequential elements. It sets the new
  attribute 'cell_type' accordingly.

  The script then checks the load on each outpout port and sets the new
  attribute 'output_load' to the value of the load on the port. Finally,
  it writes out the EDIF file.

    edifout_write_properties_list = {cell_type output_load}
 
    filter find(cell,"*") "@is_black_box==true"
    cell_list = dc_shell_status
    foreach (item,cell_list) {
    set_attribute item cell_type black_box -type string
    }
 
    filter find(cell,"*") "@is_sequential==true"
    cell_list = dc_shell_status
    foreach (item,cell_list) {
    set_attribute item cell_type sequential_element -type string
    }
 
    filter find(cell,"*") "@is_combinational==true"
    cell_list = dc_shell_status
    foreach (item,cell_list) {
    set_attribute item cell_type non-sequential_element -type string
    }
 
    foreach (item,all_outputs()) {
    get_attribute item load
    value = dc_shell_status
    set_attribute item output_load value -type string
    }
 
    write -format edif -hierarchy -output test.edif
 
I hope this helps.

  - Wayne Miller
    Symbol Technologies, Inc,


( ESNUG 248 Item 8 ) -------------------------------------------- [8/96]

From: gmann@ford.com (Greg Mann)
Subject: Handling Tricky Timing Paths Through A Bi-Directional Bus Interface.

Hi John,

I have registers with paths through logic, then through a tri-state driver,
and then out to a bidirectional bus.  Data can also be brought in from the
bus to the same registers but not on the same bus cyle.  I need to disable
the timing path which loops from the flip-flop Q out through the bus 
interface and back to the flip-flop D input without disabling other paths
with the same end-points.  I still need the timing to be checked between 
the data bus and the flip-flop.
                                     Bidirectional Data Bus
   ______________________            ======================
  |       ___            ^        Enable ___    ^
  V______|   |   ____    |      __          |   |             __
   ______|MUX|__|    |   |   ,-~  \__     |\|   |   |\     ,-~  \__
  ^      |___|  |    |___|__( Logic  }____| \___V___| \___( Logic  }__
  |        |    | FF | |     \     _/     | /       | /    \     _/   |
  | Select_| ck-|>   | |      ~---'       |/        |/     /~---'     |
  |             |____| V__________________________________/           |
  |___________________________________________________________________V
  
Has anyone come up with a good solution to this type of timing problem?

  - Gregory J. Mann
    Ford Microelectronics Inc.


( ESNUG 248 Networking Section ) -------------------------------- [8/96]

Raleigh, NC -- Alcatel seeks ASIC engineers with Synopsys & Verilog exper.
for SONET/PDH telecom design.  No agencies. "williams@aur.alcatel.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)