To run the Maia testbench under ModelSim:

1 > setenv RTV_SIMULATOR modelsim
2 > rtv des_kats.tv -f cmdfile

To run the Maia testbench under Icarus:

3 > setenv RTV_SIMULATOR icarus
4 > rtv des_kats.tv -c cmdfile

To run the Verilog testbench under ModelSim:

5 > ./modelsim.bat

To run the Verilog testbench under Icarus:

6 > ./icarus.bat

The time to run the testbench should be approximately the same for the Maia
and Verilog versions. For Icarus on an Intel Core-2 Duo 6600, 2.4GHz, the
output of the 'time' command is:

Maia version (des_kats.tv):
287.554u 0.154s 4:47.82 99.9%	0+0k 0+0io 0pf+0w

Verilog version (des_kats.v):
289.766u 0.079s 4:49.89 99.9%	0+0k 0+0io 0pf+0w

===============================================================================

The code in this directory carries out the known answer tests defined in FIPS
800-20, for both encryption and decryption, for both CBC and ECB modes. These
tests exhaustively verify the main blocks of the 3DES hardware: the initial
permutation, the expansion permutation, the inverse permutation, the key
permutation, the key shifts, the P-box, and the S-boxes.

The 800-20 known answer tests do not attempt to check any of the higher-level
3DES functionality. The problems include:

1)   all 3 keys are the same for all tests
2)   all IV's are zero for all tests
3)   no CBC blocks are tested: the CBC and the ECB tests are identical

The test carried out are:

1)   the variable plaintext known answer test
2)   the variable key known answer test
3)   the permutation operation known answer test
4)   the substitution table known answer test

The inverse permutation, variable ciphertext, and initial permutation tests
are not carried out, since they are automatically included when the above
tests are run for both encryption and decryption. All data in the 800-20
appendices is used in the implemented tests.

The four tests are run in sequence. Within each test, four subtests are
carried out, for CBC encrypt, CBC decrypt, ECB encrypt, and ECB decrypt. A
message is displayed on stdout at the end of the each test giving the number
of passed and failed tests. If a test fails, the test details will also be
displayed.

The ECB tests are pretty much pointless, since the FIPS vectors don't actually
use the feedback mode (they're all for a single pass through the 3DES
hardware). However, The doc specifies that the test should be done.

FIPS 800-20 specifies that, for hardware that does both encryption and
decryption, the results of the encryption test should be saved and used as the
ciphertext input for the decryption test. I don't do this, since there's no
point saving a bad result and then using the bad result as a ciphertext
input. Instead, I check the encryption result against the expected data, and
then use the expected data as the input to the decryption test, which has
exactly the same effect. This is what FIPS expects for hardware that does
decryption only. In other words, this test can be viewed as a compliant test
for encryption-only hardware, followed by a compliant test for decryption-only
hardware. But, as I said, the difference is completely irrelevant.

The test doesn't quite run at full UUT speed. In principle, DAV_H for a data
register load can be asserted in the cycle after DRDY_H is detected, to give
full speed operation (currently, 92 cycles). However, all three keys and the
initialisation vector are also loaded in the tests below, which takes an extra
4 cycles.