为什么 'd0 不扩展信号的整个宽度（就像 '0 那样）？
Why doesn't 'd0 extend the full width of the signal (as '0 does)?
使用SystemVerilog和Modelsim SE 2020.1，我很惊讶地看到一个行为：
bus_address 是一个 64b 信号 input logic [63:0] bus_address
使用'0
.bus_address ('0),
使用 'd0
.bus_address ('d0),
Riviera-Pro 2020.04（bug太多，我们放弃使用它，我们与Aldec有争议）
'd0:
'0:
Investigation/Answer:
11.3.3 在表达式中使用整数字面值：一个未确定大小的基于整数（例如，'d12、'sd12）
5.7.1 整型常量:
The number of bits that make up an unsized number (which is a simple
decimal number or a number with a base specifier but no size
specification) shall be at least 32. Unsized unsigned literal
constants where the high-order bit is unknown ( X or x ) or
three-state ( Z or z ) shall be extended to the size of the expression
containing the literal constant.
这很棘手，我认为它会像 '0 那样设置 0 所有其他位。
我希望规范的作者在定义这种无意义的行为时多考虑一下。
这个问题与 大小不匹配的端口连接有关 比与数字文字有关。只是在使用填充文字时问题不会出现。这是因为填充文字会自动调整自身大小以消除端口宽度不匹配。
无论您是使用文字还是像本例中那样的其他信号，您看到的问题都存在：
module top;
wire [31:0] a = 0;
dut d(a);
endmodule
module dut(input wire [63:0] p1);
initial $strobeb(p1);
endmodule
根据 23.3.3.7 不同网络类型的端口连接（网络和端口折叠），网络 a 和 p1 可能会合并进入单个 64 位网络，但只有较低的 32 位仍然被驱动，或者 64'hzzzzzzzz00000000.
如果将端口连接更改为大小文字 dut d(32'b0);，您会看到相同的行为 64'hzzzzzzzz00000000。
现在让我们回到未调整大小的数字文字 'd0。 Unsized 是用词不当——所有数字都有大小。只是大小是隐式的，而不是你想要的大小。有多少人写 {'b1,'b0,'b1,'b0} 时认为他们只是写了与 4'b1010 相同的东西？这在 LRM 中实际上是非法的，但一些工具会默默地将其解释为 {32'b1,32'b0,32'b1,32'b0}.
切勿使用大小不一的文字。
使用SystemVerilog和Modelsim SE 2020.1，我很惊讶地看到一个行为：
bus_address 是一个 64b 信号 input logic [63:0] bus_address
使用'0
.bus_address ('0),
使用 'd0
.bus_address ('d0),
Riviera-Pro 2020.04（bug太多，我们放弃使用它，我们与Aldec有争议）
'd0:
'0:
Investigation/Answer:
11.3.3 在表达式中使用整数字面值：一个未确定大小的基于整数（例如，'d12、'sd12）
5.7.1 整型常量:
The number of bits that make up an unsized number (which is a simple decimal number or a number with a base specifier but no size specification) shall be at least 32. Unsized unsigned literal constants where the high-order bit is unknown ( X or x ) or three-state ( Z or z ) shall be extended to the size of the expression containing the literal constant.
这很棘手，我认为它会像 '0 那样设置 0 所有其他位。
我希望规范的作者在定义这种无意义的行为时多考虑一下。
这个问题与 大小不匹配的端口连接有关 比与数字文字有关。只是在使用填充文字时问题不会出现。这是因为填充文字会自动调整自身大小以消除端口宽度不匹配。
无论您是使用文字还是像本例中那样的其他信号，您看到的问题都存在：
module top;
wire [31:0] a = 0;
dut d(a);
endmodule
module dut(input wire [63:0] p1);
initial $strobeb(p1);
endmodule
根据 23.3.3.7 不同网络类型的端口连接（网络和端口折叠），网络 a 和 p1 可能会合并进入单个 64 位网络，但只有较低的 32 位仍然被驱动，或者 64'hzzzzzzzz00000000.
如果将端口连接更改为大小文字 dut d(32'b0);，您会看到相同的行为 64'hzzzzzzzz00000000。
现在让我们回到未调整大小的数字文字 'd0。 Unsized 是用词不当——所有数字都有大小。只是大小是隐式的，而不是你想要的大小。有多少人写 {'b1,'b0,'b1,'b0} 时认为他们只是写了与 4'b1010 相同的东西？这在 LRM 中实际上是非法的，但一些工具会默默地将其解释为 {32'b1,32'b0,32'b1,32'b0}.