Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
18 years ago

Setting up SDC for input I/O?

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 pll_clk_60 -source [get_pins inst|altpll_component|pll|inclk[0]] -duty_cycle 50.000 -multiply_by 5 -divide_by 4 -master_clock CLK_IN_48 [get_pins inst|altpll_component|pll|clk[1]] -add

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: To Node : MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a31~portb_we_reg

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: 15.525 0.321 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~SynDup_1|datad

Info: 15.703 0.178 RR CELL inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~SynDup_1|combout

Info: 17.717 2.014 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|FIFOram|altsyncram2|altsyncram3|ram_block4a31|ena1

Info: 18.459 0.742 RR CELL MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a31~portb_we_reg

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: 16.866 -0.040 uTsu MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a31~portb_we_reg

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.

10 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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: To Node : MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a5~portb_we_reg

    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: 14.161 0.490 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~_Duplicate_RESYN1008|datad

    Info: 14.339 0.178 RR CELL inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~_Duplicate_RESYN1008|combout

    Info: 14.810 0.471 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~_Duplicate|datac

    Info: 15.132 0.322 RR CELL inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~_Duplicate|combout

    Info: 17.030 1.898 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|FIFOram|altsyncram2|altsyncram3|ram_block4a5|ena1

    Info: 17.772 0.742 RR CELL MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a5~portb_we_reg

    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: 16.124 0.718 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|FIFOram|altsyncram2|altsyncram3|ram_block4a5|clk1

    Info: 16.907 0.783 RR CELL MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a5~portb_we_reg

    Info: 16.867 -0.040 uTsu MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a5~portb_we_reg

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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: To Node : MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a2~portb_we_reg

    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: 14.598 0.307 FF IC inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~_Duplicate|datab

    Info: 15.089 0.491 FR CELL inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~_Duplicate|combout

    Info: 17.027 1.938 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|FIFOram|altsyncram2|altsyncram3|ram_block4a2|ena1

    Info: 17.769 0.742 RR CELL MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a2~portb_we_reg

    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: 16.867 -0.040 uTsu MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a2~portb_we_reg

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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 pll_clk_60 -source [get_pins inst|altpll_component|pll|inclk[0]] -duty_cycle 50.000 -multiply_by 5 -divide_by 4 -master_clock CLK_IN_48 [get_pins inst|altpll_component|pll|clk[1]] -add

    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: To Node : MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a31~portb_we_reg

    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: 15.525 0.321 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~SynDup_1|datad

    Info: 15.703 0.178 RR CELL inst2|inst2|scfifo_component|auto_generated|dpfifo|fifo_state|valid_wreq~SynDup_1|combout

    Info: 17.717 2.014 RR IC inst2|inst2|scfifo_component|auto_generated|dpfifo|FIFOram|altsyncram2|altsyncram3|ram_block4a31|ena1

    Info: 18.459 0.742 RR CELL MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a31~portb_we_reg

    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: 16.866 -0.040 uTsu MessageEncoder:inst2|MessageEncoderFifo:inst2|scfifo:scfifo_component|scfifo_0e31:auto_generated|a_dpfifo_f531:dpfifo|dpram_m011:FIFOram|altsyncram_s1k1:altsyncram2|altsyncram_qrc1:altsyncram3|ram_block4a31~portb_we_reg

    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 ---