[Librecores Discussion] [GSoC2017] What are your Verilog coding recommendations?

Olof Kindgren olof.kindgren at gmail.com
Tue May 30 22:45:49 CEST 2017

On Tue, May 30, 2017 at 8:33 PM, Amitosh Swain Mahapatra <
amitosh.swain at gmail.com> wrote:

> Hi,
> On Tue, May 30, 2017 at 6:52 PM, Stefan Wallentowitz
> <stefan at wallentowitz.de> wrote:
> > Just out of curiosity, is there anyone aware of a generic
> > approach/framework to verify coding guidelines? I know many software
> > projects have such things, are they hacked together or something
> > established and reusable?
> Absolutely. There are a few state-of-the art frameworks.
> Verifying code guidelines require parsing the source files as per a
> grammar. We have ANTLR[1], and flex/bison (lex and yacc) to generate
> the parser from a grammar. For a linter, the grammar is just the
> stricter form of the language grammar with additional restrictions.
> But designing a proper grammar is a challenging task indeed.
> > Also giving guidance and not only
> > matched/error would be interesting.
> For guidance, one could match the rule violation with a database
> consisting of help texts for rule violations and show them.
> ANTLR used to bundle a Verilog grammar, but I cannot find it at the moment.
> [1]:http://www.antlr.org/
> _______________________________________________
> Discussion mailing list
> Discussion at lists.librecores.org
> https://lists.librecores.org/listinfo/discussion

I agree with the recommendations of using a linter. verilator is quite
useful for this. But I have also recommendations more on an architectural
level. A good design is reusable and testable.

Make each module have a clear purpose. You don't need to split it up into
hundreds of small pieces, but make sure that each module perform a specific
task. This makes it easier to test that particular module, it can also
potentially be reused in other projects if the code solves a general

Use FuseSoC. This serves several purposes:
- You can easily try the code with multiple simulators to ensure that the
code is portable across different tools.
- It makes it easier for other people who wants to build or simulate your
- You get access to a lot of existing infrastructure, so that you don't
have to spend time recreating basic blocks like FIFOs or i2c/spi/uarts. In
turn, it makes it also easier for other people who want to build something
based on your code.
- You don't have to spend time on maintaining your own makefiles or build

As the main developer of FuseSoC, I'm of course biased here, but I'm happy
to help you set things up if you need any assistance.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/discussion/attachments/20170530/07b56d83/attachment.html>

More information about the Discussion mailing list