added 526 characters in body
Source Link
alex.forencich
  • 39.3k
  • 1
  • 64
  • 104

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.

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 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.

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.

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.

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.

Source Link
alex.forencich
  • 39.3k
  • 1
  • 64
  • 104

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 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.

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.

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.