Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
1,516 Views

sdc files order

Hi guys, 

 

I have several sdc fiies, some from 3rd party vendors. 

 

1. do i put my first (with the clock definitions).... 

MY.sdc 

Qip.1.sdc 

... 

 

 

2. or 

 

Qip.1.sdc 

.. 

MY.sdc 

 

 

 

 

thanks for the help.
0 Kudos
5 Replies
Highlighted
Valued Contributor III
29 Views

Most of what I've seen has the IP .sdc files first, then the user's own .sdc file/s to constrain any clocks that were missed, call derive_pll_clocks if it wasn't called already, add set_clock_groups, false paths and I/O constraints.  

 

That being said, it depends what's in them. It usually doesn't matter. This is off the top of my head, so not official and I may miss something, but the order is usually something like: 

 

create_clock assignments and create_generated_clock assignments are generally first. 

derive_pll_clocks is next 

(the order of these don't really matter, unless you do your own create_generated_clock assignment to constrain a PLL that would have been constrained by derive_pll_clocks, in which case you want your constraint first, so derive_pll_clocks will see it and not add its own clock) 

 

set_clock_groups - The one thing I've seen with this is it doesn't work on clocks that haven't been created yet. Since this is usually your constraint, your .sdc would be after any .sdc files that create clocks.  

 

set_false_path,set_max/min_delay,etc. These are usually path specific constraints and can be added anywhere. If one of the -from/-to options is a clock, then it should be done after the clock is created. 

 

IO constraints(including the creation of virtual clocks or generated clocks that only apply to I/O). These also could be done in any order, but I find putting them at the end makes sense. 

---------
0 Kudos
Highlighted
Valued Contributor III
29 Views

thanks Rysc ...! 

 

The reason i ask is that i see strange behavior in my design... 

 

and from looking at the SDCs i saw the the derive_pll_clocks was call **before** create clock was called. 

 

probably a GIT ISSUE. 

 

so this made me ask maybe the the order is off also. 

thanks!
0 Kudos
Highlighted
Valued Contributor III
29 Views

one more is you may... 

 

my sdc: 

 

create_clock -period 3.104 -name {clk322M} [get_ports clk322M] 

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

create_clock -period 40.0 -name {clk25M} [get_ports clk25M] 

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

 

derive_pll_clocks 

derive_clock_uncertainty 

 

 

if that called last is OK? 

 

or should i split it to one file with clocks at the beginning, then another with derive_pll_clocks at the end....?
0 Kudos
Highlighted
Valued Contributor III
29 Views

It's generally all right to call derive_pll_clocks before create_clock. The cool thing about derive_pll_clocks is it does a create_generated_clock on the PLL outputs where the -source is the .refclk input to the PLL. TimeQuest then traces back to the clock that drives that refclk. Because of this, derive_pll_clocks does not need to know the name of the clock that drives the PLL, and it could be something complicated(like if you're cascading PLLs). The only time it doesn't work is if you have multiple clocks feeding into the PLL, as it doesn't know which one you are referring to, and so you have to manually do the create_generated_clock assignment and add the -master_clock option to specify the clock. 

 

Yes, it's probably fine if my.sdc is called last. You might need to add a set_clock_groups to it, but that's fine. (And you might not, I don't know.)
0 Kudos
Highlighted
Valued Contributor III
29 Views

oh.. that bad.. 

hope changing the order works, otherwise i have a fifo not working as expected.... very bad....
0 Kudos