SDC - What clock should the input pin be relative to?

--- Quote Start ---

OK, I'll try that.

Should I change something in the SDC file after doing so ?

--- Quote End ---

no sdc stays as TQ knows what the relations are.

I recompiled and ran it with the PLL set to source synchronous mode.

Unfortunately, the problem persists almost no change in the negative slack.

The relationship is 5.000

I continued my investigation and looked into the chip planner.

Perhaps what you see there may shed some light on the timing results.

I marked the point of one of the failing input pins (blue x mark) and the PLL whose output is used to clock that pin (red x mark).

They are pretty far away...

What do you think ?

https://www.alteraforum.com/forum/attachment.php?attachmentid=13375

--- Quote Start ---

I recompiled and ran it with the PLL set to source synchronous mode.

Unfortunately, the problem persists almost no change in the negative slack.

The relationship is 5.000

--- Quote End ---

setup relationship must be 25 (and hold relationship should be zero).

If it is 5 it will never pass. probably you are mistaken on this.

Are you using different clock edges between sdc clock waveform and latching of input register.

The chip planner shows the nodes are too far. use fast input registers and not fabric registers

--- Quote Start ---

Hello,

signal_x in an input pin to my FPGA.

signal_x is synchronous to clock_x which is also an input pin.

clock_x drives a pll input and becomes pll_clock_x.

pll_clock_x is phase aligned to clock_x and is used to latch signal_x.

Besides feeding the PLL - clock_x isn't used anywhere else in the design.

Question:

When constraining signal_x for input_delay - what clock should be used? clock_x or pll_clock_x ?

--- Quote End ---

With regards to your original question here, the answer is neither. You should be adding a virtual clock constraint to define the external clock that is driving the upstream device that is providing signal_x to the FPGA. A virtual clock is created with create_clock and no target because it never actually enters the FPGA device. So it might look something like this (the numbers are just examples):

create_clock -name clock_virtual -period 10.0

create_clock -name clock_x -period 10.0 [get_ports {clock_x}]

derive_pll_clocks

set_input_delay -max 5 -clock clock_virtual [get_ports {signal_x}]

set_input_delay -min 1 -clock clock_virtual [get_ports {signal_x}]

--- Quote Start ---

With regards to your original question here, the answer is neither. You should be adding a virtual clock constraint to define the external clock that is driving the upstream device that is providing signal_x to the FPGA.

--- Quote End ---

virtual clock is another option, not a must.

--- Quote Start ---

I recompiled and ran it with the PLL set to source synchronous mode.

Unfortunately, the problem persists almost no change in the negative slack.

The relationship is 5.000

--- Quote End ---

Sorry, you mean the relationship is 5.0 or the slack is -5?

If the relationship is 5.0, then I assume the latching clock is not 25 MHz and/or does not have the same nominal (0º) phase as the external clock.

If the relationship is 5.0 ns and your external delay is 0.1 to 10, this will never work like this.

PS: If you can share the detailed timing of the worse case path, it would be helpful.

--- Quote Start ---

With regards to your original question here, the answer is neither. You should be adding a virtual clock constraint to define the external clock that is driving the upstream device that is providing signal_x to the FPGA. A virtual clock is created with create_clock and no target because it never actually enters the FPGA device. So it might look something like this (the numbers are just examples):

create_clock -name clock_virtual -period 10.0

create_clock -name clock_x -period 10.0 [get_ports {clock_x}]

derive_pll_clocks

set_input_delay -max 5 -clock clock_virtual [get_ports {signal_x}]

set_input_delay -min 1 -clock clock_virtual [get_ports {signal_x}]

--- Quote End ---

Then, do you consider clock_virtual as being asynchronous to clock_x? My question is about setting the clock groups with the set_clock_groups command.

--- Quote Start ---

Then, do you consider clock_virtual as being asynchronous to clock_x? My question is about setting the clock groups with the set_clock_groups command.

--- Quote End ---

No. clock_virtual is the launch edge. clock_x is the latch edge. You would not cut these clock domains from each other.