TimeQuest Constraints

[Altera_Forum]

I have taken three of the Altera classes for timequest, and it still is not very clear. I have a synchrounous DDR input with both the data and clock aligned with matched lines from the output chip. Need to output same thing with the clock shifted 90 degrees to the data. I have enclosed a sample. 

 The documentation hints that you need virtual clocks to setup up the timing for the input/outputs. However, I get an error message that the virtual clock is not associated with any of the signals when I try to use it.   Also, should need to break the false paths across the FIFO for the transisition between clock domains. There are too many signals, not sure how to do this?   Thanks

[Altera_Forum]

THis might help(yes, it's a lot,but it has examples) 

http://www.alteraforum.com/forum/showthread.php?t=4806&highlight=source-synchronous  1) You definitely want to use a virtual clock. Note that your set_output_delay -clock was the PLL output, which is definitely wrong. THis will be timed with all the delay to and thru the PLL, but it will be as if it magically leaves the chip from there with no delay and drives the external device. There's a warning about this, which I personally think should be an error. (Users make this mistake all the time. The big thing is that the -clock doesn't describe the clock in the FPGA, as TimeQuest already knows this, but the clock that drives the external device) 2) On the input side, the clock drives the DDR input clock directly. You need it to go through a PLL, and have that PLL set up in source-synchronous compensation mode. 3) The attachment in the link has examples I would suggest looking at. I made a quick pass to get you started. Note that: I made the -waveform on the virtual clock be shifted 90 degrees. This basically means that the clock and data lines inside the FPGA should be as close to equal as possible to keep the clock edge in the middle of the data window. I'm assuming that's what you want since you're not shifting the clock. I made the input and output delays 0ns, which is as least restrictive as possible(and impossible). Basically the setup and hold requirements are half a data period, or 2.5ns each. You want to expand the external delays to say how much skew is out there. For example, if the external device sending data could skew the data to the clock by +/-1ns, then make the -max 1.0 and the -min -1.0.

[Altera_Forum]

Thanks for your help it appears that I have resolved most of the errors.  

 TimeQuest is still difficult for me and others at my office to use. Please let me know if there is any good documentation for SDC, other than what is at Altera. I have downloaded most of their documentation.   Also, TimeQuest still complains that my clock output from a DDR output is not properly constrainted. Not sure how to constrain the output, since it would be reference to itself. Enclosed is the basic SDC.   Thanks for your insight.   create_clock -name {rx_virt} -period 10.000 -waveform { 0.000 5.000 }  create_clock -name {clk_in} -period 10.000 -waveform { 0.000 5.000 } [get_ports {clk_in}] create_clock -name {osc_in} -period 10.000 -waveform { 0.000 5.000 } [get_ports {osc_in}]   create_generated_clock -name {tx_virt} -source [get_nets {inst4|altddio_out_component|auto_generated|dataout[0]}] [get_ports {clk_out}]    derive_pll_clocks -use_tan_name   derive_clock_uncertainty   set_input_delay -add_delay -max -clock [get_clocks {rx_virt}] 2.100 [get_ports {i*}] set_input_delay -add_delay -min -clock [get_clocks {rx_virt}] -2.100 [get_ports {in*}] set_input_delay -add_delay -max -clock_fall -clock [get_clocks {rx_virt}] 2.100 [get_ports {in*}] set_input_delay -add_delay -min -clock_fall -clock [get_clocks {rx_virt}] -2.100 [get_ports {in*}]   set_output_delay -add_delay -max -clock [get_clocks {tx_virt}] 2.100 [get_ports {out*}] set_output_delay -add_delay -min -clock [get_clocks {tx_virt}] -2.100 [get_ports {out*}] set_output_delay -add_delay -max -clock_fall -clock [get_clocks {tx_virt}] 2.100 [get_ports {out*}] set_output_delay -add_delay -min -clock_fall -clock [get_clocks {tx_virt}] -2.100 [get_ports {out*}]

[Altera_Forum]

Your output clock generally isn't constrained. There isn't some min/max relationship it needs to meet, it's just used as a clock for the data going out. (For a parallel, you don't specify how quickly your internal clock needs to get to the each register.) TQ checks all I/O to see if they have a set_input/output_delay and will let you know if they don't. In this case, your I/O doesn't and that's all right. (I'm assuming that's the check you're concerned about, as I didn't download the .qar). 

A quick look at your constraints in the post and it looks good. The output delays look a little large, i.e. your data window is 5ns, and your basically saying the external device chews up 4.2ns of that, only leaving 800ps for the FPGA. That being said, if it meets timing then that's good. Be sure to do a  report_timing -setup -detail full_path -to [get_ports out*] -panel_name "s: -> out*" report_timing -hold -detail full_path -to [get_ports out*] -panel_name "h: -> out*" One "trick" is to highlight the all the numbers in the Inc column except for the launch or latch time(the first line) and the external delay(which is out of your .sdc). Then point to the highlighted values and a pop-up will tell you their sum. In essence this is the raw delays through the FPGA, ignoring external delays and clock phase-shifts. What you should find is that they're very close to each other, which is good. Let's say they vary by 300ps. Then most likely you would have a slack of 100ps, since you're only giving 400ps for the setup analysis and 400ps for the hold analysis. (In the next release, the timing reports will have the ability to "roll-up" these delay values into a single line item that will be clock delay and data delay. I think this will be much more readable, and then if you want to know why a delay is what it is, you just click the + sign and unroll it. Hopefully that makes the analysis more understandable.)

[Altera_Forum]

Thanks for your help on timequest. I always seem to have more questions.  

 I have a source synchrounous output design. The data output is setup to be in I/O registers, and the clock source is generated using a DDR output, so it is also registered in the I/O. These should line up rather nicely on the data output. The output clock is setup as virtual, and it shows up in the timequest clock report. I can provide a design or pictures if you want. However, my question is fairly simple.   The hold/setup results do not make sense to me. Assume a 100MHz clock. The hold results use 0ns for both the start of the data arrival path and the data required path. The setup results use 0ns for the start of data arrival path and 5ns for the data required path.    If I invert the output clock the setup/hold results do not change. What am I missing?

[Altera_Forum]

Found out that timequest does not see an inverted output clock, when using a DDR output register. You either have to put in the generated clock in the SDC or use a PLL output to invert the clock.

[Altera_Forum]

That's correct. If you invert the clock through DDR(by tying high register to GND and low register to VCC) then you need to apply the -invert to the generated clock. You also said that you're using a virtual clock, but for source-synchronous outputs you shouldn't use a virtual clock, but instead the generated clock that is applied to the output port. Finally, are you sending it edge-aligned(which means the same clock can drive the data and clock) or center-aligned(which means you need a PLL which creates two clocks, one for the data, and one phase-shifted 90 degrees for the clock)?

[Altera_Forum]

Not really using a virtual clock to drive the source synchrounous outputs. It is generated off the DDR output register. I am driving these off a PLL output that is phase shifted 180 degrees. It is just a single edge sync output, so this is working good. 

 We are using the Quad Ethernet daughter board from MoreThanIP. The first port on the device is GMII, which is single edge at 125M. The next three ports are RGMII, which is DDR at 125M. Only using two of the ethernet ports. The first is working good, and the secon DDR port output is fine.  Just having fun with the DDR input, since the clock input is not on a global clock bus. Can't use a PLL to phase shift the input. MoreThanIP has a solution. Just trying to get good enough at TimeQuest to know when I have the right answer.    Thanks for your help.