ROHD linter
- Dominant language
- Dart
- Stars
- 489
- Forks
- 88
- Avg merge
- 3d 23h
- Merged PRs (30d)
- 10
Description
### Motivation
It would be nice to have some of the best practices for ROHD code to be codified in a linter.
For example, we get in trouble exposing `Logic` from within a module, possibly transitively in grand-children.
Bad habits like not using getters or not using a protected annotation can lead to other connectivity problems.
Dart enforces a lot of good practices, but if we had a ROHD linter, we would have a place to add our own rules for good hardware generation practices.
### Desired solution
The biggest help would be a static check for obvious hiearchical connection issues rather than waiting until elaboration.
### Alternatives considered
We have a small fix for some basic hieararchy check to help the current runtime check more specifically localize connection problems, but it is still an elaboration time check and so only certain configurations will find the bug in the component (which is exposing a `Logic` not through a port. A static check would be far better.
### Additional details
_No response_
Contributor guide
Research direction
No files or tests are identified. Start by tracing the existing elaboration-time hierarchy check and the runtime handling of components that expose Logic rather than ports. Done means defining and implementing a static ROHD linter check for obvious hierarchical connection issues, with a clear path for adding further hardware-generation rules.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dart
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100