SystemVerilog Coding Guidelines

I have lots of blog entries about 95% ready to publish. This entry is from an e-mail I wrote a few months ago when somebody asked about SystemVerilog coding guidelines. I thought it would make a good article. It’s been sitting as a draft because I always have trouble finding the right title or opening words to catch people’s attention. I couldn’t come up with anything better, so here it is: SystemVerilog Coding Guidelines

My official position about this is that you pick a style and stick to it.

Which style you pick is far less important than developing the required culture that will follow it. People can spend hours arguing over the merits of camelCaps versus under_score, but once the decision is made, people on the project need to document it, adhere to it, and police it. Otherwise you’re just wasting everyone’s time.

Why are coding guidelines so important? So someone else can read your code, or maybe you can read your own code six months after you wrote it. Good comments and documentation are an import part, but you still need to be able to read the code.

This concept of reading someone else’s code without understanding the underlying conventions reminds me of the classic short article “Meihem In Ce Klasrum” by Dolton Edwards. The article was written as a satirical response to George Bernhard Shaw’s final wishes to simplify the English language. See how easy the last paragraph is to read once you understand the new writing conventions. Reading your code should be just like that (although not as cryptic).

My advice would be to pick a style from industry and adapt it to fit SystemVerilog. For example, from Google: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml or from the Free Software Foundation: http://www.gnu.org/prep/standards/

All of these rules for naming conventions, indentation, and file organization still apply to SystemVerilog. Additional rules would be for unsupported constructs, which should be in the release notes for the tool(s) you are using. Finally, there are a few constructs to avoid, like program blocks and wildcard indexes for associative arrays, most of which might be worth hours of debate, each.

Dave Rich

Post Author

Posted September 11th, 2009, by

Post Tags

, ,

Post Comments

2 Comments

About Verification Horizons BLOG

This blog will provide an online forum to provide weekly updates on concepts, values, standards, methodologies and examples to assist with the understanding of what advanced functional verification technologies can do and how to most effectively apply them. We're looking forward to your comments and suggestions on the posts to make this a useful tool. Verification Horizons BLOG

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...

Comments

2 comments on this post | ↓ Add Your Own

Commented on May 16, 2013 at 12:59 pm
By Linc Jepson

Dave,
It’s almost 4 years after this post. As far as you know, what are the most popular systemverilog/uvm style guides out there? Are there any that are similar to the Google Style Guides?
Linc Jepson

By way of its many examples, the Mentor UVM Cookbook seems closest to being a style guide from what I find online, despite its focus on being a how-to guide.

Commented on May 16, 2013 at 1:16 pm
By Dave Rich

I know a few companies that have gone to the trouble of creating style guides, but have kept them internal. If you have one and read this, please do what you can to make it public.

We recently added a few coding guidelines to the cookbook
https://verificationacademy.com/cookbook/SV/Guidelines
https://verificationacademy.com/cookbook/UVM/Guidelines

Add Your Comment

Archives