Setting up SDC for input I/O?

Altera_Forum · ‎10-06-2008

Hi,

I'm having I/O setup violations on input pins. The clock is driven by the FPGA, goes to an external FIFO that clocks out data to the FPGA inputs. The Tco of the external FIFO is max 7.7ns, min 4.1ns. I'm getting some 100+ slow model setup violations on the input side. This is the SDC i'm using:

# **************************************************************

# Time Information

# **************************************************************

set_time_format -unit ns -decimal_places 3

# **************************************************************

# Create Clock

# **************************************************************

create_clock -name CLK_IN_48 -period 20.833 -waveform { 0.000 10.416 } [get_ports CLK_IN_48]

# **************************************************************

# Create Generated Clock

# **************************************************************

create_generated_clock -name CLK_OUT_60 -source [get_pins inst|altpll_component|pll|clk[1]] [get_ports CLK_OUT_60]

# **************************************************************

# Set Input Delay

# **************************************************************

set_input_delay -max -clock [get_clocks CLK_OUT_60] 7.7 [get_ports LINKDATA[*]]

set_input_delay -min -clock [get_clocks CLK_OUT_60] 4.1 [get_ports LINKDATA[*]]

When looking at the top failing path (tsu) in the chip planner i see that 7.7ns has been added as iExt input delay per my above SDC. The total path delay is some 1.6ns too large. Is it correct to use the CLK_OUT_60 node as clock reference in the SDC or should i use the 'pll_clk_60' name in the set_input_delay SDC statement? The latter works but i'm suspecting the the former is correct.

This is the path report (report_timing -to_clock {pll_clk_60} -setup -npaths 1 -detail path_only)

Info: Path# 1: Setup slack is -1.593 (VIOLATED)

Info: ===================================================================

Info: From Node : LINKDATA[5]

Info: Launch Clock : CLK_OUT_60

Info: Latch Clock : pll_clk_60

Info:

Info: Data Arrival Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 0.000 0.000 launch edge time

Info: 2.939 2.939 R clock network delay

Info: 10.639 7.700 F iExt LINKDATA[5]

Info: 11.563 0.924 FF CELL LINKDATA[5]|combout

Info: 13.295 1.732 FF IC inst5|OUTDATA[5]~638|datac

Info: 13.617 0.322 FF CELL inst5|OUTDATA[5]~638|combout

Info: 13.923 0.306 FF IC inst7|out_msg_data_valid~161_RESYN620|datad

Info: 14.101 0.178 FF CELL inst7|out_msg_data_valid~161_RESYN620|combout

Info: 14.394 0.293 FF IC inst7|out_msg_data_valid~161|datad

Info: 14.572 0.178 FF CELL inst7|out_msg_data_valid~161|combout

Info: 14.882 0.310 FF IC inst2|inst11|HEADER[6]~106SynDup|datac

Info: 15.204 0.322 FR CELL inst2|inst11|HEADER[6]~106SynDup|combout

Info:

Info: Data Required Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 16.666 16.666 latch edge time

Info: 16.906 0.240 R clock network delay

Info:

Info: Data Arrival Time : 18.459

Info: Data Required Time : 16.866

Info: Slack : -1.593 (VIOLATED)

Info: ===================================================================

Info:

1) Is it correct to have a 7.7ns delay inserted in the path? What can be done to lower the path delay?

2) Why has a 2.939 clock network delay been inserted in the path? I would assume that the reference clock is measured on the output package pin CLK_OUT_60 so no additional delay should apply?

3) In fact, since the clock is DRIVEN by the PLL which is (apparently) 2.939ns ahead of the signal on the clock output pin, i would expect to see a -2.939ns improvement in timing if i the -clock in the SDC was set to the PLL output instead of the output clock pin. Is this correct reasoning?

Thanks,

/John.

Altera_Forum · ‎10-06-2008

The correct way to specify the -max delay is to use tCOmax + Data delay max - Clock delay min.

The correct way to specify the -min delay is to use tCOmin + Data delay min - Clock delay max.

Where Data delay is the time delay on the data trace as a result of board delays. Similarly Clock delay is the time delay on the clock trace as a result of board delays.

Jake

Altera_Forum · ‎10-06-2008

Thanks Jake. I'm assuming zero board delay because i have less than an inch of traces.

How can i get rid of the following large clock network delay on the pin output?

Info: 2.939 2.939 R clock network delay

Basically, all timing issues would go away if this could be lowered. Enabling fast I/O or something similar for the clock pin?

