Forum Discussion
Altera_Forum
Honored Contributor
9 years agoSDC - What clock should the input pin be relative to?
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 ?18 Replies
- Altera_Forum
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
- Altera_Forum
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
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"