Timing constraints with real clocks

Question

I am new with FPGA and timing constraints, so I apologize if the question will sound stupid. I try to understand timing constraints usage with FPGA. I have found the following description (in https://fpgawiki.intel.com/wiki/Timing_Constraints):

In a synchronous design you need to define the clocks used in the design. There are three types of clocks you can define:

1. Clocks at FPGA clock input PIN

2. Virtual clocks which are used to describe the clocking of FPGA external registers (external device registers)

3. Generated clocks which are derived other clocks

The command for creating clocks at FPGA input pins and virtual clocks is the same. The only difference is that you don't specify a FPGA input pin for virtual clocks. Because of this they are both listed under create_clocks.

I would like to ask:

1. Is it that "virtual clocks" are not really used in design, but just used for the timing analysis ?

2. I don't understand what it means to put a timing constrain on a real external pin clock. Is it that the timing constraint will change the real clock (I can't believe that it is possible without using a PLL) ?

Answer 1

The timing constraints do not have any bearing on the function of the design itself, only on the placement and routing. The point of timing constraints is to tell the tools what timing relationships are needed for the design to work correctly. The tools will use that information to control the placement and routing of components to try to meet all of the timing constraints so that your design will work correctly. The tools do not know anything about the external clocks that you will be supplying to the device, so you need to tell the tools what they need to know. The constraints will not have any affect on the actual clock frequency - for instance, if you set a timing constraint for a 100 MHz clock and then apply a 50 MHz clock, the design will simply run at 50 MHz. However, if the actual clock differs from the constraint, then there could be timing violations within the design that cause metastability, bit errors, hangs, and other undesired behavior. Usually this is only a problem if you apply a faster clock than what was specified in the constraint.

The tools can be smart, though: usually PLLs and other clock management blocks can be set up to propagate the clock constraints through with appropriate adjustments, presuming the tools can figure out how the block is configured. This just makes your job as a designer a bit easier as you don't have to go manually insert those constraints. It's also possible that if you generate a clock management core through the vendor tools, it will include the input clock constraint and you'll get complaints if you add another one (I have run in to this before with transceiver reference clocks).

You're right about virtual clocks--they are never assigned to any signals in a design directly, but they can be used by other timing constraints.

Basically, it's up to you, the designer, to provide the tools with accurate information about how the design needs to operate from the standpoint of timing, and timing constraints are how you do that. If you specify the constraints accurately to how the device will be connected and used in your system, then the tools can do their best job to make sure your design will work correctly.