From: rohm@cayman.engr.sgi.com (Matthew Rohm)
> Hey John,
>
> Concerning your survey for user-oriented panels/tutorials for USE/DA to
> sponsor at the next DAC, how about "Dunk Your Favorite EDA CEO"?
> CEO's from 6 to 12 EDA vendors could sit above a water dunk tank (like
> those at a state fair). Balls to throw at the dunking trigger could be
> sold at $1 each. Its bound to draw a large audience, and be a big money
> maker for USE/DA, too!!! :-)
>
> - Matthew Rohm
> Silicon Graphics, Inc.
No can do, Matt. Not only would the customers line up to buy balls, the
CEO's employees would be fighting for their turn, too! It would be a
security & logistical nightmare! (It was fun to visualize, though...)
:^) - John Cooley
the ESNUG guy
( ESNUG 227 Item 1 ) ---------------------------------------------- [10/95]
Subject: (ESNUG 226 #4) Funky Toshiba/VSS VHDL Gate Simulation Methodology
>I am currently taking a VHDL design through Synopsys 3.3b and to Toshiba's
>0.7 micron tc170g gate array line. ... To perform gate level simulation
>with Toshiba the following steps must be taken:
>
> 1. Synthesize gates
> 2. Write out VHDL netlist
> 3. Translate VHDL netlist to Toshiba's TDL netlist with Toshiba's vhdl2tdl
> application program.
> 4. Run Toshiba's TDC (Toshiba Delay Calculator) to estimate all delays and
> generate sdf file.
> 5. Use original VHDL netlist and sdf file just generated to simulate in VSS.
>
> Why can't I simply write out the VHDL netlist and the SDF file directly
> from dc_shell and simulate that in VSS? It's a lot less steps.
> If you say that I can't do that because TDC will give more accurate
> delays than Synopsys's own timing analyzer then why did I bother
> to set the constraints in Synopsys land if they are going to be
> inacurrate? Stated a different way, if Synopsys timing analysis is
> good enough for synthesis, why isn't it good enough for simulation?
> Can you imagine the iterative process that a designer would have
> to go through if the Synopsys timing analysis and the Toshiba
> timing analysis were different?
From: [ No Name, No Nothing ]
John, ( Please, No Name, No Nuthin'! I suffer from Synopcosis - the fear of
Synopsys corporate reprisals.)
This sounds like pretty standard ASIC design flow to me.
You can in fact use the SDF generated from the synthesis models. They may
(and most likely will) give numbers different from Synopsys vs. TDC.
There are multiple reasons for these variances:
1) 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.
And as each ASIC vendor tweaked their algorithms, Synopsys would have to
adjust the Design Compiler. Thanks, but Synopsys updates their stuff
enough now! Putting all of these delay calculators into Synopsys will
also give ASIC vendors immediate access to each others algorithms, which
they would not like.
2) Depending on the vendor, floorplanning IS taken into consideration in
native delay calculators. While I am not familiar with TDC, I'd be real
amazed it you could not do it in Toshiba's native environment.
In general, you should not be too worried about the timing differences
between the two environments. But if you're doing super-fast designs, or
designs with asynchronous logic and not following basic design rules, then I
would definitely recommend using the TDC. It's the golden delay calculator.
- [No Name, No Nothing]
---- ---- ---- ---- ----
From: Atle.Haga@alcatel.no (Atle Haga)
John,
I have a feeling that this user is only *STARTING* to get problems when he is
concerned about pre-layout timing. Usually the designer has to verify
post-layout timing and get all the problems if something gets too slow. My
concern is that even if pre-layout timing correlates well there is no
guarantee that post-layout timing correlates. To illustrate this I will tell
a horror story ( happy ending ):
We run a 50k gate design using LSI LCA300k. Target speed 40MHz. Could
easily been synthesized for 60MHz operation. We had plenty of margin for
avoiding timing problems after layout. The LCA300k timing correlated well
pre-layout (2-5%) and the layout tools did a good job and the post-layout
timing were just sligthly better.
Then we took the majority of this design and reused in a 40k gate design
using a 0.8 micron process and an UNNAMED vendor. Still running at 40MHz.
Since we had high utilization we assumed 3 layer metal was the only
possibility to realize this chip on a given die (biggest available for the
REQUIRED package). The vendor did not even have wire load models taking 3LM
into account! Synthesizing the chip gave 15ns VIOLATION in timing on my 25ns
period. Only due to conservative estimates. I could have optimized the
design week after week to reach my 40MHz target. Probably ending up with
lots of additional pipelining and too many gates to fit into the die. Ending
up not able to fit in the REQUIRED package.
Fortunately I had access to the place & route tools. I tried one pass and
ended up with 2ns SLACK! An improvement of 17ns! Several layout runs
confirmed that it was not pure luck. This is very depending on the layout
tool, specially the placement algorithm.
The ideal situation would have been to use a trial layout to generate new
wire load models, manually or by using floorplan manager. Then to completely
rerun synthesis based on this model. Perhaps check the wire load model once
more (iterate). Since this was a real world project I did not have time to
test this improved designflow. I was very pleased to reach the 40MHz target
and fit on the die with 70% utilization.
End of story, chip is being processed just now. I guess I was lucky because
I had access to the P&R tools. Trying to sign-off at netlist level with 15ns
timing VIOLATION would never worked.
But the margining is not always to your advantage: sometimes low drive gates
with many input pins end up close to the input source and leaving the output
with a very long wire giving a lot of unexpected delay (rubber band effect).
This hopefully shows that pre-layout is only one side of the story, unless
you get your vendor to guarantee that pre-layout timing will not get worse
during layout. If you have the posibility make a test run through P&R as
soon as possible and check the timing correlation yourself. The goal is to
estimate without being too conservative.
- Atle Haga
Alcatel Telecom Norway
---- ---- ---- ---- ----
From: rray@msai.com (Russell Ray)
I have three years of modeling in Synopsys both in creating synthesis
models and VHDL models. I can only reply to the first question as to why the
SDF from Synopsys may not be "accurate" enough. However, I have no idea how
Toshiba's models are created.
One example of why the sdf created by Synopsys is not accurate enough is an
unbuffered flip-flop. This cell has a delay from one output to the other
which makes the dependent output pin load dependent on the first output.
Assume that Q propagates to Qbar, a load on Q will slow down the clk->Qbar
transition. In Synopsys, I have not found a way to represent this output
load dependency in anything but a linear model. So if you are trying to get
high accuracy for this ff and are using non-linear models, you have to
approximate the effect due to output loading.
In a delay calculator, this approximation is not necessary and therefore you
can get the "true" delay dependency. Why is it "good enough" for synthesis
and not simulation? You have to use what is available to make synthesis
work. The only other alternative is to throw out any cell that can not be
modeled 100%, a decision that most ASIC vendors will not make due to the
advantages these cells can make in a design (ie. reduced area/speed).
- Russell Ray
Mitsubishi Semiconductor
( ESNUG 227 Item 2 ) ---------------------------------------------- [10/95]
Subject: (ESNUG 225 #3 226 #2) Surprising Answer To A Metastability Question
>For the earlier question of a two-stage design versus a single-stage
>design at half the clock rate, THE SINGLE-STAGE DESIGN IS BETTER! The
>single stage design is better because it has an entire extra 25ns period
>(the difference between 40MHz and 20MHz) for the metastability event to
>resolve whereas the dual-stage design has only an extra 25ns - Tsu - Tpd.
>
>In terms of MTBF, the single stage design is better by a factor of:
>
> (Tsu+Tpd)/tau
> delta MTBF = e
>
>For example using Tsu=1ns Tpd=2ns tau=.2ns gives:
>
> delta MTBF = 3.3*10^6 times better!!!
From: vinu@atc.olivetti.com (Vinu Arumugham)
Hi John,
I think the performance of the two synchronizers in Bob's problem cannot be
usefully compared unless the frequencies of the core logic are the same. In
his problem, one design has a core frequency of 40 MHz, while the other is
shown running at 20 MHz.
For the same core logic frequency, the use of a single-stage synchronizer
clocked at half the frequency, would be twice as reliable as a design that
used a single-stage synchronizer clocked at the core frequency. That is,
we just changed the fclock parameter in the metastability equation by a
factor of 2, while the settling time available in both cases remained the
same. However, using a dual-stage synchronizer with both stages clocked at
the core frequency, will achieve an MTBF several orders of magnitude greater
than the single-stage cases.
CALCULATING DUAL-STAGE MTBF: The data input to the second-stage is
"asynchronous" only when the first stage is in a metastble state. The
average frequency of this occurence is (1 / MTBF) of the first stage.
Therefore, the MTBF of the second-stage can be calculated by replacing the
(2 * fdata) with (1 / MTBF) of the first stage in the standard single-stage
metastability equation.
CONCLUSION: If a designer has core logic running at frequency F and needs
to chose between single-stage synchronizers clocked at F/2 & dual-stage ones
clocked at F, the DUAL-STAGEs clocked at F would be the design of choice.
- Vinu Arumugham
Olivetti Advanced Technology Center
( ESNUG 227 Item 3 ) ---------------------------------------------- [10/95]
[ Editor's Warning: DON'T DRIVE CLOCKS (EVEN WITH INFINITE DRIVE!) What
follows is not a quasi-academic discussion of an obscure Synopsys bug,
but something that was an independent confirmation of a nasty show-stopper
I just got back from helping a client on. To better understand what
Steve is describing, here's a quickie Synopsys timing tutorial:
Total Delay = Edge Delay + Intrinsic Delay +
Transition Delay + Connect Delay
Edge Delay: The delay from an input pin to an output pin because of the
slow rise or fall being applied at the input pin.
Intrinsic Delay: The build-in delay from the input to an output of a gate
(usually output resistance mulpitied by the sum of loads.)
Transition Delay: The delay due to capacitive loading on a gate's output.
Connect Delay: the time it takes for a waveform to travel along a wire.
NOTE: Setting infinite drives on clock pins, for some reason, doesn't get
rid of the Transition Delay that Design Compiler sees. - John ]
From: sgolson@trilobyte.com (Steve Golson)
Subject: (ESNUG 220 #5 221 #2) "Non-Linear Libs, Weird Delays & Clock Drives"
John,
Here's a follow-up on my weird timing problem as reported in ESNUG 221,
the problem appears as follows:
> Run report_timing and see a path with 20 ns delay, then put a
> non-inifinite drive on the clock pin with "set_driving_cell" and
> report_timing shows 210 ns delay. A 10X delay gain!
According to Synopsys, here is what is going on:
1. 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.
2. The non-linear delay model (NLDM) tables in the library are not
characterized to handle such huge transition delays. As a result you
may end up with *negative* propagation delays.
3. Design Compiler uses the largest transition delay it can find, rather
than the transition delay for the critical path.
The result is that you get calculated delays that are totally bogus.
Here are my comments on each item above:
1. Do not put a drive on a clock port (unless you plan to use
"set_clock_skew -propagated"). Be careful using "all_inputs()" with
"set_driving_cell". A STAR has been filed, so that Design Compiler will
ignore the driving cell on ideal clocks.
2. If you have the library sources you can use report_delay_calculation to
try and figure out what is going on. Without access to the library
sources, how can a user hope to know if the NLDM tables are being pushed
past their characterized limits?
Enhancement request: all library tables should have a characterization
limit specified by the vendor, and if Design Compiler ever exceeds that
limit, a warning is output.
This is a Design Compiler bug. A STAR has been filed. You can use
set_disable_timing in the v3.3b release to guide Design Compiler to pick
the correct transition value.
- Steve Golson
Trilobyte Systems
( ESNUG 227 Item 4 ) ---------------------------------------------- [10/95]
From: ehlers@brooktree.com (Steve Ehlers)
Subject: Flakey 3.3a Compile Fatals & Sensitivity Lists
John,
I too have been experiencing fatal compile errors (ESNUG 220 #6 222 #1) in
the early optimization stage (Resource Allocation) with Synopsys 3.3a. In
the failing Verilog module I discovered that I had neglected to remove some
variables from a Verilog sensitivity list (as in, "always @ (var1 or var2
or var3)") after taking them out of the corresponding "case" statement. I
removed the un-used variables from the sensitivity list and the module
compiled fine.
Synopsys is really good for reporting variables that aren't in a sensitivity
list but should be. Maybe they could report unused or redundant variables
as well? While it shouldn't be their response to the fatal errors, it would
be good not to waste the simulation time consumed by evaluating a statement
needlessly.
- Steve Ehlers
Brooktree Corporation
( ESNUG 227 Networking Section ) ---------------------------------- [10/95]
Alameda, CA, Exemplar Logic seeks EDA developers. Background in Logic
Synthesis and/or Windows95/NT are a plus. No agents. "gary@exemplar.com"
Houston, TX, Compaq Computers seeks ASIC Verification Engineer w/ Verilog
and X86 PC architecture experience. No agencies. "hoch@twisto.compaq.com"
Cupertino, CA - Ikos Systems, Inc. seeking ASIC designers w/experience
in synthesis & HDL meth for HW design position. "jonathon@ikos.com"
|
|
