Programmable delay line in CycloneIII

I did some tests on a real hardware (a Cyclone III BeMicro stick), starting with the "and/or" delay line structure suggested in the above quoted post. The delay is monotonic by design. Additional I placed each 16 delay nodes in a LAB and in one case got the below shown equidistant delays (about 0.4 ns per step) At the LAB boundary, there's an additional 0.4 ns routing delay. I didn't use any timing constraints, except for a classical timing analyzer defined clock frequency. Without the location assignment, the delays are still monotonic, but varying irregularly.

The problem is however, that Quartus P&R is apparently "fighting" against a regular delay line structure. Fixing the LABs is only part of the job. The 4 inputs of the Cyclone III LUT have different propagation delays, as the resource property editor shows. They are choosen by P&R apparently based on two criteria: 1.Timing constraints 2. Different routing capabilities of dataa-datad LUT input. So the shown equidistant delay waveform, where all delay elements are using the same input type for parallel input respectively chained delayed signal, has been only achieved by chance. Apply some changes to the design, and either Quartus' imagined timing target or limited routing resources will inforce a different result.

I didn't yet check, if detailed timing constraints will work to achieve the intended timing reliably. But my tests suggests, that is probably the only method that can work at all.

I also tried a different approach by instantiating cycloneiii_lcell_comb primitives. Here you specify LUT inputs and the logic function by a lut_mask explicitely. But these assignments may be conflicting with the available (or just intended, I'm not sure about) routing, and Quartus feels free to change lut_mask and LUT input assignment, thwarting the intended timing. The dont_touch generic, whatever it means seems to be completely ignored.