( ESNUG 227 Item 1 ) ---------------------------------------------- [10/13/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



 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)