From: rwallace@cmp.com (Richard Wallace)
> Dear John,
>
> As a lifelong New Yorker -- the proud home of fellow newspaper great
> Horace Greeley -- and the former proud owner of a certified junk-yard dog,
> I must strongly object to the suggestion by one of your readers that the
> dog food you raise should be shipped West to benefit Pacific Pooches.
> (Recall that although Greeley proclaimed "Go West young man," he had the
> good sense to remain in the East himself where he settled comfortably just
> North of New York in Westchester County!)
>
> As Editor-in-Chief of "EE Times," and a former bulldog reporter for
> "Electronic News," I have been witness to 20 years of shameful East/West
> coast rivalry in the form of West Coast engineers characterizing peaceful
> East Coast engineers as stick-in-the-mud old fuddy-duddies who are slow to
> adapt to any technical change while supposedly the West Coasters are more
> cutting edge, fleet-on-their-feet designers three steps ahead of anyone
> and anything. Although I can respect in ESNUG 224 Gunes Aybay's attempt,
> as a career enhancing maneuver, to secure some of the better dog food for
> his CEO, Scott McNealy of Sun Microsystems -- I must discourage it.
>
> I believe good engineering isn't a function of geography and wish to
> provide some balance in this unjust propaganda war pushed on peaceful East
> Coast designers by these West Coast rabble rousers. In order to give the
> East Coast dogs a "leg up" on these troublesome West Coast dogs, I'd like
> to encourage you to deliver *all* of Joe Costello's dog food to the East
> Coast Cadence office.
>
> - Richard Wallace, Editor-in-Chief
> Electronic Engineering Times
>
> P.S. Either way, enclosed is my check for $12.00 for a 22 lb bag of
> "Pedigree Lamb." Tell Joe "EE Times" says "Bon Appetit!" :^)
( ESNUG 225 Item 1 ) ---------------------------------------------- [8/95]
From: johara@ATVL.Research.Panasonic.COM (Joe O'Hara)
Subject: Synopsys Point-To-Point Timing Exceptions
Hi John,
Here's another contribution to the list of Reasons Why Synopsys (insert
your favorite expletive): If you have a design with point-to-point timing
exceptions (i.e. multicycle paths, false paths), these exceptions become
invisible to the timing analyzer when the design is incorporated into the
next higher level of hierarchy.
I have a design in which several lower level modules contain literally
hundreds of point to point exceptions (mostly from a microprocessor test port
to places in a state machine which are actually inacessible during system
operation.) After I carefully set these up & compile the block until I get
a clean timing report, I set dont_touch on the module and then work on the
next level up. But the timing analyzer does not take the subdesign's
exceptions into account!!! Consequently, I get ridiculous compile times and
a lot of bogus timing violations.
The only solution I am aware of is to write_script from the lower level
design, and then edit all of the -from's and -to's to reflect the cell name
(U-number) of the design in the higher level. <Ugh!> Doing this in a large
design with several levels of hierarchy is obviously a tedious and error
prone process. (Do you know of any more clever ways to overcome this? I am
wary of using the "-hierarchy" switch in the "find()" command as a way of
getting out of typing in the full path to an endpoint -- too much chance for
hitting the wrong one in a large design (plus it doesn't seem to work once
the design has been flattened using "ungroup.")
- Joe O'Hara
Panasonic
( ESNUG 225 Item 2 ) ---------------------------------------------- [8/95]
Subject: ( ESNUG 224 #5 ) Miracle Healing Of EDIF "write" Problem
>I faced a problem with the Synopsys 3.2b while I am writing out a design in
>EDIF. I read a design in EDIF and selected a cell in it. I executed the
>"link" command and later I tried to save the design with a different name in
>EDIF (using the write command). I got an error saying the "write" failed.
>After selecting the design and executing the link command, I looked at the
>gate level netlist to see whether there was any problem. I did nothing.
>Next, when I saved the design with some other name & it happily worked. (??)
From: drama@india.ti.com (D Ramanath)
Hi John,
This is actually not a bug. The design has to be mapped to gates before
writing out the EDIF design. It is a requirement of Synopsys for EDIF, PLA
and MENTOR formats. (But there is no such requirement with Verilog, VHDL and
db formats.)
- D. Ramanath
Texas Instruments
( ESNUG 225 Item 3 ) ---------------------------------------------- [8/95]
[ Editor's Note: I *really* liked this contribution Bob sent! - John ]
From: exabyte!loki!bobsug@uunet.uu.net (Bob Sugar)
Subject: My Surprising Answer To A Personal Metastability Quest
Dear John,
A few weeks ago, I sent out a memo to a bunch of designers asking about
metastability. After going through a bunch more articles, papers and
responses, I finally have a good answer. Since this is a problem that all
digital designers face at sometime, I decided to write up a brief refresher
on metastability calculations including the answer to my previous question.
- Bob Sugar
Exabyte Corporation
Here's my original question:
> From bobsug Fri Jul 7 11:54:36 1995
> Subject: A Modest Question
>
> I have what I thought was a simple question, but I'm having a devil of
> a time finding an good answer to it. The question involves metastability
> and synchronizer circuit design. Specifically, within a given ASIC
> technology is a dual-stage synchronizer running at 40 MHz more reliable
> than a single-stage synchronizer running at 20MHz [all other delays
> being equal]?
>
> Pictorially, here's the problem:
>
> Dual-Stage Design:
> _____ ------
> / \--------|D Q|
> ------ ------ SYNC | | | |
> ASYNC ----|D Q|----|D Q|-------| Blob | | |
> | | | | / of \ ---|> |
> | | | | | logic | | ------
> --|> | --|> | \_ | | ------
> | ------ | ------ \ |------|D Q|
> | | \____/ | | |
> | | | | |
> 40MHZ -------------------------------------------|> |
> ------
>
>
> Single-Stage Design:
> _____ ------
> / \--------|D Q|
> ------ SYNC | | | |
> ASYNC ----|D Q|--------| Blob | | |
> | | / of \ ---|> |
> | | | logic | | ------
> --|> | \_ | | ------
> | ------ \ |------|D Q|
> | \____/ | | |
> | | | |
> 20MHZ ----------------------------------|> |
> ------
>
> Which is more reliable?
>
> I've looked at a bunch of references and found a surprisingly large
> number of typo's and mistakes in equations and illustrations. None of
> the scholarly papers I have discuss multi-stage synchronizer designs.
> Depending upon what values I use for the metastability constants To and
> t [tau] along with which set of equations I use, I get conflicting
> results. Some say that the first design is better, some say that
> the second is better. Do any of you know the answer to this problem [and
> have good references to back it up]?
Now, after a quick review of simple metastability calculations, we'll get
to multi-stage calculations and finally, The Answer. In general, when
you clock a flip-flop, the output goes to the proper state a propagation
delay later. If the input just happens to be changing at the critical
time, the output may go metastable and take a little longer to resolve
itself to a stable state.
Experimentally, metastability is measured by clocking an evenly distributed
random input into a flip-flop and measuring the time until the output has
stabilized. If the results are plotted as number of occurances versus delay
time, an exponential curve will result [simplified model]:
| *
| *
Number | *
of | *
Events | *
| *
| *
| *
| *
| *
--------+------------------------------------
Tpd
Delay from clock
Just like a linear line can be represented in the form
Y = MX + B
an exponential curve can be represented in the form
-(T-Tpd)/tau
Y = K * e
After rearranging this, accounting for the nominal propagation delay (Tpd)
and adding clock and data rate scaling factors, we can come up with an
equation for failure rates. A "failure" is when the output has not
resolved itself by Tr seconds after the nominal propagation delay. A
common equation for for a single flip-flop synchronizer is:
(Tr/tau)
e
MTBF = ------------------------
2 * fdata * fclock * To
Tr is the time available for the metastability to resolve itself
(generally the clock period minus setup and propagation
delays of any intermediate logic)
tau is the resolution rate (experimentally measured)
2*fdata is the incoming event (edge) rate
fclock is the clock frequency
To is the metastability aperature (experimentally measured)
(this is a constant related to the width of time window
during which an input transition will cause a metastability
event)
For a multi-stage design, the equation becomes: [Many articles have incorrect
multi-stage equations -- I'm fairly sure that this one is correct.]
(T1/tau)
e
MTBF = ------------------------
2 * fdata * fclock * To
T1 is the total resolution time available from N stages
= N*Tclock - (N-1)*(Tpd+Tsu)
Tclock is the clock period = 1/fclock
Tpd is the clock to Q propagation delay
Tsu is the data to clock setup time
Overall, the longer the TOTAL resolution time across all stages, the better.
THE ANSWER:
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!!!
Note: the published values I've seen for modern technologies (<2um) are:
tau = .1ns to .5ns (the smaller the better)
To = .1ps to 100ns (the smaller the better)
In general, small changes in resolution time cause very large changes in
MTBF. For best MTBF when using Synopsys, split up the modules so that
the delays in the "Blob of logic" from the above example can be made
as small as possible (using a large input delay and "dont_touch"ing the
resulting logic).
Again, remember that the longer the TOTAL resolution time across all
stages, the better. For example, inserting a falling-edge clocked flip-
flop in the middle of a 2-stage synchronizer is a bad idea. Likewise,
while inserting a schmidt-trigger buffer between stages may clean up a
marginal voltage level, it ends up reducing the MTBF by much more than
the additional hysteresis can save. A change of only a couple nanoseconds
in resolution time can change the MTBF by a factor of over a million!
- Bob Sugar
Advanced Technology Group
Exabyte Corporation
For a couple good articles on metastability, see:
D. Grosse, "Keep metastability from killing you digital design,"
EDN, June 23, 1994, pp. 109-116.
[An easy to read article, but 2-stage equations are wrong]
L. Kleeman and A. Cantoni, "Metastable Behavior in Digital Systems,"
IEEE Design and Test of Computers, December 1987, pp. 4-19.
[A much chewier paper including multi-stage equations and an
extensive list of additional references]
( ESNUG 225 Item 4 ) ---------------------------------------------- [8/95]
Subject: ( ESNUG 224 #4 ) Critiques Of The Synopsys Scripting Language
>I rather disagree with the semantics of the Synopsys scripting language.
>The typing rules are complex and obscure. The correct working of commands
>is sometimes a matter of trial-and-error, even for the hotline staff. The
>understanding of some types is difficult, (e.g. can somebody tell the exact
>distinction between a design, a cell and a reference?) Attributes are
>indispensable for making scripts do what you want, but it is often unclear
>at what moment they are set by the tool. Is an attribute set after reading
>the database, after elaboration or after compilation? If it is set for a
>reference, is it also set for a cell? Some attributes appear to be set only
>after seamingly unrelated commands. User-defined variables often must be
>type cast by a find command, but if this is obligatory again is a matter of
>trial-and-error. Between different versions of the tool the rules appear
>to change, so my scripts maybe will not work in the next release.
From: hill@synnet.com (Shannon Hill)
Hey, John,
I must agree with W. Boeke's view of dc_shell's scripting language expressed
in ESNUG 224 Item 4... I'm always surprised by the its rules and how long it
takes to get moderately complicated recipes working correctly. To prove my
point, I'll ask ESNUG readers: "How long does it take you to figure out why
the following line has a syntax error in dc_shell script-land??"
dc_shell>dat_clock_pin = find(pin,*MEM*DAT*REG*/CK, -hierarchy )
- Shannon Hill
3COM Switching Division
( ESNUG 225 Item 5 ) ---------------------------------------------- [8/95]
From: cwtong@HK.Super.NET (Chi Wa Tong)
Subject: Synopsys & Two Sun SPARC 10's For Sale
Hi, John,
We have the following Synopsys licences (complete w/ two Sun Sparc 10s):
1 x VHDL Compiler 2 x VHDL System Simulator
2 x Simulation Graphical Environment 1 x Design Analyzer
1 x Design Compiler Expert
Our total asking price is US $90,000.
- Chi Wa Tong
Hong Kong
[ Editor's Note: I'm running this because it's something of a first:
customers reselling licences. If I would run these types of ads I'd
restrict them to two 78 character lines (just like the networking ads)
but I want to know what users & Synopsys employees think about this
overall before I make a decision. (As always, you can be public or
anonymous; just say which when commenting.) - John ]
( ESNUG 225 Networking Section ) ---------------------------------- [8/95]
Mountain View, CA - Synopsys seeks senior FPGA/ASIC/board designers with 2+
years Verilog/Synopsys for Arkos project. No Agencies. "markp@synopsys.com"
Austin, TX - Apple Computer, seeking ASIC designers with exp. in Verilog,
Synopsys, video. Absolutely no headhunters PLEASE. "dblack@apple.com"
Sunnyvale, CA - Escalade Corp. seeks experienced SQA engineers for UNIX &
Windows platforms. Death To Headhunters! "michiel@escalade.com"
|
|
