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

[Altera_Forum]

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 ?

[Altera_Forum]

--- 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 ---    In theory TQ allows any clock to be used as reference as long as it is known to it and you know the right figures relative to the clock! but naturally you will use the clock input at the pin (clock_x) as you know the data/clock offsets (for set_input_delay)

[Altera_Forum]

Well, 

This is exactly what I thought...and did.  I.E: set_input_delay relative to the clock pin (not the Pll output). But then I started getting setup timing violations on the nets latched by pll_clock_x.  The input delay I set wasn't strict, the design isn't congested and the frequency of clock_x is 40Mhz.

[Altera_Forum]

--- Quote Start ---  Well, This is exactly what I thought...and did.  I.E: set_input_delay relative to the clock pin (not the Pll output). But then I started getting setup timing violations on the nets latched by pll_clock_x.  The input delay I set wasn't strict, the design isn't congested and the frequency of clock_x is 40Mhz.  --- Quote End ---    I take it that io setup/hold are ok but internally setup fails and does so on 40MHz. This is unusual in most devices. You may have some other issues. you need to describe more details about your design clocking and failed paths.

[Altera_Forum]

"IN_PCLOCK_RX_12B" under the Launch Clock tab is my "clock_x" pin. 

The very long name under the Latch Clock tab is my "clock_x_pll" Any of the names under the From Node is my "signal_x". Any of the names under the To Node represent the "clock_x_pll" registered version of "signal_x".

[Altera_Forum]

This means io paths are failing. what are your set input delay figures.  

What is the figure for setup relationship on those paths. Have you added derive_pll_clocks. what mode is the pll. you may try remove pll

[Altera_Forum]

It's an integer PLL 

The set_input_delay min is 0.1ns The set_input_delay max is 10ns  The period is 25ns (40Mhz).   Regarding the "derive_pll_clocks" command - yes. I used it and requested it to create the base clocks. So I didn't have to manually use neither create_clock nor create_generated_clock - all have been done automatically by the tool via the derive_pll_clocks command.

[Altera_Forum]

do you mean you haven't declared the base clock of 40MHz? you need that even though PLL is connected to it. 

Look at the failedpath table: what is the figure for setup relationship.This should be 25ns. your set input delay of.1/10 means early margin is very close to edge. Is that how your external chip and board delay wants? is your pll in normal mode or any other mode?

[Altera_Forum]

--- Quote Start ---  do you mean you haven't declared the base clock of 40MHz?  --- Quote End ---   Sorry. This I did of course. The PLL is set to normal mode.    --- Quote Start ---  your set input delay of.1/10 means early margin is very close to edge.  --- Quote End ---   The data signals are jittery so this is why I set the max delay to 10. But even at 10ns - it leaves 15ns which I think is enough for the tool to do a good job.  I'll rerun TQ and check for the relationship.

[Altera_Forum]

yes 15 ns is plenty of margin. You might better set pll to source synchronous mode. That way the clock data offset at pins is retained by pll

[Altera_Forum]

OK, I'll try that. 

Should I change something in the SDC file after doing so ?  Just looked again. The PLL is configured as "normal"

[Altera_Forum]

--- 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.

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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}]

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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.