ALTDDIO - 16bitx250MHz to 32bitx125MHz - Proper Timequest timing closure?

[Altera_Forum]

Hi, I'm using ALTDDIO to convert source-synchronous 16-bit/250 MHz data to 32-bit/125 MHz data. The device is a Cyclone V E. I'm trying to figure out how to properly constrain this interface. I have already configured my set_input_delay -max/min with the Tco per the external device (a TIUSB1310A USB 3.0 PHY). Timequest is failing hold time on the ALTDDIO input. How do I configure my SDC for this scenario?  

 Please take a look at the attached images for detailed information.  Thanks!

[Altera_Forum]

Hi, it might be worth having a look at AN433 

 https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/an/an433.pdf  I think for source sync ddr you will also need some false paths and possibly some multicycles in your sdc to make sure the timing is analysing the correct edges.

[Altera_Forum]

Correct me if wrong but if your data @250MHz is SDR, I don't get it how and why you change it to DDR inside FPGA using DDRIO

[Altera_Forum]

For some reason, using a fitter seed of 2 gave me a 0.6ns slack on the problem paths. Why would QII do such a lousy job on one seed setting but perfectly acceptable on another?

[Altera_Forum]

I 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.

[IDeyn]

I suppose I have exactly almost the same problem you mentioned - namely I have 125 MHZ, DDR, but I use center-aligned mode. It is from PHY - to FPGA RGMII interface, receive side.

I checked constraints, setup fails and if I manually decrease D1/D3 delay values timing successfully meets. But the question is why Quartus sets D1/D3 too high automatically?

Maybe you have a new experience?

Thank you in advance.

--

Best regards,

Ivan