Need help with sha256?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

184 Stars 66 Forks BSD 2-Clause "Simplified" License 292 Commits 2 Opened issues


Hardware implementation of the SHA-256 cryptographic hash function

Services available


Need anything else?

Contributors list

# 98,736
265 commits
# 52,485
10 commits
# 726,954
8 commits


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.


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.


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... get the upstream repo ~~~ fusesoc library add sha256 ~~~

To run lint ~~~ fusesoc run --target=lint secworks:crypto:sha256 ~~~

Run tbsha256 testbench ~~~ fusesoc run --target=tbsha256 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 ~~~

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: - sha256core.v - The core itself with wide interfaces. - sha256wmem.v - W message block memory and block expansion logic. - sha256k_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


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


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


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


  • Complete documentation.
  • Bug fixes for Testbench of AXI4 wrapped core
  • Add implementation results of the wrapped core on PYNQ-Z2

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.