[SI-LIST] Re: timing analysis

> As I mentioned, there is a camp in our company that says the
> methodology I described above is too pessimistic.  As evidence, they
> point to the fact that all our boards work at 100 MHz over
> temperature, even though worst-case timing analysis says we have
> negative margin above 85 MHz. They are asking me to adjust my
> methodology in order to show positive "worst-case" margin at 100 MHz.

Are those arguments being made by seasoned engineers or young kids who don't 
understand the big picture?  Or maybe managers who don't like your answers?  
Have they gone over the timing budget and pointed at the numbers they want 
you to shave and provided some justification?  Have they commented on the 
risks?

I think there are two issues here.  One is engineering.  The other is 
management.

Management has to make trade offs between cost, time to market, and quality.  
A major aspect of quality is reliability.  The importance of reliability and 
cost differ between consumer gear and medical/defense equipment, PCs and 
servers.  Time-to-market may be critical for a startup.  ...

Engineering has to provide the information to make those decisions and tune 
the design in response to feedback.

There is another dimension to this discussion. It's the interface between 
engineering and management.  One issue is risks.  Another issue is 
confidence/trust.

If engineering says X for reliability, what are the chances they are wrong?  
One argument for having a conservative timing analysis is that it is lower 
risk.  That simplifies the interface between engineering and management.  
Engineering doesn't have to spend time explaining and justifying their 
methodology to management and management doesn't have to spend time wondering 
if engineering's designs will run reliably.  Even a solid design still has 
risks, it's just that other types of risks become much more important than 
timing errors.  (Consider vendors of key parts going out of business, or lead 
times on caps going through the roof, or software bugs.)

A design that runs at 85 MHz on paper but 100 MHz in the lab doesn't seem 
very surprising to me.  The above said "over temperature", but didn't say 
voltage.  It's also using typical silicon and typical PCB and ...

As somebody else mentioned, is 85 MHz fast enough to get the job done?  If 
so, run at 85 MHZ and go work on more important problems.  Or ship it sooner. 
 Again, part of the goal is to reduce the interaction between engineering and 
management.

It might be interesting to investigate where the differences come from.  Are 
there any  numbers you think you can shave?  Why?  What are the risks?

For example, do you really think you can save a ns off the tester guard 
bands?  Let's
assume the vendor isn't stupid.  Why do you know more about their setup than 
they do?  If there was a ns to save, wouldn't they have saved it already?  
For high volumes, you might get the vendor to sell you specially binned 
parts.  For low/modest volumes, you might be able to test them yourself, but 
I think it would be a lot of work to setup the testing procedure.  Do you 
need that hassle?  Is it worth it?  It might be if you really need to run at 
100 MHz.

Another example, I might be willing to cut corners on temperature for hand 
held consumer gear.  But what happens if it gets left in the sun?


-- 
These are my opinions, not necessarily my employer's.  I hate spam.



------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field


List technical documents are available at:
                http://www.si-list.net

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu

Other related posts: