set_max_skew constraint

Argh. Typed something up and it didn't get submitted. Here we go again...

Let's assume the clock is 20ns

create_clock -period 20.0 -name clk_in [get_ports {clk_in}]

derive_pll_clocks ;# out of habit

derive_clock_uncertainty

create_generated_clock -invert -name clk_out_ext -source [get_ports clk_in] [get_ports clk_out]

set_output_delay -clock clk_out_ext -max 4.6 [get_ports {data[*]}]

set_output_delay -clock clk_out_ext -min -4.6 [get_ports {data[*]}]

- The generated clock says a clock based on clk_in goes out clk_out. The invert option says it is inverted at the external device(the -invert does nothing to the clock inside the FPGA).

- Since the FPGA clock is not inverted but the external one is, you will have a setup relationship of 10ns and hold relationship of -10ns. That means across the interface, the data can be skewed by +/-10ns compared to the clock.

- The set_output_delays are saying that externally there is +/-4.6ns of skew being added. Since the interface allows +/-10, that leaves the FPGA with +/-5.4ns.

OK I understand (it needs some time to convert from classic analyzer to Timequest)

In line

create_generated_clock -invert -name clk_out_ext -source [get_ports clk_in] [get_ports clk_out]

you have two clocks, the incoming clk_in and outgoing clk_out. Is this a mistake? I think, if not, the master_clock option is missing. If J just write it down in this manner, the first is taken.

Anyway, as far as I understand TimeQuest's calulation it always takes the incoming clk_in for calculating output_delay. As my external latching circuit sees clk_out as sample clock and this clock has a routing delay to clk_in, can I take this into account? That makes life more easy as I then have delays in both data and clock paths.

You mean two ports? The first one is tied to the option -source, saying physically where the clock is coming from, and then clock constraint is applied to the last one. (.sdc constraints like create_clock and create_generated_clock have a target they are applied to, which is implied, i.e. it's the one with no option. I wish it was more explicit too.)

This generated clock is necessary to show how clk_in get off chip(by the output port clk_out).

The routing delay to clk_in doesn't really matter, as it affects both the data and clk_out going off chip equally. You can account for different board delays between the FPGA and external latching device. Basically any board delay on the data output to external device is added to the output delay and any board delay for the clk_out to external device is subtracted.

Hi,

I've understood, all is working fine (had a look at the various delay chains). Thanks a lot :)