verilator
Internal Error: ../V3Width.cpp:6901: Under node REPLICATE has no expected width
From wav-slink.
NOTE: One file has to be replaced because there is a reference to a missing parameter. It is attached further.
NOTE: The extension .txt has been added to the attached file name. Please rename it and replace the original file with this one.
What 'verilator' command line do we use to run your example?
verilator tech/slink_tech_lib.v app/slink_generic_tx_router.v app/slink_generic_fc_sm.v app/int_gpio/slink_int_gpio_top.v app/slink_generic_rx_router.v app/slink_generic_pstate_ctrl.v app/slink_generic_fc_replay.v app/amba/slink_apb_ini.v app/amba/slink_apb_tgt.v app/amba/slink_axi_ini.v app/amba/slink_axi_tgt.v app/amba/slink_axi_top.v bist/slink_bist_rx.v bist/slink_bist_tx.v bist/slink_bist.v bist/regs/slink_bist_regs_top.v gpio/slink_gpio_serdes.v stacks/slink_apb_axi_gpio_top.v stacks/slink_apb_gpio_top.v stacks/slink_apb_axi_regs_top.v serdes/slink_serdes_front_end.v slink_rx_align_deskew.v slink_prbs9.v slink_ltssm.v slink_ecc_syndrome.v slink_rx_deskew.v slink_sync_pulse.v slink_clk_control.v slink_attr_ctrl.v slink_ll_rx.v slink_tx_gearbox_128b13xb.v slink_rx_blockalign_128b13xb.v slink_crc_calc.v slink_ll_tx.v slink_ctrl_regs_top.v slink_attributes.v slink_ll_rx_pkt_filt.v slink.v -DSIMULATION=1 --binary -j 0 -O3 --quiet -Wno-fatal --bbox-unsup --default-language 1800-2017
NOTE: Run from the ~/wav-slink/rtl.
What 'verilator --version' are you using? Did you try it with the git master version? Verilator 5.036 2025-04-27 rev v5.036. Yes.
The piece of output corresponding to the error is the following:
...
%Error: Internal Error: slink_ll_tx.v:1693:39: ../V3Width.cpp:6901: Under node REPLICATE has no expected width?? Missing Visitor func?
: ... note: In instance 'slink_apb_gpio_top.u_slink.u_slink_ll_tx'
1693 | link_data_reg_in = {{(NUM_LANES-2)*(DATA_WIDTH){1'b0}}, crc_reg[15:8]};
| ^
... See the manual at https://verilator.org/verilator_doc.html?v=5.036 for more assistance.
What OS and distribution are you using? Ubuntu 20.04.6 LTS.
Does it work if you wrap the replicate quantity in parentheses like this?
{{((NUM_LANES-2)*DATA_WIDTH){1'b0}}, crc_reg[15:8]};
That file is very large. Can you please shrink it? See Reporting Verilator Bugs and especially section on use of sv-bugpoint.
That file is very large. Can you please shrink it? See Reporting Verilator Bugs and especially section on use of sv-bugpoint.
Sorry for the delay in response. Unfortunately, this error disappears as long as we change the context, i.e. the following command does not produce any errors:
verilator slink_ll_tx.v slink_ecc_syndrome.v slink_crc_calc.v -DSIMULATION=1 --binary -j 0 -O3 --quiet -Wno-fatal --bbox-unsup --default-language 1800-2017
And it's still a huge example. I can try to shrink that particular file, but not the whole context so to speak.
P.S. I've checked the parameters during the instantiation in the main module slink - they are the same as default parameters in slink_ll_tx module.
Did you try using sv-bugpoint as suggested?
Yes, I did. It seems that sv-bugpoint never stops on this example.
Did you try using sv-bugpoint as suggested?
Sorry, stupid question. Am I to understand that -Wno-SOMEWARNING is just suppose to ignore this particular warning? That is there is no undercover operations under the hood? I am asking this question because the command which I am giving below works just fine:
verilator tech/slink_tech_lib.v app/slink_generic_tx_router.v app/slink_generic_fc_sm.v app/int_gpio/slink_int_gpio_top.v app/slink_generic_rx_router.v app/slink_generic_pstate_ctrl.v app/slink_generic_fc_replay.v app/amba/slink_apb_ini.v app/amba/slink_apb_tgt.v app/amba/slink_axi_ini.v app/amba/slink_axi_tgt.v app/amba/slink_axi_top.v bist/slink_bist_rx.v bist/slink_bist_tx.v bist/slink_bist.v bist/regs/slink_bist_regs_top.v gpio/slink_gpio_serdes.v stacks/slink_apb_axi_gpio_top.v stacks/slink_apb_gpio_top.v stacks/slink_apb_axi_regs_top.v serdes/slink_serdes_front_end.v slink_rx_align_deskew.v slink_prbs9.v slink_ltssm.v slink_ecc_syndrome.v slink_rx_deskew.v slink_sync_pulse.v slink_clk_control.v slink_attr_ctrl.v slink_ll_rx.v slink_tx_gearbox_128b13xb.v slink_rx_blockalign_128b13xb.v slink_crc_calc.v slink_ll_tx.v slink_ctrl_regs_top.v slink_attributes.v slink_ll_rx_pkt_filt.v slink.v -DSIMULATION=1 --binary -Wno-fatal -Wno-PINMISSING -Wno-WIDTHTRUNC -Wno-SELRANGE -Wno-WIDTHEXPAND -Wno-IMPLICIT -Wno-UNOPTFLAT -Wno-SYMRSVDWORD --top-module slink
...
...
- V e r i l a t i o n R e p o r t: Verilator 5.036 2025-04-27 rev v5.036
- Verilator: Built from 11.427 MB sources in 55 modules, into 2.311 MB in 10 C++ files needing 0.001 MB
- Verilator: Walltime 10.477 s (elab=0.052, cvt=0.226, bld=9.990); cpu 0.460 s on 1 threads; alloced 51.168 MB
Turning off a warning has the effects described in the documentation for that warning. It may have no effect, or might (e.g. UNSUPPORTED) give surprising results. Many will result in some additional code to correct the issue, so it's quite possible other bugs will disappear (or appear).
Turning off a warning has the effects described in the documentation for that warning. It may have no effect, or might (e.g. UNSUPPORTED) give surprising results. Many will result in some additional code to correct the issue, so it's quite possible other bugs will disappear (or appear).
Yes, for all warning suppression that I've used there is Ignoring this warning will only suppress the lint check; it will simulate correctly. source. It does not mention that it has some side effects when turning off. Or am I missing info from somewhere else?
P.S. Ok, there is another one: Ignoring this warning will only slow simulations; it will simulate correctly. It may, however, cause longer simulation runtimes due to reduced optimizations. Is that it?
P.P.S. It turns out that the problem lies with top module auto-detection: when I add --top-module slink everything works fine.
It is supposed to simulate correctly, that doesn't mean there isn't the possibility of a bug exposed or suppressed by the disable. A bug can of course break any statement in the docs ;)
It is supposed to simulate correctly, that doesn't mean there isn't the possibility of a bug exposed or suppressed by the disable. A bug can of course break any statement in the docs ;)
I see, thank you!
Turning off a warning has the effects described in the documentation for that warning. It may have no effect, or might (e.g. UNSUPPORTED) give surprising results. Many will result in some additional code to correct the issue, so it's quite possible other bugs will disappear (or appear).
Yes, for all warning suppression that I've used there is
Ignoring this warning will only suppress the lint check; it will simulate correctly.source. It does not mention that it has some side effects when turning off. Or am I missing info from somewhere else? P.S. Ok, there is another one:Ignoring this warning will only slow simulations; it will simulate correctly. It may, however, cause longer simulation runtimes due to reduced optimizations.Is that it? P.P.S. It turns out that the problem lies with top module auto-detection: when I add--top-module slinkeverything works fine.
Just to clarify: there are some cases, when top module auto detection fails and apparently, this is the case?
I's certainly possible changing the hierarchy in any way can change hitting a later bug. Hence why sv-bugpoint to do the search is useful, it will figure that out.
I's certainly possible changing the hierarchy in any way can change hitting a later bug. Hence why sv-bugpoint to do the search is useful, it will figure that out.
Sorry, I'm little confused now. Is top module auto detection intended to behave in such way (sometimes) or not? I mean is what I've encountered a feature or a bug?
I don't understand what you are referring to about top. This issue is about a REPLICATE error.
I don't understand what you are referring to about top. This issue is about a REPLICATE error.
Forget about it. I have located the cause of this problem. Consider the following code:
module slink_ll_tx #(
parameter NUM_LANES = 1,
parameter DATA_WIDTH = 8
);
reg [(NUM_LANES*DATA_WIDTH)-1:0] link_data_reg, link_data_reg_in;
always @(*) begin
if(NUM_LANES >= 2) begin
if(DATA_WIDTH==8) begin
link_data_reg_in = {{((NUM_LANES-2)*DATA_WIDTH){1'b0}}, link_data_reg[15:8]};
end
end
end
endmodule
It produces the exact same error:
%Error: Internal Error: test.sv:10:41: ../V3Width.cpp:6901: Under node REPLICATE has no expected width?? Missing Visitor func?
: ... note: In instance 'slink_ll_tx'
10 | link_data_reg_in = {{((NUM_LANES-2)*DATA_WIDTH){1'b0}}, link_data_reg[15:8]};
| ^
... See the manual at https://verilator.org/verilator_doc.html?v=5.036 for more assistance.
I have a question. Why verilator produces the error? As far as I understand, there is no way that this instruction will be executed. verilator should go there only if NUM_LANES >= 2.
?
That's about the same as:
always @(*) begin
if(0) begin
if(DATA_WIDTH==8) begin
link_data_reg_in = {{((NUM_LANES-2)*DATA_WIDTH){1'b0}}, link_data_reg[15:8]};
The code inside a constant if still needs to be correct in every respect. An interpreted simulator won't even know the if is constant until runtime.
If you want the if to be removed at elaboration time you need to use a generate block (or implied one)
generate // Keyword is optional in SystemVerilog
if(NUM_LANES>=2) begin
always @(*) begin
if(DATA_WIDTH==8) begin
link_data_reg_in = {{((NUM_LANES-2)*DATA_WIDTH){1'b0}}, link_data_reg[15:8]};
Anyhow there shouldn't be an internal error on this, but some other error.
That's about the same as:
always @(*) begin if(0) begin if(DATA_WIDTH==8) begin link_data_reg_in = {{((NUM_LANES-2)*DATA_WIDTH){1'b0}}, link_data_reg[15:8]};The code inside a constant
ifstill needs to be correct in every respect. An interpreted simulator won't even know theifis constant until runtime.If you want the
ifto be removed at elaboration time you need to use a generate block (or implied one)generate // Keyword is optional in SystemVerilog if(NUM_LANES>=2) begin always @(*) begin if(DATA_WIDTH==8) begin link_data_reg_in = {{((NUM_LANES-2)*DATA_WIDTH){1'b0}}, link_data_reg[15:8]};Anyhow there shouldn't be an internal error on this, but some other error.
Ok, I see. Thank you!