7
\$\begingroup\$

I'm designing an application with an Altera Cyclone V SoC (5CSXFC6C6U23I7N) and interfacing ADCs and DACs at 250MS/s. In the meantime, the design complexity has increased a bit and now there are timing constraint violations near the DAC interface part. This interface uses the LVDS SERDES hardware for the DDR data format. The data clock is 250MHz and hence 500Mb/s data rate. The FPGA is internally clocked at the sampling frequency, i.e. 250MHz, which should not be a problem with this speed grade I7 device.

Now the problem: There are a few registers near the DAC interface to correctly order the data bits. But there are timing violations between such registers, altough there is absolutely no logic between the registers. When looking at the path delays in TimeQuest, I see that there are some 3.5ns delay introduced by routing (interconnect). Together with the other delays, the required 4ns are not achieved anymore. When looking at the data path in the chip planner, I see that it is routed from approximately the center of the FPGA to the I/O section. After seeing this, I thought that I could just insert an additional register stage, so that the data could be retimed somewhere in the path. But the fitter simply places those registers near the output stage as well, always making the same path(s) fail.

I know that the interface itself is not a problem, as this was working perfectly well in pervious compilation runs. Resource utilization is below 5%, so there is also no problem with missing registers/ALMs. Setting the fitter effort to "aggressive" or reducing the target temperature range slightly improves the figures, but there is still negative slack in the range of 500ps to 1ns.

btw: The design as such is working even with the violations when the device is running here at room temperature. I want to have it working reliably though, so just ignoring the violations is definitely not an option.

Any ideas?

Thanks and best regards,
Philipp

\$\endgroup\$
5
  • \$\begingroup\$ When you have such a low utilization level, the main problem is to transfer data from IO pad to IO pad, the easiest solution is to pipeline the data to help with the timing, this should not affect the overal functionality of your design if you do it right. \$\endgroup\$
    – FarhadA
    Commented Dec 23, 2015 at 8:47
  • 2
    \$\begingroup\$ @FarhadA That's something I've already tried: "[...]just insert an additional register stage, so that the data could be retimed somewhere in the path. But the fitter simply places those registers near the output stage as well, always making the same path(s) fail." Or did you mean something different? \$\endgroup\$
    – Philipp Burch
    Commented Dec 23, 2015 at 8:56
  • \$\begingroup\$ Can you share your constraint file? Do you group all the data signals in the same group and do you use set_max_delay constraint for the path? You can find some more info about it here: quartushelp.altera.com/15.0/mergedProjects/tafs/tafs/… \$\endgroup\$
    – FarhadA
    Commented Dec 23, 2015 at 9:26
  • \$\begingroup\$ Thanks for your comments! The only constraints related to these paths are derive_pll_clocks and derive_clock_uncertainty at the moment. What kind of maximum delay could I set for those data lines? Since it is only an output interface, I don't have any required relations between some input port(s) and those data lines. The actual outputs are driven by the LVDS SERDES blocks as mentioned, so it's only FPGA-internal routing that I'm concerned with right now. \$\endgroup\$
    – Philipp Burch
    Commented Dec 23, 2015 at 13:46
  • \$\begingroup\$ One more note: After reducing the design complexity in some other place, the timings are (almost) achieved. So maybe the current issues are just subsequent problems arising from some other part of the design. Is there a good way to identify critical paths even when the timings are met there? \$\endgroup\$
    – Philipp Burch
    Commented Dec 23, 2015 at 13:50

1 Answer 1

Reset to default
2
\$\begingroup\$

Are you sure there are real violations? Do you need to set false paths, or separate clock groups? STA tools are only smart as you tell them; if you don't think there's a real logic path / problem after reading the violation, I would modify my SDC to let the tool know to not worry about it. This could potentially also remove unnecessary restrictions on the synthesizer and router.

If it's a real problem and it's all coming from interconnect delay, I would wonder why the router is not placing appropriately for it. You could try adding regional constraints or investigating why the router thinks it's ok to place them so far apart -- perhaps some other constraint is missing.

\$\endgroup\$
3
  • \$\begingroup\$ The violations are insofar unreal as the design works despite them. However, when looking at the paths with the violations, these are quite real FF-to-FF paths which definitely will cause problems if timings are violated. All I could think of at this time is that the fitter has problems with some hold time requirements and tries to attack those with interconnect delay. \$\endgroup\$
    – Philipp Burch
    Commented Dec 23, 2015 at 18:45
  • \$\begingroup\$ @PhilippBurch Hold time should not be the problem within the same clock domain. For example, the dedicated shift register path between two adjacent flip-flops has a very short delay and works without problems. Is the clock distributed via a global clock network? \$\endgroup\$
    – Martin Zabel
    Commented Dec 24, 2015 at 9:01
  • \$\begingroup\$ @MartinZabel Hold time may be an issue in a shift register path if the clock has more delay than the data for some reason. I haven't manually constrained the clock network, but Quartus tells me that it has identified the signal as a clock and "promoted" it. Should be a global or regional network then. \$\endgroup\$
    – Philipp Burch
    Commented Dec 24, 2015 at 15:17

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.