Future plans of development
Raamakrishnan opened this issue · comments
We are at the verge of reaching 50,000 downloads in the marketplace. From this point, I feel it is good to have a structured development plan. The following are a few ideas that I have.
1. Support for more linters
- Verilator
- VCS
- NCsim
2. Merging System Verilog extensions
- Verilog and System Verilog are very closely related languages. The tools/linters used by Verilog can be used by System Verilog also, at the maximum by turning on a command line switch.
- Some good features like "Hover over declarations" have been added to mshr-h/vscode-systemverilog-support that this extension can benefit from.
- "Go To Symbol" like features can be found in eirikpre/VSCode-SystemVerilog
Since there is very little work being done in bringing HDL support to VS code, it is better to pool our resources and knowledge. What do you guys say?
(Update 2018-07-07)
Todo
System Verilog
- a new branch "sv" in mshr-h/verilog
- migrate syntax highlighting from mshr-h/sv
- migrate snippets
-
migrate "Hover variable declaration"(not migrating, creating new) - Parse Symbols using Ctags
- Document Outline
- Hover variable declaration
- Definition Provider
- Intellisense
- migrate "Module instantiation"
- migrate "Auto alignment"
- migrate other features
- Update iverilog linter to support SV
- Update xvlog linter to support SV
- Update modelsim linter to support SV
- Update Readme, Changelog and other documentation
- Merge to master and release
- Deprecate mshr-h/sv
Linters
- Verilator
- VCS
- NCsim
Readme
- Remove the list of snippets from Readme
- Table of settings with description and options
- Mention this issue in the Instructions for Contributors
- Section for Contributors and prior work
Thank you for your great ideas. Both will make HDL support on VSCode much richer.
I think 2 is much important.
I guess bringing features in mshr-h/vscode-systemverilog-support into this extension is a good way.
Step to merge these extension
- Support syntax highlighting for
.sv.SVfiles - Bring features in mshr-h/vscode-systemverilog-support to this extension
- Deprecate mshr-h/vscode-systemverilog-support
Any ideas or comments?
I think it would be wise to create a new branch for System Verilog and merge the new features into it. Once everything is done, it can be merged in to master and released. While new features are being ported, any other bugs/features can be added to master and released. I will create a checklist in my original post with all the things that needs to be done for this merging.
Maybe after we are finished with this, we would look into eirikpre/VSCode-SystemVerilog
3. Reorganise README
- I think it is not necessary to mention all the snippets provided.
- All the settings provided by the extension need to be tabulated properly.
- People willing to contribute should be asked to look at this issue page and plan accordingly.
- A section to mention the contributors and the resources on which this extension is based on (like previous sublime text language syntaxes, extensions etc.)
Ok.
Sounds pretty good.
I have updated my original comment with a Todo list. Will start working on it soon.
We will need the help of @HansLehnert also
Sure. Also as a future feature, it could be useful to use the "Views" feature of vscode to show the hierarchical organization of the modules.
@HansLehnert eirikpre/VSCode-SystemVerilog has Symbol indexing which we can use to implement this if eirikpre agrees to merge with us
@mshr-h I am done with syntax highlighting and snippets. Can you create a new branch for sv so that I can give a pull request against it?
Thanks.
I’ll do it within a few days.
@Raamakrishnan Just created branch.
https://github.com/mshr-h/vscode-verilog-hdl-support/tree/sv
I just finished porting "Hover" and started "Definition Provider" when I noticed most of the logic used is duplicated. Moreover, it just parses the document for the variable name without any regard for module or package. It works, but it is a crude implementation.
I feel like we should follow eirikpre/VSCode-SystemVerilog and build a symbol tree properly so that we can implement the other features like Hover and Definition Provider easily with that.
Would you like me to get in touch with eirikpre?
@Raamakrishnan Yes, thanks.
Its been 2 weeks since I emailed eirikpre. There has been no response so far. Meanwhile, I started working on a symbol provider from scratch. Some more work is yet to be done, but it has been good so far. Check it out at "sv-sym" branch of my fork of this repo (https://github.com/Raamakrishnan/vscode-verilog-hdl-support/tree/sv-sym).
It needs VS Code 1.25 to work because it uses the new outline tree view
(you can see the symbols on the bottom left in the Outline View)
Eirik replied saying he is not interested in joining us.
Regarding the symbol provider that I was working on, it is becoming unstable and very slow on real life verilog code. It is not possible to include all the possible ways to write something in verilog in a few regexes.
So, I feel the better way to proceed is to use the ctags file with the help of universal-ctags, parse the output and show it as symbols. Just like how the Python extension for VS code does it. What do you think about this?
@Raamakrishnan
I understand the problem.
The solution you are thinking sounds good to me if it supports Windows.
@mshr-h Yes it will work on Windows also. I will start working on it soon.
A must have feature(s) is the capabilities of verilog-mode to Emacs.
auto-inst and auto wire connections
i just put a pull request in with verilator support.
I have updated my original Todo list.
- Added new items for the Symbols parser using Ctags, hover provider, document outline and definition provider
- Removed the original migration plan for Hover provider. It is now implemented by the new symbol parser
- I think Intellisense can also be implemented with these symbols. Have to check them.
Is it worth considering having a comment tag at the start of the file to let you choose a different verilog linter? The reason I ask is because i find verilator the best for logic files but it doesnt do a great job of testbench files. I would be inclined to prefer iverilog for that.
Just an idea either way
I understand your usage but I am not sure if many people use it this way. We will keep this in record and maybe some day we will implement it.
A new extension for SystemVerilog with full support for AutoComplete, Symbols providers, definition provider and much more, all using ANTLR4 has been released recently Rockdoor/systemverilog.
I had tried using ANTLR4 before, but never got it to work with typescript. Rather, my knowledge with typescript is less. But that work looks solid. I hope we can get him to work with us.
Thanks!
Sounds good.
With that last PR for linting, I think everything is done. The "Auto alignment" seems very buggy for me. I will get to that later. As for the linters, those are commercial ones. So, if anyone is able to get their hands on them, maybe we can work on adding support for them.
If everyone is fine, @mshr-h can rebase it on master. Then I can add the Readme and Changelog.
Also, now might be a good time for you guys to try out these new features!
Thanks. I'll check it this weekend.
I've just mergen 'sv' to 'master'.
Thank you all for your support!
It will be the first our major release of v1.0.0.
That would be great to add some refacting feature like changing port of module and changing it else where and reanaming !
If possible to add Verilog-AMS support with .vams?
Can we add custom syntax highlighting for uvm_info, uvm_error, uvm_warning, etc.?