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: 
Explorer
Explorer
537 Views
Registered: ‎10-07-2016

Question about constraining an IDDR interface

Jump to solution

Dear constraints experts,

I have created a very simple evaluation design which samples a ddr data signal (din) center aligned, by using a source synchronous differential input clock (clk_in_p/n), as depicted below:

Pic1.JPGDDR Input sampling circuit

Since the available setup and hold time for din is quite small (tsu = 0.6ns and thd = 0.5ns), it is an ambitious goal to achieve the timing, considering that the differential input clock is running with 165MHz (periode = 6.061ns).

To achieve this, my idea was, to use a BUFIO, whose output clocks an IDDR. Further to meet the input timing, I have inserted a MMCM, which is driving the BUFIO, and which allows me to adjust the phase. Since data will arrive center aligned to the input clock, the MMCM need to shift the phase only to compensate the skew between the clock and data input path to the IDDR. Therefore, I have configured the MMCM as depicted below.

 

Pic3.png

Pic4.png

 

As a result, the MMCM is implemented as depicted in the schematic below:

Pic2.JPG

After implmentation, I have used the Constraints Wizard to define the constraints for the input. I just followed the suggested constraints in the wizard and filled in the timing parameters, like clock frequency, setup and hold time, etc. As a result, I got the following timing constraints for the input:

create_clock -period 6.061 -name clk_in_p -waveform {0.000 3.031} [get_ports clk_in_p]
set_input_jitter clk_in_p 0.100
set_input_delay -clock [get_clocks clk_in_p] -clock_fall -min -add_delay 0.500 [get_ports din]
set_input_delay -clock [get_clocks clk_in_p] -clock_fall -max -add_delay 2.431 [get_ports din]
set_input_delay -clock [get_clocks clk_in_p] -min -add_delay 0.500 [get_ports din]
set_input_delay -clock [get_clocks clk_in_p] -max -add_delay 2.431 [get_ports din]

Here are my questions:

  1. Can anybody check if the design is properly constrained?

  2. I'm not sure if the constraints above are correct, when using a MMCM in the clock path?

  3. Do I need to change the constraints above, if I would drop the MMCM, and connect the IBUFDS output directly to the input of the BUFIO?

Kind regards

stgateizo

 

 

0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
338 Views
Registered: ‎10-07-2016

Re: Question about constraining an IDDR interface

Jump to solution

Status update:

As mentoined in the last post, I have created a test design, which follows the following clock / data path structure now:

Data => IBUF => IDELAY => IDDR.D => FIFO.DI

Clock => IBUFDS => IDELAY => BUFR => IDDR.C
                          => PLL => BUFG => FIFO.DO

With this structure, the setup and hold timing is now met without timing violation. The setup and hold slack is now postive and almost equal in size, which means that the idelay value for the clock and data path is properly set. The setup and hold slack is now roughly 300ps, which is even bigger than before when I used the bufio. 

Many thanks to avrumw, who helped me a lot !!!

Kind regards

stgateizo

0 Kudos
7 Replies
Historian
Historian
468 Views
Registered: ‎01-23-2009

Re: Question about constraining an IDDR interface

Jump to solution

First, the combination of a BUFIO and an MMCM is not recommended (at least not in this usage model). One either uses the BUFIO without an MMCM or uses an MMCM with a BUFG or BUFH. Take a look at this post on recommended clocking structures for input capture.

Second, are you saying that in your 165MHz DDR input interface (which has a bit period of 3.03ns), your input device only guarantees stable data for 1.1ns (out of the 3.03)? If so, then forget static capture - 1.1ns is too small to capture statically. Even the best capture mechanism can't go down below 1.5ns (or a bit more). But these numbers are odd - I haven't encountered many devices that have this much uncertainty on a clock forwarded interface.

Assuming you do want to pursue static capture (which, again, you should only do if your input window is significantly longer than 1.1ns), then take a look at this post on constraining center aligned source synchronous DDR input interfaces.

Avrum

Highlighted
Explorer
Explorer
449 Views
Registered: ‎10-07-2016

Re: Question about constraining an IDDR interface

Jump to solution

Hello avrumw,

thank you for your help. please see my comments below:

First, the combination of a BUFIO and an MMCM is not recommended (at least not in this usage model). One either uses the BUFIO without an MMCM or uses an MMCM with a BUFG or BUFH. Take a look at this post on recommended clocking structures for input capture.

Okay, I followed your link "recommended clocking structures for input capture" and I use now a direct clocking path by using a BUFIO which drives the clock input of the IDDR.

But what if I would be faced to a edge alinged source synchronous ddr input interface. In this case, I have to use the MMCM, in order to shift the clock by 90°, isn't it. So what is the recomendation in this case?


Second, are you saying that in your 165MHz DDR input interface (which has a bit period of 3.03ns), your input device only guarantees stable data for 1.1ns (out of the 3.03)? If so, then forget static capture - 1.1ns is too small to capture statically. Even the best capture mechanism can't go down below 1.5ns (or a bit more). But these numbers are odd - I haven't encountered many devices that have this much uncertainty on a clock forwarded interface.

Defining the setup- and hold time for the ddr input interface is a bit difficult, since I do not really have the timing values available of the soruce device which is driving the ddr input interface. The only thing I know is, that this source device (which is also an FPGA developed several years ago by an external company whose developers are no longer reachable) drives also a dvi transmittter, whose minimum setup and hold time was Tsu = 0.6ns and Thd = 0.5ns. So my idea was to set the setup and hold time for the ddr input interface to the same values as for the dvi transmitter. So it can be that I have a bigger margin, but unfortunately I do not know the size of the margin. Therefore the values Tsu = 0.6ns and Thd = 0.5ns are worst case considerations.

At the moment my ddr input interface looks like as the blue highlighted circuit in the picture below. 

pic3.JPG

As you mentoined, there is no chance to achieve the timing with the setup and hold timing values mentoined above. But when I add an IDELAY element in the data path, I can eliminate the slightly bigger propagation delay time of the clock path, compared to the data path. Further, I have adjusted the IDELAY value by a value, so that the negative slack of the setup and hold time is almost equal. By using the IDELAY element I get the following slack values:

Setup = -0.297ns

Hold = -0,238ns

with the following timing constraints:

create_clock -period 5.000 -name clk_ref_in -waveform {0.000 2.500} [get_ports clk_ref_in]
create_clock -period 6.061 -name clk_in_p -waveform {0.000 3.031} [get_ports clk_in_p]
set_input_jitter clk_in_p 0.100

set_input_delay -clock [get_clocks clk_in_p] -clock_fall -min -add_delay 0.500 [get_ports din]
set_input_delay -clock [get_clocks clk_in_p] -clock_fall -max -add_delay 2.431 [get_ports din]
set_input_delay -clock [get_clocks clk_in_p] -min -add_delay 0.500 [get_ports din]
set_input_delay -clock [get_clocks clk_in_p] -max -add_delay 2.431 [get_ports din]

The slack is quite small, but as you already mentoined the timing cannot be achieved.

Well I assume I have more time available for the setup and hold time, but currently I cannot exactly say how much it will be...

Kind regards

stgateizo

0 Kudos
Historian
Historian
414 Views
Registered: ‎01-23-2009

Re: Question about constraining an IDDR interface

Jump to solution

But what if I would be faced to a edge alinged source synchronous ddr input interface. In this case, I have to use the MMCM, in order to shift the clock by 90°, isn't it. So what is the recomendation in this case?

The solution depends on your bit rate.

If your bitrate is fast, then you can use the IDELAY. The IDELAY can add as much as 2.5ns of delay to either your clock or your data, which gives you a dynamic range of 5ns. While there are other considerations, this is certainly enough to adjust the timing when your bit period is "small" (you are working with a fast interface) - for example for a 400Mbps interface the most you need is 2.5ns.

At slower rates, you may need more than 2.5ns (or even the 5ns when you consider that you can move either clock or data). In this case, you can use the MMCM. However, since your interface is slow, you almost certainly have enough data eye width to accommodate the extra setup/hold time required by the clocking scheme that uses the MMCM.

Avrum

0 Kudos
Historian
Historian
410 Views
Registered: ‎01-23-2009

Re: Question about constraining an IDDR interface

Jump to solution

At the moment my ddr input interface looks like as the blue highlighted circuit in the picture below.

What's in your clock wizard?

If you are capturing the data on the BUFIO clock in the IDDR, you should really be working with it using a BUFR clock - i.e. the IDDR outputs (Q1 and Q2) should be used by logic that is clocked by a BUFR. If your clock module is using an MMCM/BUFG, then this isn't a "recommended" clock crossing. Depending on the speed, you may be able to get that to work, but the tool will be working to fix timing problems crossing between the BUFIO and BUFG domains; the BUFIO and BUFR are phase matched so that it minimizes the timing problems.

If you really need the data on a "global" clock, the solution is to use a shallow clock crossing FIFO to bring data from the BUFR domain to a global domain (these two clocks can be treated as "mesochronous").

By the way, if you are using the IDDR (and not the ISERDES), you can use the BUFR alone - the BUFR can clock both the IDDR clock and the clocked resources in the same region - I have found that the BUFR capture is slightly better than the BUFIO...

Avrum

0 Kudos
Explorer
Explorer
385 Views
Registered: ‎10-07-2016

Re: Question about constraining an IDDR interface

Jump to solution

Hello avrumw,

see my answer below:

If your bitrate is fast, then you can use the IDELAY. 

Well I think this works only, when you are faced to a fixed input clock frequency. If the clock frequency can change (as it is the case for DVI), then I think you have to change the IDELAY value in dependency of the input clock frequency?

Kind regards

stgateizo

0 Kudos
Explorer
Explorer
380 Views
Registered: ‎10-07-2016

Re: Question about constraining an IDDR interface

Jump to solution

Hi avrumw,

see my comments below:

What's in your clock wizard?

The clock wizard contains a PLL, which generates a 0° and 90° clock with the same frequency as the input frequency, by using bufgce buffers on both outputs. As you assumed correctly, I use the 0° global clock to clock logic (registers) right after the IDDR. The 0° global clock and the 90° global clock is also used for the ddr output interface, as described in the second post I have currrently open in the community:

https://forums.xilinx.com/t5/Timing-Analysis/Constraining-oddr-output-interface-properly/m-p/954823#M16413

If you are capturing the data on the BUFIO clock in the IDDR, you should really be working with it using a BUFR clock - i.e. the IDDR outputs (Q1 and Q2) should be used by logic that is clocked by a BUFR. If your clock module is using an MMCM/BUFG, then this isn't a "recommended" clock crossing. Depending on the speed, you may be able to get that to work, but the tool will be working to fix timing problems crossing between the BUFIO and BUFG domains; the BUFIO and BUFR are phase matched so that it minimizes the timing problems.

Okay, this is something I didn't considered. So far I do net get any timing problems, but I'm aware that changing the IDELAY value can cause inter clock timing problems.

If you really need the data on a "global" clock, the solution is to use a shallow clock crossing FIFO to bring data from the BUFR domain to a global domain (these two clocks can be treated as "mesochronous").

Yes, I need the data on a global clock network. I have to do some video processing, and the data will be forwareded to anothe clock region (bank). But the idea to use a FIFO to separatethe BUFR and BUFG clock domains, sounds to be a very good solution.

By the way, how do I treat both clocks "mesosynchronous" ?
Do I need some special constraints?  

By the way, if you are using the IDDR (and not the ISERDES), you can use the BUFR alone - the BUFR can clock both the IDDR clock and the clocked resources in the same region - I have found that the BUFR capture is slightly better than the BUFIO...

Yes, I only use the IDDR and the IDELAY primitves for data capture. So if I understand you right, the following circuit should be the prefered one:

Data => IBUF => IDELAY => IDDR.D => FIFO.DI

Clock => IBUFDS => IDELAY => BUFR => IDDR.C
                          => PLL => BUFG => FIFO.DO

I will do a test design beginning of next week. I will keep you informed about the results.

Thank you for this valuable information! Maybe it would be good if Xilinx would create a paper which describes the implementation recommendations for the most used input and output interfaces, like SDR with rising and falling edge, or DDR interface with center and edge aligned sampling... These are actually the FPGA basics !!! 
The problem is that I spent too much time on this. My boss is asking me, why I need such a long time, for just passing through some DVI signals through the FPGA. As you know, time is money :-)

Kind regards

stgateizo

0 Kudos
Explorer
Explorer
339 Views
Registered: ‎10-07-2016

Re: Question about constraining an IDDR interface

Jump to solution

Status update:

As mentoined in the last post, I have created a test design, which follows the following clock / data path structure now:

Data => IBUF => IDELAY => IDDR.D => FIFO.DI

Clock => IBUFDS => IDELAY => BUFR => IDDR.C
                          => PLL => BUFG => FIFO.DO

With this structure, the setup and hold timing is now met without timing violation. The setup and hold slack is now postive and almost equal in size, which means that the idelay value for the clock and data path is properly set. The setup and hold slack is now roughly 300ps, which is even bigger than before when I used the bufio. 

Many thanks to avrumw, who helped me a lot !!!

Kind regards

stgateizo

0 Kudos