3
\$\begingroup\$

Data is moved from the Zynq 7010 to AD9779A DAC using parallel SDR link at 155.52MHz. This DAC generates DATACLK clock that is used to clock data out of the FPGA (see picture for the relevant FPGA design part). enter image description here The DATACLK signal can be delayed relative to the internal data sampling signal inside the DAC with the programmable delay, also DAC has a circuit that checks if data path timings are correct. So, with some help from the host CPU I tune the delay for the optimal data arrival time dynamically (either at startup or later if required).

All I described above works. That was just the necessary information, now the question:

What is the best practice to constrain timings of that data path?

I tried to use usual constraints and timing analysis fails at no surprise. So, currently I just marked that path as false path (using set_false_path) and fixed locations of the BUFR and OUT_FIFO for lower delay and more stable results from one compilation to another, but is that a good practice?

\$\endgroup\$
2
  • \$\begingroup\$ Does the clock signal frequency vary, or just the programmable delays? \$\endgroup\$
    – user4574
    Commented Jul 17, 2023 at 16:57
  • \$\begingroup\$ No, the frequency is fixed. \$\endgroup\$
    – Oleg Skydan
    Commented Jul 17, 2023 at 17:25

1 Answer 1

Reset to default
1
\$\begingroup\$

The programmable delays represent timing uncertainty.

Registering the input signals as soon as possible would be good practice so that the timing uncertainty doesn't propagate further into the design.

For Xilinx Vivado tools you can use the following commands to tell synthesis and implementation about that timing uncertainty:

set_input_delay -clock your_clock_name -max xxx [get_ports your_pin_name] set_input_delay -clock your_clock_name -min yyy [get_ports your_pin_name]

xxx and yyy are the min and max input delay in nanoseconds relative to your_clock_name.

\$\endgroup\$
3
  • \$\begingroup\$ If we look how the complete system (FPGA+DAC+dynamic delay control) works we will see that dynamic control actually reduces clock delay uncertainty (it will compensate for the delay variances due to the temperature and etc.). The delay can be tuned in a range sufficient to compensate for any clock delay, the only possible problem I see is data signals skew, but with the current design all signals originate from the common source located in the IOB and should not be a problem (and it can be checked by the static timing analysis). \$\endgroup\$
    – Oleg Skydan
    Commented Jul 18, 2023 at 3:06
  • \$\begingroup\$ @OlegSkydan Once the delays are properly tuned, then I agree that they reduce timing uncertainty. But prior to tuning them you may have a wide range of input delays. In any case, specify in the constraints what you think the actual timing uncertainty is in your application. If that's done, the tools should be able to properly analyze everything. Also, you may want to gate or register the inputs until things are tuned, otherwise you risk feeding metastable signals further into the design. \$\endgroup\$
    – user4574
    Commented Jul 18, 2023 at 13:20
  • \$\begingroup\$ Thanks! Currently I ended up writing a simple rule for the data lines timing relative to the RDCLK signal (the rule is needed for tools to calculate output data signal timings), then a simple TCL script calculates DAC data bus skew. That is the only problem that can not be tuned out by the programmable delay. So, now I can check data bus skew and be sure everything will be ok. \$\endgroup\$
    – Oleg Skydan
    Commented Jul 24, 2023 at 7:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.