Closed kammoh closed 4 years ago
I think this is a Vivado bug. I have heard of similar issues previously. It seems the issue is that default_nettype none
is active from an earlier file.
The currently only known workaround is to set default_nettype wire
in the beginning of the file. But unfortunately this is a fragile solution since the bug might pop up somewhere else. The real solution would be to fix this is in Vivado but since it's a closed-source program the chances are slim that this will be fixed soon :)
Thanks @olofk for the quick reply! default_nettype none
IMO can be a good safeguard against some hard-to-find bugs, but if the assumption here is default_nettype wire
, can the directive be prepended to the file (and possibly set back to none at the end of the file)? Also similar issue exists in rtl/bscan_tap.sv
.
I'm happy to change that if it solves the problem. I'm not sure it will guarantee things to always work though. The option is likely set somewhere in one of the dependencies of SweRVolf and since it's sticky across files I'm still worried it might pop up elsewhere if Vivado decides to change the compile order. I have told Vivado though to not touch the compile order, but I'm not convinced it's following my orders
In rtl/bscan_tap.sv
at least, default_nettype none
directive exists and input
and output
ports do not have a net-type, so it seems Vivado is actually right here to error out.
I also just noticed that so bscan_tap.sv
is definitely my fault. I have fixed it to explicitly define the ports as wires. For the other file I found a post that claims logic is the datatype, not the nettype, and that the correct way is to write it as input wire logic
. That was new to me. For now I will just set and reset default_nettype before and after the module for swerv_wrapper.sv
Would you mind checking out the nettype branch that I just pushed and see if that solves your issue? In that case I will commit to master
I can confirm that the nettype branch solves the issue. Thanks Olof!
Thanks for reporting and helping out debugging
Hi @olofk , Just to report the issue.
When I am implementing the EL2 core on the Nexys A7 using ac793e1cf8ed120b76ea88a0559eb69c3e26231d, I observed some inconsistency in Vivado. The first three or four times the syntesis finishes without errors, but then It crashes with the errors mentioned above.
Vivado 2019.1 can't compile, but actually the code in
swerv_wrapper.sv
looks like correct SystemVerilog to me.
fusesoc/workspace/build/swervolf_0/nexys_a7-vivado/swervolf_0.runs/synth_1/runme.log
:ERROR: [Synth 8-6735] net type must be explicitly specified for 'clk' when default_nettype is none [/src/fusesoc/workspace/build/swervolf_0/src/swervolf_0/rtl/swerv_wrapper.sv:28] ERROR: [Synth 8-6735] net type must be explicitly specified for 'rst_l' when default_nettype is none [/src/fusesoc/workspace/build/swervolf_0/src/swervolf_0/rtl/swerv_wrapper.sv:29] ERROR: [Synth 8-6735] net type must be explicitly specified for 'rst_vec' when default_nettype is none [/src/fusesoc/workspace/build/swervolf_0/src/swervolf_0/rtl/swerv_wrapper.sv:30]
I was putting by hand in every error file with default_nettype xxx
at the beginning and end , but it appears more and more modules with errors. Most of these errors appear in the axi module (pulp).
I observed that some files in the SoC have only default_nettype none
at the beginning. So I put default_nettype wire
at the end of those files, and everything works well now.
Vivado 2019.1 can't compile, but actually the code in
swerv_wrapper.sv
looks like correct SystemVerilog to me.fusesoc/workspace/build/swervolf_0/nexys_a7-vivado/swervolf_0.runs/synth_1/runme.log
:swerv_wrapper.sv
: