3
\$\begingroup\$

I need to sample 24-bit data on a DAC at 25 MHz. The data comes from a design, I implemented on FPGA. In every clock cycle, the FPGA outputs a 24-bit data, which the DAC has to sample in the next cycle. I have attached an image of the design that I am doing. How can I define the timing constraints on my design on FPGA ? I put clock constraints for 100 MHz and 25 MHz in my design on FPGA. Now the problem is, both the FPGA and the DAC chips sit at some unknown distance on Virtex-4 evaluation board. So how to make sure that the timing is met there, when the routing delay is unknown along the path ? What should be the input/output delay constraints?

enter image description here

\$\endgroup\$
7
  • 3
    \$\begingroup\$ Much better to make the interface design entirely source synchronous, that means clock your user logic output at 50MHz and treat the clock just like a data line, so that all data and the clock change with the same known timing. That way the distance to the DAC is irrelevant, all data and clock are delayed by the same amount. 25MHz to 24 bit accuracy? Good luck! \$\endgroup\$
    – Neil_UK
    Commented Dec 4, 2017 at 17:18
  • \$\begingroup\$ @Neil_UK How do we actually make it source synchronous on FPGA board ? Is it done through HDL coding or done using tool specific options in vivado/quartus ? \$\endgroup\$
    – Mitu Raj
    Commented Mar 14, 2018 at 15:09
  • 1
    \$\begingroup\$ write HDL to drive your clock and drive your data, treat the clock just like a data line, so that all data and the clock change with the same known timing, so one register gets updated with data and an extra bit which is the clock. \$\endgroup\$
    – Neil_UK
    Commented Mar 14, 2018 at 16:33
  • 1
    \$\begingroup\$ Take your 4x speed external clock, and use it to clock the output register, I'm assuming you're going to use registered I/O. All N+1 lines of N data and 1 data_clock get the same treatment. The signal to the data_clock bit into the I/O latch will be 100M/4, this may also be used as a CE to whatever is shifting the data into the I/O latch, ready to be output to the DAC. \$\endgroup\$
    – Neil_UK
    Commented Mar 14, 2018 at 18:23
  • 1
    \$\begingroup\$ Well, you don't design things so timing violations are unlikely, you design things so timing violations don't happen. It doesn't matter what length of cable goes to the DAC, or how FPGA temperature changes, the clock and data arrive there with minimal line to line skew. You choose a data_clock phase and a new data output CE phase to position the data_clock transition at the DAC in the centre of the valid data window at the DAC. Using source sychronous data means that's the same as the phasing at the FPGA output terminals. \$\endgroup\$
    – Neil_UK
    Commented Mar 14, 2018 at 18:50

1 Answer 1

Reset to default
2
\$\begingroup\$

At 25Mhz board delays are probably largely irrelevant (It is the sort of thing you worry about with multi hundred MHz memory clocks).

First thing I would do is to make sure that the output from the user logic is registered by that 25MHz clock so as to ensure you have defined timing at that point, then define constraints for the data relative to the 25MHz launch clock by studying the DAC datasheet for the setup and hold timings, you can afford to be a bit conservative here as everything is running so slowly.

\$\endgroup\$
2
  • \$\begingroup\$ Hm ! yeah. I think you have got a point there. With 40 ns time period, its quite slow. \$\endgroup\$
    – Mitu Raj
    Commented Dec 4, 2017 at 17:27
  • \$\begingroup\$ Roughly 9 inches per ns, that is some board! \$\endgroup\$
    – Dan Mills
    Commented Dec 4, 2017 at 17:49

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.