kinap / aes-processor Goto Github PK

Change the way the key expansion module works and the interface to the top level encoder and decoder so that the key expansion module includes the buffering of the round keys and then is responsible for sending the appropriate round key during the correct cycle to the top level modules. The interface between the top level and key expansion would be an array of round key signals, 1 for each round delayed the appropriate number of clock cycles inside the key expansion module.

Add additional information to the final paper, this should cover at least the following:

1. Add more AES background.
2. Add background on bottom-to-top verification strategy.
3. Clean up grammar/misspellings and figure/reference mis-numbering.
4. Explain charts/graphs better.

Enable Questa simulation profiling and use it with a veloce run to see where the software execution time is being sent. Should be able to identify the bottlenecks by looking at this report.

The HVL/transactor have definitely changed. Might need to update based on the instantiation time parameters too.

Modify the make file to run the top level testbench once now that it contains 128, 192, and 256bit key encoders and decoders.

Modify make file for other testbenches as necessary.

Issues #11 and #12 need to be resolved first.

Currently, we produce all of the rounds keys upfront and then buffer them between each round. Not all round keys need to be generated upfront and some of them can be delayed until later clock cycles. In addition to improving the number of operations occurring in one clock cycle, this would also improve the amount of data that needs to be buffered.

Create our Need For Speed Competition Proposal and submit by July 6th.

We are only using the valid bit in the submodules for an assertion. It isn't doing anything for the design once it's synthesized.

We have two options:

1. Remove it
2. Block off all instances of it's propagation through submodules through #ifdefs that will remove it for synthesis, but keep it for simulation/emulation

I would prefer option 1 to clean it up, and it has debatable value even in simulation - if there is invalid input to a submodule, we will see invalid input for at least one clock cycle, which will be detected by our test bench at the top level.

Add assertions that check that the input isn't equivalent to the output of the encoder/decoder and vice versa for the seeded tests that don't directly test the validity of the intermediate data.

Investigate how to transfer data to the emulator using other methods than SCEMI-Pipes. Suggested alternative is One-Way Callers (OWC).

Some commented out code related to file input needs to be removed.

Currently we use only the plain text data to run through the encoder -> decoder and verify the output of the decoder matches the input of the encoder. This task is to add an instantiation of the decoder -> encoder and use the encrypted data as input to these instantiations. In this case we verify the input of the decoder matches the output of the encoder.

In the Transactor add an instance of the decoder and encoder hooked up so that encrypted data is decoded and then encoded. Also add an assertion to check this. This will increase the computational burden on the emulator and will allow for better test coverage when doing "seeded" testing.

This depends on resolving issue #11 first.

Currently a round key for each round is buffered after each round and kept around until the last round. This needs to be improved because prior round's round keys aren't needed any longer and no longer need to be buffered.

According to the Veloce Assertions User's Guide, the first step to enabling assertions on the emulator is to setup "0-in" and add additional command line and veloce.config file.

Try running Mentor provided examples.

Currently we support compilation time support for choosing between the 3 different AES configurations. Change this to be an instantiation parameter that controls what AES configuration a particular AES encoder and decoder instantiation is using. This is a necessary step to allow for parallel testing of the 3 AES configurations.

Add capabilities to the transactor and the HVL test bench to support a single "testcase" sent to the emulator to be utilized as the base test case for creating many test cases on the emulator. This will decrease communication overhead and increase the amount of computation to be done on the emulator for a particular test case.

Resolve #14 and #15 first.

Instantiate all 3 AES encoders and decoders in the same test bench in parallel.

In the AESTestDefninitions.sv file there a several places in the test classes where we declare signals of explicit width were we could instead use the typedefs. Fix these.

We currently only have a Veloce-based testbench for the top level-modules.

Debugging top-level issues will be easier if we have a testbench that excludes the scemi pipe and veloce complexities. We should also add a "standalone" mode to the makefile that compiles without any of the veloce dependencies.

Options:

1. commit libtomcrypt.a and headers and build against them
2. provide script to checkout libtomcrypt

Add test cases that are purposefully incorrect in order to test that the assertions are firing correctly.

To accommodate the vector permutation scheme designed to improve emulation efficiency, the generator should produce data in the following format:

<128 bit state block (input data)><256-bit key><128 cipher text><192 cipher text><256 cipher text>

The key will be subdivided into smaller key sizes using the appropriate number of least significant bytes.

Our project doesn't have many opportunities for assertion use without reimplementing the AES algorithm in SV assertion language, but we can at least make sure we don't have any unknowns in our design.

Each module should have a !$isunknown on all inputs.

The valid signals go high at the appropriate clock cycle in the xactor, but the testOut structure doesn't have room for them. The top level test bench I don't think ever receives these values (they're always 0, not x, which is curious).

I was also seeing X's for expected data in the top level, but I didn't debug that enough to have confidence that it's not an artifact of another issue.

@pear7

Change the transactor to use assertions in the transactor to validate that the output of the encoder and decoder are correct instead of sending the data back to the hvl testbench.

Update the HVL testbench to do 2 rounds of tests, first do directed tests, and then do seeded tests.

Investigate additional SCEMI Pipes options to see if there are opportunities to improve the performance of the data transfer and consumption.