`default_nettype none breaks vivado global synthesis

[baileyji]

`default_nettype none breaks vivado global synthesis

[ZipCPU]

Yes. I make default_nettype none my regular practice, and there are quite a few libraries/IP that don't like it.

Just as background, the Verilog default is a default_nettype of wire. When you use the default_nettype of wire, however, misspelled signals are automatically turned into wires with no errors--often with no warnings either. This can hide bugs, even bugs that I've been burned by in the past, so I generally leave the default_nettype at none as a means of catching these types of errors at synthesis time.

This causes problems for anyone who likes the default_nettype wire feature, and who likes to just automatically allow the tool to declare signals when/if it needs to. Shame on those folks. I'm not sure I'd want to use their logic anyway. More significantly, though, it causes problems for anyone who uses expressions such as "input signal_name;". This latter expression needs to be converted to "input wire signal_name;". It's annoying to do, but not all that hard if you are the author of the Verilog or SystemVerilog sources.

That's all great, fine, and dandy when you can adjust your code to match the default_nettype none requirements, but what if it's someone else's code that you don't want to mess with? What if it's the foundaries simulation files? What if it's computer generated files, and you didn't write the computer generator? In these cases, my solution has been to adjust the synthesis file order. Verilog synthesis is kind of strange in this regard: the synthesizer is supposed to treat all files as though they were concatenated together into one giant file. Therefore, if you can place the files with default_nettype of none at the end of your synthesis file list, you shouldn't have any problems. This has, to date, solved my problems with this issue for both Vivado and ASIC flows. (Yes, even Xilinx's MIG logic has problems, if I remember correctly.)

Can you try adjusting the Vivado synthesis/simulation file order to see if it fixes the issue for you?

Thanks,

Dan
P.S. Compounding the problem, in my case, is the fact that not all of the synthesizers I use treat the default_nettype statement the same way ...

[baileyji]

I'll give that a try when this run finishes where I copied what you had at the end of sifo.v and just set the default type back to wire. All you said make a lot of sense though I don't follow why simply bracketing all of your library code in default_nettype none default_nettype wire wouldn't allow the same thing and facilitate compatibility.

[ZipCPU]

I don't follow why ...

It's a tool issue and it's a maintenance issue. 1) One or more of the tools I use handle default_nettype in a non-standard way (by treating it on a file-by-file basis). This can get in the way. 2) As for maintenance, those last three lines constitute a piece of logic I don't use and can't really verify. They can also cause a design to fail, as described above, if I forget to specify a default nettype of none for said design.

If it would help, I can put those lines back in for you. I'm just of the opinion that all designs should have a default nettype of none, and bug reports should be issued for designs that can't handle it ... but I seem to be a majority in a population of one on that issue.

Dan

[baileyji]

I'm with you and I don't mind changing things in a fork for our project (I need to patch the TUSER input/output already for asix2mm). I was confused because of the inconsistencies in sifo.v (with its ifndef YOSYS... at the end of the file) and the lack thereof in axis2mm.v and skidbuffer.v.

[dpretet]

Hello folks,

my two cents about the issue, I bet it could be resolved by adding `resetall statement at the end of all files to avoid such issue. I use default_nettype none too in my files' header and always finish my files with resetall and I never experience such problems. Works with all commercial tools like Vivado, DC, Questa, ... as well with Verilator, Icarus or Yosys

Hope it could help :)

Damien

[ZipCPU]

Never heard of `resetall before. Looking over the Verilog 2005 spec, I found this line fascinating:

The recommended usage is to place `resetall at the beginning of each source text file, followed immediately by the directives desired in the file.

Had everyone else done that, we wouldn't be having this discussion ...

As I see things, there are three potential solutions to this issue.

1. Recommend file reordering so this isn't a problem. I haven't (yet) seen a problem where file reordering won't solve the issue. This is my preferred approach, given how valuable default_nettype none is.
2. I could put the default_nettype wire back at the end of the various files. I just have no use for this, and (new reason) no way of measuring what impact this is (or isn't) having for those using these modules.
3. I could also instruct individuals to change it on their own. This is not the preferred solution, though, since it creates a configuration nightmare for everyone else.

My preference is for option 1) above, but I'm willing to consider option 2) if option 1) doesn't work for some reason. My least preferred solution for all would be option 3).

Dan

[baileyji]

I'll try the reorder during next implementation. Being largely clueless about verilog even a simple footnote in the documentation for the library would have clued me in to look at compile order/resetall/default_nettype wire. Mentioning something to the effect of "This might bite you if using a block design with Vivado+HLS because xilinx doesn't follow conventions well" would have made me a happy camper (yes, I hear you about it being prophylactic for others bad practices!). Xilinx's warnings are so (un)helpful that I only was clued in on a lark from a mostly unrelated forum post in 2014 that taught me a little about verilog.

[ZipCPU]

A foot note is an easy answer. I could place it into the master README.md file, if you think you would've seen it there.

I would like to hear from you whether or not file reordering works for you, though.

Dan

[baileyji]

Reordering seems to cause issues:

[filemgmt 56-587] Failed to resolve reference. Nothing was found in the project to match the name axis2mm Try changing the compile order from manual to automatic.
[filemgmt 56-176] Module references are not supported in manual compile order mode and will be ignored.
[BD 41-1726] Unable to resolve module-source for block '/capture/axis2mm_1'.
Given inputs for module-source, Top-module name : axis2mm, Module Type : RTL.
Please review and update or add design-sources to this project to resolve this module-reference.

The intuitive GUI-based approach of reordering the files compile order didn't work. I'll need to read the UG on this feature, to see if there is a workaround, something akin the a function prototype in C

[ZipCPU]

@baileyji ,
You'll find the `default_nettype wire setting returned at the end of the AXI S2MM module now. This should resolve your issue.
Dan