cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
wmaguire
Explorer
Explorer
1,938 Views
Registered: ‎06-21-2013

Constraining OSERDES outputs for Source Synchronous Designs.

Jump to solution

I am seeking some clarification w.r.t. my understanding concerning the constraining of source synchronous OSERDES Outputs.

 

I have read quite a few posts w.r.t this subject and in particular this very good post 

https://forums.xilinx.com/t5/Timing-Analysis/How-to-constraint-Same-Edge-capture-edge-aligned-DDR-input/m-p/646009#M8411

 

Which cover inputs.

 

We are using a Zynq part and use the OSERDESE2 to generate the LVDS clocks to the DAC.  As can be seen from the picture of the elaborated design below the same mmcm clock is used do drive the OSERDES devices for the DAC clock, DAC Data and DAC Frame. 

 

dacDesignElaborated.png

 

Regarding the timing constraints I have modeled these based on the Xilinx forum and AN433 from Altera

 

The DAC clock is 103.68MHz

The sampling setup and hold are configurable in the DAC over four windows.

 

For the purposes of this post I am using the largest sample window for the DAC which is

tsu = -0.47 nSec        // ADC samples input after the rising DAC clock edge.

thold = 1.38 nSec

 

The associated timing constraints are

create_generated_clock -name dac_clk_ext -source [get_pins AD9122_Interface_i/axi_ad9122_0/inst/i_if/i_serdes_clk/clk] -multiply_by 1 [get_ports TX_DAC_DCIP]

 

set_output_delay -clock dac_clk_ext -max -0.47 [get_ports {TX_DAC_DP[*]}]
set_output_delay -clock dac_clk_ext -min -1.38 [get_ports {TX_DAC_DP[*]}]
set_output_delay -clock dac_clk_ext -clock_fall -max -add_delay -0.47 [get_ports {TX_DAC_DP[*]}]
set_output_delay -clock dac_clk_ext -clock_fall -min -add_delay -1.38 [get_ports {TX_DAC_DP[*]}]

set_output_delay -clock dac_clk_ext -max -0.47 [get_ports TX_DAC_FRAMEP]
set_output_delay -clock dac_clk_ext -min -1.38 [get_ports TX_DAC_FRAMEP]
set_output_delay -clock dac_clk_ext -clock_fall -max -add_delay -0.47 [get_ports TX_DAC_FRAMEP]
set_output_delay -clock dac_clk_ext -clock_fall -min -add_delay -1.38 [get_ports TX_DAC_FRAMEP]


set_multicycle_path 0 -from [get_clocks -of_objects [get_pins AD9122_Interface_i/axi_ad9122_0/inst/i_if/i_serdes_clk/clk]] -to [get_clocks dac_clk_ext]
set_false_path -setup -rise_from [get_clocks -of_objects [get_pins AD9122_Interface_i/axi_ad9122_0/inst/i_if/i_serdes_clk/clk]] -fall_to [get_clocks dac_clk_ext]; 
set_false_path -setup -fall_from [get_clocks -of_objects [gget_pins AD9122_Interface_i/axi_ad9122_0/inst/i_if/i_serdes_clk/clk]] -rise_to [get_clocks dac_clk_ext]; 

set_multicycle_path -1 -hold -from [get_clocks -of_objects [get_pins AD9122_Interface_i/axi_ad9122_0/inst/i_if/i_serdes_clk/clk]] -to [get_clocks dac_clk_ext]
set_false_path -hold -rise_from [get_clocks -of_objects [get_pins AD9122_Interface_i/axi_ad9122_0/inst/i_if/i_serdes_clk/clk]] -rise_to [get_clocks dac_clk_ext];
set_false_path -hold -fall_from [get_clocks -of_objects [get_pins AD9122_Interface_i/axi_ad9122_0/inst/i_if/i_serdes_clk/clk]] -fall_to [get_clocks dac_clk_ext];

 

The corresponding failed path report is 

pathReport.png

 

 

