Honored Contributor
Honored ContributorI have the same problem, also with Cyclone V. My setup is more standard; I have a source-synchronous edge-aligned DDR input running at 125 MHz (250 MT/s), where I send the clock through a PLL to shift it by 90 degrees, then use that clock to clock a number of ALTDDIO_IN buffers. Timing fails with similar negative slack for all data pins, apparently because Quartus sets too high values on the D1/D3 delay chains in the data I/O elements.
- Changing the seed did now work for me. - As far as I can see, there are no conflicting conditions to meet that could justify the large delays added on the data. I have checked all models (temperatures) and believe I have set appropriate false paths between rising and falling edges. Hold conditions are failing as well. - I have tried to put the PLL in both source synchronous and normal mode, without that making any clear difference. It almost seems like the fitter attempts to match the clock and data delay to the DDR IOs, disregarding the 90 degree shift on the clock. EDIT: That hold conditions are failing as well should obviously have been a red flag. What actually happens for me is that the clock delay from the PLL to the DDR IOs varies so much between the setup and hold analysis that the whole data valid window is being eaten up. With the variations in the data delay chains this amounts to up to around 2.5 ns, which seems like a lot. I will have to look at loosening the constraints to get the window large enough.
