Minimum Pulse Width violation

[Altera_Forum]

Hello, 

 I have a design, where i am using a custom programmable delay line for shifting a clock. The delay line is implemented using and-or gates (as described in thread "Dynamic delay for LVDS inputs on a Cyclone 3").   The problem is that Timequest reports "Minimum pulse width" violation. From the Timequest report, i see that Timequest calculates "Late clock arrival" by taking the worst-case delay scenario, where the clock is passing through all 64 delay-taps, and "Early clock arrival" by taking the best-case, 1-tap delay scenario. This is logical i guess, since Timequest cannot understand that only one specific delay-path will be active at a time.  The problem is that i cannot find a way to disable the reporting of this violation and avoid the critical-warning-timing-not-met thing.   best regards, Kostas

[Altera_Forum]

I think you can't avoid this. If I understand correctly, you want to change the delay "on the field" in order to adjust the timing "artificially". So TQ analysis makes no sense in this case. 

If the input and output clocks of the delay line are related to different clock domains, you can simply set a false path between them to avoid the violation warning.

[Altera_Forum]

It looks like you are gating your clock. This is hard to survive in FPGA timing analysis. Minimum pulse width violation is distinct from tSU/tH violations and occurs at very high speeds or gated clocks. You better delay the data instead.

[Altera_Forum]

Are you sure TimeQuest is doing this? I'm pretty sure: 

1) The dynamic delay chains all power-up to the shortest delay when the dynamic inputs are used 2) TimeQuest analyzes it this way.  I just analyzed an I/O with dynamic delay chains(SIV output) and saw this occuring. Also, Minimum Pulse Width checks are usually against a single point, i.e.: - An I/O port that is clocked faster than the standard on it - A memory block running faster than the max rates in the handbook - The PLL reconfig clock going faster than it should Perhaps you're running the I/O config clock faster than allowed?

[Altera_Forum]

Firstly, thank you for the prompt replies... 

 @Cris72: yes i want to be able to dynamically change the read-data latch clock. Upon power-up, a training algorithm is responsible for setting up the correct clock delay. I've set false paths between the core-clock and read-latch clock domains but the "minimum pulse width" violation is reported on the combinatorial and-or circuitry of the delay line.  @kaz: i understand that it is not good to mess with the clock, but the data-bus is 32-bit wide..  @Rysc: i guess you are referring to the dynamic delay chains of the device io-buffers. I am using a StratixII part that does not support this feature, thus i am using a proprietary programmable delay line.  Anyway it is not that a big deal, everything seems to be working OK.. thus i just have to ignore the timing-not-met warning.  Thank you again, Kostas

[Altera_Forum]

If you're doing gated clocks, TimeQuest will analyze all paths through the combinatorial logic and use the longest/shortest combinations to do the most restrictive analysis possible. To get the analysis you want, put keep attributes on the combinatorial places the clock comes out of(to keep the name through synthesis) and apply a generated clock constraint. Now you have a new clock name and can cut timing between combinations that aren't relevant. 

For example, I worked on a design with a 4:1 clock mux, built out of three 2:1 muxes. The strange thing was that it used only 3 clocks, but one of them came into both first level 2:1 muxes(basically two different select values chose the same clock). So TQ would analyze setup by taking the longer path to the source register and the slower path to the destination register, and vice versa for hold analysis. This is all good, but we turned off the clocks when the mux switched, so these would never happen. So I put two generated clocks on each of the 2:1 outputs and cut timing between them all using a set_clock_groups constraint. (I don't know what you have, but that's the case where I've seen TQ do the longest and shortest analysis at the same time, so hopefully it's relevant.)

[Altera_Forum]

Thank you Rysc, I'll try that...