为什么verilog模拟器将网络延迟建模为惯性延迟而不是传输延迟？

我在测试台上连接了一个DDR模型，使用带有网络延迟的电线来模拟电路板上的跟踪延迟。该轨迹可以在其传输线中保留1或2个位，但由于模拟器将净延迟建模为惯性延迟，因此所有位都会作为小故障过滤掉。我甚至都不这样拿钟。SystemVerilog规范对此没有明确说明。因此，我猜测模拟器不希望将其建模为传输延迟而在性能和存储方面产生成本。然而，我坚信传输延迟是用于网络延迟的正确方法，因为否则，用每个bidir信号自身的延迟建模的麻烦是巨大的。你觉得怎么样

这是我的测试用例

`timescale 1ps/1ps

module sim_top  ();

parameter realtime NET_DELAY = 80ps;
parameter realtime PULSE_DELAY = 50ps;

logic driver;
initial begin
  driver = 0;
  forever #PULSE_DELAY driver = !driver;
end

wire #NET_DELAY a;
assign a = driver;
always @(posedge a or negedge a) begin
  $display("a=%b @ %t", a, $time);
end

logic b;
always @(*) begin
  b <= #NET_DELAY driver;
end

always @(posedge b or negedge b) begin
  $display("b=%b @ %t", b, $time);
end


initial begin
 #1ns;
 $finish;
end
endmodule

`时标1ps/1ps
模块sim_top（）；
参数实时网络延迟=80ps；
参数实时脉冲延迟=50ps；
逻辑驱动器；
初始开始
驱动器=0；
永久脉冲延迟驱动器=！司机；
结束
线网延时a；
分配一个=驱动程序；
始终@（posedge a或negedge a）开始
$display（“a=%b@%t”，a，$time）；
结束
逻辑b；
始终@（*）开始
b传输延迟可以通过使用带有非阻塞辅助的#延迟来模拟：

always @*
   out <= #delay input;

其余的大部分是行为模拟工件，应该只在测试台上使用

我发现这篇论文对这一问题非常有用：
可以通过使用带有非阻塞辅助的#延迟来模拟传输延迟：

always @*
   out <= #delay input;

其余的大部分是行为模拟工件，应该只在测试台上使用

我发现这篇论文对这一问题非常有用：

因此，我猜测模拟器不希望将其建模为传输延迟而在性能和存储方面产生成本

我能想象你是怎么得到这种推理的。据我所知，你的假设是不正确的

实际逻辑门具有惯性延迟。该延迟是由RC（电阻和电容）引起的，RC（电阻和电容）继承到设备、路由或有意添加。Verilog使用惯性延迟来模拟真实逻辑的延迟行为

我找不到引证，但从与具有Verilog之前经验的工程师的讨论中，早期的Verilog只对gates建模（想想Verilog原语
和
，
或
，
nand
，
bufif0
，等等）。Assign语句和always块是在一段时间后添加的，并可能进行合成。非阻塞（

因此，我猜测模拟器不希望将其建模为传输延迟而在性能和存储方面产生成本

我可以想象你是如何得到这种推理的。从我所学到的，你的假设是不正确的

真实逻辑门具有惯性延迟。该延迟由RC（电阻和电容）引起，RC（电阻和电容）继承到设备、路由或故意添加。Verilog使用惯性延迟模拟真实逻辑的延迟行为

我找不到引证，但从与具有Verilog之前经验的工程师的讨论中，早期的Verilog只对gates进行建模（想想Verilog原语
和
，
或
，
nand
，
bufif0
，等等）。Assign语句和always块是在一段时间后添加的，还可以进行合成。非阻塞（
谢谢你的回答。然而，这不是我要问的。事实上，你的回答正好说明了问题所在。想想你将如何使用你的方法来模拟双向导线上的延迟。你认为净延迟应该被模拟为传输延迟而不是惯性延迟，以使我们的生活更轻松吗？谢谢你的回答。但是，这这不是我要问的。事实上，你的答案正好说明了问题所在。想想你将如何使用你的方法来模拟双向导线上的延迟。你认为净延迟应该被模拟为传输延迟而不是惯性延迟，以使我们的生活更轻松吗？我同意你在这里提到的一切。我仍然有一个问题：如果连续赋值语句中的延迟是针对二进制门的，那么为什么我们需要净延迟来做同样的事情呢？IEEE1800-2012§10.3.3还说：wire#10 wiera；这种语法称为净延迟，意味着任何由其他语句应用于wiera的值更改都应延迟十个时间单位，然后再执行在作为净声明一部分的连续分配中指定延迟，应与指定净延迟，然后作出……不同。Verilog的创建者决定使这三个语句在行为上等效：
wire#10 wireA；assign wireA=wireB；
，
wire wireA；assign#10 wireA=wireB；
和
wire\10wireA=wireB；
。但是，两者都有另一个延迟选项。例如：
wire\6wireA；assign\4wireA=wireB；
这基本上创建了一个相当于
wire\6wireA；wire\35; 4invisiblebdly4=wireB；assign wireA=invisibleBdly4；
的不可见网络。我猜它们是这样做的希望它是灵活的。在实践中，我从未见过在声明和分配中使用的延迟。好吧，当它是一条驱动线时，它们是等效的。当网络上有多个驱动时，任何分配在门延迟之上生效时，网络延迟应该建模。我认为这应该是传输，而不是惯性，本质上。我只是想在我的测试台上通过下拉对双向PCB跟踪的延迟进行建模时，让我的生活更轻松。你最初的问题没有提到期望的双向传输延迟。它问为什么Verilog使用惯性延迟作为默认值。如何建模双向传输延迟是一个很好的、独立的问题n、 很好。我会让它开放几天，看看是否有更好的答案。如果我在这里的答案满足您的“为什么是净延迟惯性”，那么请投票和/或点击接受答案图标。我同意一切
reg out;
wire #(FILTER) in_filtered = in;
always @* out <= #(TOTAL_DELAY-FILTER) in_filter; // must be >=0.0

localparam LENGTH = TOTAL_DELAY/FILTER; // must be an integer >=2
wire out;
wire [LENGTH-2 : 0] delay_chain;
assign #(FILTER) {out,delay_chain} = {delay_chain,in};