Contraint for multi-cycle clock latency

[Altera_Forum]

I have a very fast clock driven from the outside that, due to board level protocol out of my control, this clock must be used to drive data back to the source. The problem is that the latency through the fpga is about twice the period of the clock. It is a free running clock so delays in units of a clock cycle shouldn't matter. 

 Unfortunately, the tool doesn't believe me. Quartus 11.0sp1 reports setup time violations in excess of a clock period.   I tried putting a negative input delay but Quartus warns that it doesn't do input delays on clocks. Setting set_clock_latency to a negative value doesn't work because Quartus just takes substracts the value of the data required time.  Any ideas? My current hack is to put a large negative output delay on the output flops. It shuts up the violations but it really isn't much different from just falsing the path.

[Altera_Forum]

If I understood your problem correctly, this is not a job for timing constrains. 

 Instead, you need to pipeline your design. That is, add layer of registers. It should be easier to start adding them at the input and output levels. Then enable the register re-timing options in the synthesis and fitting.

[Altera_Forum]

I don't see how any pipe stages would do anything but it make the problem worse. Internal timing is fine. The setup violation is between the output flop and the board. Even if there was no delay at all for the data, it would still fail.

[Altera_Forum]

Ah, I misunderstood your problem then. 

The multi-cycle part confused me.  So, let's see if I got it right this time: You have a fast clock and your FPGA has to output signals at that fast clock's frequency. Those signals will then be received by another device in your board, running at the same clock frequency. Because there isn't any kind of feedback from your receiver to the FPGA, the delay from the FPGA to the receiver can be larger than one clock.  Is this correct?   If so, this is a pretty normal situation. And using realistic output delay (set_output_delay -min and -max) constrains looks like the correct path.  What's the operating frequency and what would the realistic output delays be?  Check if the fitter is packing the output flip-flops into the IOBs, though.

[Altera_Forum]

The clock period is about 3.6ns. It takes somewhere between 5ns and 7.5ns for the clock to propagate through the input pad and the internal network to the output flops. The trouble with the large negative output delay is that the phase difference between internal and external clocks still matters, even if the total delay doesn't.

[Altera_Forum]

Er.. is that the delay between the clock input pad and the output register's clock? 

It's pretty big. Are you using a dedicated clock input pin?

[Altera_Forum]

It is not a dedicated clock pin but it is clock capable. Moving to dedicated pin is, unfortunately, not an option. The input pin drives a regional clock buffer. Judging from other paths in the timing report, the latency on this clock is not unusual. The catch is that for internal paths and even outputs clocked from internal sources, clock latency doesn't really matter. As long as both source and destination flops see the clock at nearly the same time, the actual flight time from the clock's origin is not important. It matters for this case because the off chip components see the original clock, not the delayed form distributed inside the FPGA. 

 The latency values I see are large but they are not *that* unexpected. Years ago I had a Xilinx design that was sensetive to clock latency. On a large Virtex 4 device, a typical latency for a global clock was between 3 and 4ns. Regional clocks were closer to 2ns.

[Altera_Forum]

One more question: what FPGA family are you using? 

 Anyway... 2-4 ns is normal but 5-7.5 ns is big and it's because you aren't using one of the dedicated clock input pins.  But well, you're stuck with it. Some things I'd try.  a) Pass the clock though a LCELL primitive.  Non-dedicated clock pins can't drive the global/regional clock networks directly and Quartus will often route these signals as if they were normal signals.  Adding a LCELL primitive between the pin and the clock signal used to drive the logic will make Quartus route the LCELL's output using the global/regional clock network.  b) when setting the set_output_delay constrains, shift the max/min delay value by 1 clock cycle  c) use a PLL.  Use the PLLs output clock to drive your logic. "Normal compensation mode" or manually setting the PLL's output phase might help.

[Altera_Forum]

Yea, i vote for PLL

[Altera_Forum]

Hello Ese002, 

 I do have the same problem. All the answer of the others are not really helpfull. I try to describe my system: I have one Clock Source (148.5 MHz). This clock drives my FPGA pin and the Clock Pin of a second device. The FPGA drives a Data to the second device.  I use a FPGA PLL (Cyclone IV E). After the PLL I have a Clock Switch (Megawizard) My Clock Delay from Input to Output is more than one Clock period.  I have to define my Setup Hold Time via an Virtual Clock. This is the Problem. Timequest now sees the complete Delay between both Clocks.  I did not find a solution except, defining an Clock to an Output Pin which is Source Synchron to the external Clock and do my Setup Hold time to this Clock.  Did not get it untill now.  Any Suggestion ?  Matthias