The area I am confused about is how can the DAC setup and hold times be modeled in this design using STA timing constraints when the OSERDES devices are used as shown above.  As far as the DAC inputs are concerned the setup and hold requirements are related to the output source synchronous clock and data which will have as little skew as possible (because of the use of the OSERDES) to the DAC data and frame.   Any changes in the clock driving the OSERDES devices is the same for all outputs.  Generating the output clock using the OSERDES method effectively locks the edges of the clock out and data/frame out (within skew limitations of the FPGA).  Therefore, what is being modeled by the constraints above?  Is it the internal delays and paths to the output buffers?  As the design is using OSERDES for the data and clock are the set_output_delay constraints moot?   Can these constraints be replaced by set_false_paths.

 

Regards

 

 

Walter

 

 

 

 

 

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
2,279 Views
Registered: ‎01-23-2009

As the design is using OSERDES for the data and clock are the set_output_delay constraints moot? 

 

Yes and no.

 

You are fundamentally correct - the elements associated with this output interface are "fixed" - the only things that matter to the interface are the internal clock skew (which is fixed by location and the architecture of the global clock network) and the paths from the OSERDESs to the ports (which are also fixed). So the constraints can't "change" anything as they would with an internal path or even a path to an output from the fabric.

 

So from this point of view, the constraints are moot.

 

However, the constraints also serve as the mechanism of communicating the requirements to the tool simply so it can answer the question "Will this architecture satisfy these requirements?". If you properly constrain the paths and they pass then you can rest assured that the interface will work on the board.

 

However, in your case, they fail - you are asking for the data to become valid no later than 0.47ns after the clock, and the tools are telling you that you fail by 0.127ns. They are effectively saying "I cannot guarantee that it will be valid until at least 0.597ns after the clock" - effectively saying the clock/data skew is just under 0.6ns.

 

So the tools say that this interface fails. As far as the tool is concerned this is true - your interface is not guaranteed to work under these conditions.

 

Now, we can ask ourselves if this is reasonable... The two OSERDES are clocked by the same clock network and the two pins are on the same die (and apparently near each other) - is 0.6ns of skew reasonable?

 

This is a tough question. Older FPGA tools weren't sophisticated enough to provide a skew number under these circumstances, so we needed to rely on "rules of thumb"; we made an estimate as to the worst skew. Generally this estimate was far smaller than 600ps. But Vivado says it is 600ps. So what do we do?

 

Vivado performs "on chip variation" analysis; it assumes that the Process, Voltage and Temperature can vary within a limited range even on the same die at the same time, which is true. However the on chip variation is "global" it assumes that there can be the same amount of variation between two cells on opposite sides of the die as there can be between two adjacent cells. For the most part, this pessimism enures designs are reliable and doesn't have a huge impact on timing. However in the cases of interfaces - particularly output interfaces where the OBUF has a quite large delay (almost 800ps in this case), this pessimism costs. It is this (the sum of the real clock skew and the on chip variation of the final part of the clock distribution, OSERDES and the OBUF), you get the 600ps.

 

So, what are your options. In this case you probably have TONS of hold time margin - your half period is 4.8ns and you only need 1.38ns of that for hold. You can confirm the hold margin by asking the tool - for example

 

report_timing -hold -to [get_ports TX_DAC_DP[*]]

 

So, you can consider adding some extra delay to the clock path to trade setup for hold. If this interface is in a high performance I/O bank (HP), then you can use the ODELAY to add a small amount of delay. This delay will be (at least partly) PVT compensated, so you will lose some overall margin, but can trade setup for hold.

 

If you are not in an HPIO bank, then you can consider using a second clock output from your MMCM to drive the OSERDES generating the clock, and you can adjust the phase of this clock forward slightly. You may need to change the PHASESHIFT_MODE of the MMCM or adjust your timing constraints to make the tools time this interface the same way (see this post on the PHASESHIFT_MODE). Again, this will cost you margin since there is some phase error between different outputs of the same MMCM and the two clocks will be on different clock networks (so the on chip variation will apply to more elements in the path), but again, if there is enough margin, you should still be able to make this work.

 

