Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
All support for Intel NUC 7 - 13 systems has transitioned to ASUS. Read latest update.
20561 Discussions

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

Altera_Forum
Honored Contributor II
1,434 Views

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!
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
617 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
617 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
617 Views

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?

0 Kudos
Altera_Forum
Honored Contributor II
617 Views

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.
0 Kudos
IDeyn
New Contributor III
617 Views

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

0 Kudos
Reply