Xilinx timing constraints: How to describe stationary inputs?

[ebastler]

Let me be frank: Amateur here... I have done a few projects using Xilinx' old ISE environment, Spartan-3 and Spartan-6 FPGAs, but am only beginning to familiarize myself with timing constraints. So please be kind if this is a stupid question...

So far, I always got away with just specifying the clock timing and letting ISE optimize the placement & routing to get the design to meet timing. But I am working on a project where FPGA timing is tight. Minor changes to the VHDL make it a hit-or-miss experiment whether or not PAR comes up with a solution that meets timing. So I hope that providing some guidance via timing constraints will provide better and more robust results.

One specific thing I was wondering about: I have a few DIP switches or jumpers which are read by the FPGA, so the end user can select some configuration options. These inputs are meant to never change at runtime. I understand that I should let the synthesis/place&route know about this, so it can relax the timing on all dependent signals inside the FPGA. What is the best way to specify this?

Thanks for your help!

[OwO]

False paths.

[ebastler]

Thanks OwO! That gave me the right term to look for.
Great signal-to-noise ratio in your reply! 

[Someone]

Thanks OwO! That gave me the right term to look for.
Great signal-to-noise ratio in your reply! 

Its a little more complex, as you only want the false path up to the register before those signals become part of timed paths. Accidentally pushing false paths onto all the paths from those pins may not be what you intended.

External IO without constraints are basically ignored for timing constraints anyway, and get reported as derived "datasheet" conditions for the design:
https://www.xilinx.com/support/answers/24221.html

If latency is insensitive (as you hint at with config at boot) adding a few stages of registers onto the path is low risk. It likely won't fix the timing problems, you'll need to look at the paths that are actually failing.

[Fred27]

I tried using the 90MHz clock as a clock input and got routing errors - probably due the reasons conmega specified. (I'm new at those so it could also have been a mistake on my part.)

[ebastler]

Thanks for your comments, Someone. Could I ask two follow-up questions please?

Its a little more complex, as you only want the false path up to the register before those signals become part of timed paths. Accidentally pushing false paths onto all the paths from those pins may not be what you intended.

So, say I have implemented an internal address decoder in the FPGA, to select some address ranges with special functions. I provide a few external DIP switches to choose between different memory maps, i.e. the switches configure the way the address decoder operates.

I would declare the path from the external DIP switches to the address decoder output a "false path", but of course the path from the currently active internal address to the address decoder output remains critical and is not declared "false". Correct? (Whether or not that helps in routing a faster design is another matter...)

External IO without constraints are basically ignored for timing constraints anyway, and get reported as derived "datasheet" conditions for the design:
https://www.xilinx.com/support/answers/24221.html

Hmm, that doesn't seem to match what I see. In fact, the only I/Os mentioned in the "data sheet" section of the timing report are (a) the clock input, and (b) the DIP switch inputs which I just declared to be the starting point of a false path. None of the other I/Os, for which I have not specified any constraints, are mentioned.  What gives?

[Someone]

External IO without constraints are basically ignored for timing constraints anyway, and get reported as derived "datasheet" conditions for the design:
https://www.xilinx.com/support/answers/24221.html

Hmm, that doesn't seem to match what I see. In fact, the only I/Os mentioned in the "data sheet" section of the timing report are (a) the clock input, and (b) the DIP switch inputs which I just declared to be the starting point of a false path. None of the other I/Os, for which I have not specified any constraints, are mentioned.  What gives?

Its not always obvious how things are included/excluded from reporting unless its manually specified. The easiest way to be sure is adding appropriate constraints on everything.

Constraints and timing closure are topics larger than HDL, and tool/vendor specific.