Regarding process time calculation

It's entirely dependent on what chip you implement your logic in. You'll have to synthesise and then run place and route. The timing analyser can then provide you with timing information.

What is normally done is to provide a clock that goes to every process and wrap the logic in :

if rising_edge(clk) then -- logic description in here end if;

You then tell the tools how fast the clock is that you intend to feed to the device, and the timing tools will then tell you if the logic (and internal wiring) you've described is fast enough to have finished between two consecutive clock edges.

This is very unlike software programming, where you write some code and then instrument it to get timing information (which will be more or less variable depending on data access patterns, caching and all the other non-determinism that comes with a modern microprocessor system).

In hardware, the tools know everything they need to about the timing of the chips and can give you a "cast-iron" statement as to how fast things will be in the worst-case.

Cheers, Martin

(snip)

(snip)

It will be variable, but if one wanted one could find a worst-case time for most processors. One normally wants closer to average case. Assume no cache hits, no instruction overlap, it could be done.

They might do some rounding up in the timing, to be sure.

-- glen

If you mean how long will it take in the FPGA, see Martin's answer.

If you mean how long it will take in the tool, be explicit in your question. There may be a way to get the computer time; look in your documentation.

If that's so, then why have I seen so many first-cut FPGA designs fail when run over the full military temperature range? And why have I seen FPGA designs fail during temperature cycling after months in production, after some unknown process change by the vendor?

Tools know _a lot_ of what they need, and can give you a _very good_ statement of how fast things need to be in worst case. But if you really want things to be cast-iron solid then you need to be conservative in how you specify your margins, you need to design as if timing matters, and you need to make absolutely sure that any wiring that is external to the FPGA meets it's timing, too.

If you're doing something that's really hard real time (i.e. fails once and the product -- or the operator -- dies), then for the critical cases you want to know absolute worst-case maximums.

Few things are really that hard real time, though.

Depends... for hard-real-time systems, the worst case execution time (WCET) is also important, at least for the certification of a safety-critical system.

For cached and pipelined processors such crude assumptions will usually give a hugely overestimated WCET bound, which may not be useful. There are tools that use advanced processor and program analysis to compute much better WCET bounds. See

Most current high-performance processors are so greedy and short-sighted in their internal scheduling that they have so-called "timing anomalies" which means, for example, that a cache hit at a particular point in the program may give a larger overall execution time than a cache miss at that point. Finding the worst-case behaviour by manual methods or intuitive reasoning is quite hard for such processors.

Normally in a non-real-time system. I don't do many of those, so that colours my comments ;)

It could, yes, but you'd have to do it yourself. That's part of the point - in FPGA-land we have tools that do it for us.

Also, absolutely-worst-case for a cached "modern" processor would be dreadfully pessimistic, to the point of being very little use IMHO. For example, how would a simple sort come out if you assumed no cache hits at all throughout execution? We know that's too extreme, but how do we put bounds on what is "sensible"?

More usefully (again IMHO) there are statistical methods for measuring execution time and its variability down various code paths, which can be used to provide arbitrarily high levels of confidence as to the likelihood of missing a real-time deadline, as well as showing what to optimise to improve the worst-case - this sometimes means using what might be regarded in mainstream compsci as "inefficient" algorithms, as they have better bounds on worst-case performance, even at the expense of average performance. I ought to stop now, I'm no doubt "rambling to the choir" as well as getting off-topic :)

I'm not sure what you mean by that: The tools "know" worst-case timings for the various silicon paths and add them all up. Rounding doesn't come into it.

I can think of lots of reasons that don't come down to the quality of the timing models... Or did you track the problem down to an error in the timing analysis tools and models?

I put "cast-iron" in quotes because nothing in real-life is ever 100%. They are very good though (IME) when used correctly... but only with the things that they know about - the innards of the silicon. In the context of the original question "how long will my logic take to run?" I think that's reasonable.

Of course for a complete system, the engineers responsible still need to do all the "external engineering" to make sure that they have (amongst other things):

• Specified the timing constraints correctly (and covered all the paths that matter!)

• Supplied "clean enough" power

