[Cryptech-Commits] [staging/core/hash/sha1] 16/20: Updated the README to hopefully make it more readable.

git at cryptech.is git at cryptech.is
Tue Mar 17 13:14:22 UTC 2015


This is an automated email from the git hooks/post-receive script.

paul at psgd.org pushed a commit to branch master
in repository staging/core/hash/sha1.

commit fd6391cab1447fd5362071bb7321467b253d7e2c
Author: Joachim Strömbergson <joachim at secworks.se>
Date:   Fri Nov 7 15:03:40 2014 +0100

    Updated the README to hopefully make it more readable.
---
 README.md | 103 +++++++++++++++++++++++++++-----------------------------------
 1 file changed, 45 insertions(+), 58 deletions(-)

diff --git a/README.md b/README.md
index e979b7c..69dde95 100644
--- a/README.md
+++ b/README.md
@@ -5,52 +5,49 @@ sha1
 Verilog implementation of the SHA-1 cryptgraphic hash function. The
 functionality follows the specification in NIST FIPS 180-4.
 
-This core is based on the project at:
-https://github.com/secworks/sha1
-
-The implementation is iterative with one cycle/round. The initialization
-takses one cycle. The W memory is based around a sliding window of 16
-32-bit registers that are updated in sync with the round processing. The
-total latency/message block is 82 cycles.
-
-There are top level wrappers that provides interface for easy
-integration into a System on Chip (SoC). This interface contains mesage
-block and digest registers to allow a host to load the next block while
-the current block is being processed.
+The sha1 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](http://iverilog.icarus.com/).
+
+The actual core consists of the following RTL files:
+ - sha1.v
+ - sha1_core.v
+ - sha1_w_mem.v
+
+The main core functionality is in the sha1_core file. The file
+sha1_w_mem contains the message block memory W (see FIPS 180-4).
+The top level entity is called sha1_core. The sha1_core module has wide
+interfaces (512 bit block input, 160 bit digest). In order to make it
+usable you probably want to wrap the core with a bus interface.
 
-The implementation also includes a functional model written in Python.
+The file sha1.v contains a top level wrapper that provides a simple
+interface with 32-bit data access . This interface contains mesage block
+and digest registers to allow a host to load the next block while the
+current block is being processed.
 
 
 ## Implementation details ##
+The implementation is iterative with one cycle/round. The initialization
+takes one cycle. The W memory is based around a sliding window of 16
+32-bit registers that are updated in sync with the round processing. The
+total latency/message block is 82 cycles.
 
-The sha1 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](http://iverilog.icarus.com/)
-
-The actual core consists of the following files:
-- sha1_core.v - The core itself with wide interfaces.
-- sha1_w_mem.v - W message block memort and expansion logic.
-- sha1_k_constants.v - K constants ROM memory.
-
-The top level entity is called sha1_core. This entity has wide
-interfaces (512 bit block input, 160 bit digest). In order to make it
-usable you probably want to wrap the core with a bus interface.
+All registers have asynchronous reset.
 
-Unless you want to provide your own interface you therefore also need to
-select one top level wrapper. There are two wrappers provided:
-- sha1.v - A wrapper with a 32-bit memory like interface.
-- wb_sha1.v - A wrapper that implements a [Wishbone](http://opencores.org/opencores,wishbone) interface.
+The design has been implemented and tested on TerasIC DE0-Nano and C5G
+FPGA boards.
 
-***Do not include both wrappers in the same project.***
 
-The core (sha1_core) will sample all data inputs when given the init
-or next signal. the wrappers provided contains additional data
-registers. This allows you to load a new block while the core is
-processing the previous block.
+## Status ##
+The design has been implemented and extensively been tested on TerasIC
+DE0-Nano and C5G FPGA boards. The core has also been tested using SW
+running on The Novena CPU talking to the core in the Xilinx Spartan-6
+FPGA.
 
 
 ## FPGA-results ##
@@ -77,26 +74,16 @@ Implementation results using Altera Quartus-II 13.1.
 - 104 MHz
 
 
-## TODO ##
-* Extensive functional verification in real HW.
-* Add Wishbone interface.
-* Add results for Xilinx and possibly some other FPGA device.
-* Documentation
-
-
-## Status ##
-***(2013-02-25)***
+### Xilinx FPGAs ###
+Implementation results using ISE 14.7.
 
-Updated README with some more information about the design.
+** Xilinx Spartan-6 **
+- xc6slx45-3csg324
+- 1589 LUTs
+- 564 Slices
+- 1592 regs
+- 100 MHz
 
 
-***(2014-02-23):***
-
-New version of the W memory module that quite drastically improves
-resource utilization. And a bit better performance too. Also added some
-new results for other Altera devices.
-
-
-***(2014-02-21):***
-
-Moved the core to Cryptech.
+## TODO ##
+* Documentation



More information about the Commits mailing list