Timequest Report Datasheet (setup time and hold time)

The rise/fall times account for rising and falling delay differences in transistors of the device, not the clock edge. Stratix III, Cyclone III, and newer device families take advantage of rise/fall timing for improved accuracy and performance. Prior families will show the same value for rise & fall.

As for the AP1 vs. AP0 issue, first use report_path to check that TimeQuest actually sees the I/O paths (e.g., "report_path -npaths 100 -from [get_ports AP0*]"). Also, verify that all clocks have been created correctly (look for warning messages or check the unconstrained path report), especially if the AP0 interface uses a different clock. Lastly, check for any set_false_path, set_disable_timing, or set_clock_groups constraints that may be cutting those paths.

I hope this helps!

Just an additional viewpoint, but I'm not a big fan of the Report Datasheet(but understand why it's easy to look at.)

First, it's not an actual constraint. So if anything changes and you have to recompile, those values might change. If you constrain your I/O, then use those constraints as the datasheet, and as long as it meets timing, you know you've met those constraints.

Secondly, it uses Tsu/Th/Tco/Min Tco. These are easy to understand, and work most of the time, but have issues when you a) use the falling edge of the clock or b) phase-shift the clock. For example, if you have a Tco of 8ns, and one day change the code so it is clocked on the falling edge(and let's say it's a 6ns clock), does your Tco become 2ns, 14ns, or stay at 8ns? It really depends. Phase-shifting the clock has similar implications. I know most I/O cases don't have either of these, or users know how to incorporate them, but just something to be aware of.

(I don't like it, but I've used Report Datasheet to get a "quick feel" on where my I/O timing is, and appreciate it's readability...)

thank you both for your useful answers.

To answer to Gopher, yes Timequest see AP0 path, and AP0 is in "Report Clock" with the same clock settings than AP1. So I check all others thing and it seems to be ok...AP0 physically work on my board...so I don't understand why it's not there...

Rysc, your suggestion is very interesting, but how can I set the setup time and hold time. For example, if I want to write 2ns for my setup time and 1 ns for my hold time. Where can I do that?

In Quartus assignment editor I see

tsu Requirement

th Requirement

Input minimum delay

Input maximum delay

minimum delay

and in Timequest I have

set input delay

set minimum delay

set maximum delay

which one to use and what is the difference?

I try th and tsu requirment with my bitclock and my data. But no change in report datasheet...am I suppose to see 2ns and 1 ns in report datasheet?

set_instance_assignment -name TSU_REQUIREMENT "2 ns" -from * -to AP1_BCLK_io

set_instance_assignment -name TH_REQUIREMENT "1 ns" -from * -to AP1_BCLK_io

set_instance_assignment -name TSU_REQUIREMENT "2 ns" -from * -to AP1_SDAT_i

set_instance_assignment -name TH_REQUIREMENT "-1 ns" -from * -to AP1_SDAT_i

thank you again and have a nice day!

Quartus assignment editor timing assignments are ignored when using TimeQuest. (Don't try to use the Classic Timing Analyzer.) set_input_delay is what you want. It takes a little getting used to. Basically it describes what's going on outside the FPGA. For example, let's say I have a 10ns clock coming into the FPGA:

create_clock -period 10.0 -name fpga_clk [get_ports fpga_clk]

For I/O interfaces, you first want to create a virtual clock for what's driving the external device:

create_clock -period 10.0 -name clk_ext

Why do you have to do this? There's a number of reasons, as you can make assignments to clk_ext(uncertainty, multicycle, latency, etc.) that don't affect the clock coming into the FPGA, modeling what's occuring on your board more accurately. There are some technical reasons too(specificaly derive_clock_uncertainty will calculate the correct value for your I/O interfaces). Anyway, then add assignments:

set_input_delay -clock clk_ext -max 4.0 [get_ports data_coming_in*]

set_input_delay -clock clk_ext -min -1.0 [get_ports data_coming_in*]

This assignment says there is an external register that drives data onto the ports, it is clocked by clk_ext, and the delay to those ports is between -1 and 4.0ns. So what does this mean for setup and hold? It's very simple. We know the clocks are the same period and aligned, so the setup requirement between the clocks is 10.0ns. If 4.0ns are used on external delay, then the FPGA has 6.0ns to work with, i.e. this is like a 6.0ns Tsu. We also now the default hold requirement is 0ns, so if -1ns is used externally, then the FPGA can have up to 1ns of extra data delay and still not cause a hold violation. This is like a -1ns Th(yes, the sign is annoying, but I've always been confused by the sign of Th).

So why do you have to jump through these hoops? The reason is what I described before, where the Tsu/Th constraints are incomplete, i.e. a clock inversion or phase-shift is not correctly accounted for unless you know what the clock driving the other register looks like(in this case the "other register" is the source register that is off chip and driving data into the FPGA. set_output_delay describes the destination register capturing data sent off chip from the FPGA). Look through the handbook and examples and you'll get a better feel. Most importantly create a .tcl file with the following and source it from TimeQuest:

report_timing -setup -from_clock clk_ext -npaths 100 -detail full_path -panel_name "s: clk_ext inputs"

report_timing -hold -from_clock clk_ext -npaths 100 -detail full_path -panel_name "h: clk_ext inputs"

Analyze the results and it will start to make more sense.