Scope of STA in FPGAs

I am newbie in FPGAs. I work on Xilinx FPGAs and on Xilinx ISE 14.7 IDE (Yet to learn Vivado). I would like to know about the scope of STA in FPGAs. Whenever I design something in FPGAs and fail to meet timing in FPGAs, what I do is playing around in HDL codes and set design goals to "best timing performance" in Xilinx ISE. Nothing more than that. Somehow I meet timing using them. But I dont feel I am good, if some body asks me if I am good in Timing Verification. Because I learnt so much in STA theory during by graduation, but not applying much in my FPGA designs. I don't know if we can do more in FPGAs regarding timing, other than coding tweaks and using ISE tool specific options. I feel ASICs have more flexibility than FPGAs in this aspect. What more we can do about STA in Xilinx ISE, if timing fails ? Can we manually do placing and routing ? But I think tools are programmed to do the best possible routing. So we can't do much about it ? I hope somebody puts some light on this post.

FPGAs mostly use basic timing constraints. However, you can apply custom constraints like multi-cycle paths. This is uncommon as it imposes additional simulation burdens to verify that the design doesn't violate the constraint.

ISE has LOC constraints to place logic in specific locations. This is mostly used for IO. There is also RLOC for relative location constraints, this is rare. There are also directed rounting (DiRT) constraints to specify routing. DiRT is almost never used. I have used DiRT in the past to make the best of an design that didn't place a clock IO in a location that had dedicated routing to the BUFG network. In that case I really cared that the delay not change from build to build.

These can be added in the ucf file, or by adding synthesis attributes in the HDL files. Directed routing and LOC constraints can be determined by using fpga editor.

You really need to be mindful of how many levels of logic your HDL is going to produce. For slow clocks, you can get away with several layers, but faster clocks will really need to be limited to 2 or even 1 layer per clock to meet timing. Obviously, slow/medium/fast is relative to the technology you are using. Be wary of how you are accessing RAM/DSP as these are fixed in the FPGA so you will always incur a routing penalty, so minimise logic layers for RAM/DSP inputs and outputs.

My general rules for fixing timing in FPGA (and, afaik, these rules also apply reasonably well to ASIC)
1. Ensure all appropriate constraints are applied to appropriate registers (multicycle, false paths, max delays etc).
2. If you have a path that commonly fails, you probably need to change the HDL. Changing the HDL is almost always the easiest option. This may involve adding extra pipeline stages to give the fitter more options in placement of registers, likely nearer to rams/DSPs
3. Set area contrains to try and force related logic close together.
4. For the last few (and you really dont want too many) paths that you cannot fix with 1,2 or 3, overconstrain the path during the fitter, so that during STA, you have a better chance of meeting timing.

3 and 4 really should be when life is getting hard, as they take a lot of time to run the seed sweeps and rebuilds necessary to ensure your fix works. 1 and 2 are the quickest options.

In my opinion, FPGA is much less flexible than ASIC in changing the physical information to gain the delay.
It is in term of location, moving, cell swapping ...
Instead, changing the IO location gave me some improvement in the past.
I suggest you to study the IO pin locations of FPGA part for awhile and have the inital plan for where to place the IO on your design.

You can identify the multicycle paths from simulation.
Once you get the violation, please check the waveform ( which is correct ) to know the relationship between startpoint and endpoint.
There can be the case that you can apply multicycle path.

For false path, you can check whether in all simulation waveform, a transition in startpoint cause any transition in endpoint or not.
But it really a awful job to do because you may check it manually for many things.

Another option is to shift the clock phase to be advanced in case of capture clock.
The setup can be better, but take a look at hold time.
It can be useful if you meet the timing problem with IO paths.

Design structure from HDL plays the most important factor.
In case of we can not apply multicycle path, false path to the violated paths,
we need to change the design structure, like others said, using pipeline, chosing another way to control in order to simplify the data path logic.