Large delay through IO_OBUF

[Altera_Forum]

I am having a problem meeting timing for a SPI interface that talks to an ADC. When I looked at the failing path in timequest, one thing that jumped out at me was this HUGE delay when my internal clock passes through an IO_OBUF to go out as SCK for the SPI interface, there is no way I will be able to meet timing with a 10+ns delay on the clock line. Anyone have any ideas why I have such a huge delay here?  

 Thanks! Jason

[Altera_Forum]

If you have a failing path in TimeQuest, if you run a report_timing with the -detail=full_path option, you will be able to look at the individual components that make up your clock delay so you can see where your delay is coming from.

[Altera_Forum]

Looking at first screen on row number 10 on Data Arrival Path there is i/o constraint for 10ns. Maybe it's too strict?

[Altera_Forum]

Sorry, I hadn't noticed that you posted a screencap of your path analysis. I can see that you have a source latency of 10 ns on the launch clock and 30 ns on the latch clock. You must have made some set_clock_latency constraints to get these. You should remove these. I can only guess that you were trying to establish the setup relationship with these, but the tool figures that out for you.

[Altera_Forum]

The source latency of 10ns on launch and 30ns on latch are because this is a falling edge launch and falling edge latch with a 20 ns clock. No set_latency constraints were added to modify this, it was determined by timequest and as far as I can tell is correct. 

 You are right, there is a large external delay as well, I don't have a choice here, this ADC happens to have a ridiculously large setup delay, no getting around this as I can tell.  What I am primary curious about is why there is such a large delay on what seems to be to be a simple clock path. I was hoping there was some option in the compiler that I could tweak to fix this. I have a feeling this has something to do with the fact that I am routing a global clock to an output pad without going through a PLL. I know from my experience with the evils of ripple counters that you incur huge delays when you try to route a global clock through regular logic, for example a counter or an inverter.   At first, I had an inverter between the internal clock and the SPI output clock. When I saw the huge clock delay I figured it was being caused by the inverter, but when the delay persisted even after I removed the inverter I was perplexed. It seems to me that there has got to be a quicker way to get a global clock off the chip.  Jason

[Altera_Forum]

clock delay in this case should not matter as long as it is accompanied by similar data delay. The ADC will read data on this clock... your data output delay assignments should be related to this clock.

[Altera_Forum]

Hey Kaz, 

 I don't believe that is true in this case as this is data that is launched by the ADC using SCK and latched on the FPGA using my internal 50 MHz clock.   FYI the constraints are as follows: # system clocks create_clock -period 10.000 -name CLK_100MHZ [get_ports {CLK_100MHZ}] create_clock -period 20.000 -name CLK_50MHZ [get_ports {CLK_2}] # serial adc source sync external clocks (50MHz) create_generated_clock -name CH4_AD_SCK -source [get_ports {clk_2}] [get_ports {CH4_AD_SCK}] # *** slow serial ADC delays *** set ssadc_in_min -3 set ssadc_in_max 10  set_input_delay -clock CH4_AD_SCK -min $ssadc_in_min -clock_fall [get_ports {CH4_AD_SDI}] set_input_delay -clock CH4_AD_SCK -max $ssadc_in_max -clock_fall [get_ports {CH4_AD_SDI}]  set_output_delay -clock CH4_AD_SCK -min -1.000 [get_ports {CH4_AD_CNV}] set_output_delay -clock CH4_AD_SCK -max 1.000 [get_ports {CH4_AD_CNV}]  I'm pretty sure my constraints are right, my main concern here is why the clock delay through the IO buf is so high, does anyone have any ideas how else to route the clock to get around this?  Thanks! Jason

[Altera_Forum]

Apologies, I thought you were sending configuration data to ADC. 

 If you are clocking from fpga to get ADC data remember your interface is no longer the classic source synchronous since data is opposite clock. I have never seen any altera example in this situation but it needs extra care to set delays...

[Altera_Forum]

Yes, okay, I see what you are doing now. Looking at your launch clock path, you have 4+ ns routing delay from the input buffer to the output buffer and a 5+ ns delay through the output buffer. This is giving you a 6+ ns clock skew between launch and latch clock that is hurting you. The large delay through the output buffer could be due to several things including the I/O standard you have chosen, any capacitive loading you added to the I/O, or due to programmable output delays. Regardless, the right way to solve your problem is to run the clock through a PLL. That will give you the flexibility to control your clock skew to solve your problem.