Straight-to-the-point website built with AsciiDoc
When designing in HDL (Verilog, VHDL, etc.) you must remember you are designing a circuit with a text editor. You are not programming. However, there are similarities.
Since you are creating the design using text as you often do in programming, you not only need to know the syntax of the language you are designing in, you should also follow some sort of style guide.
If you compare text design to writing a memo, think of the syntax like spelling. The compiler or syntax checker will find errors like the spell checker does.
Following a particular style (guide) is similar to using good consistent grammar. Style helps you and others understand what your design is supposed to do. A good style also helps reduce design errors that would get by the compiler. Have you ever tried to read something that is written with poor grammar? It is difficult to follow and prone to misunderstandings.
When I take on a assignment involving HDL as a consultant, I always ask the customer they have a preferred style guide — some do, some don’t. Some only provide minimal guidance, often to work with their revision-control system. Where guidance is lacking, I fill it in with guidance from the following references. If the customer is receptive to updating their style guide, I make suggestions. If they are not receptive, follow this suggestion — "Don’t try to teach a pig to sing, you waste your time and annoy the pig." Just let it go and do the job you were hired for. I’m not saying my customers are pigs. The contrary is true. I just like the visual that comes to mind with that saying.
I don’t know how I originally ended up with this guide from Cisco Systems. I most recently found a copy on Linkedin’s SlideShare website. This guide covers how to format your Verilog source. It covers alignment, white space, naming conventions, and module sections. I like that it provides examples that contrasts correct and incorrect methods to interpret the guidelines. I also like this one because it is short enough to quickly read. It is a good document share with someone that you think might be open to considering a style guide.
This style guide focuses more on Verilog-specific techniques to use and not use. It contains some guidance on naming. However, the majority of the guidance is meant to prevent you from writing unsynthesizable code and code that is difficult to reuse.
The following reference are not really style guides. However, they discuss design techniques and patterns that help create better quality designs.
Cliff has lots of great papers on the subject of RTL design. I suggest browsing his website now and then to further your knowledge of HDL deign.
Here is one paper that I refer back to every time I work on a design that has signals that cross from one clock domain to another.
A wise, experienced, and fellow UW graduate pointed me to the following reference for understanding and setup of timing constants. For timing within an FPGA, most design tools take care of the timing constraints. Signals external to the FPGA are another matter. This document describes various types of clock structures and how to define their constraints when compiling a design. It is Intel-Quartus centric. However, the same lessons apply to other design tools.