blob: 5892619ce03e8daf45dafe4295aa3a73632d2c0c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
{{{
#!htmlcomment
This page is maintained automatically by a script. Don't modify this page by hand,
your changes will just be overwritten the next time the script runs. Talk to your
Friendly Neighborhood Repository Maintainer if you need to change something here.
}}}
{{{
#!html
<h1>sha256</h1>
<p>Hardware implementation of the SHA-256 cryptographic hash function. The
implementation is written in Verilog 2001 compliant code. The
implementation includes a core and a wrapper that provides a 32-bit
interface for simple integration. There is also an alternative wrapper
that implements a Wishbone compliant interface.</p>
<p>This is a low area implementation that iterates over the rounds but
there is no sharing of operations such as adders.</p>
<p>The hardware implementation is complemented by a functional model
written in Python.</p>
<h2>Implementation details</h2>
<p>The sha256 is divided into the following sections.</p>
<ul>
<li>src/rtl - RTL source files</li>
<li>src/tb - Testbenches for the RTL files</li>
<li>src/model/python - Functional model written in python</li>
<li>doc - documentation (currently not done.)</li>
<li>toolruns - Where tools are supposed to be run. Includes a Makefile for
building and simulating the design using <a href="http://iverilog.icarus.com/">Icarus Verilog</a></li>
</ul>
<p>The actual core consists of the following files:</p>
<ul>
<li>sha256_core.v - The core itself with wide interfaces.</li>
<li>sha256_w_mem.v - W message block memort and expansion logic.</li>
<li>sha256_k_constants.v - K constants ROM memory.</li>
</ul>
<p>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.</p>
<p>Unless you want to provide your own interface you therefore also need to
select one top level wrapper. There are two wrappers provided:</p>
<ul>
<li>sha256.v - A wrapper with a 32-bit memory like interface.</li>
<li>wb_sha256.v - A wrapper that implements a <a href="http://opencores.org/opencores,wishbone">Wishbone</a> interface.</li>
</ul>
<p><strong><em>Do not include both wrappers in the same project.</em></strong></p>
<p>The core (sha256_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.</p>
<p>The W-memory scheduler is based on 16 32-bit registers. Thee registers
are loaded with the current block. After 16 rounds the contents of the
registers slide through the registers r5..r0 while the new W word is
inserted at r15 as well as being returned to the core.</p>
<h2>FPGA-results</h2>
<h3>Altera Cyclone FPGAs</h3>
<p>Implementation results using Altera Quartus-II 13.1.</p>
<p><strong><em>Cyclone IV E</em></strong></p>
<ul>
<li>EP4CE6F17C6</li>
<li>3882 LEs</li>
<li>1813 registers</li>
<li>74 MHz</li>
<li>66 cycles latency</li>
</ul>
<p><strong><em>Cyclone IV GX</em></strong></p>
<ul>
<li>EP4CGX22CF19C6</li>
<li>3773 LEs</li>
<li>1813 registers</li>
<li>76 MHz</li>
<li>66 cycles latency</li>
</ul>
<p><strong><em>Cyclone V</em></strong></p>
<ul>
<li>5CGXFC7C7F23C8</li>
<li>1469 ALMs</li>
<li>1813 registers</li>
<li>79 MHz</li>
<li>66 cycles latency</li>
</ul>
<h3>Xilinx Artix-7 FPGAs</h3>
<p>Implementation results using Xilinx ISE 14.7
This implementation includes pipeline regsisters.</p>
<ul>
<li>xc7a200t-1fbg484</li>
<li>2229 Slice LUTs</li>
<li>775 Slices</li>
<li>1935 registers</li>
<li>101 MHz</li>
<li>130 cycles latency</li>
</ul>
<h2>TODO</h2>
<ul>
<li>Extensive verification in physical device.</li>
<li>Complete documentation.</li>
</ul>
<h2>Status</h2>
<p><strong><em>(2016-05-31)</em></strong></p>
<p>The core now supports both sha224 and sha256 modes. The default mode is
sha256.</p>
<p>NOTE: 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.</p>
<p>The API version has been bumped a major number to reflect this change.</p>
<p>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.</p>
<p><strong><em>(2013-02-23)</em></strong></p>
<p>Cleanup, more results etc. Move all wmem update logic to a separate
process for a cleaner code.</p>
<p><strong>(2014-02-22)</strong></p>
<p>Redesigned the W-memory into a sliding window solution. This not only
removed 48 32-registers but also several muxes and address decoders.</p>
<p>The old implementation resources and performance:</p>
<ul>
<li>9587 LEs</li>
<li>3349 registers</li>
<li>73 MHz</li>
<li>66 cycles latency</li>
</ul>
<p>The new implementation resources and performance:</p>
<ul>
<li>3765 LEs</li>
<li>1813 registers</li>
<li>76 MHz</li>
<li>66 cycles latency</li>
</ul>
<p><strong>(2014-02-19)</strong>
- The core has been added to the Cryptech repo. The core comes from
https://github.com/secworks/sha256</p>
}}}
[[RepositoryIndex(format=table,glob=core/hash/sha256)]]
|| Clone `https://git.cryptech.is/core/hash/sha256.git` ||
|
