Information about the sources

Copyright

All files are copyrighted to the ETH Zurich, and can be freely used for research and educational purposes as long as the Integrated Systems Laboratory (IIS) of ETH Zurich is credited as the source.

These files are provided as is, no warranty whatsoever for any of these files is given.

Directory structure

We have a design flow dictated by an inhouse-script called cockpit. For each design a set of subdirectories are created. For each design tool a separate directory will be created. Below is an (abbreviated) list of directories as created by this tool. Our source distribution includes only the sourcecodes and not any technology specific data. Furthermore, we have not included some back-end/test related data.

|-- encounter       : Placement and Routing tool
|   |-- scripts     : TCL scripts for encounter
|   |-- src         : Source files for the encounter flow
|   '-- tech        : Technology libraries (NOT INCLUDED)
|-- gm              : Contains the golden model, used to generate test vectors
|-- modelsim        : Main directory for simulation 
|-- simvectors      : Testbenches expect test vectors in this directory
|-- sourcecode      : COmplete VHDL sourcecode
'-- synopsys        : Synopsys working directory
    `-- scripts     : TCL scripts for synopsys 

Naming Conventions

Simulation and Testvectors

We use a golden model based functional verification method. A golden model (written in C, matlab, perl, java) is used to generate the stimulus vectors for the simulation and the expected responses to these vectors. The golden model is usually situated under the directory gm. The generated stimuli and expected response files are copied to the simvectors directory.

Within the sourcecode directory there are (usually) three files responsible for the simulation. The first simulstuff.vhd provides some generic functions that are used by the testbech. There is a customized package (usually) suffixed with tbpkg.vhd that contains type definitions, vector file names and constants used in the simulation. Please note that depending on the type of simulation (RTL, gate-level etc) changes may need to be made to the timing constants (depends mainly on the timing scale used). The actual testbench is (usually) in a file suffixed by tb.vhd. This file instantiates the top level design, a clock generator, and applies signals until the vectors in the files have been exhausted. (Almost) all testbenches write the simulation result in a text file in the simvectors directory.

To simulate the design, change to the modelsim directory, compile the design (RTL or gate-level) with an appropriate script (there are usually usable scripts in the distribution), and start vsim. In most cases, a run -all should be sufficient to simulate the design.

Design Decisions

We tried to implement all 14 SHA-3 2nd round candidates in hardware. We do not claim that all these implementations are ideal, there are certainly possible simplifications that we have missed, or we may have made unintentional mistakes. We believ by publishing the sourcecode for the entire project, we may contribute to the effort in a fair evaluation of all the SHA-3 candidates.

We have decided to set real constraints on all implementations. Rather than having a single specification we have a high-throughput specification of 20 Gbits/s and a small specification of 0.2 Gbits/s. For some of the algorithms we were able to come up with two different architectures for both design corners, in others we made changes to the synthesis scripts only. Usually the suffix _small is added to the sourcecode or to the scripts dealing with these files.

No salt inputs have been used. Algorithms that support this have been given default values.

For the throughput calculations the largest message block size available has been used. In some cases, the algorithms have not been designed to include all message options, due to time reasons

The message digest size has been fixed as 256. Some algorithms as they are implemented may need further modifications to support other message digest sizes.

An ideal interface has been assumed. In this idealized interface all inputs to the circuit are assumed to be present in parallel. Similarly we assume that all output bits can be sampled at once. For a standalone chip this would be impractical, as many algorithms require 100s of connections. In this case an input/output buffer would have to be used.

Technology Information

All data was compiled using UMC90nm technology to which we had access through the Europractice-IC service at IMEC.

Standard Cell libraries were obtained through Faraday. We have used the 1.2V characterized libraries for fsd0a_a_2009Q2v2.0 throoughout our evaluation.

We have used the following tools in our design flow:

• Mentor Modelsim 6.5a Simulator
• Synopsys Design Compiler version 2008.09
• Cadence Design Systems SoC Encounter version 8.1.4