iverilog linting about vscode-verilog-hdl-support

[nahuel-cci]

As stated before adding -y flag solves the issue for .v files.
For SystemVerilog the flag turns into -Y .sv -y <path to source files>

[alexwhittemore]

The problem description here is a little sparse so I'm not sure if perhaps my issue is the same, or more likely that I just don't understand Icarus well:

On macOS, I installed Icarus with brew install icarus-verilog and verified that it's installed and works correctly. I enabled icarus as my executable of choice for linting, and linting does indeed appear to work. However, every module fails with [iverilog] Unknown module type [iverilog]. Even when I add the `include "gpio_if.v", the module declarations still have squiggles with the same message, but this time INSIDE the declaration. In fact, now that I've "include"d the three modules I instantiate in this example top.v, even some of my reg declarations now have the squiggles, same message. So it seems like maybe the squiggles are getting put in the wrong places?

Digging in a little further and just running "iverilog top.v," I learn a bit more. For instance, without includes:

› iverilog top.v
top.v:41: error: Unknown module type: misc
top.v:47: error: Unknown module type: gpio_i2c
top.v:52: error: Unknown module type: gpio_if

WITH includes,

› iverilog top.v
./misc.v:78: error: Unknown module type: DCM_SP
./misc.v:105: error: Unknown module type: BUFG
./misc.v:122: error: Unknown module type: PLL_BASE
./misc.v:138: error: Unknown module type: BUFG
./misc.v:139: error: Unknown module type: BUFG

What I'm getting from this is that the errors I'm seeing are because the modules I instantiate in top.v THEMSELVES need `include "<>.v"s for any of their own instantiated modules, lest my top.v fail. Is that correct?

TL;DR:
?1) Am I responsible for adding `includes all the way down the dependency tree of my project, even though a bunch of the modules in question might be Xilinx IP, for instance, that I never myself touch? Is there a sort of autodiscovery setting or something that I'm missing?
?2) Is it possible (and should I create a separate issue?) to make the linter errors in this regard a little more directive? If I'm getting top.v:41: error: Unknown module type: misc in the command line output, surely the VSCode message [iverilog] Unknown module type [iverilog] could be improved to include that information about WHICH module is unknown, right? That would at least more promptly direct users to these kinds of nested errors.

[anontruck]

@Raamakrishnan
Sorry for dropping off... to follow up yes I was able to get it working! I was using the library include flag in my linting arguments before, but was defining the path incorrectly. All good now, thanks!

[Raamakrishnan]

Hey @ngoclinhle
The iverilog error "Unknown module type" is thrown when you don't give iverilog all the files that contain your modules. Can you check how you have given the path in `includes and how verilog.linting.iverilog.runAtFileLocation is configured? Have a look at the README for more info on this.

Can you try to recreate this scenario in a small test project/folder and attach it here?

[aviadb]

Since last update, the linting is messed up.
Trying to lint closed files, non verilog files and many more bugs.
which pollute the "problems" tab

[Raamakrishnan]

non verilog files

this has been fixed in #53 . It will be out soon

Trying to lint closed files

I think you are talking about the bug where the problems reported by "Rerun linter" command is not being removed on closing the file, then it is yet to be fixed

many more bugs

Can you please file an issue?

[anontruck]

Just to add, I'm seeing the same issues as @alexwhittemore, only I'm using Windows. I can build successfully using the -y flag to include my library directories, but including them to my linter arguments doesn't make the issue go away. Using includes doesn't help either. I'm sure I don't really understand Icarus either though.

I recently discovered that the most current windows build (available here) is slightly dated and does not reflect the latest iverilog snapshot. There are at least a few compiler flags this version doesn't include, so perhaps that might be part of the problem? I doubt this is the same issue on macOS though.

[Raamakrishnan]

@alexwhittemore,
As @anontruck was saying, you can use the -y flag of iverilog to tell the directory where all your files are present. From the iverilog man page:

-y
Append the directory to the library module search path. When the compiler finds an undefined module, it looks in these directories for files with the right name

By "right name" they mean, the name of the file should be <module name>.v. Make sure all files are named like that (it is usually done that way, but just in case) and include the argument -y <path to source files>/. Your path can be absolute or relative to your workspace root

1. Adding `include is certainly one way of doing it. I understand the difficulty of doing it when it comes to IPs. Try the -y argument and let me know.
2. Yes that's a bug. While splitting the error message by ":", the last part is being left out. Can you make a separate bug so that it will be fixed properly? Thanks

@anontruck,
Thank you for mentioning about the -y flag. I completely forgot about that. I tried adding that to the linter arguments and it works fine for me.

1. The linter is executed from your workspace root (unless you have set verilog.linting.iverilog.runAtFileLocation to be true). So, if you are using relative paths in -y flag or `include, it should be relative to your workspace root. Can you check those?
2. If your path contains spaces, they need to be enclosed within double quotes while passing it through -y flag in linter arguments. Can you check this too?

If none of the above solves your problem, try to replicate it in a small workspace and attach it here. So, I can take a look. Thanks.

[shyeonn]

In vscode,

but in terminal, i can compile this tb.
what wrong in vscode?

[canseyman]

I have the same issue. If I include package, some modules are not recognized. Otherwise, I can't use the package.

[cyjun99]

use like : iverilog -y .\ abc.v -o wave
"-y ." will include all used files in the abc.v path

[M6STAR]

My problem has not been solved, and the use of y parameter still cannot be solved, which is very uncomfortable.
The first figure shows that the module is missing,So I decided to use the include directive, but the terminal representation still couldn't find the file(Look at the second picture)


Next time I'll try relative paths,The results are still problematic,As shown in the third picture

I want to use y parameter, maybe I don't use it correctly, It still shows that the module cannot be found，please teach

[YOlOKY]

I have the same problem with @M6STAR

[iSlans]

@M6STAR
if i'm not wrong, your counter module is defined in test.v... but the -y ./ is looking for a counter.v file