quartus 12.1 compilation too long using altiobuf in CycloneV

[Altera_Forum]

hello, 

i am using quartus 12.1 Build 177 11/07/2012 SJ Full Version to compile a cycloneV (5CEFA9F31C8) project. the compilation time is beyond 24 hours (still not successfully routed) when i use altiobuf with programmable input delay enabled. when not use altiobuf, the total compilation time is about 50 minutes.  i am not sure if there is something i miss that causes such a long time compilation. i searched the forum, uses the following methods, but no improvement. 1. change fitter effort from standard fit to fast fit; 2. change the router effort multiplier from 4 down to 1; 3. turn off optimize hold timing option;  the following pic is the message info from quartus. http://www.alteraforum.com/forum/attachment.php?attachmentid=10412&stc=1  another should be mention, the problem still exists when i upgrade the quartus version from 12.1 to 14.0. the project has 48-channel lvds inputs, that is, i instantiated 48 altiobuf ip cores (all with programmable input delay enabled). regards, ingdxdy

[Altera_Forum]

Strange. I'm guessing the router no-fits, as there seems to be something it physically can't route. Note that it finished 99% of the routes in under an hour, and just doesn't seem to understand that it's not converging on a solution. You can probably kill it. I would file an SR. If you can create a test case with just the IO bufs, I'm guessing that might have the same issue.

[Altera_Forum]

Thanks for your quick reply, Rysc. 

 if with just the IO bufs, i am afraid of that quartus will synthesis off relevant logic and at the same time it is not convenient for me to revise the project. the fact should be pointed out is that, the compilation time depends a lot on how many altiobuf instances i use.  i have instantiated 48 altiobuf instances now, when i directly use input_pad -> ddio_in in all 48 channels, as i said above, compilation time is around 50 minutes; however, when i use input_pad->ddio_in in 47 channels, and use input_pad->altiobuf(with programmable input delay enabled)->ddio_in in 48th channel, compilation time is around 90 minutes. when i use input_pad->altiobuf(with programmable input delay enabled)->ddio_in in all 48 channels, compilation time is beyond 24 hours and still not successfully routed.  Regards, ingdxdy

[Altera_Forum]

My point of just the IOBUFS is to make a test design to submit in the SR, but you can submit the whole design if that's easier. Unless someone has seen that exact issue and has a solution, I doubt anyone on the forum is going to debug it, where a service request with Altera would. I've done a design with about that many configurable I/O delay chains, and didn't have any problems: 

http://www.alterawiki.com/wiki/programmable_ioe_delay_chain_interface

[Altera_Forum]

hi, Rysc, I have previously looked at the examples, the document 'Design Manual_Dynamic Delay Chain (Stratix V)‘ indeed help me a lot. 

However, these examples use StratixIV and V to show the usage of altiobuf with programmable output delay. my device is CycloneV, and i use altiobuf with programmable input delay, i dont know if these make differences(especially with a different device).   And i try to just use the IOBUFS to make a test design as you said, unfortunately, Quartus 12.1 gives a internal error during systhesis process, please see the attached message.  Regards, ingdxdy

[Altera_Forum]

New Test Results Report: Still compilation too long when using altiobuf with dynamic input delay chain enabled. 

 Quartus II Version: 14.0.0 Build 200 06/17/2014 SJ Full Version Quartus II 12.1 report internal error, please see my previous post, so we divert to 14.0 to compile the project.  As Rysc suggested, we just use IOBUFs to try, and in order not to be synthesized off by quartus, we designed the following project.  DATA_RECEIVE_MODULE-->FIFO-->DATA_SEND_MODULE  DATA_RECEIVE_MODULE: receive 48 channels ddr data from out side of FPGA; DATA_SEND_MODULE:send out the received data to out side of FPGA.  the DATA_RECEIVE_MODULE uses two following fashions: 1. input_pad --> altddio_in : 36 channels 2. input_pad --> altiobuf (with dynamic input delay chain enabled) --> altddio_in: 12 channels  The following is the message info printed by Quartus 14.0:   http://www.alteraforum.com/forum/attachment.php?attachmentid=10418&stc=1  According to the message, we believe that it again enters into deadlock.  Regards, ingdxdy