rc综合，关于简单的两个时钟的约束问题，求大家进来看看，帮忙解决啊

西边的鸵鸟

顶层模块为clk_test.v，子模块为clk1.v和clk2.v，RTL代码如下：顶层：

module clk_test(a,b,c,d,clk_sys,clk_i2c);

input a,c,clk_sys,clk_i2c;

output b,d;

wire b,d;

clk1 clk1(.a(a), .clk_sys(clk_sys), .b(b));

clk2 clk2(.c(c), .clk_i2c(clk_i2c), .d(d));

endmodule


子模块clk1.v

module  clk1(a,b.clk_sys);

input a,clk1;

output b;

reg b;

reg b1,b2;

alwaysys@(posedge clk_sys)

begin

b1<=a;

b2<=b1;

b<=b2;

end


endmodule


子模块clk2.v

module clk2(c,d,clk_i2c);

input c,clk_i2c;

output d;

reg d;

always@(posedge clk_i2c)

begin

d<=c;

end

endmodule


rc综合时候，.tcl脚本里面，为了使得clk_sys 和clk_i2c不相关，采用了下面的约束：
set_false_path -from clk_sys -to clk_i2c
set_false_path -from clk_i2c -to clk_sys
这样做就能使工具在综合时候不考虑clk_sys和clk_i2c之间的逻辑，使这两个时钟独立。（应该对着的吧，版主告诉我的）

（由于设计要求）对于时钟clk_sys,需要多周期路径设置
set_multicycle_path -setup -end -from clk_sys -to clk_sys 256
set_multicycle_path -hold -end -from  clk_sys -to clk_sys 255


脚本里面关于输入输出的延时约束是这样写的
set clock [define_clock -period ${myPeriod1_ps} -name ${myclk_sys} $myclk_sys]

external_delay -input $myInDelay1_ps -clock ${myclk_sys} $input_clksys
external_delay -output $myOutDelay1_ps -clock ${myclk_sys} $output_clksys

set clock [define_clock -period ${myPeriod2_ps} -name ${myclk_i2c} $myclk_i2c]

external_delay -input $myInDelay2_ps -clock ${myclk_i2c} $input_clki2c
external_delay -output $myOutDelay2_ps -clock ${myclk_i2c} $output_clki2c


其中
$input_clksys
$output_clksys 描述的是子模块clk1.v中的输入输出引脚
$input_clki2c $output_clki2c描述的是子模块clk2.v中的输入输出引脚


问题是：
综合结束后，succeeded，但是有一个waring：possible timing problem have been detected in this design clk_test.v

可是时序报告里面的所有slack都是正值，这个waring是为什么呢？求版主大牛们刚忙解决啊

西边的鸵鸟

顶起！大大们帮帮忙

icfbicfb

应该问题不大吧，你 report_timing , report_qor 看看整体timing质量吧

西边的鸵鸟

回复 3# icfbicfb
report timing，所有路径的slack都是正的。但是，版主，我发现了一个问题，就是使用 report paths [eval [get_attribute paths <expection>]]查看，其中expection的内容是  /designs/clk_test/timing/expection/path_disable/dis_1
这里path_disable/dis_1是由于设置set_false_path 产生的（那两条语句，同时还有path_disable/dis_2），执行report paths [eval [get_attribute paths /designs/clk_test/timing/expection/path_disable/dis_1]]，报告没有发现违例路径，执行report paths [eval [get_attribute paths /designs/clk_test/timing/expection/path_disable/dis_2]]，报告结果为


Expection：‘path_disbales/dis_2’
Timing slack:UNCONSTRAINED（不受约束）  
Start-point：......(不写了)
End-point:......

很明显，warning是出现在这里的，还有Timing Slack是不受约束的UNCONTRAINED，是不是由于set_false_path这个约束导致的warning？

yiyeyo

回复 2# 西边的鸵鸟


    感觉是你的multicycle path 设置引起， 怎么会from to 一个clk呢？

西边的鸵鸟

回复 5# yiyeyo

这个设置应该是没有问题的，两个触发器，都是由时钟clk_sys驱动的，由于他们之间的组合逻辑耗时太大，默认周期检查内（默认都是一个周期）违反了setup，所以才会设置多周期路径，来放宽检测时间的。这没什么问题啊

yiyeyo

回复 6# 西边的鸵鸟


   那你不应该设置到clk上面啊，否则这个clk 除了这2个reg ，如果后面还有其他reg的话那后面的也flow这个长周期， 我觉得工具的warning 就是基于这一点，我建议你的from to 到reg的2个点 会比较好，你可以试一下

西边的鸵鸟

回复 7# yiyeyo
奥，受教了，我试试，多谢！！！！

yiyeyo

clk 自己到自己muticycle 不是很make sense ，如果lib的cell延时太长，说明频率这套库跑不上去，直接createclk 长周期不就ok了吗，或者按我说的对于clk分频逻辑 特殊处理一下，只是我觉得会有glitch什么的 ，你自己掂量吧

西边的鸵鸟

回复 9# yiyeyo
恩，您的建议也是对的。但是设计总是受限于功能需求的，这就是为什么要想方设法的满足某些苛刻的要求。。