• Supplied a "clean enough" clock

• Crossed clock domains properly

• Taken into account the timings of external parts (as you mentioned)

• Used production-grade speedfiles.

• ... and yes, put a bit more margin on top (the amount of which depends on the criticality of the system

Cheers, Martin

(snip on timing of processors and FPGAs)

Sounds right to me. Now, isn't that also true for FPGAs?

Consider that some timings might be Gaussian distributed with a tail to infinity. Also, that it is really difficult to get the exact timings for all possible routing paths. As with the real-time processor, you don't really want worst-case, but just sufficiently unlikely to be exceeded times.

Some of the distributions won't quite be Gaussian, as some of the worst-case die are rejected. Consider, though, that there are a finite number of electrons on a FET gate, ever decreasing as they get smaller.

Some of the favorite problems in physics class include determining the probability of all the air molecules going to one half of a room, or of a person quantum-mechanically tunneling through a brick wall, running at a given speed. Both have a very low, but non-zero, probability.

-- glen

Most of my experience with this has been as an amused observer, rather than an appalled participant. It stemmed from a corporate rule "thou shalt make the synthesis tool happy about timing" and a rather aggressive design group from out of state that was known to have scripts that would do synthesis runs over and over until one happened to meet timing, then stop and ship that file 'upstairs'.

The balance has stemmed from folks taking the Xilinx speed grades at face value, and using what the synthesis tool says (using Xilinx's defaults) at face value. Once the group learned that you have to force a bit of margin into the process (and the group thinks that a design that fails to synthesize once out of ten is a problem, as opposed to thinking that a design that succeeds once out of twenty is 'shippable') then those problems went away.

Ahh, I can see where that might cause hassle.

I'm not a fan of stochastic timing closure... I tend to fix timing problems by grovelling through the tmiing reports on the failing paths and fixing something in the RTL to make life easier for the tools (I tend not to push silicon right to it's limits, so I can get away with that!)

Cheers, Martin

The statistics or the algorithms?

Certainly, FPGAs often suit different algorithms.

And yes, the statistics is also there... I should've made that clear at the start - I put "worst-case" in quotes without explaining what i meant. Sorry about that.

Indeed. It's a little easier for the FPGA, especially in a highly pipelined design as the timing paths are broken up much more - so there are less "long chains of logic and routing" than their might be "chains of control flow through software".

As you say, it's a very simialr problem, but the FPGA is much more constrained.

Indeed, and because the FPGA vendors give us a timing analyser that people are going to have a reasonably high level of trust in, they define "unlikely to be exceeded" pretty conservatively. Of course, if your system is pushing the edges in some sense (esp. criticality of operation) the prudent engineer will allow more margin etc.

I think we're in violent agreement. My point really was (and I shouln't have used the phrase "worst-case" without qualification) that getting an arbitrarily high confidence of "meeting timing" is readily-available with FPGA tools, but in the software domain, it's only just starting to be an automatable task, and that out-of-the-box commercial compilers (AFAIK) are of no assistance in that respect.

Cheers, Martin

Martin Thompson wrote: (snip)

After my previous post, I was thinking about how FPGA companies have an incentive to quote faster devices, and so want the timing reports to be fast, without an excessive margin.

There are always process variations, and for the user voltage and temperature variations. For most, it shouldn't be so hard to stay within the voltage range, though maybe not so hard to miss by a little. (Slightly defective power supply.)

Temperature is a little harder to control. If one is too close on timing, and the temperature is a little high, the design could fail.

-- glen

Interestingly enough, the engineering group that I was with (which was a short walk away from the production line) felt exactly the way you did -- they would go as far as look for the worst possible path, and if it passed timing, but barely, they'd look for things sticking out and fix them.

The other group consistently got rewarded for "getting done" quickly, and somehow no one ever kept track of the number of times that their work was what was stalling production (while we fixed it in our "spare time", because we were closer).

Tim, are talking about synthesis or the timing analysis after P&R?

Nial

Sorry -- muddled thinking working in concert with mostly being an observer.

Timing analysis after P&R, yes.