[SI-LIST] Re: timing analysis
- From: Robert Szumowicz <robert.szumowicz@xxxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Mon, 23 Mar 2009 08:55:38 +0100
Hi,
the situation you described just happens. The worst case calculation is
the simplest and gives the most bullet proof design assuming that
nothing has been overlooked, underestimated, simplified too much or
wrongly modelled. Data sheet specifications call the worst case timing
parameters usually with some margin but the actual parameters may
different from manufactured batches of components. It is guaranteed that
they will not exceed the max specified values and we should adhere to
them. On the other hand they cover whole range of PVT, usually wider
than present in the application, so it gives some extra margin but it is
rather unpredictable and in my opinion should be swallowed by things not
accounted in the timing analysis. Another margin can be taken from a
variation of pin delays as a datasheet specifies timings for all pins at
once.
One thing which can help to get some extra ps in a timing budget is
taking into account a fact that timing parameters are specified at Vref
level rather than Vih/Vil of the receiver. They can be slightly derated
in a similar way as DDR2 timing parameters are. The app. note from TI
(SPRA839A.pdf) shows how to translate timing parameters from a datasheet
to a timing budget calculation. For TTLs it is not as clear as for DDR2
where there is a clear relationship between a rise time and the derating
factor but some time margin can be obtained if the worst case does not fit.
Robert
Harwood, Morton (GE Infra, Aviation, US) wrote:
> 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:
> //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:
> //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:
//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:
//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:
