cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
4,917 Views
Registered: ‎05-22-2014

LVDS DDR Parallel DAC interface timing problems

Jump to solution

Hello,

 

I need to interface with an 8-bit LVDS DDR DAC interface and have the following constraints on the DAC:

 

Data Setup Time (DATACLK to DATA): -680 ps

Data Hold Time (DATACLK to DATA): 420 ps

 

 

The data is being clocked out using a 220.184 MHz clock generated in an MMCM.

- Data path: ** -> ODDR -> OBUFDS - Output pin

 

The dataclk being forwarded to the DAC is a 90 degrees phase shifted version of the clk used to clk the data out. This is used to center-align the data and meet the timing constraints. ODDR is being used to forward the clock to the DAC.

 

I have created the following constraint for the forwarded clock

create_generated_clock -name TX_DAC_DCLK -source [get_pins TX_DAC_DCLK_ODDR/C] -divide_by 1 [get_ports TX_DAC_DCLK]

 

and the following for the data pins output delay (one of them):

set_output_delay -clock [get_clocks TX_DAC_DCLK] -clock_fall -min -add_delay -0.420 [get_ports TX_DAC_D0]
set_output_delay -clock [get_clocks TX_DAC_DCLK] -clock_fall -max -add_delay 0.680 [get_ports TX_DAC_D0]
set_output_delay -clock [get_clocks TX_DAC_DCLK] -min -add_delay -0.420 [get_ports TX_DAC_D0]
set_output_delay -clock [get_clocks TX_DAC_DCLK] -max -add_delay 0.680 [get_ports TX_DAC_D0]
set_output_delay -clock [get_clocks TX_DAC_DCLK] -clock_fall -min -add_delay -0.420 [get_ports TX_DAC_D0_N]
set_output_delay -clock [get_clocks TX_DAC_DCLK] -clock_fall -max -add_delay 0.680 [get_ports TX_DAC_D0_N]
set_output_delay -clock [get_clocks TX_DAC_DCLK] -min -add_delay -0.420 [get_ports TX_DAC_D0_N]
set_output_delay -clock [get_clocks TX_DAC_DCLK] -max -add_delay 0.680 [get_ports TX_DAC_D0_N]

 

Timing report:

timingreport.jpg

 

Running timing analysis, I see that I have a setup time violation and just barely meeting hold time - What am I doing wrong?

 

Thank you

0 Kudos
1 Solution

Accepted Solutions
Guide
Guide
8,592 Views
Registered: ‎01-23-2009

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

Just a final question; Is using BUFG on the output of the MMCM the best choice, or could I benefit / gain something from using a different type of clock buffer?

 

The two BUFG solution is definitely valid, but there are a couple of others to consider...

 

If the MMCM and the interface (and all associated logic) are in the same clock region, then you could use BUFHs for all the buffers instead of BUFGs. According to the architecture description this will give you "better" clocks (less jitter, less duty cycle distortion). However, I don't think that this "better"ness will actually be reflected in the timing analysis performed by the tools (you can always try). But, again, everything must be in the same clock region - that means the clock input driving the MMCM (see below), the MMCM itself, the output interface and everything responsible for generating the outputs. If you have other stuff from elsewhere in the FPGA, then you will need a BUFG for that, and then you have to consider the BUFG domain and the BUFH domain as mesochronous; needing some clock crossing circuit to go between them (although in certain circumstances the tools may be able to cross synchronously between by fixing the hold time problems that result from the architecturally large skew between the two clocks).

 

Above I said the clock capable input must be in the same clock region. This is true if you are going directly from the CC input to the MMCM, which is the recommended approach. Your design already has a BUFG on this path (as I mentioned before). This is less ideal because it does add some jitter to the clock as it goes through the global clock network... But, it alleviates the need for the clock capable pin to be in the same clock region as "everything else".

 

The last option for clocking uses the "High performance clock path (HPC)" - from the MMCM to the BUFIO/BUFR pair in the same clock region, You would need to use two of them (one for the forwarded clock and one for the data); there are 4, so it can be done. In theory, these give you the "best" performance in terms of jitter and (especially) duty cycle (since they are differential internally), but they can be a bit of a pain to use... You definitely cannot cross between the BUFR clock and (say) a BUFG or BUFH clock from the same MMCM (the skew is just too big). The HPC paths usually used for very high speed interfaces that use the OSERDES - I have never tried them using an ODDR (but I suspect that it is possible by using the BUFR in divide-by 1 mode). Again, I don't think this will result in any better results from the tool, but it may result in a slightly better "real" timing - it's hard to quantify this, though...

 

Avrum

View solution in original post

Tags (1)
7 Replies
Highlighted
Explorer
Explorer
4,878 Views
Registered: ‎05-22-2014

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

Some more information,

 

Device is XC7A100T and Vivado version is 2016.3

 

Thank you

0 Kudos
Highlighted
Guide
Guide
4,873 Views
Registered: ‎01-23-2009

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

First - your stated setup/hold times for the DAC don't seem to make sense, and aren't consistent with your constraints...

 

Data setup = -680ps means the data must become valid 680ps after the edge of the clock (a positive setup time is before the clock, a negative setup means after the clock). This kind of number is not unusual for a device that expects an edge aligned interface, and internally shifts the clock forward by 90 degrees internally. This is at odds with your description of the interface as "center aligned".

 

Data hold = 420ps. This means that the data must remain valid 420ps after the edge of the clock (a positive hold means after the clock edge). If you put these two together, data valid window ends before it starts! So clearly these numbers are either not right, or are being misrepresented/misinterpreted.

 

Your constraints say a different thing - they say SU=680 (680ps before the clock) and hold = 420 (420ps after the clock) - the -min timing in a set_output_delay is the negative of the hold time requirement. This is a pretty large data requirement for a source synchronous interface (1100ps total) - most are significantly smaller than this. Since the clock half-period is 2.26ns, though, this should still be doable (the allowable skew is 2.26-1.10=1.16ns)...

 

As a point of correctness, the -add_delay on the the constraints should be on only half of them; either the ones with the -clock_fall or without, whichever comes first in the file, but not both (I know the constraints wizard puts it on both - this is at least a little dangerous...). But, assuming there are no other constraints hanging around from "before" this set of constraints (and your report is consistent with the constraints that we see), this is not part of the problem...

 

I also wonder why you have a BUFG before the MMCM - this is architecturally unusual, but is not a part of this problem...

 

Finally, though, what you are seeing may just be Vivado. Vivado uses a pessimistic timing model for on chip variation, and is particularly pessimistic for clock forwarded interfaces - in my opinion, way too pessimistic... That being said, I don't see enough variation to eat the entire 1.16ns... It might help to see both the setup and hold path reports...

 

Avrum

Highlighted
Explorer
Explorer
4,862 Views
Registered: ‎05-22-2014

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

@avrumw 

 

Thank you for your time to reply.

 

The datasheet for the DAC is unfortunately confidential, so I can not share it. However it states the following timing parameters for the interface:

 

Data Setup Time, tS (DATACLK to DATA) (Rising Edge and Falling Edge): -680 ps

Data Hold Time, tH (DATACLK to DATA) (Rising Edge and Falling Edge): 420 ps

 

No timing diagram is available to elaborate further on the above paramters.

This is what I have interpreted as data has to be valid 680 ps before the clock and and be stable for 420 ps after the clock edge as the other option, like you stated, does not make sense.

 

As for the BUFG before the MMCM is because the input clock is being used directly also in other logic in the FPGA - The 2 clocks here are being generated from that same clock - I could take it directly, before the BUFG i guess.

 

I have attached the hold time report for the same net.

 

Thank you in advance.

 

timingreporthold.jpg

0 Kudos
Highlighted
Guide
Guide
4,848 Views
Registered: ‎01-23-2009

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

We agree that the numbers from the datasheet make no sense. There is a 3rd possible (mis-)interpretation of the numbers, which is that the setup is 680ps and the hold  is -420ps, requiring a a 260ps valid window that ends 420ps before the rising edge of clock. While this is a "legal" interface, it demands a pretty small window, and puts the window in an unusual place... So, of the 3 possible interpretations, I guess yours is the most reasonable (particularly if the datasheet refers to this as a center aligned interface - none of the other interpretations make this center aligned).

 

Given that, what you have looks correct - the constraints appear to be correctly applied and the tools are timing with respect to the correct edges. So, as far as the tool is concerned, it is giving you "correct" answers...

 

So this is what I was referring to in my earlier post - the tools are VERY pessimistic with this interface.  There is definitely uncertainty in this interface; the two MMCM outputs are not guaranteed to be perfectly phase aligned (with the 90 degrees you are asking for) - the datasheet specifies MMCM_Tstatphaoffset of 120ps, so the two MMCM clocks may be out by +/-120ps. There is also duty cycle imprecision from the MMCM (MMCM_Toutduty of +-200ps - including the BUFG), which matters since this is DDR. Then the entire rest of the paths (BUFG, routing, ODDR/IOB FF, and OBUF) are subject to full on-chip variation. So even from these numbers, we would expect a portion of the 1.16ns to be used.

 

But, if this interface is placed reasonably (the forwarded clock and data are near each other and are in the same I/O bank) then one would assume better correlation between the clock and data - the on-chip variation is just too pessimistic.

 

So (with one minor exception) this is the best that the tools are going to tell you about this interface. The minor exception is that you advance the forwarded clock a little more - by as close to 130ps as you can get it - to balance the setup and hold margin (to adjust for the fact that the device needs a bit more setup than it needs hold), and then keep your fingers crossed... The tools will tell you that the interface fails, but...

 

Avrum

Highlighted
Explorer
Explorer
4,844 Views
Registered: ‎05-22-2014

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

@avrumw

 

Well, the datasheet doesnt specifically state that this is a center aligned interface - My idea was to center align it based on the interpreted setup/hold times.

 

I am going to contact the vendor to confirm, how to interpret the setup and hold time parameters. As for placement of the data / clk signals, they are all placed next to each other on the same bank - Not much to do here.

 

Just a final question; Is using BUFG on the output of the MMCM the best choice, or could I benefit / gain something from using a different type of clock buffer?

 

Best regards,

AA

0 Kudos
Guide
Guide
8,593 Views
Registered: ‎01-23-2009

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

Just a final question; Is using BUFG on the output of the MMCM the best choice, or could I benefit / gain something from using a different type of clock buffer?

 

The two BUFG solution is definitely valid, but there are a couple of others to consider...

 

If the MMCM and the interface (and all associated logic) are in the same clock region, then you could use BUFHs for all the buffers instead of BUFGs. According to the architecture description this will give you "better" clocks (less jitter, less duty cycle distortion). However, I don't think that this "better"ness will actually be reflected in the timing analysis performed by the tools (you can always try). But, again, everything must be in the same clock region - that means the clock input driving the MMCM (see below), the MMCM itself, the output interface and everything responsible for generating the outputs. If you have other stuff from elsewhere in the FPGA, then you will need a BUFG for that, and then you have to consider the BUFG domain and the BUFH domain as mesochronous; needing some clock crossing circuit to go between them (although in certain circumstances the tools may be able to cross synchronously between by fixing the hold time problems that result from the architecturally large skew between the two clocks).

 

Above I said the clock capable input must be in the same clock region. This is true if you are going directly from the CC input to the MMCM, which is the recommended approach. Your design already has a BUFG on this path (as I mentioned before). This is less ideal because it does add some jitter to the clock as it goes through the global clock network... But, it alleviates the need for the clock capable pin to be in the same clock region as "everything else".

 

The last option for clocking uses the "High performance clock path (HPC)" - from the MMCM to the BUFIO/BUFR pair in the same clock region, You would need to use two of them (one for the forwarded clock and one for the data); there are 4, so it can be done. In theory, these give you the "best" performance in terms of jitter and (especially) duty cycle (since they are differential internally), but they can be a bit of a pain to use... You definitely cannot cross between the BUFR clock and (say) a BUFG or BUFH clock from the same MMCM (the skew is just too big). The HPC paths usually used for very high speed interfaces that use the OSERDES - I have never tried them using an ODDR (but I suspect that it is possible by using the BUFR in divide-by 1 mode). Again, I don't think this will result in any better results from the tool, but it may result in a slightly better "real" timing - it's hard to quantify this, though...

 

Avrum

View solution in original post

Tags (1)
Highlighted
Explorer
Explorer
4,805 Views
Registered: ‎05-22-2014

Re: LVDS DDR Parallel DAC interface timing problems

Jump to solution

Thank you for the detailed description of the different options I have - I will analyze them and find the best suitable architecture.

 

Best regards,

AA

0 Kudos