Altera_Forum
Honored Contributor
Honored Contributorset_clock_groups notes
I did a quick write-up on set_clock_groups and thought I'd post it here. In general, I think every design should use set_clock_groups in their .sdc, so it's worth understanding. (It looks complicated at first, but the more I use it the more I realize it's very powerful while remaining elegant). Anyway, onto the syntax(I'm shortening the clock names for readability in a post):
set_clock_groups -asynchronous -group {clkA PLL1_c0 PLL1_c1 } -group {clkB PLL2_c0 PLL2_c1 } -group {dsp_clk PLL3_c0 PLL3_c1 PLL3_c2 } That's the basic syntax. In essence, what it does is a set_false_path between the clocks n the first group to the clocks in the second two groups, and between the second two group(i.e. all clocks in a group are asynchronous to the clocks in another group). It's nice because the above constraint would have to be done with 66 individual constraints, which would be completely unreadable. Some notes: - I run Report Clocks in TimeQuest, and copy all the clock names out of the first column and paste them into the .sdc. Then it's just a matter of formatting them into this command, but I know I have all the clock names spelled correctly(see last note for exceptions to this) - Be careful of the escape character at the end of each line. If there's a space or tab after it, you won't see it, but the escape character will just escape that space or tab and not the end of line. The next line will be considered a new, unrecognizable command and TQ will error out. You will bang your head on the desk for an hour figuring it out. - Any clocks not in this command are related to all clocks. So if I add another output called PLL2_c3 and forget to add it to this command, it will be related to all the clocks. - You can have as many groups as you want. You can also have multiple set_clock_groups assignments. - A clock cannot appear in more than one group in a single set_clock_group command. - The -asynchronous command could also be -exclusive. This says the clocks are mutually exclusive(only one will be running at a time) as opposed to being asynchoronous. As for as TimeQuest is concerned, the two commands do the identical thing and cut timing between clocks in different groups. This option comes from ASIC land, where SI affects like cross-talk are analyzed, and so if two clocks are -exclusive, not only will paths between them not be analyzed, they won't have any secondary affects. Not only is this used by ASICs, but on our Hardcopy back-end, so if your design is going to Hardcopy it's worth thinking about. (And note that the above example, where the first two groups have the same input clock coming into PLL1, technically you would want to make those -exclusive) But if not going to Hardcopy, don't worry about it. - There is a special syntax where one -group is used. Basically it means cut the clocks from this group to any other clocks in the design. Something like: set_clock_groups -asynchronous -group {altera_jtag_tck} I've seen users take advantage of that like so: set_clock_groups -asynchronous -group {clkA PLL1_c0 PLL1_c1 } set_clock_groups -asynchronous -group {clkB PLL2_c0 PLL2_c1 } set_clock_groups -asynchronous -group {dsp_clk PLL3_c0 PLL3_c1 PLL3_c2} This will do the same thing as the first example. The reason I recommend it is because of the second bullet. If you add another output called PLL2_c3 and forget to add it to the third group, it will be cut to all the other outputs of that PLL. In other words, this can be dangerous. - In general, I recommend adding all clocks to the group. Exceptions are: 1) DDR and GXB designs, where there are about 50 millions clocks added to the design that the user doesn't know about. 95% of them have paths only to domains that are relevant or are cut in the .sdc files that get created, so basically I don't worry about them and it keeps the command a little cleaner. 2) I recommend doing virtual clocks for all I/O interfaces(except source-synch outputs, naturally). I don't add those virtual clocks to this because the only paths they connect to our I/Os that I explicitly designate, i.e. they tend to only have real paths. But it doesn't hurt to add them in either.
