1 files changed, 211 insertions, 0 deletions
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fcoretest b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fcoretest
new file mode 100644
index 0000000..ad8749e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fcoretest
@@ -0,0 +1,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` ||