UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer richnsim
Observer
1,298 Views
Registered: ‎06-01-2018

How to add signal delays to meet timing constraints?

Jump to solution

Hi

 

I have an interface that doesn't meet my timing constraints.

But when I look at the timings, I see that there is a hold violation of 2ns and at the same time a setup slack of 14ns!

 

So I ask myself, why can't the tool insert a delay of 3-4ns on the data line to solve this problem?

Do I have to enable a certain setting to allow delay chains to be implemented or chose a special implementation strategy?

 

The whole story in detail:

I have a rater curious SPI-like interface (doesn't look standard to me), where an ADC (LTC2341) outputs data accompanied by a clock signal. The special thing is, that data transitions on positive and negative going clock edges, exactly at the same time as the clock does with a skew of +/- 1ns:

 

ltc2341_timing.png

 

I think a have managed to set the timing constraints according to the specifications:

 

set_input_delay -clock [get_clocks ADC1_SCKO] -clock_fall -min -add_delay -1.000 [get_ports ADC1_SDO0]
set_input_delay -clock [get_clocks ADC1_SCKO] -clock_fall -max -add_delay 1.000 [get_ports ADC1_SDO0]
set_input_delay -clock [get_clocks ADC1_SCKO] -min -add_delay -1.000 [get_ports ADC1_SDO0]
set_input_delay -clock [get_clocks ADC1_SCKO] -max -add_delay 1.000 [get_ports ADC1_SDO0]

 

I have not inserted any primitives by hand, but Vivado inserts an IDDRE1 as I would have expected:

 

signal_path.PNG

 

Can you please tell me, how to solve this timing issue?

 

Best Regards

Simon

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
1,227 Views
Registered: ‎01-23-2009

Re: How to add signal delays to meet timing constraints?

Jump to solution

When it comes to I/O interfaces, Xilinx gives most of the control to the user; it expects the user to determine the input capture structure, including how to implement delay, and then does static timing analysis based on this structure in order to determine if the constraints are met or not. Specifically, Xilinx does not add delay using a controllable element in order to meet timing.

 

Take a look at this post on interface clocking styles.

 

Where things get a little confusing is when the flip-flop capturing the input data is not in the input/output block (IOB). In this case, the placer and routed can modify the placement and routing of the capture flip-flop in order to meet timing - this will effectively add delay through additional routing delay. However, this is not recommended - it is far better to design the interface in a reliable mechanism using the IOB flip-flop.

 

In your case, you have no choice - since you are capturing a double data rate interface, you have to use the IDDR, which is the IOB flip-flop (technically the IOB flip-flop is 1/2 of the IDDR). And Xilinx didn't "insert" the IDDR - it never inserts an IDDR automatically - either it was instantiated (which you claim you didn't do) or it was inferred - you wrote two clocked processes, one on the rising edge of clock and one on the falling edge of clock, each of which sampled the same input - this is the functional code that infers an IDDR.

 

So given that, you need to find a way to make the interface work. One way is to add delay using the IDELAY. To do this, the IDELAY (and IDELAYCTRL) must be instantiated in your RTL code and set to the proper values. As @jmcclusk said, this allows for a maximum 2.5ns (or so) of delay. Cascading IDELAYs is not a "real" thing (as far as I know) - while it can be done using fabric routing, there is a large unpredictable delay in the cascade path between the IDELAYs.

 

The other (and better) option, as also mentioned by @jmcclusk is to use an MMCM to create a new clock with the proper phase for capture - this is using a different clocking architecture; BUFG with MMCM, rather than what you originally used which is direct capture with BUFG. In the case of your interface, 90 degrees is "about right", but you can probably adjust it a bit to maximize the setup and hold margin even more - simply run static timing analysis with 90 degrees, look at the setup and hold margins, and then make a small tweak to the phase to balance the margins.

 

Avrum

7 Replies
Scholar jmcclusk
Scholar
1,281 Views
Registered: ‎02-24-2014

Re: How to add signal delays to meet timing constraints?

Jump to solution

