[SI-LIST] Re: timing analysis

Brad,

You describe the way we did SI on the Amdahl computers in 1974.  Tedious,
but necessary.

Lee


> [Original Message]
> From: Bradley Henson <Bradley_Henson-NR@xxxxxxxxxxxx>
> To: Peterson, James F (EHCOE) <james.f.peterson@xxxxxxxxxxxxx>
> Cc: <si-list@xxxxxxxxxxxxx>; <si-list-bounce@xxxxxxxxxxxxx>
> Date: 3/23/2009 9:11:34 AM
> Subject: [SI-LIST] Re: timing analysis
>
> Excellent posts.
> I grew up in digital processing in the early 80's learning Signal 
> Integrity before it had a name. We read John De Falco on XTALK, used 
> Teledeltos conductive telegraphers paper to model crosstalk (!), and ran 
> batch SPICE with punch cards!!! I even made crude IBIS models of IC
output 
> stages after curve-tracing I/Os and scoping dV/dT! These early
experiences 
> were usually based on hardware problems: I was part of a fix-it team. We 
> learned as a group to *add* more margin. In other words, what came out of 
> these investigations was to design to a higher Fmax (or shorter clock 
> period) to allow for uncertainties and tolerance build up at various 
> levels of test (vendor's component test, SPICE accuracy, module test,
unit 
> test, System test etc.).
>
> By the late-80's I had earned the reputation to lead my own design effort 
> and be responsible for large processor design project approach, margins 
> and so forth. I fought the exact same battles described in this email 
> trail: RMS/RSS, too conservative, tweak the analysis, semiconductors are 
> never worst case etc. As Jim articulated, you can sharpen the pencil, but 
> there are limits. I never went past the limits I thought I could defend
if 
> things went wrong. When the customer or situation dictated a "compromise" 
> greater than I felt was prudent, it was well documented, and. like Jim, I 
> used a Team approach, making sure all members, including the customer, 
> understood all aspects and bought into the proposed compromise.
>
> It's been over 20 years and many new programs since my first big 
> processor, and almost without exception, those that overruled me were 
> sorry at some point down the line. Many times problems took years to show 
> up: a part change, a software activity change, and so forth. Now, many 
> processors later,  most of those that used to push back and call me too 
> conservative seek me out for their projects: My designs are proven to be 
> robust over time and variables. Follow the sage advice in this thread, 
> stick by solid, documented defensible good practice and get informed team 
> buy-in at all levels.
>
> These are the fun battles you'll remember throughout your career. Relish 
> it.
>
> Brad
>
>
>
>
> "Peterson, James F (EHCOE)" <james.f.peterson@xxxxxxxxxxxxx> 
> Sent by: si-list-bounce@xxxxxxxxxxxxx
> 03/23/2009 08:37 AM
>
> To
> <si-list@xxxxxxxxxxxxx>
> cc
>
> Subject
> [SI-LIST] Re: timing analysis
>
>
>
>
>
>
> I always enjoy the timing analysis dialog on the SI-List. 
>
> I'll add a couple points to this well-answered thread :
>
> 1) this is already been stated, but there is a line you can't cross in
> timing analysis... you can squeeze your margin, push the limits, and get
> less conservative, but when you're finished, you should have a
> defendable position.
>
> 2) I agree that the 60xbus can be a challenge. Especially Freescale's
> 60xbus. Their processor io that drive this bus have rise times of 250ps
> (it's crazy to allow a 250ps rise time on a 3.3v driver in a design with
> a tco of 5.5ns!!!). At 100MHz, that 250ps rise time makes it very very
> difficult to have anything but a point-to-point topology.
>  
> Regards,
> Jim Peterson
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Gregory R Edlund
> Sent: Monday, March 23, 2009 10:10 AM
> To: Morton.Harwood@xxxxxx; si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] timing analysis
>
> Mort,
> Great posting!  Well articulated.  I've been thinking about it all 
> weekend.  Over the years, I've had the chance to be involved in many 
> similar discussions at Cray Research, DEC, and Supercomputer Systems.
> They 
> go straight to the heart of what we do as engineers.
>
> I did timing for the 60x bus a few years ago.  Our philosophy was very 
> similar to yours, but we didn't get much push-back on the margin.  One
> of 
> the first things I would ask is whether or not the 100 MHz bus is a 
> performance bottleneck.  You could go through a lot of work to make the 
> bus run faster only to find out that it didn't buy you anything in
> system 
> performance.
>
> Let's list your statistically independent variables and the underlying 
> process variables they represent:
>
> 1. Driver delay
>     a. driver chip threshold voltage (gate oxide thickness, doping, 
> dielectric constant)
>     b. driver chip effective gate length
>
> 2. Receiver setup time
>     a. receiver chip threshold voltage (gate oxide thickness, doping, 
> dielectric constant)
>     b. receiver chip effective gate length
>
> 3. Receiver thresholds - track with setup time but don't vary much
>
> 4. Transmission line impedance & delay
>     a. line width
>     b. dielectric thickness
>     c. line thickness (to some degree)
>     d. dielectric constant
>
> 6. Clock chip pin-to-pin skew - mostly on-chip and package routing, not 
> process variation
>
> So you have three main sets of statistically independent variables:
> driver 
> chip, receiver chip, and transmission line.  I think you would be 
> justified in taking a root-sum-square of the delay deviations because
> they 
> are independent, but only the deviations, not the actual delay numbers 
> themselves.  I'm not sure this would buy you 15 MHz. though, and it
> could 
> get squirrely if you have a reflection close to a threshold.  You are 
> correct to question this method and to point back to the physics.  As
> you 
> mentioned, you have not yet accounted for crosstalk - or load
> capacitance 
> on the clock input pins.
>
> I find Vih and Vil to be a large source of conservatism on the part of
> the 
> chip suppliers.  Threshold windows, as defined by receiver unity gain 
> points, are typically much smaller than specifications would lead you to
>
> believe.  And how about dc and mid-frequency supply voltage variations?
> Do 
> you really need the 5% or 10% silicon designers typically use for
> on-chip 
> static timing analysis?
>
> If you're really motivated to solve this, you could ask your silicon 
> vendors for a history of their process monitors.  (IBM is probably one
> of 
> them.)  It they are mature processes (which they probably are), they
> might 
> have them dialed in.  Of course, they always have the right to ship you 
> corner silicon without telling you according to most contracts.
>
> Ultimately, it's a statement of risk vs. performance.  You don't have
> the 
> machinery in place to do a complete Monte Carlo analysis using the
> process 
> variables I outlined above.  I find it's best to put all the cards on
> the 
> table and make the decision as a team.  Then if something blows up,
> you're 
> all in it together!  No finger-pointing.
>
> Greg Edlund
> Senior Engineer
> Signal Integrity and System Timing
> IBM Systems & Technology Group
> 3605 Hwy. 52 N  Bldg 050-2
> Rochester, MN 55901
>
>
>
> Hello all,
>
> I have a question about what other people do for timing analysis
> methodology.
>
> My example is a simple synchronous 100 MHz PowerPC 60X bus.  The bus has
> three devices on it (CPU and two FPGAs).  Hundreds of boards have been
> built and they all run great, even at temperature extremes.  Now, after
> the fact (I'm also fixing our process so in the future it won't be
> "after the fact"), I am doing a worst-case timing analysis on this bus,
> and it shows negative setup timing margin at 100 MHz.  This has
> rekindled a debate at our company.  One camp says we should play it safe
> and not run the bus faster than our worst-case timing analysis says.
> The other camp says that if we aren't "aggressive" in running faster
> than our worst-case timing analysis says, then our products won't be
> competitive performance-wise.  I'm wondering what other people are doing
> when faced with this situation.
>
> As background, let me describe my worst-case timing analysis methodology
> for determining setup timing margin.  I take the max clock-to-out time
> spec from the driver data sheet, and the max input setup time spec from
> the receiver data sheet.  I get the interconnect delay from a HyperLynx
> simulation using slow-weak IBIS.  I am properly subtracting out the
> delay from running a separate reference load simulation, which HyperLynx
> refers to as "flight-time compensation".  I make sure that, in my
> receiver IBIS file, vinl and vinh match the worst-case data sheet
> values.  I make sure that, in my driver IBIS file, the reference load
> matches the data sheet reference load.  For my PCB stackup, I adjust the
> dielectric constant to be 10% greater than nominal, and I adjust the
> characteristic impedance to be 10% lower than nominal (we are using
> controlled impedance), since I expect this should be worst-case from a
> setup time perspective.  I use the max output skew and jitter specs from
> the clock driver data sheet.  I also simulate the clock traces in
> HyperLynx to get the delays, in order to get the skew there.  Whatever
> clock driver IBIS setting (fast-strong, slow-weak, typical) I use to
> simulate one clock trace, I also use that to simulate the other clock
> trace, since both clock traces are driven by the same clock
> driver...i.e. same PVT.  I take all the resulting delays (driver
> clock-to-out, interconnect delay, receiver setup, clock skew, etc.) and
> simply subtract them all from my timing path (which is 10 ns for 100
> MHz).
>
> 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.
>
> I can accept the fact that the boards pass test at 100 MHz even though
> worst-case timing analysis says 85 MHz; this just means not everything
> is worst-case on these particular boards.
>
> What I don't really see, however, is how I can legitimately change the
> numbers "on paper" to show other than 85 MHz as the worst-case limit.
> This is what a certain group of people are asking me for, claiming that
> we need to be more "aggressive" -- perhaps by taking an RMS
> (root-mean-square) sum of delays or something of that nature -- instead
> of subtracting from the 10 ns path a straight sum of delays like I am
> doing.  Another idea is to reduce the delays by some percentage to be
> less than worst-case.  (I counter with the argument that even though I
> describe my timing analysis methodology as "worst-case", it actually
> doesn't even consider the effects of noise -- such as from the power
> distribution network or crosstalk.  So I could make my timing analysis
> even more pessimistic by adding some noise margin to the data sheet
> values for vinl and vinh.  And regarding an RMS sum of timing delays, I
> think that's a fudge, not a valid method.)
>
> Well anyway I'm wondering what alternative timing analysis methodologies
> other people use, or how other people deal with this situation at their
> companies.
>
> Thanks very much if you have comments.
>
> Mort
>
>
> ------------------------------------------------------------------
> 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
>  
>
> ------------------------------------------------------------------
> 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
>  
>
>
>
>
>
>
> ------------------------------------------------------------------
> 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
>   


------------------------------------------------------------------
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: