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

Philipp Wagner lists at philipp-wagner.com
Tue May 30 14:44:34 CEST 2017


Hi,

On 05/30/2017 02:17 PM, Jeremy Bennett wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 30/05/17 11:32, Hatim Kanchwala wrote:
>> Hello,
>>
>> Could someone please recommend what coding style for Verilog I can
>> follow for my EDSAC FPGA Museum project? My experience is limited
>> to a sandbox environment of University courses and labs. I'd like
>> to know what standards do Verilog developers follow for real-world
>> projects?
>>
>> My mentor, Jeremy, suggested I write to the mailing list requesting
>> for your recommendations. Thank you for your time!
> 
> Hi all,
> 
> I'm a software engineer, so not well qualified to advise Hatim.
> 
> The best I can suggest is for layout use the emacs verilog-mode style
> (3 space indentation) and for implementation:
> - - use blocking assignment in combinatorial always blocks
> - - use non-blocking assignment in sequential always blocks
> - - register outputs, not inputs
> - - use Verilator's linting to get feedback.

Adding to that from the top of my head, based on the style we use for 
OpTiMSoC and Open SoC Debug (obviously, all FPGA designs):

- SystemVerilog is safe to use for many of the "simple" constructs -- 
save your files as *.sv.

- Using the "logic" data type avoids the strange naming around reg/wire 
present in earlier Verilog versions. It's also widely supported by tools.

- You can avoid duplicating a lot of code by defining the ports in "ANSI 
style", e.g.

module fifo #(
    parameter LEN = 256,
    localparam WIDTH = $clog2(LEN)
)(
    input logic clk,
    input logic rst,
    input logic [WIDTH-1:0] din,
    output logic [WIDTH-1:0] dout
);
// ...
endmodule

[Note: localparam in the module list is SV-2009. It's supported by 
recent Verilator and Vivado versions. If not supported by your tool, 
replace with parameter, which was in an earlier standard, and be careful 
not to assign it from outside.]


- Write FSMs with one combinatorial and one sequential block. Find an 
example here: 
https://github.com/opensocdebug/hardware/blob/master/modules/mam/common/osd_mam.sv 


- Use always_ff and always_comb.

- Avoid using defines, use parameter and localparam instead.

- The more fancy SystemVerilog features (modports, interfaces, etc.) are 
partially usable, but are still quite buggy or unsupported in some 
tools. Stay away from them unless you test with all supported tools.

- Avoid using .* wildcat signal assignments in module instantiations. 
Even though it's faster to write, it makes the code very hard to read 
and bugs easy to miss.



Of course, much of that is just based on experience of things which have 
turned to work out well, by no means this list is "the ultimate and only 
coding guideline". But maybe a good starting point to collect more 
widely accepted ideas in the community and write them down somewhere. 
Too many people rely on outdated hearsay rules from obscure sites on the 
Internet; maybe there's value in creating a document with the 
suggestions in this thread.


Philipp



More information about the Discussion mailing list