You haven't stated what your target device is, but I'm guessing from the schematic you posted that it's an ultrascale device or higher.    You have two choices.

 

  1. Bring the clock into an MMCM, and then use a clock phase at 90 degrees to clock your DDR capture register.
  2. Delay the data using an IDELAYE3.    Since the maximum delay of each delay line is only 1.25 ns,  you might have to cascade two of them to get a delay of 2.5 ns. 

If your clock is a reasonable speed (i.e. 10 MHz or higher),  I'd go with option #1.

Don't forget to close a thread when possible by accepting a post as a solution.
Historian
Historian
1,228 Views
Registered: ‎01-23-2009

Re: How to add signal delays to meet timing constraints?

Jump to solution

When it comes to I/O interfaces, Xilinx gives most of the control to the user; it expects the user to determine the input capture structure, including how to implement delay, and then does static timing analysis based on this structure in order to determine if the constraints are met or not. Specifically, Xilinx does not add delay using a controllable element in order to meet timing.

 

Take a look at this post on interface clocking styles.

 

Where things get a little confusing is when the flip-flop capturing the input data is not in the input/output block (IOB). In this case, the placer and routed can modify the placement and routing of the capture flip-flop in order to meet timing - this will effectively add delay through additional routing delay. However, this is not recommended - it is far better to design the interface in a reliable mechanism using the IOB flip-flop.

 

In your case, you have no choice - since you are capturing a double data rate interface, you have to use the IDDR, which is the IOB flip-flop (technically the IOB flip-flop is 1/2 of the IDDR). And Xilinx didn't "insert" the IDDR - it never inserts an IDDR automatically - either it was instantiated (which you claim you didn't do) or it was inferred - you wrote two clocked processes, one on the rising edge of clock and one on the falling edge of clock, each of which sampled the same input - this is the functional code that infers an IDDR.

 

So given that, you need to find a way to make the interface work. One way is to add delay using the IDELAY. To do this, the IDELAY (and IDELAYCTRL) must be instantiated in your RTL code and set to the proper values. As @jmcclusk said, this allows for a maximum 2.5ns (or so) of delay. Cascading IDELAYs is not a "real" thing (as far as I know) - while it can be done using fabric routing, there is a large unpredictable delay in the cascade path between the IDELAYs.

 

The other (and better) option, as also mentioned by @jmcclusk is to use an MMCM to create a new clock with the proper phase for capture - this is using a different clocking architecture; BUFG with MMCM, rather than what you originally used which is direct capture with BUFG. In the case of your interface, 90 degrees is "about right", but you can probably adjust it a bit to maximize the setup and hold margin even more - simply run static timing analysis with 90 degrees, look at the setup and hold margins, and then make a small tweak to the phase to balance the margins.

 

Avrum

Observer richnsim
Observer
1,189 Views
Registered: ‎06-01-2018

Re: How to add signal delays to meet timing constraints?

Jump to solution

Dear @jmcclusk and @avrumw

 

Thanks for your replies. Sorry I forgot to mention I'm talking about an UltraScale+ device.

 

@avrumw: Yes you're right, Vivado inferred the IDDR primitive, I guess that's the right term for it :)

 

I would happily go for your solution with the 90° phase shifted clock, but the problem is, I'm note sure if that is manageable, as the clock returned by the ADC is not permanent, it is only present while data is clocked out (about 800ns = 24clock cycles during a 2us period). As far as I understand an MMCM, it will need a stable input clock that it can lock upon and will need some time to do so, isn't this correct?

 

As a former Altera user, I was used to the place and route process adding delays by itself if any timing requirements were not met.

I will try the second approach and manually add an IDELAYE3 primitive.

 

Thanks for your help

Simon

 

0 Kudos
Historian
Historian
1,183 Views
Registered: ‎01-23-2009

Re: How to add signal delays to meet timing constraints?

Jump to solution

I suspected you were a former Altera user...

 

This is a fairly significant philosophical difference between Altera and Xilinx. Altera tries to hide more of the architecture from the user and have the tool try and figure out what architecture to use based on constraints. Xilinx goes the other way - give as much information about the architecture and have the user make the architectural decisions. Both have their advantages and disadvantages....

 

And, yes, if the clock is gapped, then you cannot use an MMCM... I thought that ADCs that did this were pretty much done. Is this a modern part (or a very old one...)?

 

