Editor's Question: How did the SNUG Europe '94 meeting go? Let's see some
reports! What were the best & worst presentations/talks? Was language
an issue? How many actual users attended? Did Synopsys sales & marketing
reps take over the microphones and drone for hours on end? Any good after
hours parties? Hot gossip? Inquiring minds want to know!
- John Cooley
L'Homme de L'ESNUG
( ESNUG 196 Item 1 ) ---------------------------------------------- [9/94]
Subject: (ESNUG 195 #5) "Invoking Complex Cells"
>In order to improve routability on a particularly congested ASIC layout we
>are proposing to add complex cells to the library (such as a quad scanable
>FF with common enable, clock and scan pins). The problem is: How do we get
>Design Compiler to actually use such a FF or any other complex cell without
>hand instantiating it?
--- --- --- ---
From: kieferv@chdasic.sps.mot.com (Volker Kiefer)
Synopsys does have a limitation in inferring complex library cells. (This
is true for multi-bit FF's as well as arithmetic cells like adders,
multipliers, etc.) We used our own DesignWare library to overcome this
limitation. We built scalable arithmetic cells out of complex building
blocks -- those which Synopsys would not choose automatically -- and put
them into our own DesignWare library. (Of course, to develope this
DesigWare library, we had to buy the DesignWare Developer license.)
For arithmetic operators such as +, -, * Synopsys now will automatically
select our Designware library cell. For the multibit FF's, though, we
still need to instantiate the DesignWare cell utilizing the complex FF's.
- Volker Kiefer
Motorola
( ESNUG 196 Item 2 ) ---------------------------------------------- [9/94]
Subject: (ESNUG 195 #0) "Synopsys Announcing DesignPower"
> Editor's Note: Synopsys just announced that it's going to sell a tool
> called DesignPower that's to be used to do probabalistic power analysis on
> switching CMOS type designs. (It's sort of like a "power" equivalent of
> a static timing analyzer -- you throw vectors at the design in this tool
> and it looks at what gates switched and what didn't from a power point of
> view.) I'm very excited about this -- not the product, but what it
> signifies -- Synopsys is going to start looking at power as a user
> controllable constraint to synthesis! Cool!
--- --- --- ---
From: david@nextwave.com (David Rich)
John,
I wouldn't start counting your sheep just yet. Many Verilog-XL users have
written "toggle count" PLI programs to estimate the switching frequency of
their gates. They multiply the frequency times some AC power factor to get
the total power consumption. This was being done even before Synopsys was
around.
If you have to use simulation vectors to estimate power, then DesignPower is
nothing like a static timing analyzer. Worse yet, if you expect to run
simulations in the middle of a synthesis job to see how well you are meeting
your power budget, you better be prepared to wait a while.
- Dave Rich
ex-Cadence, now at Nextwave Design
( ESNUG 196 Item 3 ) ---------------------------------------------- [9/94]
Subject: (ESNUG 194 #3 195 #1) "Holds On A Single FF Breaks Gate Array Size!"
>I have been enlightened! All you need to do is say the SECRET PASSWORD
>and Synopsys will behave correctly. The SECRET PASSWORD is:
>
> "tvc_uncertainty_handle_self_loops = 1"
---- ---- ---- ----
From: [ Synopsys R & D ]
Concerning clock skew for register self loops in v3.1a use a hidden variable:
"tvc_uncertainty_handle_self_loops = 1"
But in next Synopsys major software release there will be a documented
dc_shell variable:
"timing_self_loops_no_skew = true"
DESCRIPTION: This Boolean variable affects the behavior, runtime, and cpu
usage of report_timing and compile. When true, clock skew is eliminated
for a path starting and ending at the same register. When false (the default
value), clock skew is not eliminated; thus, the timing for such paths is
pessimistic. To obtain the more accurate behavior of no clock skew
(uncertainty) for such paths, set the variable to true, but note that
runtime and memory usage may increase significantly.
- [ Synopsys R & D ]
( ESNUG 196 Item 4 ) ---------------------------------------------- [9/94]
Subject: (ESNUG 192 #4) "DesignWare Costs Too Much!"
>We use the DesignWare library quite routinely here. Are we getting our
>money's worth? I am not sure. We seem to only reference DesignWare for
>ADDERS/SUBTRACTORS/MULTIPLIERS and a occasional INCREMENTOR. Is there
>anyway to design your own DesignWare library? Are there any companies in
>the DesignWare library business?
---- ---- ---- ----
From: mark@abekas.com (Mark Andrews)
You can design your own DesignWare library. Unfortunately but hardly
surprising, it involves another large contribution to Synopsys for DesignWare
Developer. We ended up buying it, and it has worked very well for us, we
have used it to build parametized versions of other math functions (e.g.
dividers) which are absent from the Synopsys Designware library and also
specific custom implementations (e.g. adders optimized for our ASIC vendors
library where the fastest adder macros are all "black boxes"). The only
draw back for us has been that we use Verilog in house and DesignWare
components have to be written in VHDL ( due to Verilog's lack of such things
as GENERATE). Or put another way, we had to buy a VDHL-Compiler license.
- Mark Andrews
Abekas Video Systems Inc.
---- ---- ---- ----
From: cwg@Synopsys.COM (Charles Gopen)
Today several semiconductor companies are either shipping DesignWare
libraries or have announced intentions to do so. The ones I can mention
(because quite a few don't want to announce their DesignWare libraries
until they're ready) are Motorola, Xilinx and Altera.
In the future, DesignWare will be offering more complex designs, like our
recently announced Intel Synthesizable PCI Controller, and that will be sold
with a different licensing conditions than the standard Synopsys Foundation
library. We expect complex designs like the PCI will be a major success,
used by many of our customers, as an alternative to developing their own.
- Charles Gopen
Synopsys DesignWare Marketing
( ESNUG 196 Item 5 ) ---------------------------------------------- [9/94]
Subject: (ESNUG 193 #2) "Anyone Using The Synopsys Static Timing Analyzer?"
> Watch out for the following flags. Setting them wrong could definitely
> result in Design Time reaching the wrong conclusion. With T.I.'s CAD
> tools in their TGB2000 ASIC methodology, we use the following settings,
> which happen to be the defaults chosen by Synopsys:
>
> read_cell_transition "true"
> read_net_transition "false"
--- --- --- ---
From: mcgett@xilinx.com (Edward McGettigan)
The user didn't explain why these variables are important, plus Synopsys has
what I consider a bug in their back-annotation methodology.
The read_cell_transtion & read_net_transition are mutually exclusive variables
in Synopsys -- one has to be "true" while the other has to be "false". These
variables tell Synopsys where the Delay Transition (Dt) timing value is
located in the annotated delay. Setting the read_cell_transition = "true"
indicates that the Dt value is included the back-annotated cell delay.
Setting the read_net_transition = "true" indicates that the Dt value is
included in the back-annotated interconnect or net delay.
Why is this important? If you are back-annotating both cell and net delays
it doesn't matter. If you are back-annotating only a single type of delay it
is very important to generating correct timing.
Let's take a simple buffer to buffer example to illustrate the problems you
can encounter while using the static timing analyzer to go from an input pin
of a cell ("U0/I") to the next input pin of a cell ("U1/I"):
U0 U1
+---------+ +---------+
---|I BUF O|---------|I BUF O|-----
+---------+ +---------+
Simple Example Circuit
The Synopsys delay equation for this simple path is:
( Cell Delay ) + (Net Delay) = Total Delay
Dintrinsic + Dtransition + Dconnection = Total Delay
Dinstrinic (Di): the built-in delay from the input pin to an output pin.
Dtransition (Dt): the time to change the logic value due to loading at an
output pin (output resistance times load).
Dconnect (Dc): the time-of-flight delay - the time it takes a logic
transition to propogate through the interconnect network.
[ Note: the input slope delay term isn't important here. Also the above
defintions come out of the "DesignTime Reference Manual" (appendix A.) ]
For our example path the values are:
Di = 3.0 ns -from "U0/I" -to "U0/O"
Dt = 3.0 ns -from "U0/I" -to "U0/O"
Dc = 2.5 ns -from "U0/O" -to "U1/I"
Therefore the predicted path is:
Di Dt Dc
3.0ns + 3.0ns + 2.5ns = 8.5ns -from "U0/I" -to "UI/I"
Now lets try back annotating only the cell delay with read_cell_tran = true
and the value is 2.0ns from "U0/I" to "U0/O":
Di Dt Dc
2.0ns + 0.0ns + 2.5ns = 4.5ns
If the read_cell_tran = false the path would look like this instead:
Di Dt Dc
2.0ns + 3.0ns + 2.5ns = 7.5ns
In both these cases the transition delay component is taking care of
correctly it is lower in the first case and not affected in the second.
Now lets try back-annotating only the interconnect delay with
read_net_tran = true and the value is 3.5ns from "U0/O" to "U1/"I".
Di Dt Dc
2.0ns + 3.0ns + 0.5ns = 5.5ns
If the read_net_tran = false then the path would look like this instead:
Di Dt Dc
2.0ns + 3.0ns + 3.5ns = 8.5ns
In first case the transition delay component is not lower in the, unlike the
first back-annotating of cell delay case above. Instead the Connect Delay is
lower, but the total delay for this path is correct. And the second path is
correct.
Now lets try back-annotating an interconnect delay that is less than the
transition delay with read_net_tran = true and the value is 2.5ns. You would
expect that Synopsys would generate a timing path like this:
Di Dt Dc
2.0ns + 2.5ns + 0.0ns = 4.5ns
Instead the path is reported as
Di Dt Dc
2.0ns + 3.0ns + 0.0ns = 5.0ns
And this is where the bug is. This path is reported as 0.5ns greater than
what the true value is. The same type of behaviour would be observed if you
were back-annotating both values and had the read_net_transition = true.
There is a work around for this, set the wire load to zero with the command
"set_wire_load" and no arguments. This replaces the fanout table with zeroes
and then all of your Dt and Dc values are zeroed and your back-annotating
will work correctly.
- Edward McGettigan
Xilinx, Inc.
( ESNUG 196 Item 6 ) ---------------------------------------------- [9/94]
From: hill@synnet.com (Shannon Hill)
Subject: Hotline Refuses To Help Via E-mail
John:
The Synopsys hotline folks fail to respect requests to communicate via e-mail.
In my opinion, a well-documented problem I send via e-mail shouldn't get a
telephoned reply from the Hotline. Voice messages like: "I need to talk to
you about your problem, call me at extension XXXX." are useless & wasteful...
Not only are they ignoring my request to use e-mail, but they are failing to
leave a voice message which indicates exactly what questions they need
answered! When I actually do call back, I'm usually forced to wait because
the individual is not at their desk, OR they're helping someone else.
I specifically ask them for NO PHONE CALLS, I want to communicate via email;
yet they repeatedly ignore this request. Does anyone else share this view
and/or experience??
- Shannon Hill
3COM Switching Division
( ESNUG 196 Networking Section ) ---------------------------------- [9/94]
San Jose, California: Nextwave Design is seeking Marketing Engineers with
Verilog and ASIC design experience. "Hal" hwd@yellowstone.nextwave.com
|
|
