Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: add a sensible default configuration to the README #282

Open
DeflateAwning opened this issue Mar 23, 2024 · 5 comments
Open

Request: add a sensible default configuration to the README #282

DeflateAwning opened this issue Mar 23, 2024 · 5 comments

Comments

@DeflateAwning
Copy link

I'm at a loss of how to get started using this tool. There are so many conflicting linting rules that I don't know where to go.

Is there a sensible default configuration that can be shared and linked in the README? It'd make this tool so much more helpful.

@ronitnallagatla
Copy link
Contributor

ronitnallagatla commented Mar 29, 2024

You can refer to the Rulesets section of the manual that describe various sets of pre-configured rules. You could get started by picking a ruleset and then modifying it to fit your needs.

The configuration section also describes how to setup the config file.

Hope that helps!

@DeflateAwning
Copy link
Author

Why isn't there a sensible default set? The idea that the default is completely unusable seems insane to me

@DaveMcEwan
Copy link
Contributor

What's sensible for one use-case, e.g. a synthesizable design, isn't quite the same for another use-case, e.g. verification. There are rulesets precisely because there isn't a one-size-fits-all solution. As rotitnallagatla suggested, you can read the manual.

@DeflateAwning
Copy link
Author

I understand the desire to customize.

In regular languages (e.g., Rust, Python, etc.), embedded development vs. web development generally have different goals, difference frameworks, different editor configurations, etc.; but that doesn't stop the makers of Pyright and rust-analyzer from setting sensible defaults that allow users to get a feel for the tools before having to read the manual just to try writing a few modules of Verilog.

Why is the hardware design space so opposed to anything being usable-by-default? I'm not asking for perfect; I'm just asking for it to demo anything useful at all.

Anyway, I've read the manual. I'm a beginner playing with a toy FPGA. What configuration do you suggest I go with?

@DaveMcEwan
Copy link
Contributor

SystemVerilog is different from Rust and Python which are both software-only languages. SystemVerilog is used for writing software (that's typically for verification by simulation), and specifying hardware circuits (cosmetically similar but practically quite different), and formal specification (different from both). In software, you can get away with learning by just hacking around, but in hardware that's a long and difficult learning path. You'll have a lot less frustration if you begin by reading the LRM and really understand the programming model (IEEE 1800-2017 is the newest standard). Certainly, the first 6 chapters (about 50 pages) are well-written easy reading that will give you most of the fundamental background.

For beginning with an FPGA, I'd recommend the ruleset called designintent. That means running commands with svlint-designintent instead of svlint. That ruleset is specifically designed to help beginners avoid the common pitfalls - if your code passes and does mostly what you want, then there's a very low chance of unpleasant surprises and a very high chance you really understand your FPGA configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants