search

imc-trading / svlangserver

MIT License
95 stars 13 forks source link

Design hierarchy viewer #16

Closed jagjordi closed 2 years ago

jagjordi commented 2 years ago

First of all thank you for your great work, this LSP is truly awesome. I was wondering if it would be possible to have a design hieararchy viewer, maybe working with treemacs lsp symbol viewer? I am thinking something similar to what vhdl-mode does with speedbar: image Would it be possible to achieve something similar? Maybe it is already possible and its just that I don't know how to configure it. Thank you all.

kkanhere commented 2 years ago

Unfortunately no such feature exists as of now. But it is quite doable. There could be two modes of operation - one using the index, and another using verilator that can generate data for this tree. If you are interested in taking this up, please let me know and I might be able to provide you with pointers. Otherwise I will add this to the features TODO list.

Thanks

jagjordi commented 2 years ago

I would certainly be interested in taking that up, please do provide me with some pointers as I don't have much experience in LSP (only as a user). What you suggest of using verilator is a good idea IMO since verilator is already used for other aspects in the lsp such as the linting. There is also a tool that specifically does this, maybe it would be also interesting to integrate that for users that don't want (or can't) install verilator.

kkanhere commented 2 years ago

Glad to hear that you are interested in taking this up.

At this point I won't recommend adding another tool dependency. Especially because the existing indexing logic should have all the information about the hierarchy. Verilator's advantage would be to have a view of more optimized hierarchy (it can optimize out unused generate blocks etc.)

I would recommend adding a command for this (reference: build_index command that svlangserver already supports). The command should accept two arguments - 1. Mode (optional) - choices: Internal/Verilator (default). 2. Top (optional. Should default to a module in current file).

In terms of implementation, the Verilator one should be straightforward. It should pretty much run something like what the linting logic does right now, except it should use a '--xml' option. And then parse the output xml for the tag. That should give the complete hierarchy. The internal one will need to walk the index to find instances in the given top recursively.