Lastly, (and I this is almost the only place where I will even consider suggesting this) - you can consider ignoring the tool. From everything we know this 600ps of skew seems unreasonably pessimistic - the 470ps you need seems reasonable...

 

Avrum

 

 

View solution in original post

2 Replies
avrumw
Guide
Guide
2,280 Views
Registered: ‎01-23-2009

As the design is using OSERDES for the data and clock are the set_output_delay constraints moot? 

 

Yes and no.

 

You are fundamentally correct - the elements associated with this output interface are "fixed" - the only things that matter to the interface are the internal clock skew (which is fixed by location and the architecture of the global clock network) and the paths from the OSERDESs to the ports (which are also fixed). So the constraints can't "change" anything as they would with an internal path or even a path to an output from the fabric.

 

So from this point of view, the constraints are moot.

 

However, the constraints also serve as the mechanism of communicating the requirements to the tool simply so it can answer the question "Will this architecture satisfy these requirements?". If you properly constrain the paths and they pass then you can rest assured that the interface will work on the board.

 

However, in your case, they fail - you are asking for the data to become valid no later than 0.47ns after the clock, and the tools are telling you that you fail by 0.127ns. They are effectively saying "I cannot guarantee that it will be valid until at least 0.597ns after the clock" - effectively saying the clock/data skew is just under 0.6ns.

 

So the tools say that this interface fails. As far as the tool is concerned this is true - your interface is not guaranteed to work under these conditions.

 

Now, we can ask ourselves if this is reasonable... The two OSERDES are clocked by the same clock network and the two pins are on the same die (and apparently near each other) - is 0.6ns of skew reasonable?

 

This is a tough question. Older FPGA tools weren't sophisticated enough to provide a skew number under these circumstances, so we needed to rely on "rules of thumb"; we made an estimate as to the worst skew. Generally this estimate was far smaller than 600ps. But Vivado says it is 600ps. So what do we do?

 

Vivado performs "on chip variation" analysis; it assumes that the Process, Voltage and Temperature can vary within a limited range even on the same die at the same time, which is true. However the on chip variation is "global" it assumes that there can be the same amount of variation between two cells on opposite sides of the die as there can be between two adjacent cells. For the most part, this pessimism enures designs are reliable and doesn't have a huge impact on timing. However in the cases of interfaces - particularly output interfaces where the OBUF has a quite large delay (almost 800ps in this case), this pessimism costs. It is this (the sum of the real clock skew and the on chip variation of the final part of the clock distribution, OSERDES and the OBUF), you get the 600ps.

 

So, what are your options. In this case you probably have TONS of hold time margin - your half period is 4.8ns and you only need 1.38ns of that for hold. You can confirm the hold margin by asking the tool - for example

 

report_timing -hold -to [get_ports TX_DAC_DP[*]]

 

So, you can consider adding some extra delay to the clock path to trade setup for hold. If this interface is in a high performance I/O bank (HP), then you can use the ODELAY to add a small amount of delay. This delay will be (at least partly) PVT compensated, so you will lose some overall margin, but can trade setup for hold.

 

If you are not in an HPIO bank, then you can consider using a second clock output from your MMCM to drive the OSERDES generating the clock, and you can adjust the phase of this clock forward slightly. You may need to change the PHASESHIFT_MODE of the MMCM or adjust your timing constraints to make the tools time this interface the same way (see this post on the PHASESHIFT_MODE). Again, this will cost you margin since there is some phase error between different outputs of the same MMCM and the two clocks will be on different clock networks (so the on chip variation will apply to more elements in the path), but again, if there is enough margin, you should still be able to make this work.

 

Lastly, (and I this is almost the only place where I will even consider suggesting this) - you can consider ignoring the tool. From everything we know this 600ps of skew seems unreasonably pessimistic - the 470ps you need seems reasonable...

 

Avrum

 

 

View solution in original post

wmaguire
Explorer
Explorer
1,867 Views
Registered: ‎06-21-2013

Thank you avrumw for answering my questions.  Much appreciated.

 

Regards

 

 

Walter

0 Kudos