Programmable delay line in CycloneIII

The cyclone III family has programmable delays on all of the I/O pins. These values are accessible through the assignment editor. The values are generally fixed at each compile. If you want programmable delay on the order that you are mentioning, I would recommend an external delay element like an ON-semi MC100E195. As a third option, you can use the delay in the mega-function of a PLL clock to provide varying delays. The PLLs can be configured in real time, and so you can change the phase delay.

Have fun.

As far as I understood the intention of the original post, none of the suggested methods would help in this case, except for the external delay element. There are various options to generate variable delays and pulsewidths by analog circuits. The challenge is to implement it in an FPGA. PLL dynamic phase shift is a good tool, but it's only applicable for clocks with a fixed frequency.

Logic delay lines at first imply a large variation over pvt (process, voltage, temperature), so usually a calibration would be necessary. Not equally spaced delays are unavoidable due to the LAB granularity of the FPGA. Monotonicity is mainly a matter of how the delay chain output is switched. The mux, that has to be translated to multiple LUTs and the respective routing are causing the problems, I think.

I'm curious, if timing constraints and timing driven synthesis would be able to achieve at least monotonic behaviour.

I would try to implement a structure for the delay chain, that promises monotonicity by design, e.g. as considered in the initial post of this thread. The input should be implemented as global signal in this case.

http://www.alteraforum.com/forum/showthread.php?t=26995

hi FvM and ronp,

as FvM says, I discard the PLL way, because input isn't at fixed repetition rate; also programmable IO delays are not good for me because are fixed at compile (or is there a method to exchange it on the fly?).

External delay lines are ok, in fact in the previous version of board that I'm developing, two '195 are used for this purpose, but since I added a FPGA for other purpose, I'm trying to eliminate most of off the shelf chips.

coming back to my idea, I thought that lcells are sensitive to variations of Vdd or temperature, but interconnections between cells are almost independent. Is this right?

Then putting all the mux (designed so that there is an equal number of gates between each input and output, then the same "nominal" delay) in a single LogicArrayBlock, delays between mux part are negligible rather connection between "smalldelay" lcell and mux that are in separate LAB.

Yesterday I read some on timing constraints, but I am a newbie... I try with a SDC file with

set_min_delay -from  -through }] -to  1.000ns
set_min_delay -from  -through }] -to  2.000ns
set_max_delay -from  -through }] -to  2.000ns
set_max_delay -from  -through }] -to  3.000ns

inserting it into TimeQuestAnalyzer into project settings and fitting but nothing... I also removed LogicLock Regions (I think perhaps it would place gates in other LAB to meet constraints but it doesn't with LogicLock) but another time nothing...

Could suggest me the right procedure to write time constraints and to fit project that meets them?

sorry for long post... any other tips are welcome!!!

Ale

Interconnects are routed through silicon switches, so they are also affected by pvt variations, I think.

I'm only familiar to the TimeQuest basics used for synchronous designs and can't help you in this case.

What are the constraints for your design. From the rising edge of an input, how much jitter and delay can you tolerate on the output pulse. How much delay resolution and length do you need on the output signal? Ideally, what you are trying to do, shouldn't be done in a design.

Thanks, just curious.

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.

thanks FvM for the hardware test.. in these days I'm a little bit busy because I'm studing for this semester exams, so I cannot spend much time for the fpga project.

However I'll try as you suggested the and/or delay line.

Also the cycloneiii_lcell_comb seem good, if quartus II will do what you want!

I wait that anyone enlighten me about timing constrains...

for ronp, as I says in first post, I'm trying to make a programmable width pulser; previous design use two mc100'195 in parallel, one used to compensate the intrinsic delay of the other; but there is 10 ns from the incoming edge to the output edge of pulse. I think that with the FPGA the delay is quite similar.

The jitter matter is more critical because specifications are better than 100ps cycle to cycle jitter.

thanks again for your interest and replies.

Alessandro Ruggeri