Thought Leadership

SystemVerilog Coding Guidelines

September 11, 2009 • 2 MIN READ
By Dave Rich

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

Dave Rich

Dave Rich is Verification Technologist at Mentor Graphics and is one of the authors of Mentor’s Advanced Verification Methodology cookbook. He began his career as a design and verification engineer in 1981 at Data General. In 1987, he joined Gateway Design Automation as one of the first application engineers to support Verilog-XL. At Gateway, he helped design many of the early features of the Verilog Hardware Description Language (HDL), and after Cadence acquired Gateway, helped prepare the Language Reference Manual (LRM) that would eventually be donated to the newly formed Open Verilog International. In 1995, he joined another Verilog simulation company, Frontline Design Automation as an AE manager and later as a Product Manager after it was acquired by Avant!. In 1998, he joined Ambit Design and worked as a consulting engineer for both synthesis and simulation products after it was acquired by Cadence. In 2000, he joined Co-Design Automation as Director of Application Engineering where the Superlog HDL was being developed that eventually became the basis of the Accellera SystemVerilog 3.0 standard. Co-Design Automation was acquired by Synopsys in 2002. Dave began work on numerous technical committees within Accellera and later the IEEE P1800 working group, which he continues today.

More from this author

What to read next:

Comments

2 thoughts about “SystemVerilog Coding Guidelines”

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/verificationhorizons/2009/09/11/sv-coding-guidelines/