[SI-LIST] Re: timing analysis
- From: "Istvan Nagy" <buenos@xxxxxxxxxxx>
- To: "Harwood, Morton \(GE Infra, Aviation, US\)" <Morton.Harwood@xxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Fri, 20 Mar 2009 22:01:54 -0000
hi
i can see the same problem almost every day at work (timing, signal
integrity... are neglected), especially when I talk to a manager. But
discuss it with them (your boss), tell them if they really want this, what
will be the risk, and that it will be their fault if the board finally fails
at the customer's site and your company looses business and customers. They
should remember that day, not to blame you, the designer for it. they made a
choice.
i saw you are using an FPGA. they can produce huge input setup requirements,
especially when your bus interface module is designed that way. With a
Xilinx spartan3, it was hard for me to make a PCI interface running above 45
MHz with read or write pipelining... (dont have a multiplexer to access lots
of registers directly from the bus, but write to a single IO register and
send it forward from there only at the next clock). setup some timing
constraints for the synhesiser...
I think statistical timing should be used only if your bus has automatic
error correction, or at least multi-bit error detection, otherwise the
software may crash after a few hours or days operation, which leads you to a
not reliable product and a bad reputation of your company.
check my timing calculator at:
http://www.buenos.extra.hu/iromanyok/PCB_Timing_analysis.xls With this, you
can also determine max frequency and min/max trace lengths for synchronous
systems (also for async and source-sync.) Just simple startic timing in
excell.
best regards,
Istvan Nagy
CCT
----- Original Message -----
From: "Harwood, Morton (GE Infra, Aviation, US)" <Morton.Harwood@xxxxxx>
To: <si-list@xxxxxxxxxxxxx>
Sent: Friday, March 20, 2009 7:08 PM
Subject: [SI-LIST] timing analysis
> 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:
