blob: ad8749e7cdff65ea9edfa9fd8be7bc2d793b971f (
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
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
{{{
#!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>coretest</h1>
<p>Test platform for the <a href="https://cryptech.is/">Cryptech Open HSM project</a>.</p>
<p>(_Note:The Cryptech certificate is by choice not from a CA and therefore
not in your brower trust store._)</p>
<h2>Description</h2>
<p>This platform and hardware design is used to functionally verfiy cores
developed in the Cryptech Open HSM project. The test core itself
contains just enough functionality to be able to verify that the SW in
the host computer can talk to the core in the FPGA by reading and
writing 32 bit data words to given addresses.</p>
<p>This project includes cores in Verilog, a testbench as well as host SW
to talk to the core.</p>
<h2>Architecture</h2>
<p>The coretest consists of three state machines:</p>
<h3>rx_engine</h3>
<p>Handles receiving command messages from the host. Awaits SYN signals from
the host interface and reads bytes when SYN is asserted. For each byte
the rx_engine assetts and ACK and waits for the SYN to be asserted. When
a EOC byte has been detected the rx_engine signals the test_engine that
there is a new command available in the rx_buffer.</p>
<h3>tx_engine</h3>
<p>Handles transmitting response messages to the host. When the test_engine
signals that there is a new response in the tx_buffer the tx_engine will
start transmitting all bytes up to and including the EOR byte it is
expecting in the tx_buffer. The transmission is done by asserting SYN
awaiting ACK, deasserting SYN and moving to the next byte before
asserting SYN again. This process is repeated until all bytes has been
transmitted.</p>
<h3>test_engine</h3>
<p>Performs the parsing of commands from the host. Known read or write
commands are used to test the core to be tested. The response from the
core is collected and the appropriate response is stored in the
tx_buffer. The test_engine then signals the tx_engine that there is a
new response message to be transmitted.</p>
<h2>Interfaces</h2>
<p>The host communication interface is a byte wide data interface with
SYN-ACK handshake for each byte.</p>
<p>The interface to the core to be tested is a memory like
interface with chip select and write enable. The data width is 32-bits
and the address is 16-bits.</p>
<h2>Core under test</h2>
<p>The core under test is expected to have a simple memory like interface
with chip select (cs), write enable (we) signal ports, 16-bit address
port and separate 32-bit data ports for read and write data. The core is
also expected to have an error signal port that informs the master if
any read or write commands given cannot be performed by the core.</p>
<p><strong><em>Note:</em></strong>
The core reset signal is expected to by active high. The
core reset signal should be connected to the coretest core_reset
port, not to system reset.</p>
<h2>Protocol</h2>
<p>Coretest uses a simple command-response protocol to allow a host to
control the test functionality.</p>
<p>The command messages are sent as a sequence of bytes with a command byte
followed by zero or more arguments. The response consists of a response
code byte followed by zero or more data fields.</p>
<p>The start of a command is signalled by a Start of Command (SOC)
byte. The end of a command is signalled by a End of Command (EOC)
byte. These bytes are:</p>
<ul>
<li>SOC: 0x55</li>
<li>EOC: 0xaa</li>
</ul>
<p>The start of a response is signalled by a Start of Response (SOR)
byte. The end of a response is signalled by a End of Respons (EOC)
byte. These bytes are:</p>
<ul>
<li>SOR: 0xaa</li>
<li>EOR: 0x55</li>
</ul>
<p><strong><em>The commands accepted are:</em></strong>
- RESET_CMD. Reset the core being tested. Message length is 3 bytes
including SOC and EOC.
- SOC
- 0x01 opcode
- EOC</p>
<ul>
<li><p>READ_CMD. Read a 32-bit data word from a given address. Message
length is 5 bytes including SOC and EOC.</p>
<ul>
<li>SOC</li>
<li>0x10 opcode</li>
<li>16-bit address in MSB format</li>
<li>EOC</li>
</ul></li>
<li><p>WRITE_CMD. Write a given data word to a given address. Message
length is 9 bytes including SOC and EOC.</p>
<ul>
<li>SOC</li>
<li>0x11 opcode</li>
<li>16-bit address in MSB format</li>
<li>32-bit data in MSB format</li>
<li>EOC</li>
</ul></li>
</ul>
<p><strong><em>The possible responses are:</em></strong>
- UNKNOWN. Unknown command received. Message length is 4 bytes
including SOR and EOR.
- SOR
- 0xfe response code
- Received command
- EOR</p>
<ul>
<li><p>ERROR. Known but unsuccessful command as signalled by the
core. Caused for example by a write command to read only
register. Message length is 4 bytes including SOR and EOR.</p>
<ul>
<li>SOR</li>
<li>0xfd response code</li>
<li>command received</li>
<li>EOR</li>
</ul></li>
<li><p>READ_OK. Sent after successful read operation. Message length is 9
bytes including SOR and EOR .</p>
<ul>
<li>SOR</li>
<li>0x7f response code</li>
<li>16-bit address in MSB format</li>
<li>32-bit data in MSB format</li>
<li>EOR</li>
</ul></li>
<li><p>WRITE_OK. Sent after successful write operation. Message length is 5
bytes including SOR and EOR </p>
<ul>
<li>SOR</li>
<li>0x7e response code</li>
<li>16-bit address in MSB format</li>
<li>EOR</li>
</ul></li>
<li><p>RESET_OK. Sent after successful reset operation. Message length is 3
bytes including SOR and EOR.</p>
<ul>
<li>SOR</li>
<li>0x7d response code</li>
<li>EOR</li>
</ul></li>
</ul>
<h2>Status</h2>
<p><strong><em>(2014-02-11):</em></strong></p>
<p>Added information about the architecture and protocols. Updated the
command and response with explicit read and write ok responses. Some
cleanup of the description.</p>
<p>Completed first draft of the RTL for coretest. The RTL is not debugged
and has not been synthesized. We need to add a testbench and a simple
test core.</p>
<p>Added a simple test core.
Adding initial version of UART core that will be used for the host
interface.</p>
<p><strong><em>(2014-02-10):</em></strong></p>
<p>Initial version of the project. Based on previous cttest project but
renamed and with new (ideas) about the test architecture. Specified
command and response protocol.</p>
}}}
[[RepositoryIndex(format=table,glob=core/comm/coretest)]]
|| Clone `https://git.cryptech.is/core/comm/coretest.git` ||
|
