In this path, the data flows from the output of FF1 with the clock to Q output delay, through two combinatorial elements, and then must be set up to FF2.  The frequency that this circuit would achieve is based upon these times.  If the clock to Q were 2 nsecs, each of the logic elements were 3 nsecs, and the setup time were 2 nsecs, we would have a total delay of 10 nsecs, so the maximum frequency would be 1/10 nsecs = 100 MHz.

If the design were actually run at 80 MHz, or a period of 12.5 nsecs, then the excess amount, 12.5 nsecs - 10 nsecs = 2.5 nsecs, is referred to as the "slack".

The static timing analyzer performs this analysis through the entire design to determine the maximum frequency for the design, and to flag any errors, or "negative slack" that occurs and to report those paths.

It's important to understand that a static timing analyzer does not examine the logic in a design - the analysis is performed without any simulation of the design.  For example, if in the circuit above clock enables were used to divide the clock rate in half, the static timing analyzer wouldn't know about this unless you informed it via a constraint.  This is referred to as a "multicycle path" and is a valid method of meeting timing for large combinational blocks, for example arithmetic operations.

Modern static timing analyzers are quite sophisticated, and actually examine the delay through clock buffers and to each individual flip flops in a design, take into account clock jitter, routing, fanout, and other artifacts of the FPGA.  With static timing analysis as the standard approach, it generally is no longer necessary to perform a back annotated (timing) simulation as long as the constraints are properly constructed and the STA output is examined thoroughly.