Thanks,

/John.

Altera_Forum · ‎10-06-2008

That clock network delay probably isn't what you think it is. Use "-detail full_path" instead of "-detail path_only" for report_timing to see what is in the clock path.

Altera_Forum · ‎10-07-2008

--- Quote Start ---

That clock network delay probably isn't what you think it is. Use "-detail full_path" instead of "-detail path_only" for report_timing to see what is in the clock path.

--- Quote End ---

Thanks. This is the result (new signal top violation since the previous went away via HDL recoding):

Info: Path# 1: Setup slack is -0.905 (VIOLATED)

Info: ===================================================================

Info: From Node : NXT

Info: Launch Clock : CLK_OUT_60

Info: Latch Clock : pll_clk_60

Info:

Info: Data Arrival Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 0.000 0.000 launch edge time

Info: 0.000 0.000 source latency

Info: 0.000 0.000 CLK_IN_48

Info: 1.066 1.066 RR CELL CLK_IN_48|combout

Info: 3.525 2.459 RR IC inst|altpll_component|pll|inclk[0]

Info: -2.031 -5.556 RR COMP inst|altpll_component|pll|clk[1]

Info: -1.260 0.771 RR IC inst|altpll_component|_clk1~clkctrl|inclk[0]

Info: -1.260 0.000 RR CELL inst|altpll_component|_clk1~clkctrl|outclk

Info: -0.072 1.188 RR IC CLK_OUT_60|datain

Info: 2.939 3.011 RR CELL CLK_OUT_60

Info: 10.239 7.300 R iExt NXT

Info: 11.173 0.934 RR CELL NXT|combout

Info: 12.770 1.597 RR IC inst1|msg_data_type~435|datac

Info: 13.092 0.322 RR CELL inst1|msg_data_type~435|combout

Info: 13.393 0.301 RR IC inst5|out_msg_data_valid~78|datac

Info: 13.671 0.278 RR CELL inst5|out_msg_data_valid~78|combout

Info:

Info: Data Required Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 16.666 16.666 latch edge time

Info: 16.666 0.000 source latency

Info: 16.666 0.000 CLK_IN_48

Info: 17.732 1.066 RR CELL CLK_IN_48|combout

Info: 20.191 2.459 RR IC inst|altpll_component|pll|inclk[0]

Info: 14.635 -5.556 RR COMP inst|altpll_component|pll|clk[1]

Info: 15.406 0.771 RR IC inst|altpll_component|_clk1~clkctrl|inclk[0]

Info: 15.406 0.000 RR CELL inst|altpll_component|_clk1~clkctrl|outclk

Info:

Info: Data Arrival Time : 17.772

Info: Data Required Time : 16.867

Info: Slack : -0.905 (VIOLATED)

Info: ===================================================================

Info:

So, I see that the clock *really* goes from the CLK_48_MHZ input pin, through the PLL, out onto the internal global clock network and finally goes out on the CLK_OUT_60 pin to the external FIFO. What i don't understand is why the zero time is not counted from the external CLK_OUT_60 pin which is what i intended to use as clock in the SDC. I must get something conceptually wrong since i would assume t=0 should be the CLK_OUT_60 element. In fact, if i specify the 60 MHz PLL clock as reference the timing violation goes away - i'm however not sure this approach is correct (neighter of the clock options appear correct, really).

As can be seen in the path above, the major delays are really the 'clock network delay' and the 7.3ns delay to compensate for the external device's Tco. If i can get rid of the 'clock delay' i would meet timing...

Altera_Forum · ‎10-07-2008

If you are doing a source synchronous bus, i.e using your clock60 as the clock that latches your data in to your external fifo then you probably want to use the -reference_pin command in your output delay. The reference pin is the name of the actual output port that your clock goes out on. The required timing is then calculated with respect to this latch edge then.

example

