多时钟选择问题
我觉得用不着设create_clock，不知道对不对。
得看这个pin所驱动的时序器件有没有和这个pin之前的时序器件有交互，如果没有，且不需要考虑source delay，那么create_clock就可以
这儿如果有交互的时序检测呢，改怎么设呢?
create_generate_clock
create_clock [get_ports cclk]-period 16-waveform {0 8}
create_clock [get_ports mclk]-period 16-waveform {0 8}
create_clock [get_ports tck]-period 40-waveform {0 20}
输出时钟是mux_clk
这三个该怎么设置create_generated_clock 呢?
我试过“create_generated_clock -name mux_clk -master_clock cclk [get_pins **]”无法创建时钟
加上-add 选项呢
试过，加了“-add”也不行
为什么不能设?报什么错?
不是-master_clock，是-source吧。而且你貌似没有给generate_clock定义pin
在你目前的这种情况，我建议不用在mux处定义时钟。建议设定如下：
set timing_enable_multiple_clocks_per_reg true
set_false_path -from [xxx] -to [xxx](三个主时钟互相false_path)
让工具自动分析三个时钟的个子的时序。
直接create在输出pin上，优点是constriant 会简单， 缺点是是会导致做CTS的时候不把从真正root点到这个mux的path作时钟处理，特别是高频时钟问题会更加明显，也会导致约束点的mux输出波形不是你想要的波形，比如说你care duty cycle的电路。
用PT来做的话没有您提到的变量，该如何处理 ?我的情况比较类似也是3选1
用PT来报timing的时候，不需要设定multiple_clock，它会自动把每个时钟都check一遍，但是必须彼此间设false_path，否则会出现时序违例。
set false ?
有 set_path group-exclusive 是不是一样?
另外set false在MUX的输入端的话可能会出现startpoint invalid的问题
首先更正一点，PT里面是有那个变量的，set timing_enable_multiple_clocks_per_reg true。
第二，我在PT里没见过set_path 这个命令，我说的命令是set_false_path -from [get_clocks clk1] -to [get_clocks clk2]
不清楚这两个命令是否相同，对于你刚刚说的，在MUX输入端设false_path会产生start point的问题，我没想明白为什么。还请解释一下。
另外，不知道我说的PT和你说的PT是不是同一个工具，怎么似乎很多命令都不相同。我说的是PrimeTime。
抱歉我没有写成完整的命令，所说的确实是primt time
在system variables 列表里面，timing_enable_m* 只能匹配到max_cap之类的，
不知道您使用的是哪一版本，确实很想尝试一下您说的作法，看起来会更加简单
至于第二点，如果直接写clock之间的 false path,就没有那样的问题了，是我表述不清。
我的意思是，直接把各个clock设置 exclusive，效果应该是一样的
我刚刚找了一下，2008版得PT还有这个参数，但是到了2012版就没有了。个人猜测，这个参数应该直接就被系统默认为打开的。你可以尝试一下不设case，直接check timing看看，会不会出现多时钟互相驱动的情况。
我试过 ，不设case，就会报告每一个分支的时钟，时钟间相互驱动的状况倒是暂时没看到
再请问一下，pt对于跨时钟域的路径有没有默认的处理方法，或者说，只能根据前端设计信息来手工指定跨时钟域路径的约束?
如果是后者，对于不熟悉设计细节的STAer来说，岂不是很麻烦?
我并不是专门做静态时序分析的，所以只能说一说我的看法，但并不一定准确。
PT的对与跨时钟域的时序的检测，根据的应该是实际的连接关系，如果你的确有跨时钟域的数据的交互，那么PT必然会按照正常的时序检测方式来check，无外乎是setup,hold等。但是很多时候，对于跨时钟域的数据交互，前端必然会做同步处理，很多的时序违例是必然却不用考虑的，这种情况下，如果不告诉PT忽略或者multi-cycle，PT必然报错，所以，一个最合理的PT检测结果，必然需要前端人员对时序做充分的说明，至少我们这里时序约束是由前端提供的，再由我们后端做一些补充。
对于之前我们讨论的那种情况，我没有用2012跑过，在08版里，PT考虑的就是所有可能的连接关系（经过试验得到的结果），也就是可能出现，CLK1发送的数据由CLK2来踩，这在大部分的实际工作中是不可能的，这里就需要我们做一定的约束。但是我们不能否认，有可能，CLK1发数的同时，时钟进行的切换，那么CLK1发的数就要有CLK2来踩（虽然这样设计很脑残），那么这种情况下，如果也需要考虑，怎么办?基于这点，我觉得，在2012里，PT也应该能检测这种极端情况。