sha256
Implementation status
The core has been completed for a long time and been used in several designs in ASICs as well as in FPGAs. The core is considered mature and ready for use. Minor changes are non-functional cleanups of code.
Introduction
Hardware implementation of the SHA-256 cryptographic hash function with support for both SHA-256 and SHA-224. The implementation is written in Verilog 2001 compliant code. The implementation includes the main core as well as wrappers that provides interfaces for simple integration.
This is a low area implementation that iterates over the rounds but there is no sharing of operations such as adders.
The hardware implementation is complemented by a functional model written in Python.
Note that the core does NOT implement padding of final block. The caller is expected to handle padding.
Implementation details
The sha256 design is divided into the following sections.
- src/rtl - RTL source files
- src/tb - Testbenches for the RTL files
- src/model/python - Functional model written in python
- doc - documentation (currently not done.)
- toolruns - Where tools are supposed to be run. Includes a Makefile for building and simulating the design using Icarus Verilog. There are also targets for linting the core using Verilator.
The actual core consists of the following files:
- sha256_core.v - The core itself with wide interfaces.
- sha256_w_mem.v - W message block memory and block expansion logic.
- sha256_k_constants.v - K constants ROM memory.
The top level entity is called sha256_core. This entity has wide interfaces (512 bit block input, 256 bit digest). In order to make it usable you probably want to wrap the core with a bus interface.
The provided top level wrapper, sha256.v provides a simple 32-bit memory like interface. The core (sha256_core) will sample all data inputs when given the init or next signal. the wrapper contains additional data registers. This allows you to load a new block while the core is processing the previous block.
The core supports both sha224 and sha256 modes. The default mode is sha256. The mode bit is located in the ADDR_CTRL API register and this means that when writing to this register to start processing a block, care must be taken to set the mode bit to the intended mode. This means that old code that for example simply wrote 0x01 to initiate SHA256 processing will now initiate SHA224 processing. Writing 0x05 will now initiate SHA256 processing.
Regarding SHA224, it is up to the user to only read seven, not eight words from the digest registers. The core will update the LSW too.
Streaming interface
There is a streaming interface for the core contributed by Olof Kindgren.
- src/interfaces/stream/rtl - RTL source file for wrapped core
- src/interfaces/stream/tb - Testbench for the wrapped core
AXI4 interface
NOTE This interface is currently being developed. Expect bugs as this interface is still under development.
There is now an AXI4 interface for the core contributed by Sanjay A Menon. The interface wraps sha256_core, replacing sha256.v
The interface provides an AXI4-Lite slave interface with added hash complete interrupt signal. Chip select is implemented via axi_awprot signal.
- src/interfaces/axi4/rtl - RTL source file for wrapped core
- src/interfaces/axi4/tb - Testbench for the wrapped core
FuseSoC Integration
This core is supported by the FuseSoC core package manager and build system. Some quick FuseSoC instructions:
install FuseSoC
pip install fusesoc
Create and enter a new workspace
mkdir workspace && cd workspace
Register sha256 as a library in the workspace
fusesoc library add sha256 /path/to/sha256
...if repo is available locally or... ...to get the upstream repo
fusesoc library add sha256 https://github.com/secworks/sha256
To run lint
fusesoc run --target=lint secworks:crypto:sha256
Run tb_sha256 testbench
fusesoc run --target=tb_sha256 secworks:crypto:sha256
Run with modelsim instead of default tool (icarus)
fusesoc run --target=tb_sha256 --tool=modelsim secworks:crypto:sha256
List all targets
fusesoc core show secworks:crypto:sha256
ASIC-results
Implementation in 40 nm low power standard cell process.
- Area: 14200 um2
- Combinational cells: 2344.9230
- Non-combinational cells: 2902.4856
- Clock frequency: 250 MHz
Fpga-results
Altera Cyclone FPGAs
Implementation results using Altera Quartus-II 13.1.
Cyclone IV E
- EP4CE6F17C6
- 3882 LEs
- 1813 registers
- 74 MHz
- 66 cycles latency
Cyclone IV GX
- EP4CGX22CF19C6
- 3773 LEs
- 1813 registers
- 76 MHz
- 66 cycles latency
Cyclone V
- 5CGXFC7C7F23C8
- 1469 ALMs
- 1813 registers
- 79 MHz
- 66 cycles latency
Microchip
IGLOO2
- Tool: Libero v 12.4
- Device: M2GL090TS-1FG484I
- LUTs: 2811
- SLEs: 1900
- BRAMs: 0
- Fmax: 114 MHz
Xilinx FPGAs
Implementation results using ISE 14.7.
Spartan-6
- xc6slx45-3csg324
- 2012 LUTs
- 688 Slices
- 1929 regs
- 70 MHz
- 66 cycles latency
Artix-7
- xc7a200t-3fbg484
- 2471 LUTs
- 747 Slices
- 1930 regs
- 108 MHz
- 66 cycles latency
Implementation results using Vivado 2014.4.
Zynq-7030
- xc7z030fbg676-1
- 2308 LUTs
- 796 Slices
- 2116 regs
- 116 MHz
- 66 cycles latency
Implementation results using Vivado v.2019.2
Results kindly provided by Sanjay-A-Menon. Implemented design includes the AXI4 wrapper.
Zynq-7020
- Device: 7z020clg400-1
- Slice LUTs: 2555
- Slice regs: 2606
- Fmax: 78 MHz
- 66 cycles latency