verible
verible copied to clipboard
Developing custom verible linting rules for my organization?
I would like to be able to write rules for my organization that I do not intend to contribute back to the project for one reason or another. Is verible extendable/customizable in this way?
If so, is this an appropriate guide to follow if I want to develop rules for my own organization?
https://github.com/chipsalliance/verible/blob/master/doc/style_lint.md
I'm also interested in this, I've cases where a general rule would be unsuitable.
Is a plugin system similar to clang-tidy
and sv-lint
possible? see https://github.com/dalance/svlint-plugin-sample and https://github.com/coveooss/clang-tidy-plugin-examples.
Oops, sorry everyone, have not seen this comment - sometimes github messages go a little bit under. Thanks @burnfield to ping it.
Right now, we have not a plugin mechanism that would work over all platforms easily (e.g. via shared libraries). It would not be hard to add for, say Linux, but it would get tricky if it should work for other OSes. So for now, there is no plug-in system available (but I would also not be opposed to it. If I find time to implement :) ).
However, it is fairly simple to add new rules, so what I would suggest is to contribute directly to this project and add a new lint rule in verilog/analysis/checkers/
to add to the growing set of rules. What is useful for your organization is probably also similarly useful for others.
Even if it is something that only makes sense for some code-bases, we can have that lint rule by default disabled; then there is a concept of specifically enable/disable it for your compile, so you can build a version where this is by default enabled for your org.
The mentioned doc is a good start, yes. Also, just looking at the code of the other rules is probably useful.
Thanks for the answer!
A sort of half way approach could be a regex-solution similar to svlint
.
E.g. interface-name-style
could be split in to two flags:
- enable
- required name-ending (
_if
as default).
This would allow for some extra flexibility with naming-styles.
But as for now, I'll take a look into extending the current lint rule-set.
There are many older lint rules that have been written before there were configuration options. So if you see some that could benefit from making them configurable, please add them (in particular, there are a bunch that would benefit from regular expression handling for some of these).