--- Quote Start ---
All my design?
you mean to say each and every node?
Because the global assignments given to the entity are not working properly.
Thanks
--- Quote End ---
What is meant by '
all' is that you should specify all of the timing constraints to Quartus. At a minimum, these constraints are:
- Input pin setup time for all input pins to the device
- Output pin clock to output delay for all output pins from the device
- Clock frequency (or frequencies if more than one)
- Input pin to output pin propogation delay (if there are any purely combinatorial logic paths)
There can be other less common constraints which would be used only if your design contains certain specific features (for example, a clock boundary crossing).
The basic idea is that
- Your code specifies the function to be implemented
- The timing constraints define the performance that is required
If you have a design that implements the function you want and meets all of your performance requirements then for the most part you really shouldn't care how the tool places logic within the device. If you are concerned, it is typically because you are trying to second guess the tools. Not to say that you can't do better, but most of the time you won't.
In order to specify the various timing constraints mentioned above, you need to calculate based on the characteristics of the system in which the FPGA will live. As a simple example, consider an FPGA input pin that receives its input from a device that has a clock to output delay of 5 ns. This device is clocked by the same clock as the FPGA. Then, in order to figure out the maximum allowable input setup time of the FPGA, you would basically perform the following calculation:
FPGA_Setup_Time = Clock_Period - 5 ns - Estimated_Clock_Skew
There would be an analogous type of calculation performed for FPGA output pins. Note the following:
- You need to do these calculations independently for each input and output pin, it is not a 'global' device level calculation.
- The timing constraints are mostly I/O pin related, not so much for anything internal to the device no matter how simple or complicated the function that is being implemented is. A design with 100 I/O pins would have 100 I/O pin related timing constraints and a clock period constraint but possibly nothing else. This would be true whether the design fits into a smallest Cyclone or the largest Stratix device.
As I suggested, there can also be other constraints that might be required, but that would depend on whether or not you have those elements in your design. The most common example is having two different internal clocks running around and signal(s) that are sourced from one clock domain being sampled in the other clock domain.
Once you have all of the timing constraints entered into Quartus, do a build. Those constraints give Quartus the information it needs to do the placement and routing tradeoffs needed in order to meet your performance requirements (i.e. timing constraints). The report file will tell you if any paths failed and by how much. From there you analyze the path and try to figure out what needs to change in the logic path (or the clock period) in order to meet all of the constraints.
Kevin Jennings
Honored Contributor
