- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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. ---------- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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....?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
oh.. that bad..
hope changing the order works, otherwise i have a fifo not working as expected.... very bad....- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page