Modelsim仿真时间周期似乎与test_bench不同
我有一个测试台,该测试台在顶部说明:
'timescale 1 ns/ 1 ps
一个时钟定义为:
always begin
#5 sys_clk = ~sys_clk;
#20 clk_in = ~clk_in;
#8 clk_acq = ~clk_asq;
end
使用DO文件运行模拟: vsim in do file
但是,当Cursor测量时,ModelsIm the Clight of Criginem the Cursor测量时,是: 66ns而不是10N 时钟波形 有什么想法吗?
我真的不明白是什么原因导致这种行为。
编辑:另外,如果我在Testbench中运行流浪命令:
initial
begin
#1 $display("T=0t at time #1",$realtime);
#1 $display("T=0t at time #2",$realtime);
#1 $display("T=0t at time #3",$realtime);
#1 $display("T=0t at time #4",$realtime);
#2 $display("T=0t at time #5",$realtime);
end
我得到:
T=1000 at time #1
T=2000 at time #2
T=3000 at time #3
T=4000 at time #4
T=6000 at time #5
我想这是一个线索,但我不知道是什么原因引起的。
i have a testbench which states at the top:
'timescale 1 ns/ 1 ps
a clock which is defined as:
always begin
#5 sys_clk = ~sys_clk;
#20 clk_in = ~clk_in;
#8 clk_acq = ~clk_asq;
end
run the simulation using a do file:
vsim in do file
but the clock period in ModelSim waveform, when measured by the cursor, is:66ns and not 10ns
clock waveform
any idea?
I don't really understand what causes this behavior.
Edit: also, if i run the fallowing commands in the TESTBENCH:
initial
begin
#1 $display("T=0t at time #1",$realtime);
#1 $display("T=0t at time #2",$realtime);
#1 $display("T=0t at time #3",$realtime);
#1 $display("T=0t at time #4",$realtime);
#2 $display("T=0t at time #5",$realtime);
end
i get:
T=1000 at time #1
T=2000 at time #2
T=3000 at time #3
T=4000 at time #4
T=6000 at time #5
I guess this is a clue, but i have no idea what causing it.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您应该将所有代码都放在文本形式中。您按照以下方案生成时钟:
因此,您的时钟每 33 个周期更新一次:5 + 20 + 8,这解释了时钟周期为 66。
always 块不会运行并行作业,也不会重新启动,直到它完成了。因此,它将在再次开始之前完成所有更新。因此,所有时钟的周期都是 66,并且彼此之间会有偏移。
You should have put all the code in text form. You generate clocks following this scheme:
So, your clocks are updated every 33 cycles: 5 + 20 + 8, which explains clock period of 66.
An always block does not run parallel jobs, nor it restarts till it finishes. So, it will go through all updates before it starts again. As a result all your clocks will have a period of 66 and just will have an offset relative to each other.