Using Cylcone V HMCPHY DQ pins as high frequency inputs

[Altera_Forum]

I am working on a design that uses two 500MSps ADCs with a DDR interface clocked at 250MHz. The ADC supplies the 250MHz clock to clock the signals into the FPGA (source synchronous). I am using the ADLTDDIO_IN IP block to clock the DDR signal into the FPGA. This results in a DATA_l and a DATA_h signal which is processed in two parallel paths. This is working without timing problems for one of the two ADCs. 

The problem is that the second ADC is partly connected to multi-function pins that can also be used in combination with the Hard Memory Controller (HMCPHY). The Cyclone V Device Handbook states that one should avoid using these pins (HMC DQ pins) as input pins for signals faster then 200MHz. The problem is that all hardware (boards) are finished.   When building the project I get timing issues on the multi-function pins. When checking the timing in detail I discovered that the timing problems are caused by the fact that these signals are routed through the HMC causing an extra routing delay of about 3.0 to 3.5 ns. Because the highest worst-case slack for these signals is -1.315 ns I tried to use a second clock to clock the first register in the FPGA fabric (first register after the ALTDDIO_IN). This second clock is the 4ns (250MHz) clock used for the ALTDDIO_IN shifted with 90 degrees. The idea is to have 1 ns extra setup time. Of course the next data will be clocked into the ALTDDIO_IN when the output of the previous bit isn't clocked into the next register, but I assume that due to the propagation delay the right data will be clocked into this register (is this correct?). I am even considering adding a set_min_delay on the signal. This idea is based on "Same frequency clocks with destination clock offset" application example described in the Quartus Prime handbook - Volume 3 (QPS5V3 page 7-42).   When using the second clock with a phase shift of 90 degrees (which is in the same clock group) I added a set_multicycle_path -from [clock ...] -to [clock ...] -setup -end 2 constraint. When checking this in TimeQuest, the results looked as expected. However after rebuilding the design the fitter added extra Data Delay to all signals resulting in negative slack.  Details of my quest including screen shots and extra information can be found in the attached pdf file.  Myquestions are:   

1. Why does adding the multicycle path constraint result in extra delay being added to the data path?   This is not only the case with the HMC pin signals but also with 'normal' signals. With the HMC pin signals one could argue that the fitter has no knowledge of the extra delay caused by the HMC, but for non HMC pin signals this shouldn't be the case. 
2. Am I doing something wrong? Am I using the wrong multicycle path constraint? 

[Altera_Forum]

Hello, Jacob. 

I'm fighting with the same issue. I confirm, that fitter inserts additional delay. As I understand, it tries to find best solution for all four timing models. And slow 85C is not mail priority. In my case it tried to satisfy Fast 85C first. Other models suffer from that.  Did you find a solution for capturing the second ADC?