vscode-verilog-hdl-support
vscode-verilog-hdl-support copied to clipboard
Linter: "Unsupported: Interfaced port on top level module"
Describe the bug Linter fails with this issue:
Unsupported: Interfaced port on top level module
This is in the definition of modules that use an interface type IO signal. I guess this is becuase it assumes the file being edited is the top level module in isolation to the true top level(s) in the rest of the project.
Perhaps add a means to tell the extension what files are really top level modules on a per workspace basis?
One proposal that takes into account a given workspace may have multiple tops, e.g. test harnesses, multiple implementations or multiple target devices.
Allow a tag file, e.g. .vscode-verilator-top
. This file contains the name of the top module(s) in that folder tree?
If that file were present, any V/SV source file not defining those modules would suppress that error.
Environment (please complete the following information):
- OS:: WSL/Ubuntu 23.04 on Windows 10 22H2 19045.3448
- VS Code version: 1.83.0
- Extension version 1.13.0
Steps to reproduce Steps to reproduce the behavior: Create two modules, one true top and the other that uses an interface definition to connect to signals in the true top. Instance the 2nd in the first.
Log
2023-10-11 12:03:03.792 [info] [VerilogHoverProvider] Hover requested
2023-10-11 12:03:03.792 [info] [VerilogHoverProvider] Hover object returned
2023-10-11 12:03:20.042 [info] [LintManager] [VerilatorLinter] [verilator] 1 errors/warnings returned
Expected behavior Always pass linting on code that has no known issues or reporting of those issues is muted.
Actual behavior Reports one error per interface line on every module that uses interfaces.
I added top level support on https://marketplace.visualstudio.com/items?itemName=AndrewNolte.vscode-system-verilog, but I need to test how Verilator works with this. It works great on slang, which tends to be faster to lint than verilator, and has fewer issues with packages.