Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!dg!lewine
From: lewine@dg.dg.com (Don Lewine)
Newsgroups: comp.arch
Subject: Re: Do chip timing specs mean anything?
Message-ID: <712@dg.dg.com>
Date: 6 Aug 90 14:21:54 GMT
References: <1990Aug4.152038.1132@sbcs.sunysb.edu>
Reply-To: uunet!dg!lewine (Don Lewine)
Distribution: na
Organization: Data General, Westboro, MA.
Lines: 33

In article <1990Aug4.152038.1132@sbcs.sunysb.edu> owen@sbcs.sunysb.edu (Owen Kaser) writes:
>Do timing specs for microprocessors and their support chips bear
>any relation to reality, and do industrial designers 
>(need to) pay any heed to them?  Here's the background for my question:
>
>I did a number of microprocessor-based designs during my stay
>at a small company a couple of years ago. 
      ^^^^^

This may be valid for a small company.  For larger companies, it is best to
negotiate a new purchase specification with the manufacturer.  If they are 
willing to certify that their parts will work 30% (or 50% or whatever) faster
than it says in the handbook then go ahead and use it.  If they are unwilling
to make such a statement, I would live with the published spec.

Because I HAVE gotten purchase specs written for improved performance and 
because I don't believe that these were sorted parts, there must be lots of
parts that run faster than the handbook spec.

The problem is which parts run faster and how much faster do they run?
If you don't know, you are either giving up performance or risking unstable
operation.  Talk to the vendor and see what he says!

By the way, if the number of chips in the design is large, worst case may be
very pessimistic.  If there are many chips in the critical paths, what are the
odds that every one is worst case slow?

I worked at one computer company where manufacturing measured the highest speed
that each computer would run.  After a year, we raised the clock rate to the
highest speed that every computer ran minus 5%.

P.S.	Having 1/2 nanosecond too little setup time can be one of the hardest
	problems that you will ever debug.