What frequency is this clock - a quick calculation from your numbers above seems to indicate 33MHz... If it is really that slow, you may can consider oversampling the interface. With the 7 series devices, you can easily oversample an input at speeds up to 800Msps or even more. This would give you tons of samples during each bit period - it would be very easy to identify the transition points of the oversampled clock and use that information to identify the middle of your bitperiod of the data... The ISERDES makes this pretty easy...  (of course this assumes that you have at least one stable clock in your system).

 

Avrum

Scholar jmcclusk
Scholar
1,171 Views
Registered: ‎02-24-2014

Re: How to add signal delays to meet timing constraints?

Jump to solution

After looking at the data sheet, the solution is rather obvious.    To wit,  here are the relevant pins in CMOS mode.

 

  1. SDO0, SDO1 (Pins 18, 23): CMOS Serial Data Outputs, Channels 0 and 1. The most recent conversion result along with channel configuration information is clocked out onto the SDO pins on each rising edge of SCKI. Output data formatting is described in the Digital Interface section. Leave unused SDO outputs unconnected. Logic levels are determined by OVDD.
  2. SCKI (Pin 19): CMOS Serial Clock Input. Drive SCKI with the serial I/O clock. SCKI rising edges latch serial data in on SDI and clock serial data out on SDO0 and SDO1. For standard SPI bus operation, capture output data at the receiver on rising edges of SCKI. SCKI is allowed to idle either high or low.
  3. SCKO (Pin 22): CMOS Serial Clock Output. SCKI rising edges trigger transitions on SCKO that are skew-matched to the serial output data streams on SDO0 and SDO1. The resulting SCKO frequency is half that of SCKI. Rising and falling edges of SCKO may be used to capture SDO data at the receiver (FPGA) in double data rate (DDR) fashion. For standard SPI bus operation, SCKO is not used and should be left unconnected. SCKO is forced low at the falling edge of BUSY. 
  4. SDI (Pin 25): CMOS Serial Data Input. Drive this pin with the desired 6-bit SoftSpan configuration word (see Table 1a), latched on the rising edges of SCKI. If both channels will be configured to operate only in SoftSpan 7, tie SDI to OVDD. Logic levels are determined by OVDD.
  5. CS (Pin 27): Chip Select Input. The serial data I/O bus is enabled when CS is low and is disabled and Hi-Z when CS is high. CS also gates the external shift clock, SCKI. Logic levels are determined by OVDD

 

You should be capturing data with the rising edge of SCKI, and not trying to catch it using SCKO, which is a rather useless gated DDR clock.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Observer richnsim
Observer
1,130 Views
Registered: ‎06-01-2018

Re: How to add signal delays to meet timing constraints?

Jump to solution

Dear @avrumw

 

It's actually a rather new ADC. I think the reason they gap the clock is, so that least possible noise is coupled in during the sampling process.

Yes you're absolutely right, it's actually a 30MHz clock. I thought about oversampling in the beginning but then it somehow got swept off my mind. Maybe this would be the most easy thing to do. Non the less I will try adding a delay and also have a look at the ISERDES first, just for academical reason :)

 

Thanks a lot,

Simon

0 Kudos
Observer richnsim
Observer
1,125 Views
Registered: ‎06-01-2018

Re: How to add signal delays to meet timing constraints?

Jump to solution

Dear @jmcclusk

 

This is a bit off topic, but I think the reason for the SCKO output clock is, that when you have a digital isolator between the ADC and your FPGA, the phase shift of the input clock generated by the FPGA (SCKI) and the data outputted by the ADC (SDO0/1) can vary extremely, based on the delay of the isolator caused by temperature variation and other factors. This can go as far as varying up to 1 clock cycle, which makes it impossible to construct a reliable interface:

 

LTC2341_Isolator_Delay.jpg

 

What we have done in this situation before with other ADCs is to route back the input clock (SCKI) from the isolated ADC-side to our FPGA, so at least the isolator delays are compensated. With this ADC LTC2341 having a dedicated output clock accompanying the data, we thought it would be a good idea to make use of this "feature", but as you say, it proved to be rather a useless feature!

 

Best Regards

Simon

0 Kudos