How to set setup and hold time?

[Altera_Forum]

I find SDC file doesn't have constraints for input/output setup/hold. Instead, it has constraints of input/output delay.  

 I think the negative value of input delay represents setup time, while positive for hold time. Is the conception right? Or there's other better way to specify clock-data setup/hold timing.   Maybe you can use use the following example for the illustration.  https://www.alteraforum.com/forum/attachment.php?attachmentid=4299    Thanks in advance!

[Altera_Forum]

When using TQ, I can create "Virtual" and "Virtual Generated" clock. 

 In my opinion, the Virtual Generated clock should be used in set_input_delay/set_output_delay constraints. Because the Virtual clock doesn't have the information on which port the virtual clock binds with, while the Virtual Generated clock does.  Should I use "Virtual Generated" clock to do set_input_delay constrain?

[Altera_Forum]

You may read the TQ guide by Rysc 

http://www.alterawiki.com/wiki/timequest_user_guide If I remember correctly he explains very clearly what you ask.

[Altera_Forum]

I don't think virtual generated clocks are allowed(they didn't use to be). In general everyone uses a virtual clock. You don't need to know what port it binds with. When you do a set_input_delay, for example, you tell what data port it is referencing, and TimeQuest knows what clock drives that input register and what input port that clock comes in on, so it binds them that way.  

The only time a virtual generated clock would be nice is on source-synchronous outputs, where you put a generated clock on an output port and will use this for the set_output_delay constraint on data being sent with that output clock. I often want to say that the external receiver is doing a 90 degree phase-shift, which could be done with a virtual generated clock. Instead I just say the output clock hase -phase 90 directly on that output clock. (Sorry if that's too far off topic...)

[Altera_Forum]

Hi, Rysc: 

   --- Quote Start ---  you tell what data port it is referencing, and TimeQuest knows what clock drives that input register and what input port that clock comes in on, so it binds them that way.  --- Quote End ---    This explaination does make sense.    --- Quote Start ---  The only time a virtual generated clock would be nice is on source-synchronous outputs  --- Quote End ---    That's exactly my case. My design could only use one PLL, which has already output 32MHz and 50MHz on internal clock pins.     --- Quote Start ---   I often want to say that the external receiver is doing a 90 degree phase-shift, which could be done with a virtual generated clock.  --- Quote End ---    I'm considering to use the external clock pin of PLL to output a 50MHz, 90 degree phase-alinged clock. The 50MHz, 0 degree phase-shift internal clock can generate the output data, while 50MHz, 90 degree phase-shift external clock can be output launch clock. So the virtual clock is related to 50MHz, 90 degree phase-shift external clock, and the output_delay can be set to 0ns.   Is this right?  And your book is really a brilliant one.

[Altera_Forum]

Hi, Cris72: 

 Thanks for your advice.

[Altera_Forum]

Thanks for the compliment on the book. I will answer all questions now. : ) 

For your source-synchronous output, you want to: 1) Put a generated clock on the output port where the -source is the PLL output tap that drives it. It should not be virtual, and you do not need to put a -phase 90 or anything on it since the PLL is doing the 90 degree shift and it's generated clock already describes the 90 degree shift. 2) Do NOT use the dedicated PLL output for the clock going off chip. This is a direct connection from the PLL to the output and will have a considerably different delay than your data going off-chip, where the whole purpose of source-synchronous is that the clock and data delays match each other. There are two workarounds, a) move the clock output to another port or b) instantiate an altddio_out megafunction, where the high port is tied off with VCC and the low port to GND, and the clock drives the select. This just makes a clock going off-chip, just as if you sent it off directly. The difference is that the direct PLL output can't drive the output ddr block, and so rather than using the direct PLL -> output connection, it will use PLL -> global -> DDR -> output connection, which will look a lot like your data output path.

[Altera_Forum]

One other thing, once you use the generated clock as the -clock in your set_output_delay, when you run report_timing -setup/-hold -to [get_ports {ssync_outputs[*]}]... 

You should see a setup relationship of 90 degrees and hold relationship of -90 degrees. You should also see that the Data Required Path traces the entire path from the clock coming into the FPGA to going out the clock output port(assuming you ran report_timing with -detail set to full_path). Basically this means that your data can be skewed in relation to your clock by +/-90 degrees. Then, as your set_output_delay -max grows larger and the -min value grows smaller, it will cut into this. So, if 90 degrees were 4ns, you would have a setup relationship of 4ns. If your -max value is 2.5ns, that would show up as oExt in your timing report and chew up 2.5ns of that 4ns requirement, leaving 1.5ns for the FPGA to skew its data to clock. (That was quick, so hopefully it makes sense)

[Altera_Forum]

Hi, Rysc: 

 Thank you very much for your detailed explaination. The timing suits for the need and I really learned a lot through this thread.   Thanks again and have a nice day!

[Altera_Forum]

thanks for your explanation,