An attempt to create versatile language server for hardware description. The project is currently in the design phase, any suggestions are very welcome.
- Orthogonality.
- Support for both VHDL and SystemVerilog.
- Support for libraries, which structure is defined in different ways (FuseSoc
.corefiles, TOML). - Speed/performance.
- Libraries cyclic dependency detection. Cyclic dependencies are bad, really bad. They introduce chaos. With cyclic dependencies it is also much harder to analyze libraries in parallel. Cyclic libraries dependencies must generate fatal error to enforce user to fix libraries design.
- Libraries dependency graph generation - graph generation is needed for parallel libraries analysis anyway.
- Caching of libraries analysis results and automatic changes detection.
- There must be only single global configuration file, and single configuration file per workspace.
- hdls must support working on multiple projects simultaneously. As libraries are shared between projects, spawning single hdls process per single project (editors session) is not optimal. Each editors session must have its own dedicated context within hdls. This further implies, that communication via standard input/output is bad choice.
- What if 2 projects need different versions of the same library?
Should hdls handle this, or should it be left to be handled by the user?
I'm slightly biased to left it to be handled by the user.
For example, in the project
hdls.tomluser could provide alternative path for some library. It would be users liability to put it somewhere in the filesystem and manage its version. - Should there be only single hdls running, and handling all the clients, or should each client spawn its own hdls? By default, the LSP assumes that the server is started and closed by the client. Hence, the lifetime of a language server is fully determined by its user.
Go. Why? Orthogonal, efficient, simple, stable, oriented on concurrency.
GHDL coupled via shared library. Why? Nothing even close to what GHDL offers, plus it has been actively maintained for few years.
I don't know, I have no experience.
YAML or TOML - to be decided (slightly biased towards TOML, simpler, easier to read). JSON is too verbose, does not allow comments.
Before any target work gets started some prototypes are needed. It is worth to remind what prototype is. Prototype is temporary, disposable code. Its main purpose is to gain knowledge and answer questions. If you want to reuse your prototype code within the final implementation, then it is not a prototype! This is explained in a wonderful way in the The Pragmatic Programmer book. Independent prototypes answering following questions are needed:
- How to cache GHDL analysis results?
- Does GHDL even allow to parse independent files in parallel?
- What is the best/fastest way to detect changes of files within libraries (not workspaces).
Should libraries files be loaded only on start, or periodically during the work?
Maybe
SIGUSR*should enforce libraries reload? Neiter on start, nor periodically. Files will be watched for notifications fsnotify or watcher. - How long does it take to calculate average HDL file hash?
Results:
Average results for Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 121 files icnluded from UVVM and OSVVM. GOMAXPROCS = 12.
| Algorithm | Average time per file [us] |
|---|---|
| CRC-32 IEEE Poly | 2.98 |
| CRC-64 ISO Poly | 5.05 |
| CRC-64 ECMA Poly | 5.72 |
| SHA1 | 3.78 |
| SHA256 | 7.22 |
| MD5 | 4.69 |
All the results are on a negligible level. What is interesting, when GOMAXPROCS = 1, the results are better. Probably related with kernel handling multiple files open/close simultaneously.
Directions of arrows show the information flow.