set_output_delay -clock { clock_that_clocks_out_your_data } -reference_pin [get_ports {your_clock60}] -min -4 [get_ports.......

Altera_Forum · ‎10-07-2008

It is preferred to use a generated clock on the output device pin driving the clock instead of using -reference_pin. The generated clock is the more standard way to do it. However, both methods give exactly the same results if done correctly.

Altera_Forum · ‎10-07-2008

--- Quote Start ---

What i don't understand is why the zero time is not counted from the external CLK_OUT_60 pin which is what i intended to use as clock in the SDC. I must get something conceptually wrong since i would assume t=0 should be the CLK_OUT_60 element. In fact, if i specify the 60 MHz PLL clock as reference the timing violation goes away - i'm however not sure this approach is correct (neighter of the clock options appear correct, really).

--- Quote End ---

The "zero time" is arbitrary. In some cases neither launch nor latch edges will be at time zero. All that matters is the difference in time between launch and latch, and it is almost certain that TimeQuest is doing that correctly (except for cases that need multicycles to adjust the choice of launch or latch edge).

The generated clock on the output device pin driving the output clock or the equivalent reference pin must be traced back to its base clock, CLK_IN_48 in this case, so that TimeQuest can relate the timing on CLK_OUT_60 to the timing on the destination register in the FIFO. The destination register also has a clock ultimately based on CLK_IN_48, the base clock of the PLL.

You should not use an internal point in the clock network, PLL or otherwise, as the -clock argument for set_input_delay or set_output_delay or for the -reference_pin argument.

Altera_Forum · ‎10-07-2008

Thanks everyone for the information. I'm unfortunately completely lost what to do now. It seems my design doesn't meet timing although i don't see the tsu/th or fmax being extreme in any way. Any tips what could be optimized or changed to resolve the above setup violation?

Just as a test, i tried to use the reference_pin option:

set_input_delay -max -clock [get_clocks pll_clk_60] -reference_pin [get_ports CLK_OUT_60] 7.3 [get_ports NXT]

set_input_delay -min -clock [get_clocks pll_clk_60] -reference_pin [get_ports CLK_OUT_60] 3.8 [get_ports NXT]

This results in the following identical path (report_timing -to_clock {pll_clk_60} -from [get_ports {NXT}] -setup -npaths 1 -detail path_only):

Info: Path# 1: Setup slack is -0.902 (VIOLATED)

Info: ===================================================================

Info: From Node : NXT

Info: Launch Clock : pll_clk_60

Info: Latch Clock : pll_clk_60

Info:

Info: Data Arrival Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 0.000 0.000 launch edge time

Info: 2.939 2.939 R clock network delay

Info: 10.239 7.300 R iExt NXT

Info: 11.173 0.934 RR CELL NXT|combout

Info: 12.880 1.707 RR IC inst1|msg_data_type~434_Duplicate|datad

Info: 13.057 0.177 RF CELL inst1|msg_data_type~434_Duplicate|combout

Info: 13.969 0.912 FF IC inst7|out_msg_data_valid~161|datac

Info: 14.291 0.322 FF CELL inst7|out_msg_data_valid~161|combout

Info:

Info: Data Required Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 16.666 16.666 latch edge time

Info: 16.907 0.241 R clock network delay

Info:

Info: Data Arrival Time : 17.769

Info: Data Required Time : 16.867

Info: Slack : -0.902 (VIOLATED)

Info: ===================================================================

Info:

One thing that stands out is that the data arrival path has a 2.939ns "clock network delay" while the data required path only has 0.241ns "clock network delay".

Altera_Forum · ‎10-09-2008

FYI: The timing violation has been worked around by pipelining my design. The problem signal was sent downstream to other modules (inst, inst2, inst5) via combinational logic. By simply registering the output from the first module all timing violations went away. This is the new timing report for the previously failing path:

Info: Path# 1: Setup slack is 1.787

Info: ===================================================================

Info: From Node : NXT

Info: To Node : LinkState:inst1|curstate[1]_OTERM349

Info: Launch Clock : CLK_OUT_60

Info: Latch Clock : pll_clk_60

Info:

Info: Data Arrival Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 0.000 0.000 launch edge time

Info: 2.939 2.939 R clock network delay

Info: 10.239 7.300 R iExt NXT

Info: 11.173 0.934 RR CELL NXT|combout

Info: 12.648 1.475 RR IC inst1|RxActiveDetector|Selector1~101|dataa

Info: 13.105 0.457 RF CELL inst1|RxActiveDetector|Selector1~101|combout

Info: 13.930 0.825 FF IC inst1|Mux6~1761|datad

Info: 14.108 0.178 FR CELL inst1|Mux6~1761|combout

Info: 14.406 0.298 RR IC inst1|Mux5~2021|datab

Info: 14.927 0.521 RR CELL inst1|Mux5~2021|combout

Info: 14.927 0.000 RR IC inst1|curstate[1]_NEW_REG348|datain

Info: 15.023 0.096 RR CELL LinkState:inst1|curstate[1]_OTERM349

Info:

Info: Data Required Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 16.666 16.666 latch edge time

Info: 16.772 0.106 R clock network delay

Info: 16.810 0.038 uTsu LinkState:inst1|curstate[1]_OTERM349

Info:

Info: Data Arrival Time : 15.023

Info: Data Required Time : 16.810

Info: Slack : 1.787

Info: ===================================================================

Info:

Altera_Forum · ‎11-14-2008

Hi John,

I am not sure if you have resolved the problems that you were having. I seem to have similar problems in understanding the timing.

When I set an input delay constraint on one of the input pins, I see that the delay is automatically added as a data arrival path delay. Why does this happen? My understanding is that the input delay constraint is only to check if the input delay exceeds the value and not the actual delay itself. Is this correct?

Thanks!

--- Quote Start ---

Hi,

I'm having I/O setup violations on input pins. The clock is driven by the FPGA, goes to an external FIFO that clocks out data to the FPGA inputs. The Tco of the external FIFO is max 7.7ns, min 4.1ns. I'm getting some 100+ slow model setup violations on the input side. This is the SDC i'm using:

# **************************************************************# Time Information# **************************************************************

set_time_format -unit ns -decimal_places 3

# **************************************************************# Create Clock# **************************************************************

create_clock -name CLK_IN_48 -period 20.833 -waveform { 0.000 10.416 } [get_ports CLK_IN_48]

# **************************************************************# Create Generated Clock# **************************************************************

create_generated_clock -name CLK_OUT_60 -source [get_pins inst|altpll_component|pll|clk[1]] [get_ports CLK_OUT_60]

# **************************************************************# Set Input Delay# **************************************************************

set_input_delay -max -clock [get_clocks CLK_OUT_60] 7.7 [get_ports LINKDATA

[*]]

set_input_delay -min -clock [get_clocks CLK_OUT_60] 4.1 [get_ports LINKDATA

[*]]

When looking at the top failing path (tsu) in the chip planner i see that 7.7ns has been added as iExt input delay per my above SDC. The total path delay is some 1.6ns too large. Is it correct to use the CLK_OUT_60 node as clock reference in the SDC or should i use the 'pll_clk_60' name in the set_input_delay SDC statement? The latter works but i'm suspecting the the former is correct.

This is the path report (report_timing -to_clock {pll_clk_60} -setup -npaths 1 -detail path_only)

Info: Path# 1: Setup slack is -1.593 (VIOLATED)

Info: ===================================================================

Info: From Node : LINKDATA[5]

Info: Launch Clock : CLK_OUT_60

Info: Latch Clock : pll_clk_60

Info:

Info: Data Arrival Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 0.000 0.000 launch edge time

Info: 2.939 2.939 R clock network delay

Info: 10.639 7.700 F iExt LINKDATA[5]

Info: 11.563 0.924 FF CELL LINKDATA[5]|combout

Info: 13.295 1.732 FF IC inst5|OUTDATA[5]~638|datac

Info: 13.617 0.322 FF CELL inst5|OUTDATA[5]~638|combout

Info: 13.923 0.306 FF IC inst7|out_msg_data_valid~161_RESYN620|datad

Info: 14.101 0.178 FF CELL inst7|out_msg_data_valid~161_RESYN620|combout

Info: 14.394 0.293 FF IC inst7|out_msg_data_valid~161|datad

Info: 14.572 0.178 FF CELL inst7|out_msg_data_valid~161|combout

Info: 14.882 0.310 FF IC inst2|inst11|HEADER[6]~106SynDup|datac

Info: 15.204 0.322 FR CELL inst2|inst11|HEADER[6]~106SynDup|combout

Info:

Info: Data Required Path:

Info:

Info: Total (ns) Incr (ns) Type Element

Info: ========== ========= == ==== ===================================

Info: 16.666 16.666 latch edge time

Info: 16.906 0.240 R clock network delay

Info:

Info: Data Arrival Time : 18.459

Info: Data Required Time : 16.866

Info: Slack : -1.593 (VIOLATED)

Info: ===================================================================

Info:

1) Is it correct to have a 7.7ns delay inserted in the path? What can be done to lower the path delay?

2) Why has a 2.939 clock network delay been inserted in the path? I would assume that the reference clock is measured on the output package pin CLK_OUT_60 so no additional delay should apply?

3) In fact, since the clock is DRIVEN by the PLL which is (apparently) 2.939ns ahead of the signal on the clock output pin, i would expect to see a -2.939ns improvement in timing if i the -clock in the SDC was set to the PLL output instead of the output clock pin. Is this correct reasoning?

Thanks,

/John.

--- Quote End ---