--- Quote Start ---
When I alter code in other modules and compile everything again it can stop working (the data is transmitted properly, but the timing has changed). Actually this is another thing I was wondering about, how can a change in the project code affect the operation of logic in another part. Is it true that the fitter will do things differently if contraints are not put in place and a change in one place could cause the fitter to alter how something is impemented elsewhere?
--- Quote End ---
Every time you change anything that can affect the Fitter in any way (this includes source-code changes, synthesis settings, and timing constraints), the Fitter could give different results in any part of the design including parts that you think are unrelated to the part you changed. This is because of the way the Fitter algorithms work, which results in some random variation in the placement, routing, and timing. If you have the timing fully constrained, then at least the Fitter is going to try to meet the requirements for the entire design when you change any part of the design.
--- Quote Start ---
As I said the interface works, but marginally I think. I have played around with constraints in quartus like maximum or minimum delay, then min tco and tco etc. But the truth is that I dont really understand which type of constraint I should put in place.
--- Quote End ---
Every design needs to have all I/O and internal timing paths fully constrained. Both the Classic Timing Analyzer and TimeQuest have tools that will list the paths that are unconstrained.
Improper or incomplete timing constraints that prevent the timing reporting from revealing true timing violations is one of the possible causes of marginal behavior in hardware. There are also other possible causes like improper asynchronous design practices. The Design Assistant in Quartus can report some of these problems.
If you are using the hard-silicon SERDES for the LVDS signals, then the Classic Timing Analyzer or derive_pll_clocks for TimeQuest automatically creates the constraints needed for that.
Other I/O is preferably constrained with set_input_delay and set_output_delay in TimeQuest. If you are using the Classic Timing Analyzer, the preferred constraints are the similar ones available in that analyzer. If the I/O timing is simple, then tsu, th, tco, and minimum tco constraints are OK in the Classic Timing Analyzer. Whichever timing analyzer you are using, go through the appropriate chapter in the Quartus handbook to learn how to constrain the I/O.
--- Quote Start ---
Also, a workmate told me I should put a 'global signal' assignment on each of the signals used for the interface in the assignment editor. I have done this and the signals viewed on the scope seemed better. Could somebody explain what this assignment actually does. I know there is an explanation given in quartus, but its not always self explanitary for me.
--- Quote End ---
The "Global Signal" assignment controls which type of global routing is used by Quartus. By default, Quartus chooses which clocks and other control signals to promote to global automatically.
The most important use of global routing is for clocks to minimize skew between registers in the clock domain. Global routing is also typically used for control signals like resets that have a very high fan-out so that lots of nonglobal routing resources are not used up by these signals.
Read about global signals in the device handbook. Some device families have multiple types (device-wide globals, regional globals, etc.).
--- Quote Start ---
Also, one final thing. Is a tco constraint is a measure of the time difference betwen when the clock and the data appear on the output pins of the FPGA? or the delay incurred from when the clock signal inside the FPGA changes and the data on the pin of the FPGA changes?
--- Quote End ---
In Quartus, tsu, th, tco, and minimum tco for I/O always refer to the time difference between the FPGA clock pin and the FPGA data pin. A tco is the time from the FPGA clock input pin active edge to the change in the data output pin, even if there is a PLL, a clock mux, or other logic in the clock path between the clock input pin and the register internal to the FPGA.
Honored Contributor
