Timing Constraints for Serial Interface

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

--- Quote Start ---

I have to implement a serial interface to send and rx data to/from another board...

Basically, I have 3 LVDS lines, a chip select, a data line and a clock (83MHz). on the tranmitter side and a receiving line which receives the data from the other board (another FPGA) a specified number of cycles after chip selct falls. What I was concerned about was one of the signals, for example the clock getting delayed a fraction more than the data and at the receieving end the incorrect data being read. From scope shots i can see a small delay in the clock signal arriving between both boards (maybe 1ns I would guess, through a 5 inch long cable).

--- Quote End ---

If you are using the hard-silicon SERDES, then the timing should be fine as long as the RSKM (receiver skew margin) on the receiving device is OK. The RSKM will be affected by the relative board etch delays of the signals with respect to each other (which you mentioned), not the total board delay.

If you are not using the hard-silicon SERDES, then your transmitting interface needs to be constrained as a source-synchronous interface. The data output timing should be constrained with respect to the clock output timing. (This is not the same thing as tco. As I said in my previous post, tco is referenced to the FPGA input clock device pin.) TimeQuest is the preferred Timing Analyzer for constraining source-synchronous interfaces.

Many thanks for your response Brad.

So it seems that its vital to constrain from what you say. This is something I need to expand my knowledge of, as it's not something I have done much of.

I am using the Classic Timing Analyzer at the moment, I have heard that Timequest is quite powerful, but for the moment I am stuck with the classic timing analyzer, although I plan on learning about timequest for the next project.

I am implementing a source synchronous interface and at the moment I don't have any insight into what the FPGA on the other board is receiving. I can only judge by the response if its an error message or the expected data. It's not the ideal situation, but until things get organized it will be that way.

I am placing my constraints using the assignment editor. Is this the correct place to do it? You mentioned about the tsu, th, tco, and minimum tco constraints in the Classic Timing Analyzer, but is this where I should insert the constraint, or are they specified for the whole design in this area. (silly question, but I am a little confused).

Thanks for the explanation on the tco. I hadn't understood this properly. But I have one further question regarding it. In my case I have a 40 MHz clock entering the FPGA, which then enters a PLL where 83 MHz is produced. The 83MHz is then used to clock the logic for the interface and is also sent on the clock line of the interface. So if I set a tco of 3ns for example, how is this 3 ns calculated, would it be based off the 40 of 83MHz. I would want it to be based on the 83MHz, but from its the input clock pin to output pin that confuses me. I'm not sure how it works.

I have had a look at a couple of handbooks but its all a little daunting and its hard to know where to begin. The explanations offered at times I find a little hard to understand. I'm probably lacking a little knowledge in the theory end of things, which I hope will improve with experience.

For a source synchronous interface and using the classic timing anlyzer, which constraints should I be looking to research. There seem to be various which overlap and do similar things.

I have been thinking maybe the best approach would be to send the clock with the chip select and the data delayed slightly, perhaps by 1/3 of a cycle, so that when the the following rising edge is detected on the rxer side, I can be sure that the data is stable.

Is this the correct approach and if so, which types of constraints to I need to apply in the assignment editor. I have been playing around with different one's without really understanding what there are actually doing.

Should I be looking at tsu and th also, how do they affect the operation of the interface, is it sifficient to put the delays.

Please forgive my ignorance, but I really appreciate the help,

Thanks again

I was reading in the classic timing analyzer handbook about the maximum and minimum delay assignment.

I tired to place an assignment from the register output to the FPGA pin, but the actual bit in the register cannot be found. Perhaps it got synthesized away.

My code is as follows:

Trx_Request_Reg := Trx_Request_Reg(46 downto 0) & '0';

TRX_TX <= Trx_Request_Reg(47);

where TRX_TX is the output pin of the FPGA and Trx_Request_Reg holds the bits to be transmitted.

On each clock edge I shift the bit once to the left and clock out bit 47. When I go to the node finder in the assignment editor, to place FROM TRX_Request_Reg(47) TO TRX_TX, I see every bit in the Trx_Request_Reg excpet for bit 47. I placed the filter as "Post Synthesis" in the node finder. These are the types of things that really confuse me. The handbook makes it seem like it simple, and it probably is, but its my experience at doing this that lets me down.

Also some bits appear twice in the node finder, for example TRX_Request_Reg(6) and TRX_Request_Reg(6)~2179. Why do some appear twice and with a ~2179 or other number?

Thanks for any further advice.

--- Quote Start ---

I was reading in the classic timing analyzer handbook about the maximum and minimum delay assignment.

--- Quote End ---

"Maximum Delay" and "Minimum Delay", which create exceptions to the timing requirements created by other assignments, are rarely used. The preferred Classic Timing Analyzer assignments for I/O are "Input Maximum Delay", "Input Minimum Delay", "Output Maximum Delay", and "Output Minimum Delay", which are the closest thing the Classic Timing Analyzer has to TimeQuest's set_input_delay and set_output_delay.

--- Quote Start ---

Also some bits appear twice in the node finder, for example TRX_Request_Reg(6) and TRX_Request_Reg(6)~2179. Why do some appear twice and with a ~2179 or other number?

--- Quote End ---

Tilde suffixes are added by Quartus during compilation. Some assignments need that form of the node name, but usually assignments work with the form of register names that looks most like the source code without the suffix.

Look at the symbols by the node names. Sometimes two similar names have the register symbol for one of them and the combinational symbol for the other. At some point during compilation, the one with the register symbol is the one Quartus is using for the actual register. Because the name that looks like the source code usually works in assignments, I have rarely had to pay attention to the distinction between the similar names.

Many thanks for your help.

Just in case anyone is browsing through this at a later stage here´s what I have done.

I found a good tutorial at http://www.altera.com/literature/hb/qts/ug_tq_tutorial.pdf which describes the basics of TimeQuest and how to apply them to a simple project. In the long term I hope to convert to TimeQuest as there seems to be much more help available online regarding TimeQuest.

For the moment I have put maximum delay constraints for each of the outputs which seem to function well.