[Cryptech Tech] Some info on the Verilog HW description language

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

We just had a discussion on what Verilog is and how to understand HW
described in Verilog. Here are a few links that provides some
introduction, a reference guide and some papers that I think presents
good design and coding styles.

The Verilog tutorial - Ugly fonts and layout, but does a pretty good at
introducing Verilog:
http://www.asic-world.com/verilog/veritut.html

The Verilog 2001 Quick Reference Guide. I use this myself pretty often.
http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf

Papers by Stuart Sutherland and Cliff Cummings. These two gentlemen are
involved in the standards development and trains ASIC- and
FPGA-developers on how to do good HW design. Their websites contains
papers and presentations related to Verilog and SystemVerilog as well as
coding styles, pitfalls. Well worth reading through some of them:

http://www.sutherland-hdl.com/papers.php
http://www.sunburst-design.com/papers/

Some note on the language I use and the style I use.

I use Verilog-2001, which is a fairly old version of the Verilog
standard. We could move to something like Verilog-2005 or SystemVerilog.
But there might be tools (for example the Icarus Verilog simulator) that
does not provide support. V2001 provides enough good constructs to make
fairly code efficient implementations.

When I write Verilog I try to write code that will be possible to
implement in any FPGA vendors chip or as an ASIC. This means not
explicitly instantiating real hardware blocks (for example a FIFO Randy)
that is available in a given technology.

Also I always place all registers in a common process (reg_update) which
means that the rest of the code in a given file *should* be
combinational logic and wires. If a latch or register is inferred
somewhere else there is something wrong in the code. This makes that
problem easier to spot.

I try to structure my code in similar ways all the time. Symbolic
defines first. All registers including wires needded to control them
second. Then all other explicit wires. Then ports connectivity followed
by any instantiations of sub modules.

After this the actual code starts. First registers update with reset
condition as well as normal updates. Then the data paths. Any utility
logic, for example logic to implement a counter (or a FIFO pointer)
comes next.

Finally, at the end of a module there is the control FSM logic. This is
what reacts to input signals, asserts internal control signals and look
at internal states as needed to make the complete module provide the
functionality.

As an example of this structure, look at sha256_core.v:
http://cryptech.is/browser/core/sha256/src/rtl/sha256_core.v

This module instantiates two submodules - the K rom memory k_constants
and working memory w_mem (which includes logic to to the actual word
scheduling.)

The main datapath responsible for the logic is in the state_logic
process. Since the t1 and t2 values are so complex, they live in
separate process just above this process.

The round counter (called t_ctr in order to follow the NIST FIPS 180-4
nomenclature) comes after the data path processes. And then we have the
sha256_ctrl_fsm process. As one can see it waits in IDLE state until we
get an external init or next signal. When that happens several things
happen due to control signals are asserted. One is the t_ctr_rst signal.

That is basically it.

Some things to know is that all blocks (processes and assignments) runs
concurrently (to simulate reality).

For combinational processes (sarts with always @*) the code inside is
sequential just like a normal SW program. This means that operand
dependencies creates a chain of logic from the top of the process to the
end of it.

In reg_update this is not the case. There we use the '<=' non-blocing
assignment operator. And all assigments done take effect at the same
time. This is in line with how we expect a register (D flip flop) should
behave like. All registers sample their inputs in parallel and thei
outputs is updated at the same time.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJTX7QMAAoJEF3cfFQkIuyN9DYQAIQx7s9GZUsUROIZ8zSM6kMs
FBUqEmBqc1Eu46Pc+j7AahB68hPkCvcMALiw3u4mtZPAyt64gjCoWB4w20i4C1E+
zqTCSLoMc+lqh/Qc747AJB+05NKakHS5Dt3cM+A2HF0lC+1c01ZzomUyri2TBARM
JSGrPVNX7CyqVA/FUJ2dR9GvlsH4TUMpmh5bS7nltaWED+apEbTcwPDXNvZ5140O
nrgIdhDjSNUygiSYzPZDAQBfbjCat96VXS7AfohT6I4nzIcmnjmLtV1rD1MFfgVz
a+DPMfhS95uMj1wUtMgwBpzrCuZ5emhJqG9ddzJ3WSLWAl+ChAUxPq067CSEu6cz
NgaBvn5lxO33xhfNwaFT3/kDUkE8xhM6p1MslRiMr4iVcLkTPIN/sgTSlzw3hJwR
rYeC7nwsuJf4feobWZ8U4xk4ByIAmzygu/hEIehHu1i0mZKRfoG8PQDkTZwxK/4k
ibvIyqIn5rsEMpBaJNCRIZgowERABLA+n1ma9WGgNeDlthS30OPF+CoQbBE+sLzV
aBugxWt3JqQmKaUjOFU9KP4gx770kd7W8Zb1StyNiyH6gznSxufdaTb3XirvlsBY
AbQKKkW19R7JHPpm0zrciAcXSX/R6OQK2zq7gqFW58JanB2eVmChtazKFywsoNhN
vK5cmGI0GEiWoj8JWJcT
=Vb6f
-----END PGP SIGNATURE-----