chipsalliance / verible

Verible is a suite of SystemVerilog developer tools, including a parser, style-linter, formatter and language server
https://chipsalliance.github.io/verible/
Other
1.33k stars 201 forks source link

Developing custom verible linting rules for my organization? #1999

Open Lightborne opened 1 year ago

Lightborne commented 1 year ago

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

burnfield commented 4 months ago

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.

hzeller commented 4 months ago

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.

burnfield commented 4 months ago

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:

  1. enable
  2. 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.

hzeller commented 4 months ago

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).